Some Ideas to Unlock Programmability in Security Tokens

Written by jrodthoughts | Published 2019/01/09
Tech Story Tags: blockchain | ethereum | cryptocurrency | security-token | invector-labs

TLDRvia the TL;DR App

Programmability is one of the holy grails of the security token trends. From some perspectives, you can argue that the promise of security tokens won’t materialize without programmable interfaces and strong developer ecosystems that can help us reimagine the world of securities. Despite its potential, programmability remains a highly theoretical idea in the realm of crypto-securities where more platforms have, somewhat logically, prioritized the focus on regulation than on programmable interfaces. Obviously, creating viable programmable models for security tokens is far from trivial particularly considering the immaturity of the ecosystem. Recently, I’ve been thinking about a few strategic paths that can help unlock the value of programmability for crypto-securities in the short term and I’d decide to share some of those ideas here.

Why Programmability Matters?

If you look at the current security token ecosystem, you can’t help but question the relevance of programmability. Is programmability really necessary? Or the regulatory constraints surrounding crypto-securities are such that will prevent the viability of any on-chain programmable models? From the philosophical standpoint, programmability is the only vehicle that will allow us to create new forms of securities. While the immutability and consensus models of blockchains enables the creation of digital wrappers around existing securities, programmability offers a path to completely reimagine the ecosystem with capabilities that are not possible today. The ledger gives us digital wrappers, programmability gives us the future.

The philosophical argument about the value of programmability is pretty obvious but that doesn’t mean that it presents any value in the short term. Should security token platforms care about programmability? In my opinion, there are a few strategic reasons why they absolutely should but they all boil down to a simple crypto-economic principle: expanding the value of the ecosystem from security tokens to security token networks.

Viable programmable models will allow third party DApps to be built on top on security token protocols. That dynamic does not only create stickiness and defensibility for the underlying crypto-security protocol but also expand the value of the ecosystem from isolated tokens to a network of applications. With the right incentive mechanisms built in, security token protocols can accrue value proportionally to the number of tokens and DApps powered by them. Additionally, programmability will enable the creation of developer communities and all sorts of network effects that are hard to envision upfront.

Via Negativa

Another way to assess the value of programmability for the security token ecosystem is by analyzing the opposite phenomenon or what philosophers like call via negativa(by the way of denial). The absence of on-chain programmable models presents some very tangible risks to security tokens that should not be ignored:

· Vulnerability to Incumbents: Without programmability of protocol network effects, I am afraid the entire security token ecosystem is vulnerable to financial of enterprise-software incumbents entering the space. At the moment, the entire security token market can be taken over by a Goldman or a Fidelity entering the space. Programmability is one of the most efficient artifacts for ensure the defensibility of security tokens.

· Fragmentation & Lack of Interoperability: The absence of programmable models will indirectly influence the proliferation of isolated and non-interoperable platforms that will increase the fragmentation of the security token ecosystem. While certain level of fragmentation is good in technology movements, too much fragmentation is conducive to fragility.

· Preventing Derivatives and Programmable Finance Models: If you read this blog, you know I believe derivatives are going to be the ultimate expression of security tokens unlocking the real potential of the space. Well, crypto-derivatives are nothing but programmable smart contracts that rely on underlying assets or protocols. So, without programmability, derivatives won’t happen.

Initial Steps to Enable Programmability in Security Tokens

Even if you are completely sold in the value of programmability for security tokens, you will be discouraged when you are start digging into the specific strategies to make it happen. Unlocking the value of programmability for crypto-securities is far from trivial. At the risk of oversimplifying the problem, I believe there are three fundamental questions that can lead to an initial strategy to enable some levels of programmability in crypto-securities:

a) What areas of security tokens can be programmable?

b) What blockchain protocols with large developer communities can be adapted to security tokens?

c) What distribution mechanisms can be implemented to attract developers into the security token ecosystem?

Examining those questions in details give us three main components of a basic strategy for unlocking some levels of programmability in security tokens.

Programmable Compliance

Compliance and regulation is THE AREA of security tokens that can be enabled by programmable models. Most of the security tokens in the market are based on simple regulatory constructs such as know-your-customer, accreditation or anti-money-laundering. However, there are hundreds of regulations or compliance checkpoints that are relevant to different asset classes, jurisdictions or industries. I think is unrealistic to assume that one or two security token platforms are going to be able to implement the majority of regulatory checkpoints. Building on-chain or hybrid programmable models that allow developer to code compliance logic in the form of smart contracts or oracles is an area that can benefit the entire ecosystem. Programmable regulation has the benefit that are composable, testable and immediately enforceable. I know, I know…regulation purist will tell you that there are many processes that can’t be modeled programmatically but we can start somewhere.

Integration with Thin Protocols

The simplest way to foment programmability in crypto-security applications is to integrate security token protocols with blockchain protocols that enjoy healthy developer communities. Imagine the possibilities: developers can issue debt based on security tokens integrating with Dharma, build new forms of collateralized stablecoins using Maker, run prediction models using Augur, compose token into new securities using SET….hopefully you get the picture. This strategy is not only good for the ecosystem in general but the first security token platforms that achieve this can become extremely defensible. The diagram below shows some of the groups of blockchain protocols that I think can bring value to the security token ecosystem in the short term.

Open Source Distribution

The famous Occam’s Razor philosophical principle tells us that the solution to a complex problem is often the simplest one ;) Embracing open source distribution models is the simplest and maybe the most efficient path towards building programmable models for security tokens. Despite inheriting the open source ethos of the blockchain ecosystem, most security token platforms remain close sourced and with minimum commitment to build their developer networks. Granted, building a solid developer community is no walk in the park but the potential benefits could be tremendous.

From all the capabilities of security tokens, I believe programmability is the one that can help unlock the real potential of the space. Programmability, not immutable ledgers or tokens, is the path to the future of crypto-securities. Solving programmability is maybe the most important, and sadly ignored, challenge in front of the security token community.


Written by jrodthoughts | Chief Scientist, Managing Partner at Invector Labs. CTO at IntoTheBlock. Angel Investor, Writer, Boa
Published by HackerNoon on 2019/01/09