 share. Yes, I think the permission is already there. It just says one only one participant can share at the same time. But yeah, I'm going to share it and then we have one presentation so that we can drive through the whole presentation through the one set of slides one deck. Do you see that? Yes. Okay, that's good. There's a lot of anticipation and positive feedback about this. So hopefully we'll have more of the regular financial market participants who are always skeptical about blockchain. But they are in a hole because they cannot take care of many of the problems that they've encountered over the over the years without this technology. And they don't realize it yet. But they're going to have to come to the table in some way or form. You can only shine the light on the problem and then show the solutions. So it's going to take time. All right, so I'm going to say that we have to get through a couple of administrative administrative things. One is the Hyperledger antitrust policy. So we are bound by the Hyperledger antitrust policy, which means that we have to obey the antitrust laws of wherever we are, including those of the United States if you are from the United States, but any other country where you might be joining from since we are a global segment. The other item is the fact that we have to be nice to each other, which means you can disagree with people without being disagreeable. I'm sure that money has heard this thousands of times, if not hundreds. Anyway, so the point is that anybody is welcome to participate and of course, give respect to the presenters, but also question them about things that you do not understand or you object to. So these are the two things we have to really take care of. The few other things, right? One, I'm going to introduce money and have him go through introducing his collaborators. I have no money for a while. I have interacted with him. I have we have launched a couple of labs in Hyperledger and we have written a paper on CVDCs together, which takes care of one of the important payment legs and for which he had come up with this dual blockchain structure. One is to take care of the contracts. The other is to take care of the cash flows, which is also a blockchain structure in CDM. So without waiting further, let's have money take us on a journey on what he has been working on for the past few years. And thank you, money, for showing up. And I shall disappear into the woodwork, which is where I belong right now. Thank you. All right. Okay. Hello, everyone. Thank you all for joining us today in this presentation. An exciting one to talk about in our journey to bring in zero knowledge proof and confidential assets into enterprise digital assets framework. So we're going to tackle this thing in three segments. I'm going to give a quick introduction and outline the current status of enterprise blockchain and how we arrived at where we are. The second part would be covered by the PolyMesh team. I thank Adam, Amir, Robert, and others who are joining today. So they would take us through the zero knowledge proof and how PolyMesh implemented it. And then, you know, towards the end, I would again cover how we are applying PolyMesh along with the OTC digital asset framework. So, you know, let's jump into it. And, you know, this brief introduction, we started off working together with PolyMesh almost four years back when they first announced their public blockchain. And that was purpose built for digital assets with, you know, specifically security tokens and committing with all the compliance requirements with respect to digital identifiers, security, life cycle, and then, you know, Adam can go through his presentation. Along the way, we also compared ourselves to see how we, you know, I mean, we explored options to see how would you, how we would use enterprise or Ethereum based solutions. And one of the things that was what we did about three years back, we through the labs, we brought in ERC 1155 token and then we open sourced it. And it was adapted for carbon credit and other potentially other areas within hyper legend. And we continued our journey and, you know, and we did based upon our proof of concepts with banks and exchanges. One thing came very clear that privacy became very critical. And so, hence, we, you know, we started working with PolyMesh and they already had a framework to work with zero knowledge proofs a few years back. So, I would say less than two years back, we started this journey. And now we have in a situation where we have integrated and we are ready to, you know, launch this product working with PolyMesh. So, let's be going to the, you know, some background. This is largely to address regulations in enterprise digital assets. Regulations are key. So, the first thing to look at is the BIS, which is the Bank for International Settlements. So, they classify into two sections tokenized traditional assets into group A and, you know, and then sort of group one A and one B. And the way they look at it as to say is if these assets behave exactly as it is being currently processed and conducted in the paper base or traditional asset framework, they will be giving the same treatment with respect to capital allocation and, you know, reserves for the banks. If they do not meet that, they fall into group two, which is very punitive in nature in terms of reserves and risk-weighted assets. I mean, there's a whole bunch of calculations that go behind it. Enough to say that almost all cryptos fall into the group two, which means banks will have to put 100% or even more than 100% of the actual dollar amount using their own capital, which no bank is going to be willing to do compared to, you know, very small amount in single digits for, you know, group one assets. That plays a significant part as to what kind of an infrastructure you're going to deploy for, you know, real-world assets to be fully compliant. The other part of it, that's where the PIS addresses in multiple forms. One is, as I said, the groups and then how do they arrive at by looking at the network interoperability. That's one of their criteria. And they recently came back in December 2023. They came back with a clear indication that no permissionless networks for group one. The reason being that they felt that the banks would not be able to do KYC and all sorts of third-party processors. So just to give a quick glimpse into what that means, and here is the December 23, you know, their amendments to what they have previously described for group one assets. As you can see, I just highlighted the section where they clearly see that since banks have limited ability to conduct due diligence and oversight, what they are saying is they decided that they will not be including crypto assets into group one, which means it's a very punitive for banks to process crypto assets. Whether it is crypto assets, as we talk about the Bitcoins and the Ethereums of the world, or even traditional assets, that do not meet these requirements. In addition, we also have custody requirements from these other agencies that wants to demonstrate control of the asset. This is primarily targeted towards custodians and you want transfer guarantee to the right party, which means there's no unilateral transfer. That means both sender and receiver must acknowledge on-chain to guarantee that the transfer is complete and final. So this puts a lot of burden on what kind of infrastructure you choose and how you would go about implementing your digital assets for real-world assets. I'll jump on to the next one. Again, to go further into details, one of the things that BIS specifies for bonds, loans, or basically any claims on banks, they say it's the same level of, I'll just underline for clarity, same level of legal rights as ownership of these traditional forms. And also they want to avoid any obligations not being, not able to fulfill obligations for the banks if they have to be paid in full as opposed to the traditional version. So essentially they want same rights, same obligations to be conducted fairly from both the traditional form as well as the digital form. The other interesting thing, which is important now, is they specify commodities and say same level of legal rights as traditional account-based records of ownership. Look at the differences. They don't talk about ownership in different sense of legal rights for bonds because security is processing, where you could use IOUs of claims on banks, whereas commodities, it's actually must reflect records of ownership. As you could see, I would give an example of why this is critical for enterprise chains. So I just want to quickly refer to a background of what we see is in the evolution of the blockchain. This is our classification and no particular scientific mechanism by which we chose this. We know about Bitcoin and then we have the Ethereum that came in with World Computer and one of those things came up with the smart contracts. We all know about this. I won't go into details, but something that's important is the cap table is not encrypted, which means there's no privacy and enterprise market participants, particularly banks, hedge funds do not want to reveal their positions on chain. Explain what a cap table is to those of us who are not sophisticated. That's just simply the ownership table for the various stakeholders in that particular token. This is something that shows in Ethereum world it is nothing but your wallet public wallet address and the corresponding token and the amount you hold. That means anyone can inspect the Ethereum chain and look at the cap table and can determine who owns what because the keys themselves are pseudo-anonymous. That means through other mechanism they can track your true identity. That means from through off-chain mechanism and on-chain mechanism, they can eventually narrow down to who's holding what. That's something the banks will not, particularly no market participant in enterprise would want to reveal to their competitors. To answer that, I call them a third generation, the enterprise chains came up. These are built specifically on the model of IOU or claim on issuer model. It primarily puts stress on participants and also the way it works is that is information is shared only between parties that are out of interest. Unlike in a blockchain, every information is broadcast to all other nodes. Here only specific need nodes communicate. So while it does address privacy, but it does kind of bring back centralized cap table. That means typically an issuer or a transfer agent holds the whole cap table and all other market participants depend. That's why I call them trust in participants. So essentially it leads to pseudo-privacy and I'll explain what that means. And again, there's another question about qualified custody and then this also have further issues about global custody. As you could see that there's a lot more stress on the public chains to bring in zero knowledge proofs and a whole host of solutions are happening here. But as you could see here, pretty much most of the work are all on permissionless networks, which means according to BIS none of them would be, the public chains would qualify for group one assets, which means bank cannot directly use them for on a large scale to support real-world assets. So that means you're coming back to permission networks. And sensing this way is where Polymesh had taken this and come up with a Polymesh private, but the definition Polymesh itself is public, but it is permissioned. So this is not a question of private or public, but it's more of permission. So that's where Adam can go in more detail in a couple of slides. The main important thing is that it's purpose-built, purpose-built for financial markets. They introduce the confidential assets and you have granular key management, which is lacking in the third generation enterprise solutions. Let me jump into an exact example of what's lacking in the third generation and how it's being solved. So if you look at the way the third generation, which is typically you can categorize corridor tokenization in our dam or ledgers broadly into this category, they all depend upon IOU or play model. You typically an issuer would issue the tokens and then they would distribute to institutional investors or whoever. I generally put a name of custodian, but it could be anyone who is authorized to hold custody of the tokens. It could be called as a custodian here. What's important this is that is the issuer or the transfer agent is holding that cap table. It is encrypted, but it's centralized. And the custodians do not really have direct control of the asset, rather they have a digital receipts. That's why I call them as a pseudo-custody to the assets in the cap tables. Now, the quick question comes up is, for example, if the issuer issued gold, it is equivalent to saying that they actually hold the gold under their custody on what you're getting is only a digital receipt. So one of the interesting question comes up, what happens if that issuer temporarily goes down and if custodians want to exchange assets, they can't. You wouldn't really need that issuer or transfer agent to be always be present to process any transfers between any two parties and that's where centralized symptoms in the picture. Also, in case of bankruptcy, this is a very important question here. Yeah, I mean, there are many, many drawbacks to this model, but to mimic, to be fair, to mimic what they are doing today in securities processing is essentially transferred in today holding that cap table in paper form or in pseudo-electronic form and settlements happen and then transfer agent applies today in current world. So in that sense, what they're doing is we are mimicking existing world, so we are compatible. But the big difference is this in today's world, it all happens in a more of an end-of-day batch mode, whereas once you move into the blockchain world, this is real-time. That means real-time everyone is, the cap table is getting updated, which means the stress on the transfer agent is even more, or the issuer of the transfer agent is even more prominent as opposed to traditional model. So there are technology risks, a potential, what if this gets hacked or if it goes offline, the whole market could get shut down because of that. So that's the problem. Now, the solution is to have a blockchain, which is where the cap table is decentralized, but also encrypted, and that was a challenge that could be solved through zero-knowledge proof, and you know, we'll hear from Pauli Williams shortly, but this does solve the problem. As you can see an example here, the goal is issued and it is transferred to the custodian. The custodians hold the actual equivalent digital assets under the custody for various customers using different key sets. So that's even important, which is not even possible in here. This is almost like everything is all mixed up together. You just have one set of keys here, whereas here you have separate keys for each account. So it gives you a much more robust infrastructure and it gives you the ability to decentralize, so which means there are no single point of failures here as opposed to here. Any questions? Don't hesitate to ask. If I could, when you refer to decentralized identity here, what does that mean and how does it relate to the cap table? Maybe Adam quickly does that, because it's much more important from Polymesh's side. Yeah, I can do. So the way Polymesh works is that it's a permissioned network, as Manny sort of implied. When you're onboarded onto the network, whether you're an individual or an entity or a company or a business, you receive an on-chain identity that's sort of referenced or named via a DID or a decentralized identifier. So you can think of your decentralized identity as being your sort of pseudo-anonymous name on chain and it's an issue to you as part of the commissioned onboarding process for Polymesh. Does that answer the question? Yeah, and I guess given where we're at, the BIS considers this sufficient for mitigation and KYC risks. So in terms of the way the onboarding works in Polymesh, every user of Polymesh goes through an identity verification process, which establishes some sort of basic facts, I'll tell you from a sanctioned country or not and so on. Every user of the chain has to go through that identity verification process in order to be issued one of these on-chain identities or decentralized identities. In terms of KYC for a specific asset, those rules or conditions are driven by the asset issuer. So the asset issuer will almost certainly require additional forms of KYC that are specific to their asset or regulatory perimeter and so on. But that's all entirely driven by each individual asset issuer. So the chain has a kind of global or chain-level identity verification process, but individual asset issuers are still expected to have additional KYC requirements or KYC, KYB, AML, etc. requirements that are specific to their particular asset and jurisdiction. Just to add to more to it, yes, we do have a layer to address that specific question of control, who sees what, and that means an issuer can, for example, we use Coda as a layer to not for tokenization, but as a messaging platform where the asset issuer can define what the KYC requirements are and they're only going to interact with those that meet their requirements. So this is a layer two solution that we have added on on top of this so that you really have, you know, be fully compliant with BIS on an individual asset by asset. So as Adam pointed out, it's individual asset issuer can't have on top of this layer set of controls so that, you know, they know who they're interacting with and, you know, and they can set up their own set of rules. Go ahead with it. Yeah, does this mean that the issuer will create a new did that will then function as their did, and it's somehow connected to the overall did in some way, or does it mean that there's a whole separate, you know, digital identity system operating on for the benefit of the issuer? The second question is, what of this technology stack is shared with the issuer so that they don't have to go through this whole process of creating, you know, a digital identity infrastructure, which it becomes a heavy lift for most of them, as we know. So I can try and take that. So the way PolyMesh works is that, let's say every user, whether they're an individual or a business, receives as part of their onboarding one of these decentralized identities. That decentralized identity can then be used to store or to hold assets, you know, a variety of different assets or as many assets as you want. So that means that as an app that issuer, you don't necessarily have to worry about onboarding, you know, if your investor is already onboarded and already has an on-chain identity, then they can obviously use that on-chain identity, they don't have to be re-on-boarded. In terms of who can do that onboarding, so, you know, which entities are allowed to onboard users to PolyMesh, it's a sort of federated system. So as I said, PolyMesh is a permissioned blockchain, so not anyone can onboard. So in order to be, in order to provide onboarding services in PolyMesh, a company has to kind of go through a process and effectively, you know, persuade the PolyMesh Association that they, you know, will apply the relevance of due diligence, that onboarding process and apply the relevant rules and that identity verification process in which case they can then be commissioned to onboard users to the chain. So, you know, that due diligence process by the Association just looks like a normal due diligence process and in theory, you know, anyone that can pass that due diligence process could be permissioned to onboard new users to PolyMesh. I'm not, Vivin, did that address your first question? Yes, indeed. Sorry, there is a correspondence to LEI because LEI has a registry which is also decentralized in terms of onboarding. Yeah, so to add on to that, you know, as Adam pointed out, one of the ways you can solve the problem is that is someone like a SCCP or CSDs which do handle today LEIs and so they could actually be acting as an onboarding agent or KYC entry point that only gives a KYC or DID into PolyMesh or, you know, as a network level. But again, it's up to the individual banks to decide they can have their own independent KYC as it suits them. And on layer two, they further filter it and say, you know, who they're going to interact with on what assets. So, you really have a federated set of rules by which who gets onboarded and how are they going to interact with each other. So, that gives you the control, which is what BIS or essential the regulators are looking for. You're not like spraying out your security issues to everyone. Instead, you target who you really have relationship with or who you really are intended to. Because there are certain things, certain assets can only be distributed to certain individuals on this ghost jurisdiction by jurisdiction. So, the issue will make sure that only those targeted identities would get those assets. So, to further go forward into, you know, this is where it's interesting challenges, what's a qualified custodian. This is an interesting problem. How do you demonstrate control of an asset? If you're a global custodian and your investor is depending upon you to demonstrate that you have complete control of the asset, can you claim that role here? That's a very interesting question that, you know, I see some custodians are struggling with it. But given the fact that if a transfer agent is offline, that completely puts in a custodian under a lot of legal, I would say legal stress. What do the investor wants to move the asset and the custodian can do? How can they claim that they're a qualified custodian? So, this is something that over time, the markets has to grapple with and come to a logical conclusion. This gets even more weird on the side. When you have collateral, that's going to be used by CCPs for managing complex instruments. Interestingly enough, this collateral is held by CCP on behalf of the banks who act as transfer agents. But the same transfer agent of the banks are also holding on the cap table on the collateral itself. It looks a cyclical dependency. I don't think that this legally can be easily solved. Again, it's up to the market participants. But we think we are getting into slippery slope when there is cyclical dependency on the issuers acting or the banks acting as issuers and transfer agents. And then CCP is depending upon them. This gets very complicated. Now, one of the ways they can solve the problem is to put this in a single transfer agent for all assets. Then we are back to the square one. Why do you need a blockchain? You never get an answer to it. Anyway, to us, it's much more cleaner implementation. If you use a blockchain, it's distributed, and you use zero-knowledge proof and cryptic cap table, you get a clean implementation, and it took us so long. Another interesting challenge is that a lot of the earlier implementation of zero-knowledge proof are UTXO models. While it is easier to implement on the chain, it's a bigger lift-on application provided like us to use UTXO model, particularly for every transaction you need to generate is zero-knowledge proof. And UTXO can even have a lot of wallets spread around, and you're going to generate proof of the whole slot on the whole system. Whereas Polymesh handles that as an account-based system on chain, that solves a lot of problems as well. Again, I just want to go for a real event through the thing. What OTC Digital has done is taken the zero-knowledge proof from Polymesh and added on all these functions on top of that. I'm going to explain to that is how we built it is at the lower end level. Layer 1 is Polymesh chain, and we use Layer 2 as a corridor only for the workflows and business logic. The most important thing from our point of view is CDM. That's the interoperable digital standard because this protects all the market participants not having to worry about the Layer 2 or Layer 1 dependence. If there are changes happening here or more features coming in these layers, or our application protects that from not having to worry about that. And the way it works is we have ledger services and we use zero-knowledge proof server, which is actually supported directly by Polymesh. So we just had to give a proper instruction. The proofs are generated by the Polymesh proof server, and it's then submitted into the network for verification. And on top of that, we have our app services, and then we built our functions for it. But one of the important things we want to say is that this is fully decentralized stack. There are no OTC-centralized OTC services anywhere in this network. Everything is deployed decentralized on their connected via Layer 2 using corridor, and then they interact with each other using Layer 1 on the asset level, and then settlement level using Polymesh. So that's critical to note. A good implementation must guarantee not only decentralization of the entire stack, but also interoperability all the way up to the chain. And that's why using a standard like CDM protects us because it's not only an interoperable digital standard, but it's also an interestingly illogical blockchain because it has properties that can link the lifecycle or events of an asset. And hence, it has a similar hashing mechanism between the original asset definition and then subsequent lifecycle events. It's a good property to have because then it can be applied on any underlying blockchains. So we chose a CDM for us. That's a much bigger smart contract implementation or valuable implementation because these are CDM developed by the industry market participants. Now it's been taken over by Finos Group, Finos. So adhering to the standard helps banks not to worry about the underlying blockchains, because that's our approach. With that, I'm going to now hand it over to Adam to go into more into the zero-knowledge proof and maybe take over Adam. Thanks very much. Mani, do you want to? Well, maybe I'll just briefly introduce myself. So I'm great to meet everyone. I'm Adam Dawson. I'm the head of technology at the Polymesh Association, which is a Swiss-based not-for-profit that's responsible for shepherding and developing the Polymesh blockchain that Mani's given a great introduction to. So it's one of the features we have been working on for the last sort of six or 12 months is an implementation of confidential assets on the Polymesh blockchain. I think Mani did a great job of outlying wide privacy and kind of confidentiality of things like positions and balances and amounts being transferred between different network participants is useful and is kind of required under some of the regulations. So the approach we've taken and again Mani gave some kind of great context around this and sort of rationale is that rather than trying to achieve privacy by sort of just ensuring that only one or a limited number of network participants have access to the data, which is one approach that I think was a sort of 3G approach on Mani's previous slide. In Polymesh, we've taken the approach where we still want to have a single global state, so the same state seen by all network participants, it's just that some of that global state is encrypted so that users still have privacy and obviously in particular things like token balances and transfer amounts are encrypted. So although everybody or all network participants can see the state, they're seeing encrypted state and obviously only those participants that should be able to are able to decrypt that state and also execute transactions that change that state. So for example, transferring assets. So as Mani says, we've approached privacy via your phrases like via maths rather than sort of networking or data hiding. So privacy via encryption improves rather than sort of make sure only certain participants have access to the data. The other one of the other kind of key attributes that we've taken with our approach to confidential assets is that they are account-based. So anyone who's used Ethereum, it's kind of familiar with with a sort of account-based mechanism, unlike Bitcoin and Kedarno and some other networks where they have these unspent transaction outputs or UTXOs in Ethereum and in Polymesh, we do everything at an account level. So if you as a user have a on-chain identity that will be linked to one particular account that will hold your ACME balance and as your balance in ACME tokens increases or decreases, those balances are reflected upon that single account. So it's not like every time you transfer or receive an asset, you have to generate a new key and you end up effectively having your positions spit across multiple UTXOs. So I think the reason for doing that is it's a lot more tractable to reason about. It reflects what happens in the real world. It'd be surprising if every time you receive money into a bank account, you've got a new bank account number, that would be a kind of surprising and unusual way to operate. So I think it's a lot more kind of intuitive, let's say, to work in the account model. So coming back to how we achieve confidentiality in Polymesh, we use a combination of zero-knowledge proofs that I'll talk a little bit more about and something called homomorphic encryption that I'll also talk a little bit more about. So the idea of zero-knowledge proof, broadly, and I should point out this one, we have our kind of expert photographer and expert developers online. So if there are questions, I can point you in their direction, they could probably give a more detailed answer. But at a high level, the idea behind zero-knowledge proof is you can kind of prove the validity of a statement. You can prove that a value is, say, greater than zero without actually revealing what that value is. So in our case, it lets users prove things about their balances, their encrypted balances on chain, without revealing what those balances are, which would obviously then sort of leak privacy. So we use zero-knowledge proof for that purpose and I'll talk again a little bit more about those. Homomorphic encryption is a kind of clever encryption scheme. So the idea with homomorphic encryption is that if, for example, you have two numbers, let's say you have x and y, which are both encrypted, you can add those two encrypted values together. So you can add the encrypted value of x to the encrypted value of y and your result, which will be, let's say z, will be will be the encrypted value of x and y. So in other words, you can kind of do simple maths on encrypted values and keep the usual properties of math that you expect. I be able to add and subtract and so on values. So what that means for us in particular is, for example, if you have an encrypted balance of ACME tokens and you receive another transfer, you receive some more of those tokens, we can simply add the two encrypted values together on chain to get a valid response or a result, which is equal to the sum of those two values and you can do that all kind of in the encrypted space without having to encrypt everything, add it up and then re-encrypt it. So those are the sort of two kind of primitives that we use, zero-knowledge proofs and homomorphic encryption, what it allows us to keep this global state. I'll talk a little bit more about zero-knowledge proofs and again, if there are any questions, just jump in and interrupt and I'll answer them or I'll ask somebody else from the team to answer them. So specifically with zero-knowledge, the zero-knowledge proofs we use, they're non-interactive zero-knowledge proofs, which means that, broadly speaking, the person trying to prove something and the chain which is trying to verify that proof don't have to have a lot of chat or don't have to have a kind of conversation back and forth. So it's not like I send something, the chain sends something back to me, I have to send a response to that, the chain sends something back to me and I send a response. It's a sort of single one-shot proof that I send and the chain can verify it and be convinced of the proof I've sent. So they're non-interactive. We also use something called sigma-proofs-folds, which are, you can kind of think of them as sort of single-purpose proofs, proofs designed for very specific purposes to prove very specific things. And as a result of being sort of somewhat single-purpose, they're significantly more efficient than some of the more general-purpose zero-knowledge approaches like ZK-SNAPs that people may have heard of. So one approach of these sort of sigma-proofs we use is that they are more efficient and obviously efficiency translates to things like TPS and throughput and so on. There are some other slightly more technical advantages, so the zero-knowledge proofs we use do not require a so-called trusted ceremony. So some flavors of zero-knowledge require, before you can sort of prove things in zero-knowledge require there to be a sort of ceremony where you create this sort of trusted string and the validity of the proofs relies on that ceremony having run correctly. So it introduces an additional complexity and also an additional kind of trust assumption. And there are very good ways of running those trusted ceremonies where you only require one of N people to be trusted and so on, but it's still an additional complexity that we avoid by using these sigma protocols. I guess to get a little bit more specific around exactly what we use zero-knowledge proofs for, you can imagine that if you have a token balance of Acme tokens, I suppose I have a balance of 100 Acme tokens and I want to transfer 10 tokens to Manny for example, then I need to prove a few key attributes related to my current balance and the amount that I'm transferring. In particular, I need to prove that the amount I'm transferring is a positive number because you can kind of intuitively understand it by trying to transfer Manny negative 10 tokens and really I'm not sure exactly what that would mean to sort of transfer someone a debt. So you have to prove the amount you're transferring is a positive number and you also have to prove that you have a sufficient balance to transfer the amount of tokens you're trying to transfer. So in other words, your current balance minus the amount we're trying to transfer is also greater than or equal to zero. So in other words, you have a sufficient balance and the amount we're transferring is a positive number. So those are the examples of the type of thing we use zero-knowledge to prove. There are some other kind of aspects of the protocol. So we also, and I'll talk a little bit about it in the next slide, but we also, Polymesh sort of has this auditor interface that allows you to, you know, whilst the data remains encrypted on chain allows you to kind of share the details of transfer amounts with a third party with an auditor and there's some, you know, some proofs required to show that, you know, to prove that what you're showing with the auditor exactly matches, you know, the amount that you're transferring. So if I'm transferring 10 tokens for that, you know, I'm truthfully if you like showing that to the auditor, I'm not telling the auditor I've transferred 20 tokens when I've actually transferred 10 tokens. So, okay, so we talked a little bit about homework encryption, a little bit about zero-knowledge proofs. I guess one thing that might be worth touching on, so that's how we keep the balances, users token balances and transfer amounts confidential. The other bit of data which is useful to keep private is exactly which asset is being transferred. So am I transferring acme tokens or Tesla tokens, etc., or, you know, Microsoft tokens and so on. So to do that, we take a slightly different approach where we use so-called anonymity sets. So the idea is that if I want to transfer, let's say, some acme tokens to Manny, in addition to transferring acme tokens to Manny, I create some decoy transactions where I also say, pretend or have this sort of decoy transaction where I'm maybe transferring Tesla tokens and Microsoft tokens and so on to Manny at the same time, except that those decoy transactions only transfer a zero amount. So obviously that's, you know, effectively not really a transfer, it's a transfer of zero. And by doing that, so in this example, your acme ticker would be in a anonymity set of three, so it'd be acme, Tesla and Microsoft, and then like a kind of observer of the chain state won't be able to tell if the real transfer is for Tesla, Microsoft, or acme in this example. And you can grow that anonymity set or shrink that anonymity set as appropriate for your kind of the degree of privacy that you need. And there are some efficiency trade-offs in terms of the size of the anonymity set and the, you know, the cost of transfers and so on. So yeah, so that's how we, that's broadly how we keep balances transfer amounts and asset tickers or IDs confidential. Let me just pause there and see if there are any questions. Yeah, there seem to be one question. The first question on this is about from Jim Zhang. Is this based on Zither? It seems so far as it shares a lot of cryptographic primitives. But with this, in this context, it'll be good to draw a bright line between the so-called 3G stuff that you already have, which is, you know, the ZK roll-ups, all that, you know, Ethereum-based updates that are coming through and your approach. So in terms of whether it's based on Zither, there certainly are some commonalities and maybe that's a better question. I mean, Amir, I'm not sure if you're able to give a kind of brief comparison of some of the sort of differences and similarities between Zither and the polymesh approaches. So there certainly some, some kind of commonality on that first question. That question is already answered, but you're certainly welcome. I don't have it. Yeah, exactly. I appreciate it. Actually, Robert said that actually, Polymesh is based on Mericat, which you can see the white paper there. But just very quickly, the cryptographic primitives that Polymesh uses, more or less, are the same as cryptographic primitive that Zither uses. For example, for zero-knowledge proofs, as Adam was explaining, we do have like generally, we have two famous categories like ZK-snugs, which are more general purpose, and also Sigma particles, both Polymesh and Zither. And you can find other like blockchain particles that uses Sigma particles, both Polymesh and Zither actually use Sigma particles for their zero-knowledge proofs. And also, again, as Adam was explaining, for encryption scheme, which has this nice property of homomorphism, we use algal encryption, which is exactly like used by Zither, again, for taking advantage of homomorphism properties. So we do share some underlying cryptographic primitives with Zither, but there exist differences in terms of portable details. Yeah. And the Zither paper is, I believe, its reference in the Mericat paper. And there are some interesting, so I think the team at Polymesh are all familiar with the Zither approach. There are some interesting aspects, which Zither, I think, wasn't really focused on securities and some of the additional constraints or requirements that securities have. So, for example, something that Manny mentioned earlier is no unilateral asset transfers, I can't remember the exact wording, but something along those lines. So in the Ethereum world, either with Ether or like an ERC-20 token, or even like an ERC-1155 and 1400 and all these other sort of security token standards, they are all kind of unilaterally transferable tokens. So in other words, if I know someone's key or address, I can transfer them tokens, whether they want them or not. So in Polymesh, using, and this slide doesn't really sort of talk to me, I think maybe the next slide talks a little bit more about it, but you know, we have this kind of concept that for a settlement to occur, you know, for an asset to move, it's a sort of multi-step process where, first of all, you create a settlement instruction, you then have all of the counterparties that settlement instruction affirm it, whether you have a sender or the receiver and so on. You know, all of the counterparties across all of the legs and that settlement instruction across all the assets and so on need to explicitly agree or affirm that transaction. Once all counterparties have affirmed, only then will it execute. So that's very different to the kind of context or setting of Zeta and some of those sort of similar papers. And then the other kind of feature, which we talked about since like the auditor functionality and so on, which I don't believe was part of the original Zeta paper, this idea that, you know, as well as encrypting balances under your own key, you may also want to encrypt balances under an auditor's key and need to prove that the two balances are equivalent, obviously, without repeating the balance publicly. Manny, do you want to flip to the next slide? That's okay. And yeah, in terms of questions, feel free to interrupt. I haven't got the chat up, but we'll see about the members of the team as well, looking at the chat. One of the, yeah, you made it very clear. And I want to point out that in Ethereum, for example, there is the whole concept of dusting, which is propagating taint across multiple accounts using transfers from compromised accounts. So this receiver affirmation is a very important property. Yeah. Yeah, I think it's important, it's a great point, Bippin, right? It's important for our host for reasons, there's sort of regulatory reasons, there are potentially tax implication type reasons, if someone drops some illiquid asset with a notional value of a billion or a million dollars or something to account, maybe there's a tax implication of that. So the dusting aspect, so you know, on Ethereum, if you really don't like someone, you can send them some, you know, some funds from a compromised account, and you know, that user was probably going to have their account blacklisted by all centralized exchanges and so on. So, yeah, certainly lots of reasons why, you know, NCEs like the SEC and other regulators have mandated these types of, these types of kind of conditions on real-world assets or security tokens, tokenized assets. Okay, so this slide really goes into a little bit more detail about the different entities or actors involved with confidential assets, I'll just talk through them very briefly. So you have the sender and receiver, which is somewhat self-explanatory, so you know, the individual sending the asset and the individual receiving the asset, and you know, it's worth noting this could be the individual themselves, or it could be their custodian acting on their behalf, but either way, you know, you have an entity by the custodian or the individual user that's sending the asset and correspondingly on the receiver side. These entities need, you know, the usual stuff when you're working with a blockchain, right, they need to manage things like public-private key pairs, for, I think as Amir mentioned, we use Elgamel or Twisted Elgamel keys or encryption for these confidential balances, so there's some sort of public-private keys you need to manage or secure for that. The sender of the asset also needs to generate these zero-unlogic proofs that we talked about, so proving that the approving the amount they're sending is positive, or they have sufficient balance and so on. The receiver should verify the details, so you obviously make sure that they're receiving what they expect to receive, you know, the asset type or the asset and the asset amount that they're expecting to receive, which they can verify based on the sender proof, so in other words, they can take that sender proof and as a receiver, they can, if you like, encrypt it or extract the information they need to verify that they're receiving what they expect to receive. Once they've done that action, they can then affirm the settlement instruction, you know, as we talked about, both the sender and the receiver both need to affirm and I'll maybe talk a little bit about incoming balances, but I'll just leave that bit for now. You know, one of the other types of actors we have, which we talked about briefly, are auditors and you can actually have, you know, one or have between zero and many auditors. So auditors are sort of third parties that, you know, for example, might be a transfer agent or a regulator or the asset issue or something like that, who want to, you know, whilst obviously the balances are all encrypted on chain, that third party wants to be able to, you know, maintain a sort of transaction log of everything that's happened that's related to the asset or the transfers and so on that are related to the asset. So PolyMesh allows you, allows either the asset issuer or the business or company that's creating the settlement instruction to specify one or more or zero or more auditors and then those auditors will effectively receive encrypted versions of what's, you know, what amounts have been transferred that they can then be crypt to kind of maintain that. It's like a cap table that Mani mentioned would be one application of that or a reporting, if there's any kind of reporting requirements and so on. The third actor, which we haven't talked about so far is what we call a mediator. So mediator is, so they have all the properties of an auditor, i.e. they get to see, you know, they get to see exactly what's being transferred and so on between two parties and which asset and amounts are being transferred but they are also required to approve the settlement instruction explicitly. So in other words every settlement instruction has to be approved by all of the counterparties, all of the people that are sending and receiving assets within that settlement instruction and it also needs to be approved by any mediators associated with that settlement instruction. So the mediator, for example, might be someone like a transfer agent. Obviously if you have, you know, kind of compliance rules you want to enforce, the mediator will be one way of doing that. It may be, you know, the exchange itself wants to act as a mediator and have final approval on all these settlement instructions and so on. So or maybe the asset issuer or and so on. So that's the mediator and the different actors have, you know, more or less all of them are required to manage these, you know, probably private keepers so they can receive encrypted data and decrypt it. You know, mediators and send in receivers are required to directly submit transactions on chain in order to affirm these settlement instructions, whereas auditors just, you know, are just required to sort of read data from the chain and don't actually have to interact on chain. So there's sort of slightly different sort of technical requirements if you like to to each of these different answers. Again, I'll pause there and see if there are any questions. I know I've covered that slide quite quickly. Does anyone have questions? Please feel free. Yeah, I can see there's only five minutes left on the call as well. So probably I'll finish this sort of polymers section here. I mean this slide is sort of interesting. Maybe leave it on the screen for a minute or two, Manny, but this slide is really just to try to root some of the things we talked about, things like senders, receivers, auditors, mediators in, you know, real world descriptions. So like a sender, receiver could be a custodian, auditors will be things like transfer agents, dealers, issuers, you know, or maybe regulators. The mediators might be transfer agents or CCP in the case where there is a CCP and so on. So this is more just to kind of translate if you like between the sort of more the polymers or technical terms and what those, you know, who may actually be playing those roles in the real world. So that's the purpose of this slide. I think with that, Manny, I know you still have a few slides, I think. So I'm a bit conscious of the time. So we can probably leave the polymers stuff there, Manny, if you have kind of some completing remarks. Yeah, yeah, sure. Let me quickly run through, you know, having talked to thanks for giving a good overview of it. I mean, what does it mean? How are we using? What's the practical use? So we are actually building with some sponsorship, building a commodity supply chain network. It's interesting because it's a global supply chain, starting out with precious metals. And this is where it's interesting, the ownership moves from the miners, to refiners, to minters. So everything has to be tracked. And that's where PolyMesh Zeronautical helps us a lot to maintain that relationship. And not only that, we are linking in our existing OTC digital. This is also now being upgraded as a wholesale trading network. For example, a goal that starts from a miner goes through a refiner and a minter, all happens in the supply chain network. But then when that is ready for trading in the commercial marketplace, we actually burn that asset, in digital asset on the supply chain, minted on the digital asset network on the wholesale side. And that's how you're able to do intrapolability and transfer of the assets so that this could be traded in the marketplace. And again, vice versa, they really want to bring it back and melt it for whatever reason on the road, then you burn it here and bring it back here. Zeronautical helps a lot in also maintaining auditors. Means if you are minting something, how do you maintain that? How do you know that that's the what you have in real-world physical gold matches to what's on chain? Zeronautical allows you to create proof of balances. And that can be verified by auditors, which means now we can go to the next level saying that if you want to build, let's say, a commodity fund, which is fund of underlying precious metals, you would actually hold those metals or digital assets in collateral account, freeze them, and let know of an auditor who can actually in real-time monitor those accounts. And then you would be actually creating funds and issue those funds in the wholesale market. So you really are linking in a physical market to a trading market, and that's where the real application comes in. So without these interoperable asset transfers, it is very hard to have to isolated instruments networks. But again, this is where PolyMesh also helps us in transferring these assets between the networks. I don't know, we have a couple of minutes. So I'm going to go through one example of how actually happens. We use an OTC digital, which is in this case, I'm taking a simple example of two investors exchanging an asset and they invoke one custodian. So that makes life easier. So the trade is done between two the investors and let's say an RFQ or any other secondary market. That trade information is in CDM, so the investors and the custodian know the actual trade details. So the custodian, because the custodian is the same custodian for the both investors, custodian will initiate a settlement instruction on chain on PolyMesh, followed by generating the proof of balance for both investors, depending upon whether it's a single asset or dual assets, whether it's DVP or a simple payment or delivery. And then finally, the custodian issues a very fine approval settlement and that gets recorded on chain. So very quickly, this is what I'm showing, but it gets more complex when you have multiple parties and we have multiple networks, but the idea is the same that you would take the asset, you would initiate the transaction, submit the zero knowledge proof and also the parties will verify and that gets finally settled on the network. With that, I'll stop here because of lack of time and any questions, please feel free to ask. Yeah, it is always a pleasure to have you guys here. And of course, with such a complex topic and black, it's very difficult to cover all the points. But I want to ask whether any of these presentations are shareable. And of course, it's been on the chat that you can ask your questions to Will at polymesh.network. Yeah, I would check with Adam and we definitely we can share this presentation with the group. Yes. And we discussed having a demo, demo, which is going to be more than just one hour, which will, once you have a little more clarity and closure, then it's very nice if you could come back and do a demo. That would be a fantastic thing. Yeah, the coming months definitely we can come back. If there's enough interest in the audience, yeah, they're more than happy to come and give a demo. Well, let me tell you, this call has generated more than 31 people participating in the middle of the week at 10 o'clock, which means it must be interesting to the audience. But, you know, we are not specialists on the ZK proofs. I was a participant in the ZK standard first pre-ZK standards, you know, which have been still ongoing. The next one is in Berlin. So if you are in Berlin, please register for that. And the ZK standards is where the real, you know, nitty-gritty work on the academic and deep level on ZK proofs is being done. I hesitated to post this on the ZK proof standards list, which I'm a member of the Slack. But thank you for coming. And last one thing, thanks to Bunny Adam. It's 1103, Jeff. So that's why we have one more quick question. Go ahead. I think maybe some know I'm the co-chair, one of the co-chairs of the display chain. So they really like to see that demo because it crosses a lot of areas that we're looking at around, I guess some of this is fintech. And so I'll be curious to having, talk about having, probably much to come back, maybe a dual. Someone should talk about maybe having a dual presentation for two weeks. Yeah, we could have a general presentation. Too many people on there, but yeah, it's okay. It's really got a lot of fintech stuff. We're just back-macing stuff. And I think if the pie mesh has got part of that in there, we're probably going to take it loans out on some of that. We're going to find our smaller example stuff in the warehouse. So we're really interested in seeing it. So I just, should I talk to you offline then? Yes, we'll have to have poly mesh back and then we'll see if the pie mesh is one of the dual, but then we'll put two weeks display chain with the finance when we put together. Are we going to, I think it's a part of the area anyway. Yeah, yeah. I'm sure, I'm sure we can arrange something. I will put the chat up on the meeting page. So you should be able to see Will's contact there. And thank you again. Jeff, thank you. Money, Adam, and Robert, and all else I missed on your team. And this has been wonderful. And hopefully this is what is going to make a difference in real-world assets on chain. And good luck to you. And thank you. Thank you very much. Thank you. Thanks. Thanks.