Fluidity Explains How Ethereum Platform Automates Security Token Compliance

In a recent post, Fluidity Engineer Deepa Sathaye outlined the need for compliant security tokens and the automated compliance featured in many ERC-20 token standards on Ethereum. Many protocols exist, which is great for the security token industry. Yet the situation begs the question of whether or not the industry will eventually collaborate on a select few protocols to foster further implementation and eventually, adoption.

The Many Different Security Token Standards on Ethereum

Security tokens are unique from other forms of cryptocurrency insofar as they represent physical, real-world assets. Such assets are subject to pre-existent laws and regulations. Security tokens are therefore required to maintain regulatory compliance in the same fashion as securities— stocks, bonds, funds, real estate, etc.— have for years.

Smart contracts and blockchain technology allow for the most streamlined compliance possible: automated compliance. Real-time checks and verification systems are already implemented in several ERC-20 compatible token standards. Several are live on Ethereum’s public blockchain.

Fluidity Engineer Deepa Sathaye recently outlined a few of those standards, sharing her technical expertise for the general education of us all.

OpenFinance Network’s Smart Securities Standard (S3)

The Smart Securities Standard aims to comply with all registered and restricted securities offerings, such as Reg D, Reg S, Reg A+, and Reg CF. The standard features a permissioned token with two primary components: a cap table and its core logic.

The cap table stores all S3 securities on a contract which is separate from all transfer restriction rules. The contract then utilizes a two-step clearing and settlement protocol.

The core logic components function as a proxy in a differing smart contract. This contract can be called by another contract, which allows for token modification in the case of new rules or laws that must be implemented.

Harbor’s Regulated Token (R-Token)

Harbor’s R-Token features centralized compliance, with decentralization everywhere else. It showcases three aspects which are respectively divided into three different smart contracts.

When an asset is tokenized with Harbor, a service registry is attached to the token through a smart contract. That service registry to mapped to one location which maintains all transfer checks for a particular token.

Before any transfers are performed, the token will automatically query the associated service registry to ensure that all parties involved— based on wallet addresses and transfer amount— are eligible for such a transfer.

With the R-Token, there is a need for a centralized owner, or administrator, to ensure regulatory compliance.

The Polymath ST20

Polymath’s ST20 is synonymous with the ERC-1400. A unique feature of this standard is forced transfer. In the case of legal action or fund recovery, certain addresses have the rights to force the transfer of ST20 tokens. Interestingly, this function seems to be unique to the ST20, as other standards have yet to explicitly express such a capability.

The Polymath ecosystem was built for life-cycle compliance. The token can be regulatory compliant through several embedded modules. It also enables token creators to update compliance requirements over time, such as restricting the number of total investors or decreasing the total amount to be held per investor.

Digital Securities (DS) Protocol by Securitize

This token features embedded functions which call back to the DS protocol. The DS protocol is then responsible for compliance, containing numerous modules to ensure everything checks out.

There are three main services which collectively automate compliance. First, there’s the trust service. This allows for various exchanges and decentralized applications to integrate with the DS standard by performing KYC and accreditation checks handled by the trust service.

Second, the registry service examines criteria such as investor location and KYC expiration dates. It also hashes this information to allow for validation without providing access to unknown entities.

Third, the compliance service verifies with the registry service that every transaction request is compliant. It also contains the logic for the DS token constraints.

The Commonalities of ERC-20 Compatible Security Token Standards

All of the aforementioned tokens shared some characteristics. They’re all ERC-20 compliant, they allow for transfer restrictions, and have some mechanism which provides information on why or why not a transaction was successful.

Yet still, there are several differences. Each company is likely trying to develop a standard with perhaps a slightly different use case. Nonetheless, there’s a lot of overlap. And this article is far from inclusive— other standards such as the ERC-1404 perform similar actions.

The situation then begs the question: will developers collaborate to develop one single, all-encompassing ERC-20 standard, or will they continue to develop ERC-20 compatible variations?

The answer, of course, is yet to be seen. But whatever answer unfolds, is likely to have a significant impact on the future of security token adoption.

What do you think about the many ERC-20 security token standards? Will the security token industry eventually segment itself from Ethereum? Let us know what you think in the comments below.

Image courtesy of Fluidity.