paint-brush
Some Cool Protocols to Consider for the Next Generation of Security Token Platformsby@jrodthoughts
815 reads
815 reads

Some Cool Protocols to Consider for the Next Generation of Security Token Platforms

by Jesus RodriguezOctober 23rd, 2018
Read on Terminal Reader
Read this story w/o Javascript
tldt arrow

Too Long; Didn't Read

Building the right infrastructure for security tokens is the next pivotal challenge in order to make crypto-securities a relevant asset class. Moving beyond the basic tokenization capabilities in today’s platforms and enabling infrastructure building blocks that can mimic the dynamics of securitized products, its imperative for the long-term viability of the security token space. However, the process of creating the next runtime building blocks for security token is governed by the friction between infrastructure and applications. Without the right infrastructure, it is going to be near impossible to tokenize asset classes that can catalyze the evolution of the space. At the same time, without getting exposure to sophisticated projects its very hard to know what infrastructure building blocks are really required in security tokens. The right, and far from trivial, answer is to determine how much infrastructure to build to enable the implementation of great security token projects.

People Mentioned

Mention Thumbnail

Companies Mentioned

Mention Thumbnail
Mention Thumbnail

Coins Mentioned

Mention Thumbnail
Mention Thumbnail
featured image - Some Cool Protocols to Consider for the Next Generation of Security Token Platforms
Jesus Rodriguez HackerNoon profile picture

Building the right infrastructure for security tokens is the next pivotal challenge in order to make crypto-securities a relevant asset class. Moving beyond the basic tokenization capabilities in today’s platforms and enabling infrastructure building blocks that can mimic the dynamics of securitized products, its imperative for the long-term viability of the security token space. However, the process of creating the next runtime building blocks for security token is governed by the friction between infrastructure and applications. Without the right infrastructure, it is going to be near impossible to tokenize asset classes that can catalyze the evolution of the space. At the same time, without getting exposure to sophisticated projects its very hard to know what infrastructure building blocks are really required in security tokens. The right, and far from trivial, answer is to determine how much infrastructure to build to enable the implementation of great security token projects.

Determining the right infrastructure blocks of the next wave of security token platforms its certainly difficult but there are some clear areas that can serve as a starting point. Even in the very nascent state of the crypto-securities industry, we are already seeing projects claiming for capabilities that are missing in the current generation of platforms. From the market perspective, one interesting area of debate is to determine whether those capabilities are going to evolve as standalone protocols or be incorporated into generic security token platforms.

The Pre-Chasm Dilemma: Platforms vs. Protocols

In the blockchain space, we are seeing an explosion of tier2 protocols that focus on enabling a singular capability of decentralized applications. You can certainly make the case that there are areas of security tokens such as derivatives or liquidity that are complex enough that merit their own protocol. However, that might not be the case in the short term.

In his best-seller book, Crossing the Chasm, Geoffrey A. Moore explains different dynamics governing the evolution of technology markets. Moore divides any technology market between the pre-chasm or early market where new technologies are the subject of experimentation and the post-chasm or mainstream market in which the technology is adopted in the broader market.

One of the lessons we can extrapolate from Moore’s thesis, is that in pre-chasm markets, solutions that provide an end-to-end experience tend to be more successful than capability-specific solutions. Taking that analysis to the security token space, we should expect the current phase of the market to be led by end-end tokenization platforms that incorporate simplified version of crypto-securities protocols. As the market evolves, some of those protocols will become relevant enough that might evolve into standalone offerings that can be integrated into different platform.

With that thesis in mind, the next logical step is to determine what protocols should be included in the next wave of security token platforms. Given that most crypto-securities platforms live in the Ethereum runtime, they can benefit from the great levels of innovation that we have seen in Ethereum-based protocols in the last couple of years. Below, I listed some areas and protocols I believe could bring some immediate value to the current generation of security token platforms. I like to keep these blog posts to a manageable length, so I am only providing a brief description of the protocols. I have a series of posts coming up that deep dive into these different areas. Also, I am aware that there are protocols that are missing in this list but I am trying to focus on the ones I believe can be rapidly incorporated into the existing group of security token platforms.

Liquidity

· The Problem: Liquidity is, arguably, the most important challenge of the crypto-securities market. While part of this challenge is going to be addressed as a natural evolution of the space, the platforms need to incorporate liquidity protocol as a first-class building block.

· Bancor: Bancor proposes a protocol for liquidity based on the notion of Smart Tokens which are tokens that hold balances of other tokens within their smart contract. Making security tokens, Smart Token compatible can be a basic step to enable a first level of liquidity in the space.

· Two-Token-Waterfall: Michael Oved recently co-authored what I considered one of the most important whitepapers in the security token space. The Two-Token Waterfall proposes a token structure that combines debt and equity tokens that activate based on different triggers to streamline liquidity in security token transfers.

Governance

· The Problem: Security token require new governance and voting dynamics beyond a transaction-based consensus mechanism. From simple compliance and validation to sophisticated dividend distribution dynamics, voting and governance models should be incorporated into the next wave of security token platforms.

· POA Network: Proof-Of-Authority is one of the identity-based consensus models that I believe can become relevant to enable governance dynamics in security tokens. POA Network implements proof-of-authority using an Ethereum-compatible side-chain model that can be adapted to different security token platforms.

Privacy

· The Problem: Security token transactions today share the same level of privacy which is basically none. Enabling privacy-policy models is essential to unlock an entire group of security token scenarios across different industries.

· Buletproofs: Recently adopted by Monero, Bulletproofs provide a high performance protocol for confidential transactions. Bulletproofs addresses some of the limitations of protocols like zk-Snarks to enable the validation of transactions. A simpler version of Bulletproofs can be implemented on security token platforms to enable different levels of privacy in crypto-securities.

· zk-SNARKS: Arguably the most adopted privacy protocol in the blockchain space, zk-SNARKS has been implemented on Ethereum on several occasions. Adopting zk-SNARKs might be a low hanging fruit to enable privacy in security token platforms.

Disclosures

· The Problem: Information disclosures is one of the most important missing features of security token technologies. Enabling access to datasets related to crypto-securities is essential to enable liquidity and compliance in the space. If we don’t know anything about an asset, how can we expect to price it correctly?

· IPFS: IPFS is one of the most adopted protocols for content and data storage. Integrating security token disclosures into IPFS is a fairly simple effort.

Sidechains

· The Problem: Security token applications are vulnerable to the limitations of the Ethereum platforms. In my opinion, security tokens are likely to require a new runtime that expands the capabilities of the Ethereum platforms. Sidechains is a middle ground to achieve this goal.

· Loom: Loom Network is a recent project that enables the implementation of DChainApps which are DApps that can execute in their own sidechain while maintaining interoperability with the Ethereum mainnet. I am not certain whether the use of Loom can be generalized for crypto-securities but it can certainly be useful in plenty of scenarios.

Debt

· The Problem: Debt is one of the killer scenarios for security tokens but the protocols today simply don’t support that use case. Incorporating debt protocols into security token platforms can become a extremely useful use case.

· Dharma: Dharma is one of the most robust protocols for decentralized debt scenarios. While Dharma is a very generic protocol, a simpler and more specific version of it can be adapted to security token platforms.

Derivatives

· The Problem: It is almost impossible to develop a new asset class just focusing on long-trades. Implementing mechanisms for shorting, hedging crypto-securities is fundamental to enable sophisticated tokenized security scenarios

· dYdX: dYdX is one of the main protocols in the emerging area of tokenized derivatives. dYdX provides a collection of protocols for enabling key crypto-financial primitives such as margin trading, futures, options, shorting etc. Adapting some of dYdX protocols into security token platforms can enable the implementation of very interesting scenarios.

These are some of the key protocols I believe can expand the capabilities of existing group of security token platforms. There are many other interesting areas that might play a relevant role in the next wave of crypto-securities but, as always, we need to start somewhere.