Pragmatic Programmability in Security Tokens

At a recent interview at a crypto conference someone asked what was the one feature I was most excited about security tokens. Hoping for a classic answer related to regulation or the potential of unlocking trillions of dollars in value, the interviewer was surprised when I answered using a single word: programmability. I am a firm believer that programmability holds the key to the future of security tokens and is the one future that truly differentiates crypto-securities from previous movements in the financial industry. However, enabling programmability in crypto-securities is far from a trivial endeavor. In the past, I’ve written about some general-purpose ideas to achieve this. Today, I would like to go a level deeper and discuss some tangible steps that I believe could improve programmability in the current wave of security token platforms.

The Theory of Marginal Improvements in Technology Movements

The team at venture capital powerhouse Andreessen-Horowitz share a theory about the evolution of technology markets that I think applies beautifully to security tokens. In their opinion, the first stage of a breakthrough technology trend tends to be worse in almost every aspect compared to the previous tech trend except in a handful of features. Those minor improvements are the ones used as the foundation to unlock the value of the space. I like to call this the theory of marginal improvements.

To illustrate this theory of marginal improvements, let’s use the example of the evolution of mobile apps. In the early days of the smartphone era, you could make the case that smartphones were worse than PCs in almost every aspect [battery life, screen size, apps] but they improved PCs in two tiny areas: camera and GPS. Those two features unlocked the mobile app economy and created levels of adoption that surpass PCs by several orders of magnitude. In the case of the big data movement, emerging technologies like Hadoop were considered worse than relational databases in almost every aspect but one: they were able to perform scalable computations on large unstructured datasets. That single feature catapulted the entire space to relevance.

Extrapolating theory of marginal improvements to security tokens, we can make the case that crypto-securities are worse than traditional securities in many elements such as disclosures, liquidity, market making, secondary trading and many others. However, security tokens do provide one marginal improvement over traditional vehicles: programmability.

Smart, programmable interfaces represent the true north of security tokens. Programmability is the feature that will enable the implementation of new forms of securities that were unconceivable before. From that perspective, the platforms that invests the most in programmable interfaces are likely to achieve relevance in the market. However, enabling effective programmability in security token can result in a very complicated effort. Until now, the security token space hasn’t been exactly attractive to developer communities so enabling programmable interfaces might sound like a solution looking for a problem. In the context of security token platforms, programmability needs to start at a very basic level.

Baby Steps Towards Programmability in Security Tokens

The idea of programmability in crypto-securities can take us down the rabbit hole of creating exoteric protocols that nobody uses. Alternatively, I would like to frame this problem in the context of a simple question: “What would developers to today with security tokens?”. In my opinion, that question needs to be answered across three main dimensions that form the main stages of the lifecycle of security tokens:

· Issuance: How can developers author security token contracts?

· Post-Issuance Off-Chain: How can developers interact with issued security tokens?

· Post-Issuance On-Chain: How can other blockchain protocols leverage security tokens?

Issuance Phase: A DSL for Security Tokens

Programmability during the issuance phase of security tokens should be fundamentally focused on streamlining the authoring of the crypto-securities smart contracts. At the moment, that process requires writing on-chain smart contracts in languages like Solidity that require very specialized skills. In a previous article, I presented the idea of a higher-level, domain specific language(DSL) that can abstract some of the fundamental building blocks of a security token smart contracts. The DSL model will allow non-Solidity experts to model security token contracts while still maintaining sophisticated levels of programmability.

From all the options to improve programmability during the issuance phase of security tokens, the DSL models seems to be one of the most pragmatic ones. In the nascent state of the market, security token protocols still represent a high barrier of entry, both culturally and technological, for most developers. Removing some of that friction seems to be the most practical step to improve programmability in the issuance of crypto-securities.

Post-Issuance Off-Chain Phase: JavaScript Interfaces and APIs

Another aspect of programmability is the interaction with security tokens after issuance from third party off-chain applications. The number one use case during this phase is to access data or to trigger actions in security token smart contracts. Enabling simple JavaScript interfaces or APIs to interact with security tokens seems like the most trivial way to foment programmability during this stage.

The good news is that we already have plenty of solid programming models and protocols that can be leveraged to enable interactions between security tokens and off-chain applications. frameworks such as Web3JS or EthereumJS provide robust interfaces for interacting with Ethereum smart contracts from JavaScript applications. Similarly, new protocols like TheGraph could be used to access data generated by security token smart contracts using GraphQL interfaces.

Post-Issuance On-Chain Phase: Integration with Developer-Friendly Protocols

The easiest way to improve programmability in security tokens is to tied into developer-friendly and popular blockchain protocols. The integration with popular Ethereum protocols can expose hundreds of thousands of developers to the new world of security tokens. Among the ocean of protocols in the Ethereum network, there are three main categories that I think can be strategic to improve programmability in security tokens in the short term:

· Stablecoins: Integration with Stablecoin protocols such as MakerDAO could provide programmable models to unlock the potential of dividend payments in security tokens.

· Decentralized Exchanges: There is a lot of developer activity taking place around decentralized exchange protocols. Integrating security token compliance models with popular protocols such as 0x, Kyber Network or AirSwap can open the door to new exchange models in crypto-securities that challenge the traditional approaches.

· Derivatives & Token Baskets: The idea of composing security tokens into other forms of crypto-securities is an interesting form of programmability. Protocols like SET are gaining a lot of traction within the developer community. While the entire derivative space holds a lot of promises for security tokens, composable token baskets seems like the lowest hanging fruit in this area. Integrating security tokens with protocols like SET can enable the creation of new forms of crypto-securities that combine underlying pools of security tokens and balance aspects like risks, dividends, etc seems like a great mechanism to streamline programmability in the space.

Those are some of the initial capabilities that can enable programmability for security tokes in the near future. The subject of programmability in crypto-securities is both broad and complex so focusing on key areas that can deliver immediate value for developers is essential to start the journey towards programmable securities.