Polymath 3.0 Developer Update #2

Published in

Polymath Network

10 min readSep 16, 2019

Welcome to the second 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 for the most part is publicly available on our Github repositories.

On our first update we covered a lot of the work we have been doing for the past month or so, organized in 4 main categories:

Smart Contracts
SDK / CLI
Reference Implementations / Guides
The TokenStudio Issuer dApp

For each and every issue we’ll keep the same structure where each team member that has contributed to any of these categories will talk about their work.

Let’s see what the dev team has been up to these past 2 weeks!

Smart Contracts

Advanced PLCR Voting — By Satyam Agrawal

With the growing ecosystem of blockchain-based securities, we have found a growing need for reliable systems that allow issuers and token holders to affect governance on-chain. With this in mind, we are introducing a new voting module called `AdvancedPLCRVotingCheckpoint`. It works very similar to PLCRVotingCheckpoint module that we already released a few months back but this module brings a set of upgraded features necessary for performing very robust voting operations. Let’s explore the new features!

There are 2 types of ballots — statutory and cumulative — that issuers are allowed to create with this module. The basic difference between them is that the statutory type only contains one proposal, while the cumulative type can have multiple proposals. Issuers or permissioned addresses (delegates) can create them in 4 different ways.

Create a ballot with a dynamic checkpoint (new checkpoint created during transaction).
Create a ballot with a specified custom checkpoint (should be less than or equal to current checkpoint).
Create a ballot with a dynamic checkpoint and an exemption list (list of addresses that are not allowed to vote for this ballot).
Create a ballot with a custom checkpoint and an exemption list.

Note: The checkpoint is used to get the tally of balances on a particular block to avoid the double spending problem. Only investors who have a non-zero balance at a checkpoint can participate in the ballot associated with that checkpoint.

Ballots have 4 stages PREP, COMMIT, REVEAL and RESOLVED, detailed below:

In the PREP stage, issuers can notify the allowed investors to let them know about upcoming vote sessions. During this stage, the issuer can change the local exemption or global exemption list if they want to exclude some addresses from voting for any particular reason (I.E: Excluding known exchange addresses).

Once the PREP stage ends, the COMMIT stage will automatically begin. In this stage, investors can commit their votes by passing a hash H(x) = hash(w1, w2, w3,…, secret salt), where w1, w2, w3 is the amount of vote power allocated to proposal choices while wn should be equal to ∑(proposalᵢ * noOfChoicesᵢ) where i = 0 … totalProposal-1. Secret salt is a random 40–50 character-long uint256 number which helps make a vote secret while `vote power` of an investor can be calculated as `balance on the given ballot checkpoint * no. of proposals a given ballot has`. So, if Alice has 100 tokens and a given ballot has 4 proposals then `vote power` will be 400 (i.e 100 * 4). Now Alice can allocate this voting power to a single choice of a proposal or distribute the vote power within the choices of the proposals on the basis of how strongly she supports a given choice.

After the end of the COMMIT stage, the REVEAL stage automatically starts. Only investors who participated in the COMMIT phase can take part in this stage. Investors have to pass the array of w1, w2, w3.. as they allocated in the COMMIT stage and the random salt in order to reveal their original vote to make it valid. If an investor doesn’t pass the same data as they filled in the earlier phase then they will not be able to reveal their vote, leading to that vote not being taken into account at the time of result computation.

Just after the end of the REVEAL stage, the ballot goes into the RESOLVED stage automatically. This stage finalizes the voting process and allows the issuer to get the result of the given ballot using `getBallotResult()`function.

Custodial Ownership ERC (ERC-2258) — By Adam Dossa

Effective custodial options is one of the key pieces of functionality that regulators prioritize in the digital asset ecosystem. ERC-2258 was proposed as an addition to the ERC-1400 library of interoperable security token standards to provide a simple and efficient approach to custodial ownership of security tokens with the aim of cleanly separating custodial and beneficial ownership. This allows custodians (either organizations or smart contracts) to take custody of securities whilst beneficial owners retain direct access to governance and capital distribution. All feedback and commentary on ERC-2258 is encouraged at: https://github.com/ethereum/EIPs/issues/2258

If you’d like to know more about this ERC, check out this introductory article: https://blog.polymath.network/erc-1400-custodial-ownership-899ec175f96b

SDK / CLI

Advanced PLCR Voting CLI — By Victor

For the past two weeks we have been working on integrating the new voting module to our CLI. This particular module was quite a challenge as it features a lot of complex interactions that we need to support.

We decided to add a new command to cover all voting related modules and we called it ‘voting_manager’ or ‘vm’. As many other module-related scripts, it allows the Security Token owner to add new modules or manage existing ones if there are any. It can also be run by any investor if they want to participate on an existing ballot.

Once you have attached a new voting module, you get a summary including the amount of current running ballots and their stages and how many ballots are waiting for your votes.

The CLI helps you create any type of ballots, with any amount of proposals and choices you need. Once created, a ballot will run through four different stages:
- Prepare: From the creation time to ‘startTime’. During this stage you can modify the list of exempted voters.
- Commit: From ‘startTime’ to ‘startTime + commitDuration’. In order to keep all votes secret it’s necessary to perform a two-step process and this is the first one. The CLI will ask you to distribute all your votes across any amount of choices over the ballot proposals. It will send your vote encoded to the contract and at the same time it will create a local file saving all its details to help you reveal it in the next stage.
- Reveal: From ‘startTime + commitDuration’ to ‘startTime + commitDuration + revealDuration’. The second step is to reveal your secret vote. This time the CLI will require the voter to select the ballot and it will load your vote details from the file saved previously.
- Resolved: From ‘startTime + commitDuration + revealDuration’. Once the ballot has ended, the results are public for any user who wants to check them.

With this, the CLI is fully updated to the current state of the v3.1.0 contracts and we can resume our work integrating it with our SDK.

SDK Progress Update — By Jeremías Díaz

The last two weeks of SDK development have been focused on multi version support. The nature of our smart contracts makes it so that, in the future, there can be many different versions of any given module deployed to mainnet. The SDK must support all of them (from 3.0.0 onwards) concurrently and seamlessly.

The idea behind this is that the end user of the SDK shouldn’t have to know the particulars of each version of each contract. Of course, this means that behind the scenes, the SDK is juggling different interfaces for the same contract, which do things in a slightly (or sometimes not so slightly) different way. New features and breaking changes must be taken into account as well.

Most of the heavy lifting in this regard is being done by the contract-wrappers package, which is undergoing major refactoring in order to accommodate this new focus, offering version-specific contract wrappers with their corresponding type-guards and helper types.

This is a massive endeavor which has understandably slowed down the rate at which the SDK is covering contract features, but it is fundamental in order to keep up with changes in the Polymath protocol while still being able to fulfill the needs of all our users; old and new.

Another cool feature is the support for custom transaction speeds. The latest SDK beta accepts a speed parameter in its connect method. This parameter regulates the gas price paid for transactions. The faster the desired speed, the larger the gas price. Gas prices are fetched from https://ethgasstation.info for mainnet, and from the network directly in testnets, falling back to sensible defaults in case of an error when fetching.

Reference Implementations

Whitelist Manager Application — By Remon Nashid

In continuation to our effort to help developers with building applications for the Polymath ecosystem, we’ve created a “reference implementation” for one of the most used features, that is “token transfer management”|https://github.com/PolymathNetwork/whitelist-standalone

The app enables Security Token issuers (or a privileged delegate) to set rules that specify a token holder address, and associated timestamps for when that address can send or receive tokens. Additionally there are flags that allow issuers to modify the rules in specific circumstances, for example when tokens are being transferred as part of an STO investment.

Note: The app assumes that you’ve already deployed a security token on either Kovan or Mainnet. If not, you can easily create one using the Polymath Token Studio|https://tokenstudio.polymath.network for now. It’s a wizard that leads you through token creation in a few simple steps. In fact, we’re going to address programatic token creation in a following tutorial, so stay tuned!

The app is purposely simple and relies on just a few dependencies; React.js for UI components and for state management, and the Polymath SDK to facilitate communication with the blockchain; Polymath contracts in particular. If you’ve attempted to build integrations with the Polymath ecosystem before, you will really appreciate the conciseness provided by the SDK.

The app is accompanied by a fairly detailed tutorial , it takes you through the app building process, step-by-step. Feel free to clone the app, follow the tutorial, and hopefully build your own apps. We look forward to see your creations! 🤓

PolymathNetwork/whitelist-standalone

Contribute to PolymathNetwork/whitelist-standalone development by creating an account on GitHub.

github.com

Polymath Issuer dApp (Token Studio)

Volume Restriction Transfer Manager — By Fahd

Our efforts are focused on ensuring the issuer dApp contains all the features of the protocol. Continuing with that mission, the next feature the dApp will introduce is Volume Restriction Transfer Manager (VRTM). VRTM allows an issuer to limit the amount an investor can transfer within a time frame. There are three ways to enable restrictions for a token. An issuer can set global restrictions that apply to all investors. The issuer may add a volume restriction with a daily or custom time frame. These two restrictions may work in conjunction with each other, allowing for both of them to be applied at a global level.

An issuer may want to have granular control on an investor address. This will allow for special conditions for each of these addresses, bypassing the global restrictions. Again, you may add a restriction with a daily or custom time frame to each address individually. These next set of features will be introduced to the dApp soon. We look forward to hearing your feedback.

PolymathNetwork/polymath-apps

You can't perform that action at this time. You signed in with another tab or window. You signed out in another tab or…