Guest post by Brad Buck, co-founder and VP of Strategy & Development Solutions, OpenCrowd, a custom blockchain and Fintech technology solution firm and Digital Asset Partner.
Asset backed tokens are a great way to provide users with ownership rights in both physical and intangible form. However, we also need solutions that can guarantee the security, fungibility, and availability of the underlying physical asset. Developing such solutions leads to a wider set of architectural and technology integration challenges than just tokenization.
OpenCrowd has developed a Daml implementation based on our ongoing work with Diamond Standard Co. to create fungible asset tokens that are backed by real physical assets (diamonds). Diamond Standard is creating a novel, new commodity asset class that is a store of value, like gold. This has never been done before.
Our solution consists of an underlying master registry of diamond assets and a fungible token (a BitCarbon). The diamond assets are stored offline in secure units called “bars”. The contents of each bar are algorithmically selected to ensure each has the same gemological value of underlying physical diamonds, thus enabling the fungibility of the coins that are issued against these bars.
The implementation includes key operational workflows such as the registration and verification of assets, creation/minting of fungible tokens, and custody management. Minting of fungible tokens is done by approved minters that create new coins. The approval of minters is also developed as a Daml workflow.
Components of the solution
The asset backed tokenization solution has several key components listed here:
| Registry |
The contract that registers diamonds. |
| RegistryInvite |
An invite contract for a Diamond Registrant to register diamond properties. |
| Minters |
Manages Minters and issues out invite to mint diamonds. |
| MintersInvite |
An invite that would mint diamond pucks upon acceptance. |
| Token |
A contract would check if diamond IDs are valid and would generate fungible tokens that are tied to minted diamond pucks. |
| Lien |
Option to create a lien for a minted puck with a lien expiration date. |
| LienProposal |
An invite to enter into a lien agreement with the lien expiration date specified. |
Why did we choose Daml?
As blockchain technology continues to gain traction, companies have quickly realized they will utilize multiple distributed ledgers. Until recently, if a company wanted to have a smart contract run on multiple blockchains, they would write smart contracts for each separate blockchain, in a different language for each blockchain. This is expensive, laborious, and time-consuming for a business. Enterprises using multiple blockchains are better off standardizing on technologies to achieve efficiency, but this has not been possible to date.
With Daml we were now able to create concise and secure smart contracts that can be executed by the privacy aware Daml runtime on different distributed ledgers. Thus, different parts of a solution can potentially be deployed on multiple ledgers and even databases, while still enjoying a common business process integrated through Daml. This capability is enabled by the DA Ledger model that outlines the privacy and integrity properties of Daml. These properties are physically implemented by the individual ledger platforms to varying levels. However, the logical conformance to these properties is still enforced by the Daml runtime that works with each underlying persistent layer at each node.
For this use case, we use the Multiple Party Agreement design pattern. This pattern uses pending contracts as wrapper agreements before the final agreement contract so that any one of the counterparties to the contract can initiate the workflow by creating a pending contract. The final contract agreement is not created on the ledger until all the counterparties involved in the pending contract sign all pending contracts.
A very positive outcome of using Daml was the increase in productivity while developing this solution. Since Daml is designed to focus only on the business functionality while abstracting away the underlying ledger level complexities, it simplified our smart contract and workflow development, allowing developers to focus on implementing the behavior and logic of how asset backed tokens would work.
The effect of this focus becomes apparent when comparing the amount of code needed for a contract: equivalent smart contracts we developed before were 710 lines of code, while the Daml smart contracts are only 200 lines, a very significant difference, further amplified by the clarity of business function, ease of maintenance, and ability to collaborate better with business and operations counterparts.
Creating a blockchain solution that spans physical-virtual worlds presents its own challenges. The Daml stack provided us a simple way to manage that through ledger APIs that can be invoked by designated parties who are stakeholders to the contracts. The contracts themselves can have granular visibility defined thus providing confidentiality at a sub-transaction level. This layered design provided us a lot of flexibility in defining the logical architecture of our solution as IoT messages are received from the storage units, while maintaining various security criteria.
Finally, our Daml solution can also run on a traditional database such as AWS Aurora, in addition to running on DLT platforms. This capability of Daml, and full portability of the code, provides for an excellent development environment, and also a target deployment model for high trust scenarios (e.g. when all parties are within a single enterprise). Over time, this can lead to interoperability between Daml smart contracts across both high-trust and low-trust environments, a huge advantage.
Asset Based Dapp in Action
If you would like to see the demo Dapp in action, here is a link to a full annotated walkthrough video on the OpenCrowd YouTube channel:
The universality of Daml smart contracts has beneficial implications for any use case with multi-step processes involving multiple party interactions. Developers only need to focus on implementing the core logic when building smart contracts, as opposed to creating unique signatures, key structures, and other fundamental blockchain transaction components from scratch.
We hope this blog provided some insights into the future of how physical assets can be tokenized using a mutualized business process across all parties involved. A common business process such as the one we described in this blog is a powerful capability. It is very different from many different applications sharing a conceptual business process but still exchanging, maintaining and reconciling data in their own different silos.
Enterprises should take note of Daml’s many benefits and consider its use for multi-party workflows and permissioned blockchain solutions. Please feel free to get in touch with me if you need assistance with use case analysis, benefits modeling, process design, and implementation.
About the Author
OpenCrowd is a blockchain fintech solutions firm that creates custom solutions for startups and investment banks since 2005. Our blockchain work spans from the ledger layer to the Dapp layer and our expertise in blockchains including Daml, Ethereum, EoS, Hedera HashGraph, R3 Corda, GoChain, and Stellar