We’ve been gearing up for Mainnet launch, all thanks to our dedicated and hardworking team To give you a behind-the-scenes look into building Polymesh, we spoke to a few of our developers.
Here we hear from members of the back-end team, SDK team, and front-end team to find out what exactly they’ve been working on for Polymesh, where they overlap and interact with each other, and what they found challenging and interesting when it comes to building a blockchain specifically for securities.
I’m the Senior Manager of the Back-End team. Our daily responsibility is to develop the solutions that facilitate the integration of the Polymesh blockchain with the institutions and different service providers (i.e custodians, exchanges, transfer agents, etc.), and facilitate data indexing services for the dApps.
I’m the Senior Manager of the SDK team, which is between the blockchain and front-ends. We provide the tools for them to interact with each other.
I’m the Senior Manager of Global Tools, meaning the front-end team. We primarily work on the apps and whatever a regular user uses, although we might also work on other things here and there, like our CDD service.
On the back-end team, developing data reporting services and ensuring they are live and running to facilitate dApps and client integrations. This means building an indexing service that will gather the data from the blockchain and facilitate the structured data caching to dApps. For example, if you want to create the cap table for a particular asset, our indexer can give the required data using our graphQL APIs that will allow us to create a cap table of an asset.
I’ve been working for the past few years in SDK, a tool to help developers interact with and integrate their systems to Polymesh. Our user interfaces are using SDK to communicate with the chain, and they use it every time they try to read or write into the blockchain. The SDK makes the process easier for developers since they do not need to know anything about how the chain actually works and its APIs, they only need to know TypeScript (one of the most common programming languages) and UI’s can interact easily with Polymesh.
We collaborate with Core and Tooling teams because requests and requirements can come either. For example, they might come directly from UIs, or from a new feature that needs implementing in the chain to be made available for use by any developer.
One of the things we noticed at the beginning of the ITN were problems with users being onboarded to the chain. In an attempt to make it as frictionless and easy as possible for users, we began building a CDD service to streamline aspects that can happen on-chain for any CDD provider that integrates with us, with Netki as our pilot. We went through a couple of iterations of how to build it and settled on trying to make it as highly available as possible, with 100 percent uptime. We opted into using AWS as a technology and a lot of their server-less functions.
When it came to collaborating with Netki (our pilot program), we began by building it on our end first, with the idea of making it as easy as possible for new CDD providers to integrate with. This was important because the CDD process is a barrier of entry for our blockchain since all users need to be verified.
First, we built the core and fundamentals of the system and figured out how it will interact with the chain. We then began interacting with Netki and figuring out what they would need to integrate with us. There was a lot of back and forth in figuring out the nuances between both, and how they would integrate with each other. For example, our entire app is built on desktop, but Netki’s onboarding app is a mobile app. We had to figure out how to handoff between the desktop, mobile, and the back-end to get everyone through the onboarding process. We’ve struck a balance mainly using emails. Overall, the CDD service was a nice complex project and fun to create.
One challenge is indexing. We were originally using older technology, specifically Harvester, but it was kind of like a black-box for us because we didn’t have that much experience with it. It was vaguely wired up (it has a lot of sub-modules) and that made things very hard in terms of testing and release management.
We wanted to avoid this structure and worked hard to ensure that we didn’t have this kind of solution within the back-end team. Ultimately, we removed and replaced the technology with SubQuery. It was a challenge because we had to make sure that we migrated the right set of data from Harvester to SubQuery. We didn’t want to lose any data, so we built a custom comparator to compare the data indexed by Harvester and SubQuery. This helped us improve SubQuery to get the same data and also allowed us to find bugs in the existing decoder we were using.
Another challenge is having some kind of center or one-stop testing solution on the development side. For our product, we need to make sure the chain is running and providing data, and for this we need indexes, but there are a lot of things needed within each of them. Ideally, we build an in-house solution called Polymesh-local which has the containers of the different services and a snapshot of the Polymesh chain data which gives the pre-state to test and give a holistic feel of integration testing.
When trying to make it easier for UIs to work with Polymesh, the level of abstraction can be a challenge. We try to abstract the complexity of blockchains and Substrate (the framework we are using for the blockchain) and make it simpler and easier to use. We want to let people forget about what’s happening behind our API and just keep the interface explicit about what they are trying to do. In other words, “hide the blockchain”.
We’ve faced some problems with the library we were using to communicate with the chain. Polkadot-JS is the official tool to communicate with Substrate-based blockchains, but we experienced a few problems because it wasn’t working for Polymesh in the way we wanted it to. However, being an open-source project, we were able to collaborate, make fixes, and add new features. Now those fixes and solutions are available for anyone who wants to interact with any of these blockchains. It’s awesome because we’re sharing the knowledge with the wider community.
Early on, it was getting the engineers acquainted with blockchain. A lot of the engineers on our team were not from a blockchain background, they’re full-stack engineers who had to learn the specificity of the blockchain itself and figure out the domain-specific things that Polymesh is trying to accomplish.
At the onset of the project, we were doing a lot of things manually, learning new technologies, and trying to learn and understand Substrate and Polkadot-JS together, as well as gain this domain-specific knowledge for Polymesh.
What made it easier was that the SDK team, led by Victor, was able to take a lot of the complexity away and put it behind the SDK. Essentially, they took a lot of the functions available on the blockchain and simplified them to be more business-driven, narrowing the scope. For example, if I was to create a ticker, before I would need to use Polkadot-JS, have the schema loaded into the app, and then use the extrinsic (function) which would require data to be sanitized for use. The SDK removes all that, so that I only have to use a function that is purpose-built for us. We just put the asset name with no manipulation of the data and it just works.
The gist of the problem that we’re trying to solve – having securities on the blockchain – and how it can increase transparency, eliminate T+2 settlement time and its resulting friction, and significantly reduce the operational costs related to securities trading. On the blockchain, much paperwork will be removed and you can easily transfer private equity to someone else, or tokenize your houses and real estate easily. The concept of asset ownership is working well in terms of real-use cases for securities or any assets with value.
One thing I was surprised by in this project is the role and significance of regulation. I’ve learned a lot about how the financial market works in terms of compliance and what you can do versus cannot do– I wasn’t aware of most of this previously, but it’s really good to know.
I started at Polymath when we were still working with Ethereum. It was a great experience going through the new ecosystem of our new blockchain. I learned a lot about Substrate, Polymesh, and how blockchains work and interact with each other, as well as why we as a company were learning how to deal with the problems we’re trying to solve. With a lot of people learning, it was also easier to share knowledge. Right now, we’re a lot of experts!
Even now, the most interesting thing is the people. We have an amazing team comprised of a lot of people with a lot of knowledge and expertise on specific topics. In my team, Jeremias is a genius related to Type-Script language, while on the core team, Mazdak knows almost everything about Rust. Adam Dossa, our CTO, has a lot of knowledge about blockchains and the whole ecosystem. We’re a great team, and we’re always open to new members to collaborate with our common knowledge and help each other improve.
In the last year or two and especially with the pandemic, a lot more people have begun investing, but there are problems with the system, especially when it comes to settlement. That’s what makes me super excited about the project: it provides a way to solve these problems by providing instant settlement. With blockchain, if you buy a share or token, you’ll receive it instantly. It won’t be sitting in some settlement house for 2 days, there isn’t any opportunity for dark pool trades or the other advantages that market makers get. They forego that and have to operate as true agnostic operators. It’s fascinating and fun to think about.
What’s also fascinating is the community. They really care about the product and the underlying asset (the token). Fans are zealous and very interested in what the team is up to and where we’re headed next.