In my essay about controversial ideas about security tokens (part I, part II) I mentioned that there is a significant probability that Ethereum might not be the platform of choice to implement security tokens in the long run. The idea might seem ludicrous at a time in which Ethereum is pretty much the only active runtime in the crypto securities ecosystem. However, the reasoning starts making sense once you balance the limitations of Ethereum in the context of the future architecture of security tokens.
I am a big fan of Ethereum both as a platform and as a crypto asset. As a technologist, I use the tech stack on a regular basics and I believe the platform might go down in history as one of the greatest technological contribution of the first century of computer science. However, when I think about security tokens, there are many elements that make me question the long-term viability of Ethereum. None of those aspects are related to the well-known limitations of Ethereum in terms of scalability or transaction-cost. I firmly believe there is enough talent behind Ethereum to address those issues. My premise comes from fundamental frictions between the nature of crypto-securities and the architecture of Ethereum. To explore this idea further, let’s start with debating what to look for in a platform for security tokens.
What Makes a Good Platform for Security Tokens?
When building an architecture for tokenized securities, there are three fundamental building blocks that need to be place: identity, asset-ownership representation and compliance models. Security token laws around the world require that the identities of parties involved in a transaction need to be known and verified. Asset-ownership representation is a key element of the DNA of security tokens while governance and compliance rule security transactions across different jurisdictions and industries. From that perspective, identity-asset ownership-compliance trifecta is the cornerstone of any security token platform.
If we agree that identity, asset ownership representation and compliance are the three main pillars of a security token model we might already start having issues with Ethereum as the platform doesn’t really support ( and to some extent negates) any of those elements.
In addition to the key three pillars, there are some secondary capabilities that become really desirable in security token models:
· A Simple Consensus Model Based on Identity: Security token models do not require computationally expensive consensus protocols such as proof of work or proof of stake. Operating with known identities drastically simplifies the consensus mechanics in a security token transaction. I recently wrote about the need of new consensus protocols for security tokens.
· Crypto Financial Primitives: Any security token is a composition of basic financial primitives such as debt, equity, risk, dividends etc. It would be nice to live in a world in which using those primitives doesn’t require using exoteric protocols that don’t interoperate with each other.
· Simpler Oracles: Security tokens very often require interactions with off-chain data sources. While this can be done on Ethereum by implementing Oracles, the model is really constrained and complex to model most of the scenarios relevant to crypto-securities.
Transactions vs. Ownership
The fundamental limitation that makes Ethereum a painful choice for security tokens can be expressed as the friction between transactions and asset ownership. Ethereum is a very powerful platform that is fundamentally optimized for one use case: transfer a crypto-asset from point A to point B. The behavior of security tokens, on the other hand, is fundamentally dictated by dynamics related to asset ownership that have little to do with transaction mechanics. Can you model asset ownership in Ethereum? Yes, but it feels like a never-ending hacking exercise.
Smart Contracts vs. Crypto-Financial Primitives
Smart contracts such as the ERC-20 standard are the cornerstone of security tokens today. Now, if you ask any technologist in this space why are we using smart contracts to implement security tokens the answer most likely will be related to the fact that is the only mechanism available on Ethereum. In turns out that smart contracts are a really painful way to model security tokens. Smart contracts are too constrained in terms of code-semantics, every single financial model is a monster coding effort, they have some very tangible limitations in terms of size and portability and a million other limitations that make it a nightmare to express complex crypto-security models.
Let’s use financial securities as an analogy. A securitized product like a mortgage-backed security is effectively a contract. It just happen to be a contract backed by a really sophisticated financial infrastructure that is not based on contracts. Similarly, smart contracts might be the ultimate representation of a security token but the underlying infrastructure might be based on more sophisticated components.
Instead, or rather in addition to, smart contracts, security tokens might benefit from a programming model that includes crypto-financial primitives such as debt, equity, payments, dividends, risk, defaults etc as first class constructs that can be composed into sophisticated financial products. Modeling a relatively trivial example of a security token derivative such as a collateralized debt obligation in Ethereum requires assembling a few exoteric protocols such as Dharma, {Set}, 0x in a way that they all interoperate with each other without breaking any of the smart contract constraints in Ethereum. We need a simpler way.
5 Blockchains that Provide Interesting Ideas for Security Tokens
The blockchain ecosystem is exploding with innovation and some of that creativity can permeate into the security token space. If we think about some of the key capabilities that we would like to have in a security token platform, there are some interesting ideas in the new generation of blockchain platforms that might become relevant to crypt-securities.
· DFINITY: DFINITY’s blockchain nervous system includes many interesting governance principles for security tokens. Similarly, DFINITY’s scalable architecture might be a solid runtime for implementing and hosting building blocks like Oracles or data providers that are relevant to security token models.
· Tezos: Many of the governance protocols included in Tezos are relevant to security token architectures. I particularly like many of the ideas behind Tezos’s economic protocol and validation system
· Enigma: I believe secure multi-party computations is one of the most viable privacy techniques for security token transactions. Enigma’s implementation of sMPC is one of the best I’ve ever seen.
· Hasgraph: Hashgraph has a unique advantage that it supports smart contracts written in Solidity which is not a small advatange considering that almost all security tokens are ERC 20-based. The uber-scalable infrastructure is obviously a strong plus.
· Stellar: Stellar’s architecture includes many of the building blocks required for security token architectures such as compliance check points. Unfortunately, the Stellar platform still has some work to do when comes to apsects such as smart contracts to become a viable option for security tokens.
The Ethereum of Security Tokens Might Not be Ethereum
Ethereum already won the utility token race. When comes to security token, Ethereum’s position is not so clear. From a market dynamics perspective, security tokens have the opportunity to add as a corrector in the market leveling the play field for many of the emergent blockchain players.
In my opinion, we are likely to see new blockchain architectures and protocols optimized for security token use cases and, who knows?, the Ethereum of security tokens might not be Ethereum.