Automatic Regulatory Compliance with Ethereum
A summary of security token standards that are incorporating compliance with smart contracts on the Ethereum blockchain
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
Essentially, the technical gist of these protocols is some permissioned smart contract that adheres to certain restrictions on transfer and other rules and regulations imposed on the issuer or holder. Some of these protocols use standard error code to allow for more information on restrictions. For security tokens, these rules need to be enforced through the entire lifecycle of a token, i.e. primary issuance and secondary trading. Some base features are restricting the secondary trading to only eligible parties. This means that trading is restricted to a certain set of counterparties. This could be simply a list of Ethereum wallet addresses at its core. While simple, having a notion of identity on a blockchain is powerful given the “Know Your Customer” (KYC) and Anti-money Laundering (AML) regulations. In addition, it is important to be able to lock tokens for an account and restrict them from transferring due to a legal dispute. Another common feature of these tokens is that different tokens may have different lockup periods, depending on the asset or jurisdiction. Being able to ensure all the parties cannot break that invariant is important. In addition, administrators need to be able to mint or burn tokens.
Many of these protocols usually just add a few extra functions on the base ERC-20 token interface. One feature is a transfer check embedded within the transfer and transferFrom functions. The second allows an administrator to mint and burn tokens. In addition, token ownership is publicly accessible. However, when you start diving into the project implementations, it is more comprehensive. These projects are making compliance their main job, and they’re doing it on behalf of the token projects. Doing compliance every few months or checking daily transactions is unacceptable. Because these transactions are in real time and every event is potentially a tax event, transfer restrictions and checks ultimately should be embedded. All of the protocols discussed are ERC-20 compliant, allow for transfer restrictions, and have a mechanism for preCheck transfers with some error codes on why a success or failure may occur.
All these projects are trying to solve a similar problem, but for their own organizations use cases. They realized that a basic ERC-20 token did not have sufficient checks in place to make it compliant. Token projects who ran just with an ERC-20 but had strong real-world compliance leading up to the sale have had to re-issue their tokens to comply. Many of these tokens did not restrict trading on the secondary market. Trading no longer occurs at centralized institutions. Peers can trade with other peers and thus regulatory checks built into the token are required. Many of these solutions incorporate some aspect of centralizations where there is an administrator or certain group who maintains the compliance standards.
Don’t worry, I’m not here to push another token standard on the world. The existing ones have pushed the conversation towards creating a standard. If we think standardization brings about interoperability and allow for more processes and systems to be built within the paradigm, a standard — even if extremely lightweight — will merge. At Fluidity, we are working towards tokenizing real-world assets. We understand that compliance is important and, therefore, incorporate automating compliance into our design.
Reference
