Share with your friends:

ERC-1400, first published around three months ago, has evolved from a single ERC to a library of security token standards, each representing a different facet of modelling the lifecycle, trading, and management of securities on Ethereum.

These standards are self-contained but can be combined in different ways that reflect the specifics of the jurisdiction and asset class, whilst still remaining interoperable across the ecosystem.

These standards are currently split into the Core Security Token Standard, Partially Fungible Token Standard, Document Management Standard and Controller Token Operation Standard. Below we’ll explore some of the rationale and behaviour defined by each of these groups.

ERC-1594: Core Security Token Standard

Designed by Starline / Freepik

 

This ERC covers the core functionality that is expected to be needed for all security tokens.

Injecting Off-Chain Data

If security tokens are to underpin decentralised finance, then the transfer of assets needs to incorporate both on-chain rules and data (smart contracts and global state) as well as real world (off-chain) input and authorisations.

Off-chain data, such as signed authorisations for a particular transfer, have the potential to improve user experience dramatically by simplifying their workflow, reducing costs and on-chain transactions. User experience is one of the critical factors that drives adoption of blockchain technology and adding this flexibility to transfers, issuances and redemptions of security tokens has a virtually zero upfront cost and covers many potential use-cases.

As an example, many exchanges generate a new deposit address for each transaction (usually using an underlying HD key derivation). Usually processing such a transaction would require the exchange to whitelist the deposit address on-chain, and the user to then transfer tokens to the address. With off-chain data injection the exchange can sign a message authorising the investor to make the deposit and the transfer can be deemed valid by the token contract — as an added bonus the deposit address can be automatically whitelisted as an exchange wallet for future transactions.

Trading Restrictions

The ability to check, on-chain, whether a transfer of security tokens is valid provides clarity around liquidity and exchange protocols.

This approach maintains separation between transfers of assets (e.g. an investor sending another investor some securities) and the settlement of those transfers (e.g. a payment made in DAI for the securities).

As well as determining whether or not a potential transfer of assets is valid, the standard also supports returning a more fine-grained status code if the transfer is not valid. This allows exchanges and wallets to provide a more sophisticated user experience, providing the user with a detailed explanation of why they are unable to transfer securities (for example the securities may be locked, or the receiver may not have been KYC’ed).

Issuance / Redemption Semantics

Although not specified in ERC-20 it’s been relatively commonplace for token implementations to have some notion of mint and burn where tokens are created and destroyed respectively. With security tokens, the lifecycle of issuance and redemption is critical to the structure of the security so this needs to be captured explicitly.

This allows wallets, exchanges and block scanners to accurately present a picture of when securities are being issued and redeemed, which is also useful for regulatory reporting.

ERC-1410: Partitioning Balances

Designed by D3images

 

Transparency is one of the key advantages of public ledger based securities. It is likely that many security token implementations will partition user balances into categories relating to vesting, time locks, voting, etc.. These tokens may all represent ownership in the same underlying asset, but may be treated differently by the token contract for the purposes of transfer restriction, capital distribution and governance.

As an example, suppose an investor has the following categories of shares:

  • 30 tokens — Locked for 3 years, no voting rights
  • 40 tokens — Locked for 1 year, full voting rights
  • 50 tokens — Unlocked, full voting rights

For the purposes of governance you’d want to know that there are 90 tokens with voting rights, for the purposes of trading there is a balance of 50 tokens, and for valuation purposes you care about the total of 120 tokens.

ERC-1644: Controller Operations

Designed by Blossomstar / Freepik

 

Despite using an immutable blockchain to record the ownership of securities, for many asset classes and jurisdictions there is a requirement to have a controller of the token who can forcefully transfer tokens between any addresses. This is needed to account for court orders, fraudulent activities or lost private keys.

The standard provides for making this a transparent process so that security token owners collectively have visibility into any such actions. In addition, the issuer can publicly disavow this ability if appropriate in their particular use-case.

ERC-1643: Document Management

Photo by Maarten van den Heuvel on Unsplash

 

Securities, whether digitally or traditionally issued and managed, will always have documentation associated with them. This standard provides for the ability to attach notarised documents to the security and notify investors of any documentation updates via events.

Documents (and any updates) are captured on-chain via their hash (which provides an optional “fingerprint” of the document that can be used to determine whether or not it has changed) and a URI to the underlying document stored off-chain. The document can be stored on centralised storage (e.g. the issuer’s website) or decentralised storage using something like IPFS.

Currently the notification mechanism relies on events and there is no way to tell that an investor has read and acknowledged a particular document or document revision.

Future Developments

We expect the suite of standards that make up ERC-1400 to continue to grow over time.

Some interesting areas which are still under discussion include:

  • Dividends / Capital Distribution: a standardised way to distribute capital (e.g. tokens or ETH) on-chain that accounts for possible taxation, beneficial owners in pooled wallets, and reporting.
  • Confidential Transactions: the ability to transfer security tokens without publicly revealing information about the transfer (e.g. the recipient or amount of the transfer). Techniques using zero-knowledge proofs and homomorphic encryption are increasingly possible on the public Ethereum mainnet.
  • Checkpoints: several token implementations include some form of checkpointing, whereby the balances of token holders can be queried on-chain as of historical checkpoints. This is useful for dividend distribution and governance (both of which require consistent historical balance queries).
  • Pooled Wallets: it is relatively common for exchanges and custodians to use pooled wallets, where all investors assets are held in an on-chain wallet contract. This poses some potential issues for capital distribution and governance — having a standard approach to such contracts that allows visibility into the underlying beneficial owners of the assets may be useful.

Summary

ERC-1400 is an evolving and growing community effort. The aim is to drive forward consensus on a set of interoperable standards that allow securities to be issued and managed on the Ethereum network.

The current standards cover much of the necessary functionality for this, but there are plenty of areas which still need more discussion or where the technology is evolving and not yet reached a stable state.

The (non-exhaustive) list of groups participating in this effort can be seen at https://thesecuritytokenstandard.org/, and thanks goes to all of those who have contributed across the many forums and discussions.

To get involved in the discussion please join the Telegram group linked in the above website, or comment on any of the Github ERCs referenced above.

(This article is originally posted by Adam Dossa on Polymath Blog.)