Injecting off-chain data

If security tokens are to underpin decentralized 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 authorizations.

Off-chain data, such as signed authorizations 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 driving the 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 authorizing 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.

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

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

Securities, whether digitally or traditionally issued and managed, will always have documentation associated with them. This standard provides for the ability to attach notarized 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 centralized storage (e.g. the issuer’s website) or decentralized 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 standardized 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 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 that still need more discussion or where the technology is evolving and has 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 go to all of those who have contributed across the many forums and discussions.