Why Develop Modules on Top of Polymath?
Hint: To get paid while creating better financial markets!
The Polymath implementation of the security token standard allows developers to build new types of security token functionality as modules, which can be dynamically attached to a security token by the issuer of that token.
So, why should you build a new module on top of Polymath?
This applies to anyone who has experience with building smart contracts and wants to turn their skill into a new income stream while having a direct influence on the financial revolution.
If you build one of the modules on our module marketplace roadmap, they come with different payment options:
The Vesting Wallet Module is one of the modules that a developer can build with us. Since Polymath is paying a bounty for the module to be developed, the developer has a few options:
1. Once developed and audited, the developer gets paid a set amount. Polymath would then maintain full IP rights to the code and will set fees for issuers to use the module.
2. Once developed, the developer sets a maximum cap (in USD) for the setup fee that the developer can charge to STO Issuers when using their module.
Basically, the choice is between being paid upfront by Polymath with Polymath owning the IP (developer receives a one time payment), or having the developer forego a Polymath payment to freely set the price for their module (developer receives payments based on usage of their module).
In the case where the developer sets their own price and charges fees for the module, there is the option to specify a one-off upfront `setupCost` and an additional `_usageCost` which is triggered every time there is a particular action (e.g. an investor being whitelisted in a `TransferManager` module).
Additionally, there is another component a developer can leverage called `subscription cost`. This is a kind of periodic cost that is being paid by the Issuer until the Issuer decides to remove the module. This component has not yet been implemented in our protocol but it currently in the pipeline.
For example: Vesting Wallet Module
Suppose a company with a security token adds one employee and sets up an annual vesting program. For this, the contract would have the functionality of charging a small fee in POLY to the issuer and that cost will directly be transferred to the developer or to the factory where the developer can receive the fee accordingly.
As you can see there are many reasons why building a module on top of Polymath is beneficial, and developers have the option to choose between being paid in the short term (taking the POLY bounty) or reaping long term benefits (charging fees).
Other beneficial aspects to building with Polymath are:
- Gaining Access to an elite open source developer community — We are a leading project shaping the security token space, and by building with Polymath, you join the founding movement revolutionizing the securities and financial industry.
- Streamlining Recruitment — think of building a module as a test trial to become an official full-time member of the Polymath team. We care about what you can build. Show us :)
Getting Started
Please check the following links for our current module/features Issues that you can tackle to get started (Polymath Github Issues, Solidified Bug Bounty Program and Gitcoin Bug Bounty Program):
If you have any questions about the code or this walkthrough we would love to hear from you! Join our Gitter: https://gitter.im/polymathnetwork and ask away!
Exploring Polymath Core
Are you a developer interested in how securities tokens work? Take a look at our Github repo and feel free to ask any questions and submit any issues you find.
Follow Us!
Website: https://polymath.network
Reddit: https://reddit.com/r/polymathnetwork
Twitter: https://twitter.com/polymathnetwork
Telegram Group: https://t.me/polymathnetwork
Polymath GitHub: https://www.github.com/polymathnetwork
Polymath Gitter: https://gitter.im/PolymathNetwork/
We’re Hiring! Build the future of finance with us: https://polymath.bamboohr.com/jobs/
