From rogue ideas to full-fledged products: The Polymesh SDK and Polymesh-local

Note: This blog post comes from Polymath’s full-stack lead developer Jeremias Díaz.

For me, one of the best parts about working as a developer at Polymath is the freedom to pursue and self-start projects. The environment is one where you really have the freedom to develop an idea to the point where you can reasonably assess whether it can become useful for the company, and even make it into a full-fledged product. 

Almost all of the projects I currently work– be it by coding, reviewing, or designing– were formed in this way. Initially rogue ideas, they became tiny little tools or libraries developed with the purpose of making our own lives easier, and eventually grew into flagship products we now offer to external parties to facilitate integrations with our technology. In this blog post, I present two such projects: the Polymesh SDK and Polymesh-local. 

Polymesh SDK

‍Before Polymesh was even an idea, I was part of the team in charge of building Polymath’s Token Studio; a user interface (UI) that interacts with Polymath Ethereum Smart Contracts. While building that UI, the team lead and I realized it would be much easier for us to manage all direct interaction with the chain in a separate library, which we decided to call the “Polymath SDK”. The separate library would allow us to avoid code repetition in the long run while providing a single point of failure when it came to encoding/decoding data as we wrote to and read from the chain. 

We started out with a few wrapper classes for the most relevant smart contracts, and a few utility functions to handle and validate data. As the amount of protocol features we covered in the UI grew, so did the SDK library, until it became a project in itself. It soon had transaction queues, domain specific validation, support for multiple protocol versions, roles and permissions, and more. We had essentially ended up building an entire layer on top of the original protocol. 

The intent then moved from providing internal utility to ourselves to providing an interface that any developer could use to communicate with our protocol, with little to no knowledge about blockchain or smart contracts. Of course, this would take some time to design and implement, so we negotiated with the product team until they agreed that developing the SDK would save more time than it would cost in the long run without it. When they later saw the potential the library granted in terms of third-party integrations, an SDK team was assembled and the library was raised from a small internal tool to an almost full-fledged Polymath product, which many external parties started using. 

Fast forward a few months to when we were planning how to build Polymesh. At this point, I was working exclusively on the Polymath SDK as the technical lead, so it only seemed natural that I would move towards building the Polymesh equivalent. In building the Polymesh SDK, I used a lot of what I had learned from the previous SDK. The experience was invaluable, and both our team and our integration partners have given nothing but positive feedback regarding its usability and clarity. 

Polymesh-local

While working on Token Studio and the Polymath SDK, we relied heavily on Ganache (a personal Ethereum blockchain used for development and local testing). The monorepo where both projects lived also contained a snapshot of the chain with the latest version of the protocol deployed to it, as well as yarn scripts to launch Ganache with specific parameters, which allowed us to load the snapshot and play around with the contracts in a safe environment. In the end, we had three simultaneous versions of the protocol coexisting in our development scheme. 

Knowing that keeping track of which branch held snapshots for which protocol version would eventually drive us insane, I took the time to hack together a small command-line interface (CLI) utility called “local-blockchain” and publish it to NPM. This tool basically allowed anyone to spin up a simulated Ethereum environment with everything they needed to play around with the Polymath smart contracts. 

Whenever I found myself with some extra time, I would add features to this “local-blockchain” tool. Some were fairly simple, like selecting a protocol version or running an instance with all versions deployed for migration testing. Others were more complex, like allowing users to pass a configuration file that specified initial data to be written into the chain at launch. With those files, a user could specify any number of assets to be created, their whitelists, which addresses held which amounts, and existing STOs and their tiers, and the tools would interpret it and execute the pertinent transactions, writing the data into the chain. 

While the tool was used mostly within my team, it was very impactful. Manual tests that previously took up to 15 minutes to perform were now able to be completed in less than two, with instant block times. The importance of that time reduction should be evident on its own. 

A few months later, I was writing end-to-end tests for an internal project for Polymesh when I became concerned with the testing process. Specifically, I feared that testing against a development chain was problematic. Public development chains tend to be reset frequently, so we can’t rely on existing data for tests. Yet the projects we need to test don’t always have the capability of writing their own testing data, and running specific SDK scripts tailored to each project is not only a lot of work but also adds another point of failure. 

I pitched Polymath’s CTO Adam Dossa the idea of building something similar to my “local-blockchain” package except for Polymesh. He liked the idea, as did the rest of the team, so in my free time I implemented a prototype CLI using the oclif framework and “Polymesh-local” was born. 

The basic idea was to be able to easily run a Polymesh instance locally with certain guarantees about the data that would populate it– like a Polymesh-in-a-box. This would allow you to write end-to-end tests without worrying about testing data being wiped out or modified by others. The beauty of it is that external developers attempting to integrate with Polymesh would be able to use it too and experience those same benefits. 

The CLI uses docker containers behind the scenes and supports several options, like selecting the chain version, reducing block times, and saving/loading data snapshots. On top of that, it also creates containers with other Polymesh related services such as the GQL server, which allows users to access historic event data, providing an integral testing solution for internal and external developers. 

Other team members have since participated heavily on the project, and Polymesh-local is now considered a selling point when talking with potential partners. Like the Polymesh SDK, it’s an example of something that started out as an idea for making our own lives as developers easier and ended up as a serious team-wide project. 
‍

All that being said, these two projects wouldn’t be possible without Polymath’s leadership being open to new ideas and fostering an environment in which employees can take these ideas and grow them into full-fledged products. I’m grateful to have had the chance to do just that with the Polymesh SDK and Polymesh-local, and am excited for more opportunities to develop my ideas into genuine contributions.