The Polymesh Grants Program is officially in gear, and we’re kicking it off with 6 Request for Proposals. Here we provide a bit of background on the projects. Get ready to build!
The Polymesh Grants Program is officially in gear, and we’re kicking it off with 6 Request for Proposals (RFPs).
An RFP is a declaration of interest for others to submit a grant application regarding a specific project. Polymesh RFPs revolve around features and functionality that the Polymesh team deem useful that have yet to be implemented in the Polymesh ecosystem.
You’ll find the full list of initial Polymesh RFPs and related documentation under the grants program on the Polymesh Github. We’ll be updating it with new RFPs regularly, but in the meantime, there are a few key features we’d love to have implemented.
If one of these projects catches your eye and you’re confident you could build and maintain it, feel free to let us know by submitting a grant application (just remember to reference the RFP you’re addressing!).
With that, let’s get into the 6 initial Polymesh RFPs!
The Polymesh Block Explorer with Subscan is great when it comes to viewing generic activity on Polymesh, including the transactions on the blockchain and the tokens that have been issued. However its ‘financial knowledge’ is a bit limited; the Block Explorer can’t parse or share necessary data on identities, securities functionality, or compliance rules.
As a blockchain built for the financial industry, having a finance oriented block explorer is a must for Polymesh. This explorer would be oriented directly to our exact layer 1 data and leverage it to report based on identity, assets, and settlements. You could use it to view and index security tokens issued on Polymesh, provide them with context, and perhaps even track their prices.
If we had to choose, we’d put the finance oriented block explorer first on the list for fulfillment as it would increase the use and value of Polymesh for the financial industry and enable further development in the ecosystem (e.g. by providing a possible starting point for a reporting portal).
It’s important for Polymesh token holders to feel confident that their POLYX can be held securely. Common wisdom in the cryptocurrency community dictates using a hardware wallet, which offers enhanced security.
Wallets allow users to store and manage POLYX tokens and interact with the Polymesh blockchain. Whereas software wallets (e.g. the Polymesh Wallet extension) store keys online, hardware wallets keep the private keys of users secured in “cold” storage (offline) in a hardware device, making hacks highly unlikely.
When it comes to hardware wallets on Polymesh, there’s currently only an integration with Ledger models (the Polymesh Ledger App).
So, one key integration developers could work on would be hardware wallet integration for non-Ledger models to expand users’ options for securing private keys.
As a blockchain for regulated assets, Polymesh and the applications built on top of it need to go beyond base-layer functionality; there needs to be use and value for financial functions more widely.
Trading processes involve a lot of reporting, and luckily the blockchain can help automate much of it. One useful way to make reporting on Polymesh easier for investors would be through a double entry accounting style export.
The report export could record transactions as fully double entry accounting style ledgers, possibly through integration with an accounting program such as QuickBooks or Freshbooks (e.g. the Bitcoin app for QuickBooks).
As-is, the Polymesh Wallet limits the availability of access to Polymesh; many prefer to use an enterprise software wallet to keep their keys safe, or an alternate browser to Google Chrome.
One very useful integration for Polymesh would be an enterprise software wallet integration. This would not only provide new ways to onboard users, but also provide a fiat on-ramp since it would add new ways to buy and sell POLYX tokens.
Since Polymesh is built on the Substrate framework, it’s fairly easy to integrate with any Substrate-based wallet. One great option would be Exodus, a popular wallet used to secure and manage multiple cryptocurrencies with both a mobile and desktop application.
You could also add Polymesh support to an API service such as Zumo, a non-custodial cryptocurrency wallet infrastructure that provides integration with Android, iOS, and Web apps. Zumo makes it easy to integrate with an SDK that’s blockchain agnostic, but there are lots of other API services you could integrate with as well.
Wallet integrations are highly valuable to Polymesh, so the more wallet integrations, the better! Just note some knowledge of key management integrations would be useful.
Just as some users prefer a hardware wallet to safe-keep their POLYX and private keys, some prefer not to rely on physical proximity to a storage device and instead use a mobile wallet.
Mobile Wallet Options are highly useful to Polymesh as they allow a broader range of wallet solutions. These might be custodial solutions that use multi-party computation (MPC) technology to divide and encrypt private keys among multiple parties, or they might be totally self-custodial. Either way, they’re giving Polymesh users more choices on how to secure their private keys and widening accessibility of the network.
An example of how you could approach this RFP would be via WalletConnect, an open protocol that securely connects blockchain wallets to dApps via web3 connections. It’s chain agnostic and can be integrated easily with just a few lines of code.
Hundreds of dApps use WalletConnect to connect with wallets. Integrating Polymesh with WalletConnect’s SDK would permit any of these dApps to communicate with Polymesh’s backend wallet software, enabling them to delegate transaction signing to any arbitrary wallet (including mobile wallets) through QR codes.
When it comes to data streaming from a blockchain, things can get messy very fast. Depending on the software used to grab and report data, new solutions might need to be built from scratch whenever there’s a new use case to use full chain data. This can be confusing as it stirs up issues related to which data is correct, as well as how to best synchronize a multiplicity of systems.
Unfortunately, there isn’t a single source of truth that can stream Polymesh data to all systems. So, one ideal implementation would be a Source Connector for Kafka.
Apache Kafka is one of the most widely used messaging platforms out there, and for good reason: it can serve as a source of truth for data by a number of applications, and it supports schema evolution (meaning you don’t need to resync from scratch whenever there’s an update).
Implementing the source connector on Polymesh would allow all events on Polymesh to be streamed to a multiplicity of systems under the schema evolution, to be used for whatever use case an individual or company desires (e.g. a token issuer wants to configure the connector to only subscribe to events related to their tokens).
And there you have it! Those are our six initial RFPs.
We’ll be continuing to update the RFP tree of our Github with new RFPs in the future. Of course, you’re welcome to propose your own ideas for projects on Polymesh too– all the information you need on applying to grants can be found on Github.