How security token protocols handle compliance

Distributed ledger technologies like blockchain have established a new way for companies to raise funding through Initial Coin Offerings (ICOs). However, after investors have lost a whole lot of money due to scams and hacks, ICO funding volume has declined rapidly. The advent of security tokens promises a new way of blockchain based funding with more focus on investor security. But, security tokens pose new requirements on token design regarding compliance. This post gives an overview on promising security token protocols and how they ensure compliance to security laws.

The ICO ecosystem is not capable of handling security tokens

Security tokens offer a more secure way of investing. That is because they rely on the value of real world assets like the valuation of a company rather than the abstract value of a network which is more or less captured by an utility token. The “downside” of security tokens clearly remains the need for compliance. Security tokens are almost always classified as securities which makes the issuing and trading of these tokens more complex. In concrete terms trading of a security token at least means that:

  • Buyer’s and seller’s identity have to be verified following Know-Your-Customer (KYC) laws.
  • All participants have to be checked for compliance with Anti-Money-Laundering (AML) rules.

The most common standard for issuing and trading utility tokens at the moment is the ERC-20 token interface with the top three token having a market capitalization of over two billion US dollars. However, the interface itself does not imply any rules regarding compliance. The transfer() and transferFrom() functions of an ERC-20 token can be used without the need for any party to reveal their identity. So, there is no way to adhere to KYC or AML restrictions.

Security token protocols emerge on the market

A bunch of companies and projects aim to solve these problems by establishing new protocols in the form of token standards reflecting compliance to security laws. Although there might be others, the ones that have got the most attention are the R-Token by Harbor, the S3-Protocol by Open Finance Network, the DS-Protocol as outlined by Securitize.io, the ERC-884 proposal for a new compliant token standard on the Ethereum network and the ST-20-Protocol proposed by Polymath. A look into their white-papers reveals their broad aspirations:

R-Token: “Harbor is building a decentralized compliance protocol to standardize the way crypto-securities are issued and traded on blockchains.” — https://harbor.com/rtokenwhitepaper.pdf

S3-Protocol: “OpenFinance Network […] has developed a framework to transform the trading, clearing & settlement process in the [alternative investment] industry, leveraging distributed ledger technology to bring efficiency, transparency, and interoperability to a fragmented market.” — https://www.openfinance.io/public/whitepaper.pdf

DS-Protocol: „Securitize’s mission is to be the leading platform for enabling compliant Digital Securities issuance and liquidity on the blockchain. To achieve this, Securitize has built a technology platform […] to manage all the elements in the full Digital Security lifecycle […]“ — https://www.securitize.io/uploads/whitepapers/DS-Protocolv1.0.pdf

ERC-884: “By deploying an ERC-884 token, a firm may be able to raise funds, either via initial public offering (IPO), or by private equity sale, in a manner conforming to Delaware Corporations Law, but bypassing the need for a custom share registry, or the involvement of a traditional stock exchange or transfer agent” — https://medium.com/coinmonks/tokenising-shares-introducing-erc-884-cc491258e413

ST-20-Protocol: “ […] a protocol to facilitate the primary issuance and to restrict the secondary trading of blockchain security tokens. […] By creating a standard token protocol which embeds needed requirements into the tokens themselves, these tokens can only be purchased and traded among verified participants.” — https://drive.google.com/file/d/180nPuOOPOZlDRDKSUoJP84AvFY0T5AuB/view

Although framed slightly different, all projects share the vision to create a new way of owning and trading securities. Blockchain technology promises to cut out intermediaries and therefore make the processes cheaper, faster and more transparent.

Technical dive into security token protocols

Despite these upsides, all projects have acknowledged the fact that their token will be classified as securities and they have build the protocols to support compliance restrictions:

Each token which uses the R-Token standard is deployed as an ERC-20 compatible token contract along with a reference to a Service Registry contract. This contract is a wrapper for an instance of a contract implementing the “Regulator Service” interface which defines only one method named “check” being responsible for the actual KYC and AML checks. The interface doesn’t state any requirements on whether these checks have to be performed on or off chain. However, all checks have to be performed before the actual transfer happens.

In the S3-Protocol the token contract is as well ERC-20 compatible. In addition, the token contract owner has to select a “User Checker” contract deployed on the network and registers it to be used with the token. The user checker is called from within the transfer() and transferFrom() functions with the task to validate KYC and AML compliance for the sender and the recipient of the transactions with regard to the token being transferred. All other compliance restrictions are bundled as regulatory frameworks which are deployed as separate contracts. These contracts check constraints off-chain (see the implementation of the SEC’s rule 506c as a framework contract for example).

At the moment, there is no open source code available that describes how the DS-Protocol will actually handle compliance. However, the white-paper states some basic concepts: A “Compliance Service” will be responsible for handling validation calls from compatible tokens. Identity information about an investor will be stored within a “Registry Service”. Both services communicate to determine which constraints have to be set on token transfers.

The ERC-884 reference implementation uses a slightly different approach. In contrast to all other protocols, checks are only performed for the recipient address. After a new address has been verified and owns token, that address is always free to send these token. In addition, besides the balances mapping, the contract stores all addresses of shareholders in an additional array to allow the query of the mapping’s keys.

Within the ST-20-Protocol a “Transfer Manager” is assigned to each token contract responsible for maintaining an on-chain whitelist. Other constraints which do not need off-chain information are checked directly from within the token contract.

Security token protocols compared

All token protocols are in fact compatible to the ERC-20 interface which has several advantages: Existing centralized and decentralized exchanges can add such tokens without further efforts. In addition, these tokens can be used within all forms of token economies. Therefore, new projects can continue to build on the ERC-20 ecosystem without worrying about their token being classified as securities. That should help projects focussing on US based investors where the SEC has made clear that “tokens and offerings that feature and market the potential for profits based on the entrepreneurial or managerial efforts of others contain the hallmarks of a security under U.S. law”.

Implementing the ERC-20 interface for these token protocols means that the mentioned token standards require — beside other methods — the transfer(address _to, uint256 _value) and transferFrom(address _from, address _to, uint256 _value) functions. In order to restrict the transfer of tokens all protocols use a whitelisting scheme. From within the transfer() and transferFrom() functions the addresses of sender and recipient are checked against a list of addresses that have been verified in a previous step. If the addresses are present on the whitelist the transfer is allowed. If they are not the functions fail and revert.

Whitelisting scheme within security token protocols

All projects mentioned here use such a whitelisting scheme. There always is a verifier component that acts as a whitelist. R-Token calls it “Regulator-Service”, S-3 introduces a “User Checker”, DS-Protocol mentions a “Compliance Service”, within the ERC-884 proposal the functions are implemented within the actual token contract and the ST-20-Protocol requires each token to have a “Transfer Manager” attached. Beside naming there are only marginal differences. The DS-Protocol white-paper even states that their desired solution will be compatible to the R-Token and the ST-20-Protocol. They could at no cost add the other protocols as well.

Limitations of existing security token protocols

Issuers of security tokens today face the problem that there are several projects out in the market but there is still no consensus on one standard. That truly matters because issuers have to make sure that the choosen protocol will work in the market for several years. However, given the fact that all protocols use very similar technologies, that shouldn’t be much of an issue soon.

What gets me thinking more, is that some of the existing protocols (like POLY for ST-20 or OFN for S3) make use of utility token within their ecosystem. Sure, ICOs have been an attractive way for those companies to attract funding, but on the other hand their utility token make the decision-making process of issuers more difficult and the ecosystem vulnerable to attacks.

Another limitation lies within the whitelisting scheme itself. The token protocols always require a trusted third party to add wallets to the whitelist before a transaction happens. Because of this, the third party hasn’t got any possibility to check for compliance at a transaction level. A transaction between two investors maybe compliant until some point in time t, but maybe forbidden at t+d where d can be only milliseconds. That requires the third party to be fast in updating the whitelist contract leading to high gas costs in order to prevent non compliant transactions. In addition, third parties must update whitelist data in near real time which requires them to store a large amount of data on-chain.

In a nutshell, all presented protocols are able to process tokens classified as securities. This is a big step towards a more effective and efficient capital market not at least making transactions more transparent. However, there are issues that have to be tackled. In fact, most of them arise because the protocols want to be ERC-20 compliant. It may be that it is time for a new ecosystem designed from the ground up to support compliant token offerings.