State of the Standards: A Technical Review of Current Digital Securities Standards

Part one of a series on blockchain development in the tokenized securities ecosystem

The future is digital for the world of capital markets.

Background

In recent months, businesses have begun to invest heavily in the development of solutions that apply blockchain technology to the issuance of securities and the automation of regulatory compliance. In particular, the Ethereum blockchain enables the use of self-executing smart contracts that have become the building blocks for a new generation of programmable assets and securities. Put simply, a smart contract provides digital agreements designed to execute specific actions upon satisfying a set of conditions without the need for an intermediary. This functionality is especially useful when it comes to automating the enforcement of securities laws in real-time, allowing for expedited settlement and transparency for regulators and issuers.

In contrast to the largely non-compliant tokens arose during the ICO craze of 2017, “security tokens” represent ownership of real world assets, including everything from company equity, private investment funds, debt positions, real estate, and fine art. These securities clearly fall subject to the regulatory compliance obligations of existing securities laws. In the United States, the issuance and trading of these digital securities, depending on their specific use cases, must meet the requirements of the Securities and Exchange Commission (SEC), the Commodity Futures Trading Commission (CFTC), and/or the Financial Industry Regulatory Authority (FINRA). These legal requirements include enforcing Know Your Customer/Anti-Money Laundering (KYC/AML) laws and investor accreditation checks to regulating secondary markets with lock-up periods and trading limitations.

Digital securities offer many advantages to issuers and investors unavailable prior to their invention. Traditionally, broker/dealers and other financial service providers hire dedicated compliance teams to monitor large volumes of transactions and run daily checks to detect potential rule violations. This inefficient system requires manual oversight and tends to involve retrospective analysis that verifies the integrity of financial transactions ex post facto. Alternatively, smart contracts automate compliance and enforce compliance in real-time, ensuring that non-compliant trades or transfers can’t happen at the start. This removes the barriers caused by traditional compliance approaches and, ultimately, allows for broader access to economic opportunity, arguably, a requirement for human freedom.

By implementing smart-contract compliance, digital securities can be legally issued, distributed, and traded in a global market, and the pool of investors grows to the benefit of both sides of the transaction. Additionally, many previously illiquid assets become available for purchase in a global market. The ERC-20 standard that many new digital securities build upon also introduces interoperability between different asset classes. The fact that tokens representing revenue shares of companies, land titles, and commodities can communicate and coexist in the same wallet unlocks a new world of innovative, interconnected financial products.

So far we have discussed the overall trend of tokenized securities and the unique advantages they bring to the financial industry: issuers can cut costs associated with raising capital and compliance — private investors benefit from increased accessibility and liquidity while regulators gain improved transparency and enforceability of securities laws.

Below we have conducted a survey for some of the leading open source projects and standards in the digital securities ecosystem, including Securitize’s DS Standard, TokenSoft’s ERC-1404, Harbor’s R-Token, Polymath’s ST-20, and OpenFinance’s S3. Although all of these protocols aim to accomplish the same task, they do so with differing mechanisms worth examining during this early period in the development of digital securities . Additionally, we have synthesized the advantages and limitations of these frameworks to provide context for Atomic Capital’s new Digital Security Standard (DSS).

Digital Securities Protocols*

ERC-1404 (TokenSoft)

The ERC-1404: Simple Restricted Token is a standard proposed by TokenSoft that provides a sort of baseline for applying regulatory compliance to the existing ERC-20 token functionality. At its core, the standard implements two main functions to enforce transfer restrictions based on the complex requirements of an issuer: detectTransferRestriction and messageForTransferRestriction. The former holds all the restrictions logic that is called by the base ERC-20 transfer and transferFrom functions, and it returns a specific restriction code that either signals a successful transfer of tokens or else represents the reason why a transfer was restricted. In the default implementation, the return value 0 is reserved for success and the meaning and designation of all the restriction codes are up the implementer to define. The second function essentially takes these restriction codes as input and returns a human-readable error message that explains why a transfer failed based on the rules set by the issuer.

ERC-1404 is a simple but flexible standard that expands on ERC-20 to detect restrictions on transfers given any number of rules defined by the issuer. For example, this standard can be implemented to include a built-in whitelist of Ethereum addresses that represents an active list of accredited investors who are able to purchase and trade the digital security. This makes it easy for an issuer to apply their KYC/AML checks and their own onboarding process while automating trade regulations in secondary markets. One limitation of the ERC-1404 standard is that it does not have a mechanism to change its restrictions logic once the smart contracts are deployed, and this ability is especially important in a changing regulatory environment. Since Ethereum’s blockchain is immutable in nature, special attention is needed to be able to upgrade the specifications of a token once it is live. Although this standard can have some degree of versatility with an implementation of amendable whitelists, it does not contain the functionality to change what kind of restrictions are enforceable during the lifecycle of the token.

R-Token (Harbor)

Harbor has been gaining a lot of traction recently for its own decentralized compliance protocol called the Regulated Token Standard, or R-Token. This standard allows for proactive compliance checks on top of ERC-20, while also providing a mechanism to modify the token’s restrictions logic after its deployment. The R-Token’s smart contract protocol is divided into three parts: the RegulatedToken contract, which integrates ERC-20 and stores the main components of the digital security; the RegulatorService contract, which contains all the restrictions logic that the token accesses during every transfer attempt; and the ServiceRegistry contract, which stores a reference to the address of the current RegulatorService and has the ability to replace the token’s restrictions logic by changing the reference to a new regulator contract.

So when the R-Token is created, a service registry is attached to the token and acts as a proxy between the base regulated token and the regulator service that holds the restrictions logic. This allows for a stable contract address for the token itself while also enabling the modification of the regulatory instructions at the contract owner’s discretion. When a transfer is made by a token holder, the R-Token first initiates the check method that calls to the service registry, which then maps to the current regulator service to verify if the transfer passes the specified compliance requirements. The regulator service, similar to ERC-1404, then returns a code that signifies the success or failure of a given transfer.

In essence, this architecture centralizes compliance with an active administrator while decentralizing the token’s operation and validation. This has unique advantages because it enables permissioned upgradability through the replaceRegulator function inside the service registry contract that basically points the R-Token to a new set of restrictions. Although the R-Token standard achieves live upgradability on an immutable blockchain, the protocol contains unnecessary complexity and can be simplified by removing the service registry component altogether (more on this later).

ST-20 (Polymath)

ST-20 (originally presented as the ERC-1400/1410 token standard) is another promising digital securities protocol that was developed by Polymath, a platform for creating and issuing security token offerings. The ST-20 standard implements the verifyTransfer function which is very similar to the other protocols in the sense that it checks whether a transfer should be restricted based on specified parameters and returns a reason for the restriction if applicable. The most unique aspect of this standard is that circulating tokens can be divided into tranches that each have an identifying key and balance. The point of this additional granularity is the ability to assign metadata to individual tokens that are grouped under various tranches; and this is useful for building functionality or restrictions into tokens depending on their specific tranche. In other words, an issuer is able to assign arbitrary metadata to groups of tokens that can determine how those tokens behave in the network.

Tranches are useful for a variety of use cases. For example, an admin can specify what kind of share a token represents (e.g. voting or non-voting) or when a token was minted to enforce a lockup period for specific portions of a user’s balance. This means that tokens held in a single address can have distinguished properties based on their assigned tranches, and therefore they can be assigned different restrictions based on those properties. This functionality is not possible with simpler standards where, for instance, a simple whitelist implementation either restricts an entire address or doesn’t. Whereas with this protocol, a single address can have both restricted and unrestricted tokens based on their individual tranches.

Additionally, Polymath’s ST-20 has useful features such as the ability to store legal documents on-chain while preserving privacy via hash functions, the ability to mint and burn tokens to control supply, and upgradability throughout the lifecycle of the token. Another feature that is explicitly stated in the protocol is a function only accessible to the admin that forces transfers from any wallet address, which can be used during government intervention or when securities law is violated in a specific instance. Overall ST-20 is a robust standard that provides a wide range of functionality for a digital security and contributes a unique implementation of tranches that can be useful for the entire security token ecosystem.

S3 (OpenFinance)

The OpenFinance Network is building a secondary market exchange for tokenized securities, but also they have put forward their own open source library of smart contracts to aid in the standardization efforts for digital securities that build on the Ethereum blockchain. The Smart Securities Standard (S3) outlines an architecture for a permissioned ERC-20 token where the rule checking for compliance does not occur on-chain. Instead a third party must resolve the validity of transactions and provide the error codes associated with their restrictions. S3 consists of a TokenFront contract that essentially holds a fixed Ethereum address and the ERC-20 interface. All of the calls to this contract are forwarded to the SimplifiedTokenLogic contract which actually implements the business logic. This allows the token’s core implementation to be modified while also giving a static address to the proxy token contract, so that data trackers can easily listen to emitted events like Transfer and Approval.

What differentiates S3’s architecture from the rest is its separation of the token’s functionality and storage. Typically, standard ERC-20 tokens handle both the storage of holder’s balances and the actual transfers between accounts. On the other hand, S3 contains a separate CapTable contract that stores the balances and accounts for all of the securities issued on the standard. So when a user requests a token transfer, first they make calls to the proxy contract which routes them to the core logic handler contract. Next, a third party resolves each transfer by inputting the appropriate error code, and finally a successful transfer fires a Transfer event that instructs the central cap table contract to actually update the balances of the involved parties. This structure makes sense for an exchange like OpenFinance that needs to consolidate data from multiple securities, and it creates a single source of truth for the entire secondary market.

OpenFinance has contributed significantly to the digital securities ecosystem by putting forth a unique architecture that logically separates the storage and functionality of an ERC-20 compatible token. However the obvious design flaw of S3 is the fact that compliance checks are dependent on a third party actor as opposed to being resolved on-chain. Implementing enforcement on the smart contract level is what enables real-time automation and transparency that relying on an off-chain solution does not. This alternative model requires a certain level of trust that the transfer validator is honest and enforces regulations correctly. And although there may be a lower risk of transfers happening that are not compliant, this can be easily resolved with consistent smart contract audits/updates and a permissioned structure that enables admins to control the token supply.

Atomic-DSS (Atomic Capital)

The Atomic Capital team has worked hard to develop and contribute improvements to a digital security standard. We have learned valuable lessons from observing this emerging industry as it has grown over the past few months. This learning is reflected in the design and implementation of the Atomic-DSS and would not have likely been possible without those listed above. Our standard draws inspiration from many of the protocols discussed in this article combining the best features from each to create a simplified and efficient framework for digital securities that we issue on Atomic platform. Following the basic functionality of ERC-1404, the Atomic-DSS implements two functions: verify and restrictionMessage. The first overrides the standard transfer and transferFrom functions with compliance checks and returns a corresponding error code. That code then receives a human-readable error message that enhances user interfaces and provides token holders with specific guidelines.

The Atomic’s DSS takes the ERC-1404 approach but places these two central functions in a separate RegulatorService contract that exclusively handles compliance. Similar to R-Token and ST-20’s approach, the restrictions logic is abstracted from the core functionality to allow for updated to rules after the token’s deployment. R-Token achieves this by having an additional proxy contract store the modifiable reference to the current regulator contract, but the Atomic-DSS simplifies this process by storing the regulator’s reference inside the main AtomicDSS contract. By implementing the replaceRegulator function in the token contract itself without an additional ServiceRegistry contract, it provides the same capabilities like upgradability and a static token contract address.

Lastly, Atomic-DSS contains a tiered permissions system that gives issuers the ability to mint and burn tokens as well as forcing transfers from any account similar to ST-20. To account for legal liability, the forceTransfer function allows for a recourse in the case of violations of securities laws, government intervention, and fund recovery for investors who lose access to their wallets. It is also advisable to be able to temporarily lock transfers from both generally and for specific accounts in case of legal disputes or unforeseen exploitations. Atomic-DSS also supports the ability to grant specific admin roles for secondary markets and compliance officers for various tasks such as amending investor whitelists and verifying investor information. These permissions settings are flexible and can be customized to fit the needs of each issuer and jurisdiction.

Conclusion

The article aims to provider readers with both a general overview of the nascent digital securities industry and also a technical review of current open source standards, including Atomic Capital’s DSS. This dialogue will continue and provides a collaborative approach to shared progress. The projects discussed above share similar goals and challenges. The intersection between open-source collaboration and legal considerations dependent upon jurisdiction will continue to push society towards seeking out approaches that achieve both protection and freedoms that the the blockchain community aims to achieve.

In our next article, Atomic Capital will provide an analysis of alternative blockchains to Ethereum for digital securities development.

REFERENCES:

1. https://github.com/ethereum/EIPs/issues/1404
2. https://github.com/ethereum/EIPs/issues/1410
3. https://github.com/ethereum/EIPs/issues/1411
4. https://github.com/harborhq/r-token
5. https://medium.com/harborhq/securitytokenstack-e6a273c1104e
6. https://medium.com/fluidity/automatic-regulatory-compliance-with-ethereum-892f01ef9eaa
7. https://medium.com/fluidity/security-tokens-and-the-digital-wrapper-61b8938b382
8. https://github.com/OpenFinanceIO/smart-securities-standard
9. https://github.com/AtomicCapital/atomic-dss
10. *Securitize DS Standard, a prominent and capable leader in this dialogue, was not included because open-source information wasn’t found.

Special thanks to Hassan Khan and Amish Gandhi of the Atomic Capital team for their preparation and review of this article.

Atomic Capital (www.atomiccapital.io) is a digital investment bank uniting growth capital and exceptional investments across the physical infrastructure, software, and life sciences sectors. We deliver the core technology, global relationships, and industry experience to move ideas to execution.

Contact us at dsi@atomiccapital.io to discuss your upcoming issuance needs and follow us on Twitter to stay up-to-date with company news.