Five Simple Features that can Improve the Current Generation of Security Token Platforms

In my Security Token 2.0 Thesis article, I presented a series of ideas for the next wave of security token platforms. Some of those ideas covered highly sophisticated topics such as governance or pricing models that I think are vital for the mainstream adoption of security tokens. However, the transition to Security Token 2.0 architectures is going to take some time. Lately, I’ve been spending some time diving deeper into some of the most popular platforms in the security token space and correlating their capabilities with some of the tokenization scenarios I am being presented with. As a result, I’ve put together a list of basic capabilities I believe can really improve the current generation of security token platforms helping issuers, investors and developers together. In my opinion, these capabilities are natural extensions to the existing security token platforms that don’t require drastic changes in the current architectures. Here are five of my favorite capabilities. As always feedback is welcomed as long as its rational and doesn’t entail hate email 😉

1-JavaScript Interfaces

The programming models for most security token platforms is pretty rudimentary compared to some of the more mainstream blockchain protocols. As a result, we are still not seeing blockchain developers super excited about the security token space and no relevant third parties are building DApps on the current group of security token platforms. Obviously, this is also a reflection of the youth of the security token space.

One feature that I think can help a lot in this area is providing JavaScript/NodeJS interfaces that interact with security token protocols such as Polymath, TrustToken or Securitize’s DS. Think about having Polymath.js or DSProtocol.js as an interface that allows you to start the issuance of a security token, submit the appropriate documents, specified the initial regulations that need to be followed or simply querying the status of the issuance process.

The idea of providing JavaScript/NodeJS bridges has recently become popular among many popular blockchain protocols as a way to improve the developer footprint and enable the creation of third party tools and applications. Projects such as {SetProtocol} or Origin Protocol or even Stellar have done a great job in this area.

2-A Smart Contract Catalog

As security token platform evolves, it’s almost certain that they will create different smart contracts that abstract many of the regulatory or integration components of crypto-securities. There are several classes of smart contracts such as compliance, integration with exchanges or integration with investor pools that are already relevant in security token issuances.

Discovering the smart contracts that available for a specific platform, their expected functionalities, SLAs and responsible parties is a simple feature that can really improve the usability of security token platform. We can envision this feature as a simple smart contract catalog ( a la App Store) in which developer can browse and discover the different smart contracts available for a specific security token issuance.

3-A Real Security Token Standard

The security token space is evolving fast enough that the need for standards is going from being a fancy requirement to a very relevant element of this nascent industry. Companies like Polymath have taken the charge producing the first iterations of security token standards but they can certainly use some help. The current wave of security token standards are hardly sufficient to model the behavior of the different types of crypto-securities in the real world.

In my opinion, security tokens require different levels of standards and not a single one. Just like we have different types of securities such as stocks, bonds, commodities, fiat and derivatives, we can probably use a hierarchical set of standard protocols that reflect the behavior of security token. A basic security token standard can abstract the regulatory aspects such as KYC/AML or trench management. A debt token standard based on the general security token standard can add new capabilities such as dividend payments or arbitration. A real estate debt token can extend the debt token standard with features specific to the real estate industry. Following that thinking, here is a basic hierarchy of security token standards that I think can guide the standard creation process.

4-Disclosures Marketplace & Analytics

Professor Stephen McKeon often uses the term disclosure marketplace to refer to a model in which authorized third parties can report information relevant to a security token. From audit reports on the valuation of a real estate lease to financial information about a private company, disclosures are a key element to evaluate the performance of a security token. The lack of solid disclosure mechanisms is one of the elements preventing large institutional investors from fully participate in the security token space.

Complementing the disclosure marketplace, I believe security token platforms can benefit from better levels of analytics in areas such as macro-economic indicators, token performance metrics, etc.

5-Programming Models and Developer Experience

The current programming experience of most security token protocols is relatively complex even by blockchain standards and very limited from a functional standpoint. I believe that’s one of the aspects preventing blockchain developers from jumping into the security token space. Companies like Securitize have started addressing this challenge with the release of their Developer Platform but more work is required in this area.

We already explored the concept of a JavaScript interface as a mechanism to improve the developer experience of the current generation of security token platform but there are several other ideas that can be helpful in that regard. Here are some that come to mind

· Containerizing developer instances so that they can be easily provisioned.

· Enabling instances of the security token platforms on cloud blockchain infrastructures such as AWS or Azure.

· Providing a clear mechanism for developer contributions to make it into the main platform.

· Providing test frameworks to validate the current functioning of security tokens.

Other Features

I selected five capabilities that seem to have the right balance between being relatively easy to deliver( easy is not easy by blockchain standards 😉) and filling an important gap in the current group of security token platforms. Other aspects such as better tooling, identity-governance models, oracle enablement as well as the interoperability with foundational protocols such as Civic(identity), {SET}(derivatives) or 0x(decentralized exchanges) are also relevant. Security token platforms like Securitize, TrustToken and Polymath have been able to come a long way in a short period of time so, hopefully, we will see some of these features in the near future.