Understanding the Layers of the Polymath Network
Enable sustainable growth towards the distributed future by unlocking deep tech capabilities through meaningful, real-life actions for innovative organisations like yours across the globe.
blockchain,digital assets,sto,security token,cryptocurrency,ethereum,bitcoin
post-template-default,single,single-post,postid-1894,single-format-standard,bridge-core-1.0.6,ajax_fade,page_not_loaded,,qode_grid_1300,qode-content-sidebar-responsive,qode-child-theme-ver-1.0.0,qode-theme-ver-18.2,qode-theme-bridge,disabled_footer_top,wpb-js-composer js-comp-ver-6.0.5,vc_responsive

Understanding the Layers of the Polymath Network

Understanding the Layers of the Polymath Network

Polymath’s Vision

We envision a world where security tokens are the default form factor for securities, enabling a true upgrade to the existing financial system with increased liquidity, efficiency, and transparency. To achieve this, Polymath has built the world’s first decentralized protocol that acts as the interface between financial securities and the blockchain. Additionally, the Polymath Token Studio acts as an easy-to-use, self-serve application that makes it easy to create a security token with customizable features.

The Layers of Polymath

Layer 4: Marketplace

The marketplace includes work from Polymath’s internal developers as well as external developers. In the marketplace, developers can offer up modules and STO smart contracts for issuers to use. Issuers then select modules to customize their security token and STO based on their specific situation. In the future when an issuers needs to select the features of their token and their STO smart contract, there may be several different modules to choose between for dividends, voting, volume transfer restrictions, and so on.

At the present moment, the marketplace contains modules built only by Polymath, but we hope to open it up to external developers shortly.

Layer 3: Polymath Token Studio

The Polymath Token Studio allows issuers to create their customizable token and launch their own STO by going through the following processes:

  1. Registering a Token Symbol
  2. Choosing Providers (Advisors, Legal, KYC/AML, Marketing, Custody)
  3. Creating a Token
  4. Setting Up Offering Details
  5. Whitelisting Investors To Participate In the STO

The Token Studio greatly lowers the barriers to entry for businesses looking to create tokenized securities to their own specifications.

Note: The Polymath Token Studio dApp can be used on both the “Kovan Test Network” and the “Main Ethereum Network” by simply selecting the appropriate network in MetaMask.

To test out the process of creating a security token and STO, visit this link for guidance: https://blog.polymath.network/create-your-own-security-token-offering-sto-with-polymath-7d37f8cd9a6c

In order create a real security token and conduct an STO, please visit https://tokenstudio.polymath.network/ and select “Main Ethereum Network” within your MetaMask extension.

Layer 2: ST-20 Protocol and Polymath Core Architecture

The Polymath Core smart contracts provide a system for deploying security tokens with built-in transfer restrictions on a decentralized blockchain. This particular repository is the implementation of a system that allows for the creation of ST-20-compatible tokens. The system has a modular design that allows a variety of pluggable components to be used to satisfy various types of issuances, legal requirements, and offering processes.


An ST-20 token is an Ethereum-based token implemented on top of the ERC-20 protocol that adds the ability for tokens to control transfers based on specific rules. ST-20 tokens rely on Transfer Managers to determine the ruleset the token should apply in order to allow or deny a transfer, be it between the issuer and investors in the primary market, or between investors in the secondary market.

How it works

ST-20 tokens must implement a verifyTransfer method which is called when attempting to execute a transfer or transferFrom method. The verifyTransfer method will determine whether that transaction can be completed or not. The implementation of verifyTransfer can take many forms, but the default approach is a whitelist controlled by the GeneralTransferManager.

A high-level diagram view of the various modules, registries, and contracts implemented within the latest Polymath Core Release.


Polymath Registries

Security Token Registry (STR) — This registry tells us which tokens and tickers have been registered to it. This allows us to prevent people from reserving the same ticker as another issuer. It also checks for inputs such as ensuring the ticker is a maximum of 10 characters and the expiry date. Today, if you reserve a ticker it will be yours for 60 days, but if you create your token it will be yours forever. If you do not create your token and the 60 days expires, someone else can reserve it or you can re-register it.

With the 2.0.0 Core Release, you deploy a token through the ST registry and it keeps a record of which tokens have been registered within it.

The Module Registry — This registry keeps a record of all the different module factories.

The Features Registry — A registry of features that we may enable in the future. For now, only Polymath has control of the features, and once it is enabled, Polymath can easily turn access on and off.

To be clear, each module has its own factory which is in charge of deploying an instance of that module for the issuer’s token.

There are General factories which every token uses (if desired by the issuer). It works by sending the token to the factory where it asks for an instance of that said module and the token will add an instance of that module to itself. This allows for each token to have its unique modules associated with it. All of this is created through the factories, and the module registry keeps a records of all the different module factories that are registered.

As of now, Polymath is the only one that can add or register a module factory to the module registry. However, we are exploring different approaches to open up development to other parties such as potentially working with external developers to provide services to issuers through modules.

Polymath has 3 main registries:

  1. Security Token Registry
  2. Features Registry
  3. Module Registry

The Polymath Registry holds the addresses of the 3 registries above.

As of the 2.0.0 release, the Module and Security Token Registry are upgradeable. This means that down the road if there is something in the logic that we need to change, we can do that without having to re-deploy the entire thing. All we need to do is an update.


Security Token (ST-20): The SecurityToken is an implementation of the ST-20 protocol that allows the addition of different modules to control its behaviour. Different modules can be attached to a SecurityToken.

We have an ST-20 token which is an Ethereum-based token implemented on top of the ERC-20 protocol that adds the ability for tokens to control transfers based on specific rules. ST-20 tokens rely on Transfer Managers to determine the ruleset the token should apply in order to allow or deny a transfer, be it between the issuer and investors in the primary market, or between investors in the secondary market.

To simplify, it breaks it down to having a base token that gives the issuer the ability to add functionality through modules.

For Example…

We have modules that can deal with transfer management. You can restrict transfers through a whitelist or just restrict a transfer between addresses that could cause an account to exceed a specified limit. You can also limit the number of token holders, and even limit transfers to prevent any large, coordinated selling of tokens by having a lockup period for token holders.

Polymath’s Modules

TransferManager modules: These control the logic behind transfers and how they are allowed or disallowed. By default, the ST (Security Token) gets a GeneralTransferManager module attached in order to determine if transfers should be allowed based on a whitelist approach.

The GeneralTransferManager behaves differently depending on who is trying to transfer the tokens.

a) In an offering setting (investors buying tokens from the issuer) the investor’s address should be present on an internal whitelist managed by the issuer within the GeneralTransferManager.

b) In a peer to peer transfer, restrictions apply based on real-life lockups that are enforced on-chain. For example, if a particular holder has a 1-year sale restriction for the token, the transaction will fail until that year passes.

Security Token Offering (STO) modules: A SecurityToken can be attached to one (and only one) STO module that will dictate the logic of how those tokens will be sold/distributed. An STO is the equivalent to the Crowdsale contracts often found present in traditional ICOs.

Permission Manager modules: These modules manage permissions on different aspects of the issuance process. The issuer can use this module to manage permissions and designate administrators on their token. For example, the issuer might give a KYC firm permissions to add investors to the whitelist.

Checkpoint Modules: These modules allow the issuer to define checkpoints at which token balances and the total supply of a token can be consistently queried. This functionality is useful for dividend payment mechanisms and on-chain governance, both of which need to be able to determine token balances consistently as of a specified point in time.

Burn Modules: These modules allow issuers or investors to burn or redeem their tokens in exchange for another token which can be on chain or off-chain.

With the latest Core 2.0.0 Release, Polymath has also introduced the USDTieredSTO. This new STO module allows a security token to be issued in return for investment (security token offering) in various currencies (ETH, POLY & a USD stable coin). The price of tokens is denominated in USD and the STO allows multiple tiers with different price points to be defined. Discounts for investments made in POLY can also be defined.

Layer 1: Ethereum Blockchain Network

As you can see below, the Ethereum Blockchain Network is also a layered solution. The Polymath Token Studio is a dApp (Layer 3 in the below image) that lies on top of custom built smart contracts as well as Polymath’s ST-20 Protocol (Layer 2) and is powered by the Ethereum Blockchain network (Layer 1 in image) to make it all possible.

(This article is originally posted by Charles St.Louis on Polymath Blog.)

No Comments

Post A Comment