There are General factories which every token uses (if wanted). To be clear, each module has its own factory which is in charge of deploying an instance of that module for the issuers token. Later, Polymath can easily turn access on and off. The Features Registry - A registry of features that we may enable in the future but right now only Polymath has control of the features. The Module Registry - This registry keeps a record of all the different module factories. With the 2.0.0 Core Release, when you deploy a token you do it through the ST registry and it keeps a record of which tokens have been registered within it. After it expires someone else can go ahead and reserve it or they you can re-register it. Right now, if you reserve a ticker it last for 60 days. This allows us to prevent people from reserving the same ticker as another issuer as well checking for inputs such as making sure it is a maximum of 10 characters and what the expiry date is on the respective ticker. Security Token Registry (STR) - This registry tells us which tokens and tickers have been registered to it. The diagram below depicts a high-level view of the various modules, registries, and contracts implemented within Polymath Core 2.0.0: transfer, transferFrom must respect the result of verifyTransferįunction verifyTransfer(address _from, address _to, uint256 _amount) view public returns (bool success) įunction mint(address _investor, uint256 _amount) public returns (bool success) The implementation of verifyTransfer can take many forms, but the default approach is a whitelist controlled by the GeneralTransferManager. The verifyTransfer method will determine whether that transaction can be completed or not. ST-20 tokens must implement a verifyTransfer method which will be called when attempting to execute a transfer or transferFrom method. 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 a peer to peer exchange, or a transaction with an exchange. ST-20 Interface Overview DescriptionĪn 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. Security token structure, distribution, or changes that could affect investors are now accessible to all via the blockchain. Security tokens offer the benefit of bringing significant transparency over traditional paper shares through the use of the blockchain and its associated public ledger. Such as having a stake in a company, real estate, or intellectual property can all be represented by security tokens. On the other hand, security tokens represent complete or fractional ownership in an asset (such as shares in a company, a real-estate asset, artwork, etc). Utility tokens give you that same type of access to a product or service. Utility tokens represent access to a network, and your token purchase represents the ability to buy goods or services from that network- Think of when you purchase a arcade token to allow you to play an arcade game machine. The concept of utility tokens is fairly well understood in the blockchain space today. While utility tokens have no limitations on who can send or receive the token, security tokens are subject to many restrictions based on identity, jurisdiction and asset category. Security tokens are designed to represent complete or fractional ownership interests in assets and/or entities. Introduction to Security Tokens What is a Security token?Ī Security Token shares many of the characteristics of both fungible (erc20) and non-fungible tokens (erc721). This system has a modular design that promotes a variety of pluggable components for various types of issuances, legal requirements, and offering processes. This particular repository is the implementation of a system that allows for the creation of ST-20-compatible tokens. The Polymath Core smart contracts provide a system for launching regulatory-compliant securities tokens on a decentralized blockchain.