Token generation network Polymath releases core 2.0.0

Token generation platform Polymath (POLY) has announced the release of core version 2.0.0. This 2.0.0 release comes with a lot of improvements. However, in order to introduce some of these new features, the Polymath team had to implement breaking changes to the underlying Security Token smart contract and many other registries and modules, which inevitably break backward 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 deploying a security token after November 22nd, 2018 — when the new smart contracts are deployed and made available on the Polymath dApp — nothing needs to be done; an issuer will be able to make use of the new features right away. If previously deployed a token using the existing version of the smart contracts (v1.3.0), and would like to migrate to v2.0.0, Polymath will soon release instructions to make the transition as seamless as possible

New in v2.0.0

Polymath Core v2.0.0 brings several new features and improvements, see below for the most important updates:

Pegged to Fiat Offering

Polymath has introduced a new type of Security Token Offering that will allow issuers to conduct fundraising in ETH, POLY and/or DAI with the price pegged to fiat. In order to achieve that, Polymath partnered with MakerDAO who has provided a POLY to USD price feed as well as their well-known ETH to USD price feed.

The Pegged to Fiat STO (USD Tiered STO 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.
• The ability for issuers to raise funds using any stable coin along with DAI

Forced Transfers

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/token holder 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 token holder 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.

The Polymath acknowledged 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, Polymath added a new pair of modules that allowed on-chain dividends distribution in ETH or any ERC20 token. With v2.0.0 Polymath is 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, Polymath has taken the first steps towards smart contract upgradeability, allowing the team to future-proof the protocol by supporting new features without requiring them 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.

The SecurityTokenRegistry and ModuleRegistry contracts 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 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 users explore the contract on Etherscan they 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 users enter the SecurityTokenRegistry contract address and its ABI, they 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, users can work with the methods you know from the SecurityTokenRegistry but dealing with the right data stored on the proxy.

The Polymath team says they 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. The team says it feels 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.

For more details, also refer to the v2.0.0 release notes.

To date, more than 100 token symbols have registered on the platform, with more than 40 security tokens being deployed to the Polymath network.