In the past six months, there have been numerous protocols presented to deal with automating certain aspects of compliance on the Ethereum blockchain. Compliance is needed because securities and other representations of value, which are now being stored on the blockchain, are subject to regulatory compliance obligations. By incorporating real-world assets, “security tokens,” for example, have to comply with existing securities laws. What’s exciting is that in the past month, some of these protocols are now live and being run on the public Ethereum blockchain!

Taking a step back, let’s ask why automating compliance is attractive? Compliance is hard. It is costly, tedious, and seems bureaucratic. Compliance ensures that organizations adhere to a set of precise rules, standards, and processes set forth by another entity. These rules protect national security, fight money laundering, and deter criminal activity within financial systems. If you’re located in the United States, these entities include the Financial Industry Regulatory Authority (FINRA), the Commodity Futures Trading Commission (CFTC), the Securities and Exchange Commission (SEC) and the Financial Crimes Enforcement Network (FinCEN). Even in the decentralized world, compliance is necessary for certain digital assets. While issuers need to think about how to ensure that their digital asset remains compliant in primary and secondary markets, the ability to program compliance may limit the need to rely on gatekeepers subject to human error.

Automated compliance has quite a few perks. The alternative is running interval compliance checks where you’re following a “trust but verify” structure. Historically, broker-dealers would have compliance departments that ran checks daily to see if they had any “breaks” or “anomalies”. Now they can run these at real time, ensuring no trades or transfers can take place if they would cause a violation. With better technology, automated compliance will become the standard in IT and financial services. Thus, if we’re using a technology like blockchain to improve efficiencies in finance and allow for borderless trading, we can utilize the technology of smart contracts to conduct these real-time checks.

At this point, I’ve covered why automating compliance is required for security tokens. Below I’ve analyzed S3, R token, ST20, DS Protocol, and ERC-1462 protocols. Each project provides a protocol for automating compliance with similar, but slightly different mechanisms, depending on their use case. There are several other projects not discussed who have expressed similar standards like LDGRToken, Abacus, and Meridio.

Smart Securities Standard (S3) — Open Finance Network

OpenFinanceNetwork focuses on security token trading platforms, but they do also have a framework for automating compliance in smart contracts. The framework was published as a flexible smart securities standard (S3). Their Github repository does contain both a smart contract library as well as a library for interacting with the smart contract. OpenFinanceNetwork mentioned that this library will be able to encompass all offerings of “ registered & restricted securities, including Regulation D, Reg S, Reg A+, & Reg CF” [1].

The simplified S3 architecture provides a permissioned token with no rule checking on chain” [1]. The standard, compatible with the ERC-20 standard, contains two main components, where one holds the Cap table for tokens and another that contains the core logic for the token. The core logic components, known as the DelegateERC20, acts as a proxy for all the token logic which is handled by another smart contract. This contract, aptly named TokenFront merely allows itself to be called by another contract. This allows the business logic for the token to be modified if there are new rules that need to be followed but allows for the token to keep a permanent address and have a singular contract that emits events like Transfer which other interested parties or data trackers can listen to.

This framework has two unique features in how it handles balances and transfers. Unique to this framework compared to other standards is that the cap tables of all S3 standard securities are stored together on a separate contract that is separated from its transfer restriction rules. Theoretically, there could be one central smart contract that contains the balances and holders for all securities issued on the S3 standard. This contract implements a two-stage clearing and settlement protocol. Users create token transfer requests by calling transfer and transferFrom on the associated TokenFront. Then a third party resolves each transfer request by providing an output, called an error code. Only on error code “0” is the transfer settled. Non-zero codes reveal to the sender why a transfer would not succeed automatically. The transfer is able to be bubbled up to the central cap table where the actual decrementing and incrementing of token amounts takes place. The transfer restrictions can only be updated by a registered party. Thus, this protocol allows for this token to be listed and shared on secondary markets without the risk of transfers occurring non-compliantly. In addition, the error code acts as a signal ensuring that the users understand when and how they may transact compliantly.

Regulated Token (R-Token) — Harbor

Harbor has been vocal with their promise of automating compliance [2]. They released a whitepaper in February 2018 as well as sample source code for smart contracts in April 2018. I’m basing most of the discussions based on what is present in their whitepaper and Github repository. Harbor created a decentralized compliance protocol known as the R-Token that ensures digital assets can be traded compliantly.

This protocol has three parts which is split up into three different smart contracts. The actual digital asset (token part of the protocol) is built on top of ERC-20 standard which allows for integration with existing decentralized application systems. The token embeds regulatory checks on the token itself with the help of the other two smart contracts. When the smart contract for a token is created, a service registry is attached to a token. The service registry is mapped to exactly one registry service that contains the transfer checks for a particular token. Prior to doing any transfers, the token will check with a service registry who will map it to the regulator service. The regulator service embeds the exact compliance checks that ensure two parties, based on their wallet addresses and amount transferred, are eligible to complete the transfer. If a check succeeds or fails, a public event is outputted that allows parties who are listening to this contract to determine why a transfer check failed.

Similar to the S3 mechanism, there is a fixed contract address that has a stable address and specific functions that can be called. The service registry acts as a proxy to the regulator service which can be modified. Only designated owners of the service registry can update the regulatory service. This protocol requires an owner, or central body, that acts as administrator on the regulatory checks as well as the token itself. The regulated tokens (R-Token) is permissioned because there is a regulatory service that checks for trade approvals and thus they’ve taken on the role of automating compliance. This adheres to Harbor claim, “What we do is we centralize the compliance and decentralize everything else [3].”

ST20 (Security Token Standard) (ERC-1400/ERC-1410) — Polymath

Another protocol, that was introduced as an ERC standard is ERC-1400/ERC- 1410. It is being supported and implemented by Polymath. The ST20 is synonymous with ERC-1400/EC1410 in which it strives to be a standard interface for issuing security tokens, managing their ownership, and transfer restrictions [4]. The Polymath ST20 implementation has a verifyTransfer function which checks whether a transfer will succeed based on certain data parameters and outputs the reasons for failure if there is one. On-chain document support by placing a hash of a legal document is also present in this specification.

The security token standard is built to be flexible and allows for managing different types of ownership of fungible tokens representing asset ownership. ST20 by itself only has a few additional checks on top of ERC-20 which are verifyTransfer, mint, and burn. In addition, the ST20 protocol requires that tokens have the ability to perform a forced transfer for legal action or fund recovery. These special shareholders or STO roles can only be operated by certain addresses with these rights. The specific mention of forced transfer is unique to ST20 that other frameworks have not explicitly discussed whether their frameworks can support.

The security token standard contains a section about partially fungible tokens which means that owners of a token can be segmented into different tranches. These different tranches can be used for different vesting or lockup logic. While this adds complexity, this structure may apply better to certain use cases that Polymath has been working on.

The Polymath Core implementation builds an ecosystem for the whole token lifecycle. With the use of several embedded modules, the security token can be regulatory compliant. It allows primary issuers to create upgradable compliant tokens that can be compliant over any set of complex rule sets. One example is that there is a module that can handle either restricting the number of total investors or limiting the percentage of token supply held per investor. In addition, there are modules that can handle dividend payments and bridge the gap between off-chain and on-chain information handling.

Digital Securities (DS) Protocol — Securitize

The Digital Securities protocol from Securitize champions to be a full token lifecycle and architecture for all issued securities. Their protocol works for issuers, investors, and exchanges. Their DS Token is ERC-20 compliant. On initiation of the token, they have embedded functions that call back to the DS Protocol. The DS Protocol contains multiple modules that ensure compliance.

This ecosystem, as described in their whitepaper, contains three main services that ensure compliance: Trust Service, Registry Service, Compliance Service. Similar to other standards, the transfer and transferFrom functions contain checks that will use the previously mentioned services. In addition, they offer the ability for decentralized applications like exchanges to also be integrated with the DS Protocol and these applications can trigger functions for a token. This extra functionality is handled by the Trust Service and thus Dapps can do KYC and accreditation for investors. The DS Protocol via the Registry Service looks at investor information on a more granular level than just whether an investor is eligible to trade. It contains public information regarding the investor country, KYC expiry date, and KYC information hashed. Having information hashed means that it is a one-way lookup so you can validate, but one should not be able to glean information from the hash. One consequence of having more information stored on-chain is it allows trustless parties outside of the issuer to take compliance responsibility.

The last service, Compliance Service is what service is called during a transfer and transferFrom call from a DS Token. This service checks the Registry Service and contains the logic for this token’s constraints.

Base Security Token (ERC-1462) — Atlant

Atlant, which focuses on tokenized real estate, came out with ERC-1462 (Security Token Standard) which is a general security token standard. The token standards builds off the ERC-20 standard while allowing tokens to be locked for an account as well as restrict them from trading. It allows you to upload documents and look them up by some name as well. They add four checking functions to determine whether a token can be transferred, minting, and burning can occur. The checking functions use standard Ethereum status codes as defined by ERC-1066 which tells users whether a transaction will succeed or fail based on trade-specific inputs. Because this standard is generic, there are no specific jurisdictions and it allows people who build on top of this project to set their own specific functionality and limitations.

Summary