Good Protocols: How to Properly Standardize Security Tokens

Blockchain is a technology that brings the communication revolution, kickstarted through mass adoption of the internet, to the next level. The internet removed various intermediaries (for example mass media) from the flow of information. This made peer to peer communication easy, censorship hard and broadcasting (e.g., publishing a blog post like this) available to everyone. The promise of blockchain is not only to “free communication”, but also to let people make complicated transactions without needing to trust anyone but the system itself. Transacting parties do not need to trust each other and they do not need any trusted third parties like banks, notary services, stock exchanges, etc. to make a transaction happen. If they follow a specific set of rules set in the system they can be certain of the outcomes. In other words, all interactions that happen between parties on-chain follow a protocol.

In the context of Ethereum, every smart contract defines a protocol, because it enforces how people and other contracts interact through it. This is likely why the term protocol is used so often when people talk about anything blockchain-related.

I feel, however, that this term has been abused. Protocols should represent something more than just a set of any rules. We want good protocols: ones that are universal (standardized), deal with a well-defined domain and set of concerns, and which allow developers to build many different applications on top of them without presupposing or defining what those applications should be. An example of a good protocol is a reliable transport layer like TCP, or ERC-20 which defines a type of token: it offers a set of rules on how to own (fungible) things on blockchain.

With a protocol for ownership you can build an almost endless number of applications. Various types of tokens, centralized and decentralized exchanges, escrows, swaps and peer-to-peer lending networks are based simply on a right to own, enforced by the ERC20 protocol.

In short, a protocol is good when it allows creators to build an entire ecosystem of applications on top of it (think about HTTP).

The Neufund platform is an interaction system through which people (or smart contracts) can create and issue new tokens via a token sale or tokenize existing off-chain assets. It is comprised of a technical component, whereby on-chain interactions are mediated and enforced by smart contracts, and a corresponding legal component that deals with off-chain matters like regulations and dispute resolution.

In other words, the Neufund platform lets you issue a legally binding and regulated token and put it on the market — if you follow the on- and off-chain rules of the system. Now, from this perspective the platform is not limited solely to one type of token, such as Equity Tokens. For example, a Reg-D compliant security token (like the R-Token) or a Euro Token are just one of many applications that could run on top of our system and which need to conform to several interfaces, some of which are already protocols (like ERC-20) and some of which I’d like to see become standardized protocols in the future.

Tokens on the Neufund Platform and other Protocols

As mentioned above, each type of token that can be issued on the platform is considered to live in the application layer. The Neufund platform strives to be token-agnostic: in an ideal world, the only protocol a token needs to follow is ERC-20. This is, however, not the case. Once any token is used as an investment vehicle, it becomes a security that needs to comply with regulations. Even more restrictions apply for tokens that are designed from bottom up to represent off-chain assets.

Still, we want the freedom that an Ethereum token offers us and the last thing we should do is to pollute this with irrelevant off-chain considerations. Tokens want to be free and you can preserve that desire by designing your protocols carefully. Below are some general guidelines:

• Be compatible with ERC-20, which is the only true standard on Ethereum and a really sound protocol for defining ownership. Just like TCP is built on top of the Internet Protocol, we want our tokens to fully support baseline ownership rights. In practice, tokens issued on the Neufund platform must work with all applications designed for ERC-20 tokens after they are issued.
• Leverage as much as possible from existing patterns and experiences of the Ethereum developers’ community (MiniMe!). Developers are already using a lot of patterns when writing code without knowing that they could be common.
• If we need to extend ERC-20, we should do it in separate steps/protocols that can be independently adopted and be useful to many other projects and developers.
• Ideally, each extension could spawn a whole ecosystem of apps built on top of it.
• Everything else should be built on the application layer. As a token-agnostic platform, we do not want to standardize a particular token. We want to have a few simple protocols that are useful, whether our platform is there or not.

Legally binding contracts

There is just one other fundamental protocol (besides ERC-20) that any token needs to implement to talk to the Neufund platform. It’s a protocol of legally binding smart contracts. This is a kind of on-chain and off-chain bridge which is not only applicable to tokens. Its features include:

• Irrevocably linking a smart contract to a legal document and vice versa.
• Allowing for retrieval of a current legal agreement (or a smart contract if initiated from the paper side).
• Allowing amendments to a legal agreement (the mutable part — see later).
• Allowing parties to sign-up and to link the smart contract’s blockchain state at the moment of signature to an off-chain agreement.
• Checking to see who signed up and at which block.

Here is the IAgreement interface and mixin class used everywhere on the platform that express these requirements (surely we can improve them!).

Implementing legally binding contracts involves working side-by-side with (smart) lawyers. I quickly realized that their practice is very similar to coding: it’s about procedures, rules and their enforcement. And the cool thing is that 90% of each legal agreement can be put straight into code. The remaining 10% is even cooler. It’s basically covering the meta-programming part that Ethereum lacks. For example, here’s what we meta-define on our smart contracts via “paper”:

• Fork arbitration clause: What happens in the case of a fork? Which fork do we support? You need a meta-level to define a correct procedure and an off-chain agreement is the way to do it.
• Bug-fixing clause: We need to upgrade our code (e.g., via forwarding a contract) when we have a bug or an efficiency problem. But how to define a bug fix? Another meta-level problem, so we use this clause.
• Migration clause: Parties may migrate to different sets of rules (to a different contract). What is the procedure?
• Immutability clause: Parts of a legal agreement correspond to the code and cannot be changed. Others correspond to off-chain or meta-programming and we should be able to amend them without migrating from smart contracts. But, the immutable parts need to stay.

Here are two such agreements where you can find all the provisions above. One is attached to a token (NEU), the other is attached to a token offering contract.

Snapshot Token

There is another component that seems kind of universal and is already adopted in many places. It’s the ERC-20 extension that lets you keep certain rights after you trade your tokens. Do you want to sell your tokens, but still claim your dividends prior to the sale? It’s the way to go!

The protocol we follow is what we call snapshot token protocol and is based on a kind of engineering marvel which is the MiniMe token from Giveth. The extension is very simple.

The best thing is that you can build a whole set of apps on top of it, just like you can build a whole set of apps on top of ERC-20:

• All the apps for voting, dividends, information distribution that Securitize describes in their whitepaper.
• Dividend distribution that Polymath is implementing.
• Voting procedure of ERC-1384.
• Can be (and is already) used by Aragon organizing profit distribution and voting.
• Used by Neufund token controllers (see below) to execute Equity Token shareholder rights.

All of this is possible via a simple extension which gives you past balances of a token.

Token Controller

There is another building block which I’m not sure could be a protocol but that seems to be pretty universal. We call it token controller (again after MiniMe). It’s a way of removing concerns from a token contract into the app layer. Example of token controllers could be:

• A controller that implements transfer and approval permissions.
• A controller that implements company governance with votings, dividends, vesting, cap table, different token classes, secondary issuances all other things you do in an organization.
• A controller that implements any type of decentralized governance for a network, a DAO, where you are free to use any organization building toolkit like Aragon OS.
• A controller which is controlling off-chain assets like bank minting and settling USD Tokens.

All of that can be implemented via a very simple interface which we use extensively on our platform. Instead of trying to standardize functions of a particular controller (like “security token issuer”), it’s a much better pattern to standardize a token <-> controller interface so any app can be built on that.

This is an interesting pattern, however I still consider this an app layer, at least until more use cases are discovered.

Examples of tokens. All of them ERC-20 (+ERC-223)

The Neufund platform is token agnostic and we have a few tokens deployed on it already.

• The Equity Token is legally binding contract that allows for shareholder rights to be executed by any app understanding the snapshot token protocol. It also has a token controller which is simply a company/issuer of the token. The token controller implements company governance and it is a legally binding contract as well. It also controls token transferability. Part of the company governance is to set up a transferability policy and this depends on the shareholders’ will and of course regulations . In the current legal setting after we issue Equity Tokens, transferability can be enabled via shareholders voting and in principle a token could be freely transferable after that, without any KYC, whitelists and other restrictions.

• The Euro Token is a legally binding contract that represent Euro which is off-chain asset. It does not need snapshot protocol, because it represents money where the only right that counts is a right to own so ERC-20 is enough. It however has a token controller and a pretty restrictive one. Let’s say it represents a bank and is responsible for checking KYC/AML verification and settling deposits and withdrawals.
• The NEU Token is the Neufund platform network token. It’s legally binding — regulatory status of its issuance is clear and yes you will get your dividends in Euro. It also implements the snapshot token protocol, because it pays you proceeds and gives access to the platform token portfolio. It may also be used for voting on platform settings and for anything else which snapshot token apps might allow in the future. It however does not have a token controller, because there is no entity controlling it — it’s a token of a decentralized network and it just listens to internal issuance rules along an exponentially diminishing curve.

Network token self-controlling its issuance

Conclusion

Protocols should be simple, well focused and able to spawn a whole ecosystem of apps around them. Not every good piece of code or an interface is a good protocol. Bad things that people do include:

• “I have a nice implementation of a thing, let’s make it a standard.”
• “My smart contract is doing cap table or voting nicely, let’s standardize it.”
• “We discovered a cool way to avoid regulations, let’s standardize it.”

Frankly, I do not believe that there’s anything like a security token standard. There are many things that may be put together to create a security token which is just a kind of app built on a set of clever protocols and each of those can be used for something else.