The Emergence of Enterprise Tokens
Can we have our (Corda) cake and eat it too?
Could the same enterprise-ready focus that lead to the design and capabilities of Corda also extend to the ‘wild west’ of the token world? In others words: we may be on the cusp of the emergence of properly regulated (and useful!) Corda-powered tokens that are fit for the enterprise user.
Two recent announcements have brought this topic to the fore:
- The Global Digital Finance (GDF) industry group publicly launched on June 21, and I have been fortunate to participate in this effort on behalf of R3. GDF is led by the indefatigable trio of Lawrence Wintermeyer, Simon Taylor and Jeff Bandman. For those interested, Simon provides a great, succinct overview of the GDF in this Medium post.
- Earlier last week, CoinDesk published an article highlighting the work of the Cordite open source community, with the appropriately buzzy title of Banks Are Trying to Launch Crypto Assets with R3 Tech, which features quotes from that project’s leader Richard Crook (as well as our CTO, Richard Gendal Brown).
In this post, I introduce the beginnings of a GDF-inspired taxonomy for tokens, provide some current token examples within the Corda ecosystem, and pose a few questions (to be explored in more detail in future posts) on the definition and evolution of what CoinDesk dubbed ‘Enterprise Tokens’.
The emerging taxonomy of tokens
I will admit that my 2014-self wouldn’t even know how to use ‘taxonomy’ in a sentence. But I have come to appreciate the power of giving a ‘thing’ a common definition and a common name, especially in a space that is ever evolving (and ever confusing). GDF has recently posted their Taxonomy for Cryptographic Assets for public consultation, so I thought I would take that taxonomy for a spin and relate it back to some thoughts on what Corda enterprise tokens might look like.
The GDF taxonomy introduces three categories. I have included the definition from the paper below, with a (purposeful) re-ordering:
- Financial Asset Tokens: Tokens whose intrinsic features are designed to serve as or represent financial assets such as financial instruments and “securities”.
- Consumer Tokens: Tokens that are inherently consumptive in nature, because their intrinsic features are designed to serve as, or provide access to, a particular set of goods, services or content.
- Payment Tokens: Tokens whose intrinsic features are designed to serve as a general purpose store of value, medium of exchange, and/or unit of account.
Firstly, the re-ordering: I am attempting to introduce the concept of a continuum for these blockchain-related assets, which is driven by the degree that an ‘off-chain’ relationship or entity is involved in the backing, obligation or trust of the on-chain asset.
Starting from the left-hand side of the diagram, I have included two sub-types of Financial Asset Tokens.
The ‘Depository Receipt’ (1a) can be imagined as an on-chain state that is a digital representation of some type of asset or some form of value held ‘somewhere else’ which most likely would be termed the custodian. The Depository Receipt moves from owner to owner on ledger based upon the appropriate rule set, while the underlying asset remains happily in the same spot at the custodian. As you will read below, this has been the main area of focus for early CorDapp projects.
The ‘Native Asset’ (1b) is a slight move right on the continuum, as it introduces the concept of the asset or value being issued directly onto the blockchain. As a subset of a Financial Asset Token, this can be imagined as a recognizable financial asset like bonds or equity or bank deposits, that has some sort of obligation back to its issuer. The big difference from a Depository Receipt is that the token is not a representation of an asset somewhere else…the token is the asset. A large part of the recent ‘Security Token’ space would fall under this concept.
The Native Asset model holds the most near-term upside and I would suggest will be the main area of focus for CorDapp token projects, and in fact might emerge as the defining use case for Corda. The bulk of the hard work for Corda in 2016–17 (the focus on the legal-world to code-world interlock, robust contract code, a strong identity layer) was undertaken precisely to solve the problem of how to represent real-world agreements on a blockchain in a canonical/enforceable way. And Native Asset Tokens may prove to be the perfect place for the corporate world to embrace enterprise blockchain as a positively disrupting force.
Moving right, we enter the world of mostly ‘crypto assets’, where the off-chain obligations reduce to near-zero. The GDF term ‘Consumer Token’ (2) attempts to rebrand what are broadly thought of as app-tokens, where the token is the mechanism for the ‘app-economy’ participants to consume goods, services or content. Some crypto examples might be projects like FileCoin, Augur…while the ‘old school’ example would be airmiles. We have started to venture into ‘tote bag’ territory as it relates to what level of obligation that the token issuer has to the token holder. Yet there is still some ‘real world’ trust that remains, as the app provider in the end controls the rules of the game and heavily influences what the tokens can actual be used for. Going back to the airmiles example, we all know the dread of Delta or BA unilaterally re-basing or expiring hard-earned frequent flyer miles with little or no notice!
Finally, on the far right are Payment Tokens (3), which attempt to be crypto-asset version of a general purpose store of value or medium of exchange. The GDF includes the prospect of Central Bank Digital Currency (CBDC) in this bucket, but for the above model I would argue that CBDC fits more into the Depository Receipt or Native Asset bucket, depending on the implementation. The mental model for Payment Tokens is quite easy: think Bitcoin.
The evolution of tokens on Corda…hidden in plain sight?
It might be surprising to learn that Corda-based token examples began back in 2016. What isn’t surprising: that this work is emerging from the models of Financial Asset Tokens described above.
R3 began a collaboration with Bank of Canada, Payments Canada and others back in 2016 under the name Project Jasper. As can be seen from the pic to the left, the first Jasper model leveraged the Depository Receipt, where a token called CAD-COIN represented collateral held by the central bank (in this case, represented by Bank of Canada).
This interplay of a regulated custodian linked with an on-chain digital representation, while seemingly simple, unlocks new ways for markets and marketplaces to transact and expand. It also offers a way for enterprises to begin to iterate and implement enterprise-friendly digital assets, as the Depository Receipt model builds out from an accepted regulatory base, as the assets are held at a recognized and regulated custodian. Since the CAD-COIN example in 2016, we have seen pilot and production examples from our partners, in particular from HQLAx in securities lending and Tradewind Markets in gold. Corda is open for business today for any project or app looking to leverage the Depository Receipt approach, as the operating/regulatory models have existing proof points, and the smart contract modeling within Corda is extremely straightforward (check back with https://corda.net/samples/ as the community releases code samples).
Use of Native Asset Tokens is still early, as certain implementation and regulatory questions need to be answered. But interest in this space is only increasing, as Native Asset Tokens can be a synonym for the current belle-of-the-crypto-ball: Security Tokens. Depending on what you read, Security Tokens will either change the very world we live in or become another example of financial engineering solving a problem that no one has. After some initial skepticism, I have fallen more on the bullish side than not, but even the skeptics need to pay heed to the investment being made in this space.
Recently we have seen examples of how the legal, regulatory and technology aspects can come together for Native Asset Tokens. Nivaura and Allen & Overy have released a series of papers describing their Ethereum-based structured products. And late last year, Commerzbank, kFW and MEAG conducted a regulated end to end Euro Commercial Paper issuance and settlement on Corda, where “the security was sold to MEAG, and settled without a paying agent or a clearing system.”
What comes next?
As laid out above, there was a purposeful initial focus for Corda use cases on Depository Receipts and Native Asset Tokens, as both the business process and regulatory backdrop was by far the clearest for enterprise use cases. We’re now seeing some ‘green shoots’ for the regulatory outlook for consumer/payment tokens, and with the strong Corda foundation in place (identity, finality, legal interlock), our community is starting to explore these use cases more.
Coming back to the Cordite project, Richard Crook shared a short post on the concept of a decentralized autonomous organization (DAO) based on an existing legal framework. I am sure that most banker-types would run screaming for the hills whenever something like ‘DAO’ is uttered, but Richard makes a compelling case that this is could be designed as a technological implementation of an existing, well known structure: what he calls the ‘Digital Mutual Society’.
Our friends at Tieto, Nordea and OP Financial recently demoed their take on a Finnish ‘Digital LLC’, which was founded and created on Corda and included verifiable identities of the Digital LLC officers via the Hyperledger Indy identity blockchain. If you squint, you can start to see the emergence of regulatory-friendly, digitally-native, distributed companies using Corda to manage some (all?) aspects of legal formation, capital formation and governance…or said di
fferently, a certain 3-letter acronym that enterprises (and regulators!) might embrace.
How will ‘Enterprise Tokens’ be defined?
The attributes of an enterprise token are beginning to take shape. The token needs to be novel but of course useful (the introduction of a token cannot increase friction!). The legal and regulatory construct has to be from a solid foundation, with a clear integration and interplay with existing laws and structures (such as the role of a custodian, settlement finality, adhering to securities law). Yet I would suggest that more projects need to be done, and openly debated/discussed, to help flesh out the full picture.
I’m excited to see where the Corda community could take this work. Roger Willis recently began a thread in the Corda Dev mailing list titled Request for comment: Corda financial type hierarchy that proposes a more in depth taxonomy for interested developers:
Thanks to the following folks for their input for / review of this post: Richard Gendal Brown, Isabelle Corbett, Jesse Edwards, Chris McCann, David Nicol, Kevin Rutter, Roger Willis.