Polymath Core v2.0.0 Release
Two months ago we released Polymath Core v1.3.0 on Ethereum Mainnet. This release was met with great interest as issuers began signing up to use the dApp. To date, more than 100 token symbols have registered on the platform, with more than 40 Security Tokens being deployed to the network.
Since then, we have been working on exciting new features including the introduction of a new type of Security Token Offering that will allow issuers to conduct a fundraise in ETH, POLY and/or DAI with the price pegged to fiat. In order to achieve that, we have partnered with MakerDAO who has provided us with a POLY to USD price feed as well as their well-known ETH to USD price feed.
This 2.0.0 release comes with a lot of goodies, which I’ll explain below, but these improvements come at a price. In order to introduce some of these new features, breaking changes had to be made to the underlying SecurityToken smart contract and many other registries and modules, which inevitably break backwards compatibility.
This means that existing token issuers will only be able to enjoy these new features if they deploy a new token under the 2.0.0 version. If you are deploying a security token after November 22nd, 2018 — when we deploy the new smart contracts and make them available on our dApp — you don’t need to do anything; you’ll be able to make use of the new features right away.
If you previously deployed a token using the existing version of the smart contracts (v1.3.0), and you’d like to migrate to v2.0.0, don’t worry! We’ll provide instructions to make the transition as seamless as possible. Once we release the new version of the dApp that supports 2.0.0, you will be prompted to learn more and upgrade.
What’s New in v2.0.0?
Polymath Core v2.0.0 brings several new features and improvements. In the following paragraphs I’ll introduce some of the most important and relevant changes. For more details, you can also refer to the v2.0.0 release notes:
https://github.com/PolymathNetwork/polymath-core/releases/tag/v2.0.0
Pegged to Fiat Offering
Back when we launched, we released a very simple STO which allowed issuers to raise funds in ETH or POLY. As we engaged with more and more issuers it became evident they were looking for increased flexibility in their offerings, and in particular, they didn’t want to be required to tie their calculations and filing duties to cryptocurrency exchange rate fluctuations.
One way to overcome that problem was to introduce an STO model that pegged all calculations to fiat, typically USD. This way, issuers don’t have to continuously update their numbers when preparing filing documents (because they must report in fiat terms), and they can remove the typically high volatility of cryptocurrency.
For that reason, we are introducing a new STO module that allows the issuer to enter all the parameters of the raise in fiat. For example, when configuring the STO you no longer have to price your security tokens in ETH or POLY; you can price them in USD. Later on, when an investor participates in the STO, they will still send ETH or POLY to the contract, but the number of tokens will be converted to the USD equivalent, and tokens will be minted according to the token price in USD and how much USD the sent ETH or POLY represents.
As an issuer, you are still receiving ETH or POLY, but this new feature makes the fundraising process easier, since you no longer have to change your targets if cryptocurrency exchange rates go up or down during your raise.
This new feature works by making use of a set of pricing feeds provided by MakerDAO that allows us to query the USD price of both ETH and POLY on-chain. When an investor sends ETH or POLY to the STO smart contract it will fetch the current price from the MakerDAO feed and mint the corresponding amount of tokens based on tokens sent, its price, and the price per security token (denominated in USD as well).
The Pegged to Fiat STO (USDTieredSTO smart contract) introduces a few new features as well:
- Issuers can set multiple tiers with different caps and prices per token (in USD).
- Issuers can define a required minimum investment per investor.
- The issuer has the ability to define an investment cap per non-accredited investor. If a non-accredited investor exceeds their maximum allocation in any single transaction, the ETH / POLY sent in excess is immediately refunded.
There’s one more thing! Since we are partnering with MakerDAO to use their pricing feed for ETH and POLY, we also added the ability for issuers to raise funds using any StableCoin and the dApp will natively support DAI.
Forced Transfers
We recently led the Security Token Roundtable with industry leaders from many different areas including developers, KYC providers, lawyers and transfer agents. One of the most candid debates of that weekend was related to forced transfers. In layman’s terms, forced transfers grant the issuer the ability to take tokens from one account and put them in another account, regardless of whatever other rules / restrictions are in place.
This feature, while controversial to some in the crypto world, allows for use cases that are required for “real-world” securities. For example: In the case of a divorce where a shareholder/tokenholder is required to give 50% of her tokens to her ex-spouse, forced transfers are absolutely necessary. Without forced transfers, it would be impossible to do that if the tokenholder refused to comply with a court order.
The way the protocol handles this functionality is by providing the issuer the ability to assign a 3rd party as a delegate with access to this feature. Once this delegate has been assigned, they can perform forced transfers.
We acknowledge not every issuer would want to have access to this feature, so the protocol allows issuers to turn forced transfers off permanently to signal they will never allow for this kind of transfer to occur.
Support for Tax Withholding and Address Exclusion on Dividends
In the previous release, we added a new pair of modules that allowed on-chain dividends distribution in ETH or any ERC20 token. With v2.0.0 we are relaunching these modules with a few new features: tax withholding and address exclusion.
Tax withholding allows the issuer to assign how much eth and/or tokens they want to withhold from dividends owed to investors. For example, if Alice is supposed to get 10 eth in dividends and it was determined that the issuer is supposed to withhold 25% — in accordance to off-chain calculations that depend on the jurisdiction of the company and of the investor — then Alice is only going to be able to withdraw 7.5 eth and the other 2.5 eth withheld will remain in the dividend contract waiting for the issuer to withdraw them and forward them to the corresponding tax agency.
Address exclusion allows the issuer to exclude certain accounts with respect to dividend payments. Dividends are calculated by taking the total supply of tokens, looking at how many tokens a given account has and calculating what percentage of the total supply that balance represents. The problem with this approach is that there might be some balances that the issuer might want to exclude from this calculation.
For example, the reserve wallet. Let’s say token ABC has a total supply of 1 million tokens, of which 50% is held by the reserve wallet and 5 token holders have 10% each. Without being able to exclude the reserve wallet from this calculation, if the issuer were to post dividends worth 10 eth, each investor would get 1 eth and the reserve wallet would be entitled to 5 eth, which makes little sense. What makes more sense is for the reserve wallet to be excluded and for it to receive 0 eth, while the rest of the investors receive 1/5th of the funds allocated towards dividends. Behind the scenes, the address exclusion feature does not count the excluded address, so instead of basing the dividend payment off the total supply of 1mm tokens, it bases it off the total supply (1mm) minus the balances of the excluded address(es) (500k in this case).
Support for In-Place Upgradeability
In this version we have taken the first steps towards smart contract upgradeability, allowing us to future-proof the protocol by supporting new features without requiring us to redeploy these contracts and to migrate old data. Redeploying contracts and migrating old data is what will happen when this release hits Mainnet in November (More information about this at the end of the article).
We started with the SecurityTokenRegistry and ModuleRegistry contracts which now support in-place upgradeability through the use of Proxy Libraries and EternalStorage contracts. By using this pattern, one can provide new functionality by replacing the smart contract holding the logic while keeping the smart contract that holds the data unchanged.
One of the drawbacks of the approach we’ve taken to upgradeability is that it makes exploring the data on the contract much harder. Since the SecurityTokenRegistry contract is now storing just the logic, when you explore the contract on Etherscan you can read the verified code but not the data, since it is stored on a different contract. The same happens if you try to explore the data on MyCrypto/MyEtherWallet. If you enter the SecurityTokenRegistry contract address and its ABI, you will be able to access the contract’s methods, but the data returned would be junk.
One way to mitigate this when trying to interact with the SecurityTokenRegistry contract on MyCrypto/MyEtherWallet is to instead access the SecurityTokenRegistryProxy which holds the real data but using the SecurityTokenRegistry’s ABI. That way, you can work with the methods you know from the SecurityTokenRegistry but dealing with the right data stored on the proxy.
We are currently exploring making other smart contracts upgradeable but such a process requires a lot of effort to make sure the process doesn’t introduce any security issues. We also feel that this process causes obfuscation, as explained above, which isn’t suitable for every contract, especially the actual SecurityToken contract or the STOs which need to be as transparent as possible.
What Else We’ve Been Up To
The team keeps growing!
September and October have been very busy months for Polymath as a whole, but especially for the Solidity team. The team has grown by 100% with the addition of: 2 new Solidity developers, a senior Solidity developer, and a full-stack developer.
Gitcoin Bounties and Volume Restriction Transfer Managers
During September we also kicked-off the development of a handful of transfer management modules by launching bounties on www.gitcoin.co.
The reception for these bounties was terrific, with developers starting to work on them the very same day we published them. All of the external developer work revolved around stand-alone modules that deal with volume transfer restrictions. For example, the Single Trade Volume Restriction Transfer Manager allows the issuer to set a limit to how many tokens can be transacted in a single operation. Another one is the Lockup Volume Restriction Transfer Manager which allows the issuer to lock up tokens in a wallet according to a schedule akin to vesting, so investors can only transfer part of their token balance according to the schedule set for them.
Right now we are in the process of reviewing the code and we’ll be releasing these new modules as they are finished and integrated in upcoming weeks.
You can take a look at other Volume Restriction Transfer Managers being built right now on our Github: https://github.com/PolymathNetwork/polymath-core/issues
Upgrading to v2.0.0
If you’ve gotten this far you are probably as excited as we are about this new release and the features it includes, and you might be wondering what to do next in order to be able to work with them.
If you have already used our dApp to reserve a ticker or deploy a token, you should have received an email with instructions by now explaining the migration process and next steps. If you haven’t heard from us by now, please submit a support ticket on our customer support platform: https://polymath.zendesk.com/hc/en-us/requests/new
If you haven’t yet deployed a security token with Polymath, the dApp will automatically use the 2.0.0 smart contracts starting on November 22nd, and you will be able to make use of these new features.
Joining Polymath
Do you want to join the security token revolution? We are growing rapidly and always looking for high quality talent. Check out our careers page at https://polymath.bamboohr.com/jobs/ to apply!
About Polymath
Polymath Network (Polymath) is a decentralized platform that makes it easy to create security tokens. The platform simplifies the complex technical challenges of creating a security token and aims to bring the multi-trillion dollar financial securities market to the blockchain.
