Security tokens offer a blank canvas to reimagine the finance ecosystem with programmability as a first-class citizen. The possibilities are immense but where to start? To build an open, programmable financial system, security tokens will require a new wave of blockchain protocols. However, the security token use cases today are basic enough that don’t need too many protocols beyond a compliance stack. At the same time, its hard to envision sophisticated financial use cases without having the corresponding blockchain protocols. From that perspective, you can say security tokens are experiencing a very aggressive form of the traditional friction between infrastructure and applications in technology markets.
Identifying what blockchain protocols will be relevant to security tokens in the immediate future is, from my perspective, one of the most important challenges faced by the security token market. While the possibilities for new programmable crypto-securities are tremendous so are the risks of building protocols that won’t correlate to any real-world security token scenarios. If you read this blog, probably you’ve come across some of my exoteric ideas for security token protocols that are unlikely to materialize any time soon. I like exploring those ideas because I think help us expand our thinking in a space that I feel is too narrow technologically. However, I would be the first one to advice against embarking on an effort to implement many of those concepts in the current market. In my analysis, there are five key points that might help us decide the viability of a specific security token protocol.
1) Applicable to Real Use Cases: Technological pragmatism is of the essence in order to advance the security token industry. In the current state of the security token market, we should focus on building protocols that are correlated with real-world use cases. To use a controversial example, I believe there are enough demand in the market for debt use cases that merit a debt protocol for security tokens. However, building a protocol for derivatives and margin trading seems premature at this point.
2) Thin Tier2 Protocol: The current dynamics of the security token market favor the creation of tier2 security token protocols that run on an existing blockchain. Enabling increasingly sophisticated crypto-financial scenarios powered by tier2 new security token protocols is arguably more important than solving tier1 protocols such as consensus or governance.
3) Accrue Value Independently: The most difficult criterion to decide the viability of a security token protocol is to decide whether this one can acquire value independently beyond a specific product. For instance, if a compliance smart contract is meant to be used solely as part of a specific issuance platform, then we are talking about a smart-contract feature rather than a protocol.
4) Open Source: I feel that the security token industry is neglecting the value of open source which, paradoxically, has been one of the fundamental ethos of the blockchain movement. An open source distribution model should be a key element of new security token protocols. The main goal of security tokens is to build an open, programmable securities ecosystem. In that objective, open means open source and programmable means developer friendly.
5) Designed for Decentralized Networks Instead of Products: The purpose of blockchain protocols is to coordinate actions in a decentralized network. However, the current generation of security token platforms operate as isolated products with close to zero network effects. In those conditions, the value of security token protocols is large diminished. The balance between building networks or isolated products is not a trivial problem to solve by any stretch of the imagination but is certainly a foundational argument for the security token industry.
A Security Token Protocol Taxonomy
A few months ago, I published an essay titled “The Security Token 2.0 Stack” in which I discussed an ambitious group of capabilities for the next generation of security token platforms. Many of the protocols included in that article won’t match the criteria outlined in the previous section and, consequently, I don’t think that will be very relevant in the near future of security tokens. However, following our five-point criteria as a guideline, we can identify several key areas that are well suited for brand new security token protocols. Here is a possible taxonomy that might serve as a starting point.
Let’s discuss some of the specific protocol in more details.
Compliance has been the key area of focus of the current wave of security token platforms. Protocols such as DS or ST-20 abstract some of the fundamental compliance mechanics of security token transfers. At the moment, those compliance mechanisms are mostly constrained to validations such as know-your-customer, anti-money-laundering or investor accreditation. Expanding the set of compliance checkpoints and opening the protocols in a way that can be seamlessly used by third party applications should be the key objective of security token platforms.
Equity backed security tokens are the predominant form of digital securities in the current market. I believe this area is broad enough that deserve a standalone protocol. Capabilities such as share buybacks, voting rights, share splits and several others should be abstracted at the protocol level.
An emerging use case in security tokens, tokenized debt is big enough that should merit its own protocol. Dividend payments, risk management, rating or default resolution should be key capabilities of this protocol. The combination of equity and debt protocol should cover the vast majority of the security token scenarios in the next phase of the market.
Addressing information asymmetry is another key challenge faced by the security token industry. Providing cryptographically immutable proofs of public material information is essential to assess the fair price of crypto-securities. While there are some ongoing efforts to incorporate disclosures in issuance platforms of exchanges, I believe this capability is better enabled as a standalone protocol.
The digital securities industry requires new levels of privacy. Global, public ledgers are far from ideal to store the details of securities exchanges. Different industries, jurisdictions and financial vehicles are subject to very strict privacy requirements that need to be addressed in this new world. A series of privacy-protocols based on ideas such as zk-SNARKS, zk-STARKS or BulletProofs are likely to be needed to power a new wave of security tokens.
Custody is one of those areas that I find really frustrating in the security token space. On one hand, until we have viable custodian models, its hard to see large institutional investors moving into the space. On the other hand, its frustrating to see an industry trying to address the custody of, essentially, alphanumeric characters with the same methods used to custody precious metals. I believe and hope that we will see the emergence of new custody protocols designed specifically for the security token industry.
There is an increasing number of scenarios in the market focused on security tokens that are collateralized by a dynamic pool of underlying assets. Think about a security token that represents a pool of real estate leases or municipal bonds. This new type of collateralization model is perfect for a new protocol. The good news is that we can borrow a lot of ideas from the stablecoin movement.
Token Holder Management
As security token evolves, the need for new token holder management capabilities such as cap table management, voting, dividend distribution, etc. is becoming increasingly important. I like the idea of addressing many of these capabilities as standalone, decentralized protocols.
These are some of the protocols that I believe will play an important role in the immediate future of security tokens. Many other protocols will become relevant as the industry evolves but we still need more sophisticated applications and use cases. Finding the right balance between new tokens and protocols is a key challenge in the current security token market. However, we should all agree that a new, open, programmable securities industry deserves its own protocols.