This is the second and last part of an article that demystifies the idea of self-service security token issuance platform. In the first part, we explored some of the challenges of self-service security token issuances. Today, I would like to discuss a potential solution that balances technical viability without incurring in any of the fundamental limitations of the current set of self-service security token issuance tools.
The idea of building tools that simplify the issuance of security tokens seems incredibly compelling particularly considering the complexities of the current issuance models. However, complexities should be expected in early stage technology markets and trying to abstract them too quickly results in the creation of tools that are not correlated with real world scenarios or, how less polite people call them, useless. I feel that’s the case with the current wave of self-service security token issuance tools. In the first part of this article, I highlighted three main factors that conspire against the current approach to self-service token issuances:
The entire analysis of the first article can be summarized to the simple idea that self-service token issuance are not only unpractical but impossible with today’s technology. I am pretty certain that is impossible to abstract complex financial instruments in a few clicks with a UI but, even if that was possible, we just don’t have the security token infrastructure to create any relevant abstractions.
Leaky Security Token Abstractions
Thinking about self-service security token issuance tools reminded me of a very popular concept in modern software development: leaky abstractions. Initially coined by Joel Spolsky in a 2002 blog post titled “The Law of Leaky Abstractions”, the concept expresses the idea that effective abstractions should “leak” details of the layer below it. The “leaks” allow the abstraction to adapt to scenarios that require to deep dive into the actual implementation. The fundamental premise of the leaky abstraction thesis is that most abstractions are hardly sufficient when comes to sophisticated concepts.
In the case of security tokens, the idea of leaky abstractions is incredibly relevant. Imagine a higher level construct that enables the abstraction of security token smart contracts while still “leaking” enough details about the underlying protocol that can be modified by developers. Now we just need to figure out the correct abstraction 😉
A Solution for Semi-Self-Service Security Token Issuances
Solving the challenges of self-service issuance in security token goes beyond finding the right abstraction construct. In my opinion, enabling simpler, semi-self service models for security token issuances can be based on two main elements:
a) Creating a set of crypto-financial protocols that abstract the fundamental dynamics of security tokens.
b) Creating a domain specific language that can declaratively model a security token based on the underlying protocols.
Putting these two concepts together we get something like the following figure:
Crypto-Financial Primitives
Security tokens are, ultimately, programmable representations of financial dynamics based on cash flow and voting rights. Some of those dynamics are concepts like equity, debt, convertible bonds, derivatives and numerous other variations. Implementing protocols that abstract those financial primitives in the form of composable smart contracts is the first step towards achieving any level of abstraction self-service or not.
A DSL for Security Tokens
The fundamental challenge of security token issuance is that is time intensive to build smart contracts over and over again with very basic levels of reusability. While thinking trying to simplify security tokens to a few if-then-else rules seems like extreme, there might be intermediate abstraction models that can be viable in the near future. From all the ideas to abstract the structure of security tokens, I am particularly intrigued by the concept of creating a higher level domain-specific language(DSL). Conceptually, a DSL is a computer language specialized to a particular application domain. This is in contrast to a general-purpose language (GPL), which is broadly applicable across domains. The concept of DSLs have existed forever in computer science but it was just recently that achieved certain popularity particularly driven by the evangelism of software development legends like Martin Fowler.
Applying the ideas of DSLs to security tokens, we can envision a declarative (maybe JSON based ) language that represents the contract behind a security token. The DSL will reference of the underlying smart contract protocols using a leaky abstraction model.
The idea of a DSL for security tokens has many tangible benefits beyond the abstraction of the token contract. By abstracting the representation of a crypto-security using a higher level language, security tokens can enable some interesting capabilities using this model:
· Rapid Authoring: While a DSL for security tokens is not necessarily a self-service mechanism it might be even more effective streamlining the authoring and versioning of crypto-security smart contracts. A mechanism that relies on well-known declarative structures like JSON with references to the underlying smart contracts seems like an great combination for this approach.
· Metadata Management: Today, it is pretty difficult to attach any metadata related to a specific security token. However, having a declarative structure based on a DSL provides a seamless vehicle for including metadata elements that can be used to better understand the underlying smart contract.
· Search: Complementing the previous point, a declarative DSL structure will facilitate the search and discovery of security token smart contracts using mainstream search technologies. As the number of security tokens increases, search and discovery will become more relevant capabilities of the ecosystem. Technologies like TheGraph are laying out the ground work for this approach.
· On-Chain Off-Chain Programming Model: Security token smart contracts often involve a combination of on-chain dynamics and off-chain data or actions. The latter mechanic if typically enable via components like Oracles which always feels like operating two different programming models. A DSL for security tokens can provide a consistent programming model that abstract both on-chain and off-chain dynamics.
· Other Benefits: Versioning, portability, documentation are some of the other side benefits of a DSL model for security tokens.
The idea of self-service security token issuance tools is unrealistic in the current state of the market. However, the principle of writing smart contracts for everything seems also hard to scale. The path towards a semi-self-service token issuance model requires, first, enabling a core set financial protocols that provide the main mechanics of crypto-securities. Once those core protocols are established, the idea of using a higher-level domain specific language seems like a viable path. Only when those two foundational building blocks are established, the concept of self-service security token issuance tools might have some relevance and, even then, I believe the scope would be quite limited.