Introducing the Dynamic Security Token.
Security Tokens
Firstly, we’re not talking about those RSA tokens you got from work once... Security Tokens are digital representations of real world assets and securities. They could be stocks or options in a company, and legally they represent and perform the function of traditional securities, but digital. When represented on a smart contract platform like Ethereum, they become programmable, cryptographically secure, and better than traditional securities because of:
- Lower setup costs, issuance and transaction fees for all participants
- Ensure a greater level of security and ownership when on a blockchain.
- Automated legal compliance, regulation and transfer obligations
- Instant settlements & reduced dependency on third party intermediaries.
- Liquidity from regulated trading on decentralised exchanges
ERC1400 Security Token Standard.
The ERC1400 Security Token Standard is the latest development for representing a Security Token on the blockchain from authors Adam Dossa, Fabian Vogelsteller, Stephane Gosselin, and Pablo Ruiz, designed to:
“Accelerate the issuance and management of securities on the Ethereum blockchain by specifying a standard interface through which security tokens can be operated on and interrogated by all relevant parties.”
This comprehensive smart contract standard has been formalised over a series of Ethereum Request for Comments (ERC’s) that make up the ERC1400 Security Token Standard. Namely:
ERC-1400: Security Token Standard
ERC-1410: differentiated ownership / transparent restrictions
ERC-1594: on-chain restriction checking with error signalling, off-chain data injection for transfer restrictions and issuance / redemption semantics
ERC-1643: document / legend management
ERC-1644: controller operations (force transfer)
See also these links:
https://github.com/ethereum/EIPs/issues/1411
http://thesecuritytokenstandard.org
Aside from some of the technical specifications above, the ERC1400 Security Token Standard is made up of a clear set of requirements that need to be met in order to be compatible with other ERC1400 Security Tokens and exchanges. We’ll be looking at some of the core components of the Security Token Standard as well as putting some of these pieces together in a new way.
Partitions
For a security token, partitions are defined as different allocations for the same underlying asset. A great example would be founders shares that have special rules, making them different to the rest of the shares issued. Founders shares could have conditions that convert after 3-4 years. Employees would be in a different partition with a different set of restrictions and converting after, say 1 year. These different share allocations are commonly referred to as classes of shares, tranches or partitions. In the ERC1400 standard, we’ll be referring to these separate types of share as “partitions”.
Partition Conversions
Since we have a different partitions of the same underlying asset. At a minimum they are partially fungible, we would need them to function as such and/or have a way to convert from one partition to another.
Documents
Storing documents is also covered in the ERC1400 Security Token standard, and includes features such as storing document pointers, signed and hashed company documents.
Whitelisting
Aside from regulations affecting token transfers, there are Know Your Customer (AML/KYC) requirements, for say sophisticated investor whitelisting, anti money laundering, different jurisdictions etc. As we get further into security tokens, we also begin to have whitelists for specific partitions.
Say the company allows for employees to exchange their employee shares privately, among themselves before they are vested. One would need to keep a whitelist for restricting transfers to a list of employees.
Token Restrictions
Along with having different partitions, tokens will also need to have transfer restrictions for a number of reasons. For different asset classes and juristictions, there are rules on the number of investors, total share issuance limits and holding periods. One example would be Reg S Category 2&3 which has regulations requiring either a 40 day or 12 month resale restrictions.
Overall security token standards are a great initiative to help improve interoperability for token exchanges, lower settlement time and costs, help standardise regulation and compliance.
Cant we keep Tokens, as Tokens!
Tokens are great!, But we quickly begin to see as we add more and more functionality to this new security token standard, we also add complexity. Complexity from handling new partitions, different logic for handling new partition conversions, token restrictions and whitelisting requirements, all using immutable smart contracts that cannot be changed once deployed.
Yet at the same time, securities must adapt throughout the life cycle and events of a real world asset, and so the Security Token contract, must also be dynamic.
To solve this there are few options, such as creating add-on modules, upgradeable proxy contracts or adding various functionality to the contract. Today I’ll be going through my preferred method, by representing partitions as individual tokens.
By doing this we’ll open up a composable token architecture which is both flexible and extensible. By keeping tokens as tokens, we’re able to be apply our framework easily to a number of Security Token use-cases, as well as interact with individual partitions.
ERC777
The ERC20 token standard was one of the first attempts to create a token standard. It’s our go-to basic token, but not the token standard that will take us where we need to go. One of the more advanced base token contracts now available is the ERC777 token standard, developed by Ethereum developer heavy-weights Jordi Baylina, Jacques Dafflon, and Thomas Shababi.
We’ll be using standard ERC777 tokens in our design. It’s essentially an advanced, backwards compatible ERC20 with some extra functionality for token operators and uses the ERC820 Registry for safe token transfers (we’ll be using both features later for our token regulator).
Deepyr’s Dynamic Security Token
The Dynamic Security Token is essentially a family of contracts, with a main composeable ERC1400 contract that is able to own multiple tokens.
Token Architecture
Token Converters are then able to mint and burn, converting one token to another, while regulators contain transfer logic. Together, this family of contracts form the basis of our Dynamic Security Token.
Each ERC777 token represents a partition, one of which, is the base token. It is this base token that allows standard ERC20 token functions to be handled, while other partitions can be called specifically by partition ID.
The document / metadata management (ERC-1643) and controller operations (ERC-1644) are also added to the main ERC1400 contract to keep that metadata common all. When included with an ERC820 contract registry for safe token transfers, as well as connecting regulators with whitelist contracts, you begin to have a framework of smart contracts that is both flexible and extensible.
Well, this might seam overkill for your standard security token (and you’re right!) flexibility and extensibility becomes increasingly important for assets with long life spans, such as your company, with evolving capital requirements, new issuance and changing crypto regulation.
From a security perspective, this adds granularity that can be utilized when delegating roles based permissions for each contract. DApp developers could also save gas by calling ERC777 token functions directly, instead of traversing through arrays and partition logic, yet still be restricted.
Token Regulators
To manage token transfers, our approach will be taking advantage of token operator, which comes baked into the ERC777 standard. We’ll also be using the Token Sender and Token Recipient interfaces for our Token Regulators. This lets us add logic on how tokens are able to be sent or received by adding a new regulator.
Token Converters
Each Dynamic Security Token keeps a list of any tokens it manages, as well as a mapping of Token Converters and which tokens they’re able to operate on. Generally the main contract owner has permissions to add or remove token converters.
When there is new stocks or partitions being issued, that’s simply adding a new ERC777 token into the Dynamic Security Token. This lets your securities scale out by incrementally adding new partitions.
To convert between partitions, the security contract is able to grant operator permissions to the Token Converter, who then is able to mint Token A and burn Token B, effectively converting a Class B token into a Class A.
Extending the Dynamic Security Token
Since partitions are just tokens in our architecture, when we deploy a new token contract, any new tokens are added with operator permissions granted to the main contract. We also have the option to add Token Converters or connect partitions to new or existing token regulators.
The main point to highlight here, is that new partitions or class of shares can be added easily and dynamically to an existing Security Token without breaking or redeploying the contract, as well as being able to add logic to define how partitions are converted and exchanged.
Tokens and converters are immutable smart contracts. The side effect of having separate contracts is having a full audit trail with logs of which token converter address, handled what token, with what contract logic, timestamped when!
Token Converter Examples
A combination of token converters and token regulators allow for a number of emergent use cases.
Internally Traded Employee Share Options
For companies wishing to pay a portion of wages in company stock, this would be done by issuing company stock options. Traditionally this involves an accountant, solicitor and an expensive fees, sometimes in the thousands of dollars per employee. In our example, we would be the issuer and able to issue a new partition for the cost of the gas, along with an owner approved token converter and a whitelist including only eligible employees.
If an employee wishes to trade that option with another employee on the employee whitelist, then the exchange will go ahead.
Convertible Stock Options
Once they have options, employees could then convert their options into the base security token themselves, using a company approved Token Converter. This token converter could be custom made with a time bound transfer restriction. Say an employee or investor needs to wait 12 months before they can convert their Class X tokens to Class A’s. Initially the transfer will fail, but after a set time, and satisfying any internal logic, the user can then convert these options themselves into Class A shares, all without the intervention or approval of a third party.
ERC20 User On boarding
Since only the owner can add token converters and set permissions, you could let users migrate your existing ICO token or crowdsale token into a Security Token. By add a different custom Token Converter, like the previous example but an on-ramp, but specifically converts your ERC20’s into Dynamic Security Tokens.
Dynamic Security Token Extensibility
These 4 main components make for a flexible token architecture and at the same time, makes it modular and extensible.
Dividend Issuance
To issue dividends based on an existing token balance, we can add another custom converter, that will issue dividends based on a balance of Class A’s tokens at the Ex Div date. Check-pointing can be added to the base token, time-stamping each of the token transfers. This allows the smart contract to get the users exact token balance at a certain time, ie. the Ex Div date, and then issue dividends based on token holdings at a certain block.
Additionally the token converter could potentially hold ETH and distribute dividend payments in ETH as part of the conversion. This makes it really easy for a users to claim their dividends or for a company to push dividends to token holders provided you check pointed appropriately.
Token Voting
Simply add your governance token to the main Security Contract. New issuance could be handled with a token minter and delegation could be handled with the token regulator. For inspiration, check out the token voting library in BokkyPooBah’s DAO
Privacy
Different industries, jurisdictions and financial vehicles are subject to very strict privacy requirements that need to be addressed in this new world. A series of privacy-protocols based on ideas such as zk-SNARKS, zk-STARKS or BulletProofs are likely to be needed to power a new wave of security tokens. Again, theses are just tokens that can be added or converted to as the technology matures.
Upgradeable Security Contracts
Components of the framework can be decoupled and replaced as needed, better than most upgradeable design patterns. Deploying a new base security contract will require pointing all the previously attached tokens to the new security contract. Token addresses, balances and history remain the same which is a bonus. Token Converters still know which tokens can be converted. For individual token contracts that need to be upgraded, simply issue a new token, and naturally a token converter would do the job.
Debt
Once we have a framework for digital assets, naturally we begin to see how debt tokens can be included into our framework. In addition to adding debt tokens, we can start to think of a range of token converter contracts that convert between assets and debts, that can lock up equity as collateral and issue debt tokens, or act as convertible note contracts. The possibilities are endless!
Many more..
As you can see with this flexible architecture, we keep the standard ERC1400 interface for interoperability and compliance, and at the same time, making it dynamic and extensible. We’re able to be flexible in both how tokens are exchanged with others and converted between partitions, as well as being able to add new partitions, token converters and regulators as needed throughout the life cycle of the asset.
Next article will hopefully go into a bit more depth into both the regulator and converter contracts, authorisation and permissioning, and hopefully share some code from our upcoming reference implementation.
Let me know what you think in the comments, or reach out to collaborate!
Adrian Guerrera
www.deepyr.com
This is all inspired by a failed arbitrage attempt on the https://cryptoderivatives.market/ where I bought what looked like some cheap MKR tokens, which turned out to be old MKR tokens, and so I had to convert them to new ones. I loved the trustlessness of being able to convert your old tokens into new, and the beauty of interacting with a contract that is immutable and will be available for the life of the network.
That idea stuck with me when researching then building my own implementation of the ERC1400 standard and naturally fit with the role of Token Converters. I was fortunate enough to participate in the Council of Prague, Security Token ring thanks to the DFF, in which the ensuing conversations really cemented the idea, as well as the regular chats on a Friday evening with my mentor BokkyPooBah.
