Web3 Builders: Polymesh | Built with Substrate

Security tokens have the ability to alter the financial landscape, unlocking trillions of dollars in asset value and investment, programmably automating operations, and driving new paths to liquidity. For Polymath, the Ethereum blockchain has been an excellent starting point for security tokens, but is missing foundational elements that issuers and investors need, and that institutions and regulators require. After having enabled the creation of 150+ tokens, our research and experience has shown that institutions need a blockchain built from the ground up with the specific requirements of securities regulations in mind.

Polymath addresses this need with Polymesh, an enterprise-grade blockchain built for security tokens. The foundations of Polymesh are focused on the most crucial regulatory elements, addressed by four key design principles meant to meet the demands of regulators and institutions, while unlocking the true potential of security tokens:

1. Confidentiality — protecting information and ownership privacy while providing a mechanism for accurate reporting and auditing.
2. Identity — ensuring that no individual or entity can create, acquire, or sell security tokens without a validated identity. Securities regulation requires issuers, in certain instances (i.e. issuances under exemptions), to know the identity or confirm the profile of their investors prior to investment, and continuously monitor their suitability throughout their investment. Additionally, all Validators must be known, regulated entities.
3. Governance — providing an operating and governance structure for how Polymesh is managed that allows for curation, and protects assets from contentious forks during network upgrades. This includes providing an established method for addressing and actioning proposals.
4. Compliance — providing financial primitives and smart extensions to manage security tokens across one or more jurisdictions and enforce appropriate rules for creating, issuing, and trading security tokens while also providing the capacity to manage necessary complex restrictions and distributions on-chain.

Polymesh will use the Nominated Proof-of-Stake staking mechanism with the finality gadget GRANDPA, and be supported by POLYX, the native protocol token. With Polymesh, Validators stake POLYX on the network and run authoring nodes, Nominators stake POLYX on Validators, and both are rewarded or fined by the network based on blocks being added to the chain and fulfillment of their roles. All POLY tokens currently existing on Ethereum will be able to be upgraded to POLYX at a 1:1 ratio.

Structured in this way, we believe Polymesh will fill the gap between security token technology and the needs of issuers, investors, institutions, and regulators.

“Web3 Builders: Polymesh” on Polkadot’s Crowdcast:

Web3 Builders Crowdcast Transcript:

Dan Reecer (Web3 Foundation):

Hi everybody, this is Dan Reecer from the Web3 Foundation, and I’m joined here today by Adam Dossa, the head of blockchain at Polymath. Thanks for joining again, hopefully some of you have seen some of our previous Web3 Builders Crowdcasts. We started this to talk broadly about the Web 3.0 ecosystem teams that are building on Substrate, in the Polkadot and Kusama ecosystems.

So Adam is here to talk about Polymesh, the new project that Polymath is working on in relation to security tokens. They are using the Substrate toolkit to help them build this project. Adam will go over that today. I’ll kick it over to him to introduce himself and get started. So thanks everyone.

Adam Dossa (Polymesh):

Thanks very much Dan. It’s great to be here, thank you very much for having us on the Crowdcast today. So as Dan says, I’m Adam Dossa. I’m the head of blockchain at Polymath. I’m going to talk about Polymath and Polymesh today. I want to start by sharing our mission statement at Polymath, which is to unlock global access to wealth creation through additional economy.

By way of background, we have a layer two protocol which has been live for a couple of years in Ethereum. And as of last year, we started building a new blockchain based on the Parity Substrate framework called Polymesh, which is what I’m going to be focusing on today.

A couple of weeks ago, we released a white paper outlining the vision for Polymesh and starting to flesh out many of its details. We are going to be releasing additional papers, articles and documentation as we approach the testnet and mainnet rollout. Those will dig into more detail into different areas, things like governance, tokenomics, confidentiality and identity. These will be coming out over the next few weeks and months.

My aim today is to give a brief overview of a few different things. I want to talk about why we chose the Parity Substrate framework for Polymesh and what some of the decisions around that were. I’ll also talk a little bit about the architecture and design decisions that we’re making for Polymesh.

In brief, we have four core design principles in Polymesh: identity, confidentiality, governance and compliance. I’ll touch on each of those briefly. And I’ve got a couple of slides at the end which do a deeper dive into one specific area, identity, the core of Polymesh.

So what does our journey to Substrate look like? Polymath came into being in 2017. We had a clear vision to bring regulated securities to public block chains. We wanted to leverage the transparency, the innovation, the interoperability and accessibility that DLTs provide.

And back then in early 2018, building on Ethereum made a ton of sense. Ethereum was relatively mature, there was some tooling, there was a community, there were things like best practice around smart contract development. And building on Ethereum allowed us to prove our concept, gain traction and distribution and, probably most importantly, learn a whole bunch of hard lessons.

So the protocol in Ethereum has been live for a couple of years. It’s had great traction adoption. We’ve had over 100 companies issue security tokens throughout, but there have been interesting lessons that we’ve learned. And that’s really what fed into our approach with the Polymesh blockchain.

Some of the more interesting lessons we learned are around the importance of standardization. Standardization and standards are something the financial industry is intimately familiar with. They’ve probably existed as long as the modern financial system has existed. They cover all sorts of things from how different participants communicate to how to represent different types of assets, and so on.

In the Ethereum space, with the help of the community and other stakeholders, Polymath put together ERC 1400, which is a collection of interoperable standards for security tokens that cover different aspects of security tokens from lifecycle management to asset modeling, and so on.

The majority of the ideas and approaches that went into ERC 1400 carry over very nicely into Substrate. I’ll talk a little bit more about that later.

The other really important lesson we learned is that Polymath wants to be a global platform. We want to be able to cover a whole range of different regulated assets and a whole range of different jurisdictions. That means that there are a lot of different ways that assets and jurisdictions can be combined, a lot of different ways that you have to manage compliance with different types of assets, crossing or covering different jurisdictions.

And the lesson we learned with Ethereum is that you really need to have a very modular, flexible and extensible design. You want your users in the network to be able to take your financial primitives, all of this logic in the base layer, but to be able to use it in a flexible way so that you don’t have to provide all of the functionality you need for every possible different type of compliance out of the box, but you give people the tools to extend the financial primitives provided by Polymesh as needed.

That’s another important lesson we learned. I’ll talk a bit about how we plan to achieve that and about Polymesh using smart extensions later. The other key insight is that regulated securities have a lot of different stakeholders. You have issuers, you have investors, you have regulators, you have KYC and AML providers. You have custodians, exchanges, legal firms, marketing firms, standardization bodies, and many, many more.

One of the things that Polymath has done very successfully over the last couple of years is work collaboratively with a whole range of different stakeholders. That’s reflected in things like ERC 1400 and a whole bunch of other areas and standardization bodies that we sit on and contribute to.

Although we obviously have competitors — there’s a whole bunch of companies working in this space — the overriding motivation or aim is really to grow the size of the security tech market. So as much as companies obviously want to increase their share of the pie, right now really everyone’s focus, as it should be, is on growing the size of that pie and growing the number of assets under management which are represented in public blockchains.

That’s important, it takes a lot of stakeholders to bring these things to market. And bringing all these stakeholders along with you is very important to Polymath and essential to our approach.

Technically, whilst Ethereum has been very useful in gaining some traction and learning these lessons, Ethereum is a general purpose blockchain. It was designed to be general purpose. It’s not tailored or optimized to any specific use case, whether that’s security tokens or prediction markets or gambling and so on. It’s not optimized for any specific purpose. And as a result, lots of the trade-offs that Ethereum makes are sub-optimal for our specific use case, which is regulated assets, capital markets and so on.

Some very quick examples are things like the gas fee and pricing approach in Ethereum which allows front running; this is an issue that’s problematic when it comes to securities. Privacy being a sort of layer 2 construct is somewhat problematic, or as well the complexity around privacy. Confidentiality, as I say, is one of the key four design principles of Polymesh.

There were some technical issues around the way finality is provided on Ethereum. In Ethereum, which is, currently anyway, a proof of work network, finality is probabilistic. So we’ve seen block reorganizations — not so much in Ethereum but certainly in things like Ethereum classic and some other blockchains — we’ve seen pretty large block reorgs, which are obviously problematic if you’re dealing with securities and asset transfers in general; having a block reorganize itself and have transactions that could have been considered finalized become unfinalized is problematic.

Governance. I have a lot of respect for Ethereum. Ethereum tries very hard to cleave to this decentralized governance approach. We’ve seen that in action with things like the Prog PoW discussion recently. But while this sort of decentralized governance might make sense for Ethereum, it is quite problematic for larger institutions and the security space where compliance is so important.

One of the great things about Substrate is that because the state transition function of the blockchain is actually held on the consensus itself, if you want to upgrade the network, it makes that process a lot simpler, a lot smoother, and gives a lot more clarity to institutions, individuals or organizations that are using the blockchain.

Lastly, Ethereum is permissionless. That means that miners are effectively anonymous. This is an issue that large institutions often raise; that if you’re a large bank and you make a transaction, it’s possible that your transaction is actually mined and included in the block by a miner that’s in, say, North Korea, which means that not only his [inaudible] and you’ve also paid them a fee as a transaction fee to potentially a miner that may be in a country where you’re not meant to make payments to. For large institutions which have this really high bar around compliance that can be very problematic.

So there are a whole bunch of lessons learned, a whole bunch of reasons that we saw this great opportunity to build an optimized blockchain which is purposed specifically around security tokens, regulated assets and compliance. And Substrate is great because it gives you a whole bunch of functionality out of the box.

So things like your your consensus algorithm, your networking protocols, all of these kinds of basic pallets that help you manage native currencies and other things, all come out of the box. And you can also modify those. For example, we’ve modified lots of their functionality to reflect the fact that Polymesh is permissioned. And you can also add in your own pallets, your own modules, which we’ve done by adding modules for things like identity, regulated assets and so on.

So it’s this great combination of providing a whole bunch of functionality out of the box whilst giving developers the ability to modify that functionality and add in their own logic at layer one.

So I’m going to talk a little bit about the architecture. I’ll split the architecture side into three layers for this presentation. The first is around the security of the network, or the base layer of the network enabling economy. The base layer of Polymesh needs to match the needs and requirements of regulated markets, capital market institutions and so on.

This is critical if we want to achieve widespread adoption. So what does that mean in practice? We have a few key bits to that. The first is that all network participants need to go through a basic customer due diligence process, which is this federated CDD process on the slide.

This ensures that network participants are privately linked to real-life legal entities or identities, that they’re not in sanctioned countries, and so on. And it helps to provide a certain amount of provenance around the POLY native token on Polymesh. All ownership of POLY, transfers of POLY and use of POLY, and so on, can be linked back to an identity that’s gone through this basic customer due diligence process.

This helps provide some provenance around the token and the blockchain. And, there are a few other advantages. It helps give a certain level of civil protection, and so on, which could be useful in other areas, which I’ll touch on later.

So how is this process managed? That brings us to the next topic, which is on-chain governance. On-chain governance is pretty interesting. There’s been lots of innovation, lots of exploration and experimentation in the area of on-chain governance. It’s not something that is really embraced by Ethereum, but chains like Polkadot and Kusama and Tezos are all taking pretty interesting novel approaches towards moving lots of the chain governance on-chain.

Polymesh does this as well. So we have on-chain governance, which combines POLY token holder inputs and voting and so on with these kinds of secondary governance committees, a range of different committees that help to manage governance in different areas like network upgrades, tokenomics, and so on.

So we have this two-layer process, involving both token holders and these committees. And it’s this governance that decides which KYC providers are eligible or trusted to provide this CDD claim. It handles things like Tokenomics parameters — our reward percentages and how Tokenomics are managed on the chain, and also managed network upgrades. So if we want to release a new version of the blockchain and so on, it helps to manage that network upgrade process.

We have this on-chain governance, which helps to manage all these different aspects of the chain. It’s all transparent. There’s a place for both token holders and committee members to get involved.

The last thing to talk about is that Polymesh is a permissioned public blockchain. The state of the blockchain is public. So anyone can run [inaudible] and check the current state of the blockchain, see that state evolving, check what the state transition function is, make sure that all the participants are following the rules and so on.

But the entities which validate blocks, collect together transactions into blocks and then check the correctness or those blocks, are permissioned. And this is in contrast to blockchains like Ethereum and Polkadot and Kusama, where validators are not permissioned.

So why did we take this approach? It helps to solve a lot of the problems I mentioned earlier. It means that if you’re making payments on the network or you’re interacting with the network, you know that your transactions are not being handled by an organization which might be in a sanctioned country and that type of thing.

So it helps solve those problems, and it also helps to increase the security of the network. So rather than just relying on crypto economic guarantees around things like proof of stake, block rewards and incentives and slashing, you also have security. You can also bolster that security through the idea that the validators on the network are publicly verifiable organizations. They may be regulated, they have a public reputation. So you have these kinds of additional assurances or network security that derives from that.

Those are some of the reasons we introduced this permissioned layer in validators in Polymesh. I’ll talk about a couple of other things now, they don’t actually appear on the slide. I mentioned confidentiality as being one of the key design principles of Polymesh. Again, confidentiality for securities is a pretty interesting area. There are trade offs between investor privacy, which for equity or security positions, is really critical, and regulatory oversight, the fact that regulators may need to do due diligence, and transactions on the network. And the fact that issuers of assets will almost certainly have various reporting requirements.

So there has to be some types of data that’s shared between investors and issuers so that issuers can fulfill their own reporting requirements, but you want that data to be private and not public to everyone in the world.

So it’s a really interesting space. And I think it’s very different to the kind of privacy you see with currency coins or confidentialities of the currency coins, which probably has fewer trade offs, or stakeholders to consider.

So my belief and the kind of approach we’re taking with Polymesh is that the markets will embrace both non-confidential assets — assets which have pseudo anonymity, similar to ERC 20 tokens in Ethereum and so on — as well as confidential assets, where confidentiality brings in a certain amount of technical complexity and UX complexity, but it obviously brings a whole bunch of advantages to investors and issuers and so on.

My belief at the moment is that both of those types of assets will have use cases.We have some more details around confidentiality that we’re aiming to release in the next few weeks, which will help flesh out our approach there.

The next set of things in our architecture are these so-called runtime modules or pallets as they’re known in Substrate. So these are pretty straight forward. One of the great things about Substrate is that it lets you build in logic at layer one. In your normal general purpose blockchain, everything has to be at layer two. But with Substrate and Polymesh, we can add these kinds of key financial primitives at layer one. So things like identity, key management, regulated assets, compliance, settlement and so on can all be built as runtime modules. Our code is open source, and if you’re interested in any of these areas, you can go and take a look at our code and at how we’re approaching these.

So, we have these runtime modules as layer one constructs. Why is that important? First of all, it gives a very standardized approach towards regulated assets. So rather than having everyone who’s issuing an asset come up with their own approach to how they’re going to manage and represent that asset, you have this standardization locked in at layer one. And that makes it a lot easier for third parties and stakeholders to integrate with Polymesh. For exchanges, custodians and transfer agents, it becomes a lot faster and cheaper for them to integrate.

And on that side, I guess one of the other nice thing about Substrate is that many industry participants are already familiar with integrating with Substrate chains. So they may have already taken a look at a Kusama, or Edgeware, or Polkadot. So they already have a lot of the knowledge and technology they need to integrate with Substrate based-chains, which helps to bootstrap, accelerate integration with Polymesh.

I see a few questions coming in. And okay, I will definitely come back and address all of those. Let me just flip to the next slide. So the last thing on the architect’s side I want to talk about smart extensions. So one of the lessons I said we learnt from Ethereum is that our protocol or the blockchain has to have this flexibility or modularity and extensibility if we want to fulfill our aim to be a truly global blockchain that can cover any assets or jurisdiction combination.

So what that means in terms of Polymesh is that we have these runtime modules that they’re representing like assets and so on, and identity. But we want those runtime modules to be able to be extended flexibly in a somewhat controlled manner. So smart extensions are how we approach this. So a smart extension is really just a smart contract. It’s written in a particular DSL and it has to conform to a certain interface and specification.

And that smart extension can then be attached to a specific asset or potentially some of the other runtime modules, and modify the behavior of that module. So a good example would be say for compliance or transfer management as it’s described here. So suppose you have some new type of transfer management rules, so perhaps you have to limit the maximum number of investors in your assets. One way to do this would be you create a smart extension, which is to say just a smart contract. That smart extension encodes the logic you want, and maybe the smart extension encodes the fact that you’re only allowed to have at most, 10 investors in your assets. And if somebody tries to transfer assets that would break that rule, the transfer should fail.

And you then attach that, you then deploy that smart contract to the network, and you then attach that smart extension directly to your asset. To your [inaudible 00:23:18] asset, let’s say that it needs to have that compliance rule.

So because smart contracts [inaudible 00:23:24] complete, and you can encode any type of, say, compliance logic or transfer restriction logic you want in that smart extension. And it allows you to augment or extend the compliance logic of your asset really in any way that you see fit.

So it’s a great way to bring this extensibility. I think one of the other things it highlights is that, I think it’s one of the interesting ways that something like Substrate, or this new breed of blockchains differentiates themselves from previous blockchains.

It’s this idea that you can have this baseline logic represented by runtime modules, alongside this dynamically deployed sort of smart contract logic and you have these sort of rich interactions between smart contracts and runtime modules is something which is pretty novel and it’s not something you can do in any other blockchain, to my knowledge.

And I guess one other interesting thing to mention is that when we first started looking at Substrate last year, this ability for smart contracts to richly interact with runtime modules was missing. So smart contracts kind of lived off in their own sort of playground, and runtime modules lived in their own playground, there’s very limited interaction between them.

One of the areas we’ve been working with parity really late last year, in Q4 last year, was to add this type of flexibility or this type of functionality to Substrate. And that’s now been added by the parity team, collaborating with Polymath and all of that functionality is in the public master branches of Substrate and Ink!, which is the Substrate DSL for writing smart contracts.

So I think that this type of functionality, I think it’s very interesting. I think it’s obviously very important for our specific use case, but it feels like something which other projects building on Substrate will also be able to leverage in lots of new and exciting ways.

Let me just take a quick look. There’s a few questions. Let me just run through those. I’ll take a quick pause here to do that. So the first question which got three votes is, is there a testnet available for Polymesh for us to take it for a spin? I mean the answer is that, right now we don’t have a public testnet. Our roadmap, I have a slide at the end of our road map, on our roadmap is to have a public testnet in Q2 this year. So that’s fairly soon now.

Having said that, if you want to take it for a spin, I mean our codebase is public. I have a link to the codebase on the last slide. But I think if you Google Polymath network, or Polymesh in GitHub, you’ll get to it. And the codebase is open so you can certainly pull the [inaudible 00:26:01] or develop branch, compile it and run a private testnet if you want to take it for a spin.

And there are instructions on the read me on how to do that. And I said, we’re aiming to have a public testnet in Q2, so pretty soon. So that was one question. Will the requirements from becoming a permission validator Polymesh fan become one?

So this is an area that we’re still working through. As I say, the reasons we’re permissioning validators is to make sure that every validator is a … Is a publicly identifiable organization or a company that has a great reputation and that that adds to the security network. So we’re still, I would say we’re still working through exactly what those criteria are. We’re talking to a number of organizations that [inaudible 00:26:50] match that specification.

So probably this is a case of stay posted, but I can say that the intention is really to have, let’s say public, well-known organizations, which can be, let’s say publicly identified and have a public reputation. Let’s keep going through the questions. So if you look at the current validator Kusama, will they after a possible KYC, also be able to validate?

I guess this is probably somewhat similar to the previous question. So yeah. I’d say we’re still working through what the criteria should be for a permission validator in Polymesh. So I’ll leave that one. And they said, where would an industry specific regulator requirement fits in, runtime module versus smart extension?

So this is an interesting question. It can get detailed quite quickly, but so at the runtime module level, we do have … So we have compliance built in at the runtime module level, and that compliance is built in is really compliance based around identity and claims. And I’ll talk about this a little bit more in the next slide, but yeah, everything in Polymesh is mediated by identities. Identities can collect claims, maybe a KYC claim or a credited claim or a claim that you’re operating in a particular jurisdiction.

And [inaudible 00:28:18] can build compliance rules that leverage those claims, and maybe you want to say, only want to allow transfers of my asset to investors which have a UK jurisdiction and have a KYC claim from a particular KYC provider and that type of thing. So you can have these claim-based compliance rules. All of that happens at the runtime module level. Where smart extensions come in is where you need more like esoteric or asset-specific logic.

So for example, maybe [inaudible 00:28:56] transfers assets issued in a particular way we have, maybe some sort of volume restrictions of how many ads you can transfer in a particular, say, 24-hour period. [inaudible 00:29:07] more [inaudible 00:29:08] logic [inaudible 00:29:09] the smart extension level. Where you would [inaudible 00:29:13] build that logic as a smart extension, or as a smart contract and then attach it to your assets and your asset would then validate that logic every time a transfer was made.

So it’s a great question. Some compliances [inaudible 00:29:23] the runtime module level, a claim-based compliance, and then more like asset-specific compliance is that smart extension level. Then there’s one more question which is, will smart extensions be activated by a smart contract platform on Polymesh since it won’t be runtime modules?

I’m trying to stay if I … I’m not sure I exactly follow that. I mean, maybe if it’s asking [inaudible 00:29:55] smart extensions, the idea is that [inaudible 00:29:58].

Okay. Great. So I was just answering … Okay, I answered the last question. So the last question, is what will the performance of Polymesh be? I would say this is something we’re still profiling and improving, so I don’t have any exact metrics around the performance to share right now.

Okay. Let me flip to the next slide. Okay. So yeah, so this slide is … This slide shows the overall architecture of the system. So we’ve talked actually a lot about some of these pieces already. There’s one area I wanted to touch on a little bit, which is the bottom row, which is the open finance protocols.

So one of the really interesting innovative areas in it, making a huge explosion of interest in over the last probably 12 months, maybe a little bit more, is around these sort of DeFi protocols or open finance protocols.

So some of the examples are listed at the bottom here, things like DEXs, lending, lending protocols and so on. We want Polymesh to be a platform that really fosters this type of innovation. And I think it’s also quite uniquely positioned on this side of things.

So what does Polymesh bring to the space, which is kind of unique and novel? I think there’s two key things. The first is that, because we have all this layer one functionality and smart extensions that help you create and manage regulated assets, it means that today’s DeFi protocols mainly deal with, I would say utility assets or things like Ether, which are native coins. And one of the holy grails of DeFi is to be able to expand that to also start including regulated assets, which one of the big problems with using things like ether and bat and these other kinds of utility tokens as collateral is that the prices of these things tend to be highly correlated, when the price of Bitcoin drops, price of Ether drops and so on and so forth. And of course they’re not exactly correlated, but they are highly correlated.

So if you can start bringing in regulated assets that really are very uncorrelated to crypto assets, that allows you to change some of the characteristics of these DeFi protocols and gives a lot more stability around use of collateral and these types of things.

Also being able to borrow and lend regulated assets opens up a whole range of different types of protocols, which are interesting both to I guess existing DeFi users as well as more traditional financial market innovators and investors.

So that’s one area that Polymesh brings in these regulated assets, which have all the things we talked about in the previous slide. And the other really important thing that Polymesh provides, it provides civil protection. So civil protection is this idea that’s on Ethereum or most say, public networks like Bitcoin and Ethereum, it’s very easy to spin up new addresses and new identities. You can create a script that creates thousands of new Ethereum addresses very quickly. And it’s very hard, if you’re building a DeFi protocol or an open finance protocol, it’s very hard to sort of tell whether you have one user masquerading as a thousand addresses or a thousand users each with their own address or somewhere in between.

And this brings in lots of challenges around things like governance for these decentralized financial protocols. And also, it’s really what drives this idea that most of the current DeFi protocols are based around over-collateralization.

So because you don’t have any civil protection, you don’t have a strong idea of identity, the way you protect yourself is you make sure that any lending or borrowing rather is fully collateralized or over-collateralized, which works. It seems to be working pretty well right now. But I, probably in the longer term, become a less attractive way of deploying capital.

So what Polymesh allows is it dramatically increases this design space for these DeFi or open finance protocols. And being able to use civil protection lets you build out these kinds of interesting governance and signaling schemes around DeFi protocols. And maybe rather than just relying on over-collateralization, allows you to rely on maybe some mixture of reputation and collateral to guarantee good behavior.

So that is an area I think that’s worth focusing on. I think DeFi or DeFi is a really interesting area. I think it’s in one area which really, when people talk about killer apps for blockchains and so on, it’s one area that really seems to have taken off and provide genuine additional utility over what’s possible with paper assets, let’s say, or traditional assets. And that’s something we’re really focused on making sure that Polymesh is this great environment to foster these for third party innovative DeFi protocols that can come into the platform, build their protocol on top of our platform, which can leverage all of our primitives and smart extensions.

Okay. So okay. I’ll answer this one question just as we go. So there was a question that says, how’s code protected from competitors? They can copy Polymath hard work and try to sell it before Polymesh. I mean, certainly our code is open source. That is true. I think probably the answer here is similar to the answer probably for many different blockchains. Ethereum also is open source and many other blockchains are open source.

I think the … I’m trying to remember exactly what the phrase is, something, you can copy the code but you can’t copy the network of participants. And Polymath has been in industry for a good amount of time now. We have a great brand. We have a huge network of stakeholders and relationships and partnerships. I think you go to the Polymesh website and look for partners, some are in the top menu, you can see a list of all of our service providers and we have a really vibrant large list of service providers. So I think that’s … Now that’s really a strategy there, is that they can … Obviously, you can copy code but where they can’t copy is our traction, our adoption and our network and relationships.

The next question is, are you afraid that your permission chain infrastructure and KYC requirements will hinder adoption from crypto DeFi investors? I mean, I would say this is definitely something we’re really focused on. So we have, Polymath has a great product team. Has a truly world-class product team, and as a company, we’re focused on solving real problems, right?

So we’re not interested in just building tech for the sake of tech, even if that technology is really cool. We’re always, our approach is always to start from a problem and then figure out what technology is most appropriate to solve that. So we are … We’re a very product-focused company. We’re focused on solving real problems.

And one of the big issues in the crypto space at the moment is UX friction, user friction. And so we’re highly aware of that. We put a lot of thought, effort and design into making sure we minimize those friction points for investors, both traditional investors and I guess you could say crypto or DeFi-type investors. And so it’s something we think deeply about and it’s something that we will be getting Q2 this year, we’ll be releasing a whole bunch of tooling around the chain. And hopefully, when people start playing that tooling, the effort we put into reducing that friction will be apparent. So all I can say, I guess, is that we are thinking a lot about this and aware that this is one of the trade offs around this approach.

Okay. So how are we doing for time? We’re at 40 minutes. Okay. I’m going to flip to the next slide. All right. Okay. So I’m going to talk a little bit about identity. So identity is one of the core design principles of Polymesh. I’m going to talk this very briefly because I think we’re 40 minutes in, but the idea is that, one of the things that differentiates Polymesh from other blockchains is that, so typically in a blockchain, when you think like Ethereum or Kusama or Polkadot, every transaction is associated with a public key.

And that’s the linkage you have between something off chain and something on chain. In Polymesh, every transaction is associated with an identity. So an identity is a collection of claims. So you can see a couple of claims on the slide. So an identity is really just a collection of claims that other people have made about your identity. So that might include a KYC provider, a testing jurisdiction, or somebody else in testing to whether or not you’re an accredited or sophisticated investor and so on.

And every single transaction in Polymesh is associated with some identity. So what this gives you, is it gives you a very clear sort of network topology and provenance for transactions because everything that happens on chain is associated with these identities. And that’s one really key difference between Polymesh and some other blockchains that are out there.

In terms of our approach to identity, there are some sort of W3C standards around decentralized or self-sovereign identity, decentralized identifiers and so on. And we’ve tried to cleave to those [inaudible 00:42:14] where it makes sense. Our implementation identity is very much focused on regulated assets and compliance and regulated securities and capital markets. But where it makes sense, we’ve used, we’ve followed standards where it makes sense.

I think that covers that slide. Let me just click to the next slide. So yeah. So one of the other aspects of identity is key management. So every transaction has to go through one of these identities, but you still have to be able to authenticate access to an identity. Again, every user needs a way to control or manage access and permissions around their identity.

So the way we’ve approached this is that every identity has a master key. So you can think of this maybe as being your hardware wallet or maybe a multisig, where the signatories of that multisig are members of your organization. And that’s like an admin key, it has total control over the identity. But you can also create one or more signing keys, where assigning key provides a way to authenticate identity, but to have more constrained roles or permissions.

So for example, it may be that you want to handout assigning key to one of your employees but you want to limit that person to only be able to deal with a certain asset or assets or maybe only be able to issue claims against other identities and not be able to transfer your assets and so on.

So you can have this granular permissions and role-based permissions at the signing key level, which means that every owner of an identity can sort of manage their security requirement and needs themselves and have this fine grain control. And also, delegate activities to other individuals.

So I think in the slide … [inaudible 00:44:14] back to the slide. So in the slide, we’re showing … So you have this identity of the Apple issuer, which has a bunch of signing keys. Some of the signing deeds might be multisig, some of them might be just external addresses. In this example, one of the signing keys is actually another identity, which is a transfer agent identity. So it gives you this very flexible way to model different types of organizations and different ways that organizations interact and typologies of these different types of organizations.

The other thing that should be mentioned is that all of your assets, all of your security, I guess security tokens are held at … Or are associated with a particular identity. And they may be organized into portfolios under that identity, but ultimately, all of these kinds of security assets roll up to a particular identity. So for asset issuers, you always have this very clear idea around compliance and so on.

Okay. And so I have a couple of more slides left. So in terms of roadmap, I mean it’s pretty clear here. I think I mentioned before that we’re … So we released our [inaudible 00:45:25] a few weeks ago, which you can find on our website which is polymath.network. And then, we will be releasing a public testnet in Q2 as the next major, major phase. And this likely, and we’re still planning out the details, but we may see some of these things being [inaudible 00:45:44].

But yeah, our roadmap is to have a public testnet in Q2 for everyone to be able to play around with. I think as mentioned, so our codebase is public, it’s open source. So if there are any [inaudible 00:46:01] on the call, I highly recommend going to the codebase, having a poke around the main codebase for core blockchains [inaudible 00:46:12], which is what Substrate itself is written in. And you can see our … You can go and see our activity, our core requests and so on, going through on that network. And I think as I mentioned, if you’re super interested, you can pull the code, build it [inaudible 00:46:25] and interact with that [inaudible 00:46:28]. There’s instructions on how to do that on the read me of the [inaudible 00:46:31].

One thing I want to mention is that we are hiring. So in particular, if there are any Full-Stack developers on the call or any dev ops experts on the fall, then we are hiring. And we’re always instead in hearing from developers or the developer community. So our email address is just there, or you can reach out to me directly. I’m adam@polymath.network. So you can reach out to me directly or to our recruiting email address. But we’d love to hear from anyone out there who’s interested in security tokens or in building blockchains.

That’s it on the slide side. And I see there’s one more question. So let me stick with it. So it says, do you expect companies utilizing third-party services for token issuance and trading, and what are your thoughts on securing the master key?

So let me do the second bit first. So securing the master keys, clearly a complicated topic. I mean, one of the advantages of working with Substrate is that there were certain types of integration which are generally useful. So things like hardware wallet integrations. So we were just talking to one of the companies that received a Web3 grant to build a hardware wallet integration for Kusama, and then maybe Polkadot as well.

Now of course there might be some customization required, particularly for Polymath, but … Or Polymesh, but a lot of the basic work is already dealt with at the Substrate there. So certainly, hardware wallets I guess is the often quoted way of having a secure master key. And there’s always ways to … When you have multiple hardware wallets, if you want some redundancy and so on.

So Polymesh also has multi sigs, where the keys of that multisig can hide to be other identities or hardware wallets or in fact even other multi signs for that matter. So if you’re an organization, it may be that multisig wallet is the most appropriate [inaudible 00:48:32], where you require two or three signatories to authorize a transaction. And yeah, and then there will be others I guess … Probably more flexible key management software, things like Chrome plugins and that type of wallet software, which may be appropriate maybe not for managing a master key, but for managing signing keys that have limited permissions.

The first part of the question is do you expect companies utilizing third-party services for token issuance and trading? So if I interpreted this correctly, I mean it’s … So it’s to say, definitely a Polymath approach is to build functionality, not just in house, but through partnerships and integrations. So whether that’s integrations with exchanges or custodians or transfer agents or KYC providers, we’re not planning on building … That’s all … So Polymath is not going to be building all of that stuff, right? That type of functionality, we’ll achieve through integrations with our existing partners, which we have many from our Ethereum protocol and obviously new partners that maybe make sense on Polymesh specifically. So absolutely, we expect companies to be … Third parties or companies to be interacting with the blockchain and managing token issuance and trading on behalf of other people.

And then there’s one new question, which is, is it possible to do reporting to regulators through Polymesh and taxes? Is a great question. I mean, I think one of the … We’ve had lots of conversations with different regulators, and of course regulators are not like a unified body but every jurisdiction, every region has its own regulator. So there’s probably no single answer.

When I think about the advantages to regulators of putting securities on a public blockchain, I think there’s a couple of key advantages. One is that you can do your compliance in real time. So traditionally, compliance would be a [inaudible 00:50:36] fact activity where maybe every six months, a regulator comes in and audits your books and records, make sure that you’ve been reporting things correctly and you’ve been enforcing compliance correctly.

With protocols or blockchains like Polymesh, all of that compliance can be done in real time as transfers are happening. So you don’t have to come and do a retrospective audit, you just have to audit that an asset has the correct compliance rules attached to it. And then you have this guarantee that those compliance rules are respected as transfers of that asset are happening.

So that’s one big advantage to regulators. And the other is that, you have this transparency, certainly for non-confidential assets. You have a single source of truth, which is blockchain. And let’s say the ledger of the blockchain. And that can be used for all sorts of things, [inaudible 00:51:24] reporting, tax reporting and so on.

With confidential assets, it becomes a little bit more complex [inaudible 00:51:30]. You want my data to be available to [inaudible 00:51:36] so they can be reporting but not available to the general public. So it comes a little bit more nuanced and complex. And I guess tax is in a similar case. I don’t think there’s any plans to like build tax software in house at Polymath, but absolutely, having say, a third party organization building, or let’s say integrating with Polymesh, that you can put in your raw data from the Polymesh ledger to calculate your taxes and do your tax returns, would seem to make a ton of sense.

Okay. I think that is all of the questions I see in the Q&A. I’m just having a quick look through the comments, but I think that’s all answered as well. Back over to you, Dan.

Dan Reecer:

Yeah. If anyone has any more questions, speak up in the chat or the, ask a question section. If not, we can send a followup email with some of these links and email addresses that Adam mentioned in the presentation here along with the link to the video. But I just want to say thanks Adam, for the great insightful presentation and thanks for coming on and presenting to us.

Adam Dossa:

No, great. Thank you very much for having me and some great questions. So that’s always great to hear.

Dan Reecer:

All right, thanks everybody. Have a good day.