Polymath 3.0 Developer Update #4

Published in

Polymath Network

6 min readNov 5, 2019

Welcome to the fourth issue of our developer updates for Polymath 3.0!
These regular updates are a great way to stay on top of what the developer team is working on, which is largely publicly available on our Github repositories.

As always, we’ll cover updates on these 4 categories:

Smart Contracts
SDK / CLI
Reference Implementations / Guides
The Token Studio Issuer dApp

Before we start, this time we have a brief recap of Mudit Gupta’s and Satyam Agrawal’s visit to Osaka for Devcon 5!

Polymath at Devcon 5

Devcon is the largest Ethereum conference, organized annually by the Ethereum Foundation. This year, our developers, Mudit Gupta and Satyam Agrawal, flew to Osaka to attend Devcon 5.

Polymath has always believed in sharing knowledge, and our developers gave three technical talks at Devcon, continuing our commitment to making educational content accessible. The talks were recorded and will be shared by the Ethereum foundation online for the world to see.

You can read more about their experience at Devcon in their own words. Mudit wrote about it on his blog: https://mudit.blog/devcon-adventure-osaka/

Smart Contracts

Custom Oracles — by Satyam Agrawal

As of right now we are only supporting USD fiat currency in our STOs but once this `custom oracle` feature is rolled out, every new TieredSTO will support any fiat currency provided by the issuer. Let’s dive deep on how we are delivering this.

During configuration time of the TieredSTO, issuers can now provide the denominatedCurrency symbol to let the STO know in which fiat currency they want to raise funds and also provide the custom oracles addresses with the same denominated currency to facilitate an investment through ETH and POLY. These oracle contracts will be owned by the issuers themselves and should be compliant with the IOracle interface to work with the STO.
We will soon release a procedure so issuers can produce compliant oracles. In the future, Polymath itself may provide the support for multiple fiat currency oracles but for now issuers have to provide their own oracle addresses.

If an issuer chooses a stable coin as the sole fund raise type then there is no need to provide custom oracle addresses as the 1:1 ratio is hardcoded for every denominated currency.

For those who want to configure their STO as in previous versions, they don’t need to provide anything else. Just leave the fields empty and the smart contract will automatically fallback on the default currency type (USD) and use default oracle addresses.

Code coverage — by Remon Nashid
Slowly but surely, we continue to increase the code coverage of the Polymath smart contracts. Recently, we have increased the coverage of both LockUpTransferManager and AdvancedPLCRVotingCheckpoint modules.

SDK/CLI

SDK Updates— by Jeremías Díaz

The last two weeks of SDK development have been focused mainly on internal improvements and raising test coverage.

One noteworthy feature is the addition of minting capabilities. Minting has been part of the Token Studio dApp for a long time, however it has only been added to the Polymath SDK in version 2.0.1-beta.42. The shareholders namespace in the Security Token has a new mintTokens function. This procedure allows the user to mint tokens to new/existing shareholders, provided their KYC data is up to scratch. KYC data for shareholders can be optionally added/modified in the same procedure, or by using the already existing modifyData function in that same namespace.

Here is a code example of how you would use the Polymath SDK to mint tokens to a new shareholder and an existing one at the same time:

CLI Updates — by Victor Vicente

The CLI has been updated to support the latest changes in our core codebase.
We have modified the Manual Approval Transfer Manager script to reflect the new struct data for approvals, including the original allowance amount for each approval.

Regarding per-use POLY fees of our modules, whenever a module is added, if it has any cost associated to it, the CLI will ask the user to set a budget for it and if they want to transfer this amount of POLY to the Security Token contract. Following this line, now the CLI shows the POLY balance at the Security Token summary and the remaining budget on each of its modules. Finally, the token_manager script has a new option to change the current budget for any module.

Also, the CLI has been updated to support our recently deployed contracts in Goerli testnet, detecting this network and automatically using our PolymathRegistry address.

Reference Implementations

Role management — by Remon Nashid

Previously, we published a small app as well as a guide that demonstrates the programmatic management of the investor whitelist. For now, the app allows only the token owner (Issuer) to modify the whitelist. However, that is hardly the usual use case. Usually, certain tokens functions are delegated to an operator or an administrator to conduct.

We’re currently building a reference implementation of an app that does just that, enabling the token issuer to assign permissions to arbitrary delegates of their choice. But not only that, the app will also let the token issuer assign the permission management task itself to other delegates!

The app should be published by the time of our next developers update, but if you can’t wait, you can check the source code here.

Polymath Issuer dApp

Manual Trade Approvals— by Fahd Wahab

Manual Approval Transfer Manager (MATM) is the newest feature currently under development for the dApp. MATM allows for issuers to create manual approvals between two addresses, a “from address” and a “to address”. Manual approvals are special exemptions that allow transfers between the two addresses, while upholding all other restrictions applied to the address. The approval only works in one direction where the “from address” is the sender and the “to address” is the receiver. In a scenario where the to address is sending tokens to the from address, you would need a new manual approval giving you the special exemption.

The manual approval allows the issuer to create an allowance with an expiry time. While the approval is active there is a limited amount of tokens the “from address” can send to the “to address”. After expiry the addresses are subject to any other restrictions. MATM is another set of features we look forward to getting into the hands of our users.

CSV file validation — by Remon Nashid
A couple of Token Studio features, such as whitelist management, token minting and VRTM management, allow users to upload a CSV file of records to be inserted/updated. That proves handy when many changes need to be applied, in bulk.

As long as your CSV is formatted as expected, and all the required columns are in place, you should be fine. Previously, our dapp didn’t provide any feedback in the case of validation issues, such as a missing or invalid values. Since our latest release, CSV import forms will return some comprehendible feedback in case of validation errors. Hopefully that will make the lives of token issuers and administrators a lot easier! See the screenshot with detailed errors below.

Thank you for reading our fourth update! If you have any questions about any of the features we presented in this update, feel free to reach out to us in the comments section below. See you in two weeks!
- Pablo Ruiz

Joining Polymath

Are you interested in joining the security token revolution? We are always looking for high quality talent. Check out our careers page at https://polymath.bamboohr.com/jobs/ to apply!

Newsletter: https://polymath.network/newsletter
Reddit: https://www.reddit.com/r/PolymathNetwork/
Twitter: https://twitter.com/polymathnetwork
Telegram: https://t.me/polymathnetwork
Facebook: https://www.facebook.com/polymathnetwork/
Youtube: https://www.youtube.com/c/polymathnetwork
Website: https://polymath.network