Announcing the SFT Procotol - Part 3: On The Technical Foundations Of Our Protocol

This is the third part in our series of articles introducing the SFT Protocol, a set of compliance-oriented smart contracts for Ethereum based security tokens. You can read the first part here, or the second part here.

The popularity of ICOs in the past two years has resulted in widespread adoption of the Ethereum ERC-20 standard. A multitude of wallets exist that support this standard, exchanges have infrastructure built around it, and most end users have at least a basic understanding of how it works.

Specific to security tokens, Ethereum is not without issues:

  • On-chain compliance is only useful when transactions occur on-chain. To allow for secondary trading, market operators and custodians must be trusted to understand and abide by the issuer’s transfer restriction rules. This is made exponentially more complex when tokens are trading on multiple markets simultaneously. The obvious solution is to use decentralized markets where compliance is still handled on-chain. However, the logic involved in on-chain compliance translates to higher gas costs during transfers. Given the current block gas limit of 8 million and the transfer cost of security tokens likely to weigh in at several hundred thousand, this approach will be unable to adequately scale.
  • When security tokens and investor identity do not exist as first class citizens they are susceptible to a variety of attacks. Front-running, miner manipulation and transaction spam are all very real concerns. We can take steps to mitigate against these, but ultimately it is akin to filing away the edges so that a square peg fits in a round hole.
  • The lack of privacy inherent in public blockchains presents a huge hurdle when on-boarding large institutional investors who wish to preserve their personal data and do not want their holdings being shared with the public.

Improvements to Ethereum such as Shasper or implementing zk-SNARKs may solve these problems, however we think it is important not to be overly attached to any one blockchain. As the industry grows more suitable technology may emerge, either as implementations upon existent blockchains or new, purpose built blockchains that handle securities as first class citizens.

That said, mass adoption of tokenized securities will require far more than just technical innovation; it will take understanding and participation from regulators, financial institutions and the general public. As a catalyst for initiating these discussions we believe that an important first step is simply having security tokens being traded. To that end, we consider Ethereum and the ERC-20 standard to be the optimal starting point for making this happen.

The SFT protocol is a set of open sourced compliance-oriented smart contracts, written in Solidity for the Ethereum blockchain, that allow for the tokenization of debt and equity based securities. It provides a robust, flexible framework allowing issuers and investors to retain regulatory compliance throughout primary issuance and multi-jurisdictional secondary trading.

We invite you to view our code on GitHub while reading this article. You can also read our yellow paper for a more thorough overview, and see our technical documentation for a detailed breakdown of the protocol’s functionality.

How SFT Works

The SFT protocol is designed to maximize interoperability between different network participants. Broadly speaking, these participants may be split into four categories:

  • Investors are entities that have passed KYC/AML checks and are are able to hold or transfer security tokens.
  • Issuers are entities that create and sell security tokens to fund their business operations.
  • Registrars are trusted entities that provide KYC/AML services for other network participants.
  • Custodians are trusted entities that hold tokens on behalf of multiple investors and facilitate secondary trading.

The protocol is built with two central concepts in mind: identification and permission. Each investor has their identity verified by a registrar and is assigned a unique ID hash that is associated with their wallet addresses on-chain. Based on this identity information, issuers and custodians apply a series of rules to determine how the investor may interact with them.

Issuers, registrars and custodians each exist on the blockchain with their own smart contracts that define the way they interact with one another. These contracts allow different entities to provide services to each other within the ecosystem.

Security tokens in the protocol are built upon the ERC-20 token standard. Tokens are transferred via the transfer and transferFrom methods, however the transfer will only succeed if approved by a series of permissioning modules. A call to checkTransfer returns true if the transfer is possible. The base configuration includes identification via KYC/AML whitelists, tracking investor counts and limits, and restrictions on countries and accreditation status. By implementing other modules a variety of additional functionality is possible so as to allow compliance to laws in the jurisdictions of the issuer and investors.

Features and Capabilities

Identity as a Service

The current norm for identification is such that in order to invest in ten different projects, an investor must submit their KYC/AML data ten times. This is highly inefficient and provides an increased opportunity for identity theft due to maliciousness or negligence.

In SFT, investor whitelists exist independently of token issuances. Each issuer may choose to accept KYC data from as many or as few registries as they wish. We envision large, multinational organizations will provide on-chain identification as a service, charging fees to verify the identity and accreditation status of investors, and then approving these investors to buy or sell any token issuances that receive KYC data from that registrar. This massively reduces costs to issuers around KYC, as well as friction for investors.

Detailed On-Chain Cap Tables

Each issuer deploys an IssuingEntity contract, which is then associated to the security tokens they create. This contract maintains accurate on-chain investor counts, even in cases where an issuer creates multiple tokens. Issuers may impose limits based upon the number of investors, accreditation rating, country of residence, or any combination thereof. This is often necessary in order to comply with restrictions around private placement.

Issuers pull investor data from one or more registrar contracts. Because registrars allow each investor to have multiple wallet addresses associated to them, an investor may hold tokens across many addresses and still only count as a single beneficial owner. They may also transfer tokens between their addresses with less significant restrictions, as in this case there is no transfer of beneficial ownership.

Custodians deploy a Custodian contract, through which they hold tokens on behalf of one or more beneficial owners. This contract allows interaction with the issuer’s cap table, such that even if an investor has tokens in their wallet and tokens held by multiple custodians, they will only count as a single beneficial owner in the cap table.

Multi-Authority and Multi-Sig Functionality

The protocol incorporates both multi-authority and multi-sig functionality. Contract owners may declare sub-authorities that are able to access a limited range of admin-level functionality. This can be used to compartmentalize control over the contract, greatly decreasing the potential damage possible in the event of a compromised private key. This approach is also useful in large organizations, to provide limited access to individual employees or third party contractors.

Each authority may also have multiple addresses associated to it, and a threshold value can be set such that in order to execute any method it requires multiple calls from different addresses belonging to that authority. With proper private key management, this reduces the possibility of a compromised contract in the event of a data breach.

Modular Design

Issuers and custodians may attach modules to their contracts that hook into specific methods to implement a wide range of added functionality or permissions. Modules can be used to handle a variety of life-cycle events including (but not limited to) crowdsales, country/time based token locks, right of first refusal, voting rights, dividend payments, centralized and decentralized exchanges, tender offers and bond redemption.

Thanks to the on-chain cap table tracking, it is trivial to introduce modules that enforce compliance with common legal frameworks issuers may wish to abide by. Meeting the requirements of private placement exemptions such as Reg CF, D or S are all possible.

Modules are intended to be ephemeral. Once a module’s purpose has been served it can be detached as a means to minimize gas costs. For example, there is no need for dividend payment logic to remain in place once a dividend has been fully distributed.

Highly Gas Efficient

First transfer to a new investor (the most expensive token transfer) — using brownie

Enforcing on-chain compliance while minimizing gas costs is no easy task. We have spent many hours running tests and looking for ways to better optimize our code, and we are proud to report that at present a token transfer on the SFT protocol cost between 80–210k in gas. This is no greater than some code-heavy utility tokens, and significantly less than we have seen demonstrated by other security token frameworks.

This is accomplished primarily by minimizing the number of external contract calls and using efficient structures for data storage. All relevant information about an investor is obtained from the registrar in a single call, and passed between methods to prevent a need for further external calls. We take advantage of solidity’s tight variable packing, and organize code so as to minimize the number of writes to storage.

An Invitation to the Community

Again we invite you to view our code on GitHub. You can also read our yellow paper for a more thorough overview, and see our technical documentation for a detailed breakdown of the protocol’s functionality.

Thanks, xkcd

We welcome any comments, inquiries, and suggestions for improvement around what we have built. This protocol is still under development and we look forward to speaking to others in the industry about their technical requirements, so that we can better attempt to address them. At present we are undergoing internal unit tests and auditing, and we anticipate we will be ready for an external audit prior to the end of the year. Visit our website, Twitter, or Telegram channel for contact details.

In the coming weeks we will publish more articles explaining specific areas of the protocol. We will outline use cases, explain our methodology in specific areas, speak about challenges and limitations, and address the feedback we receive.