What Use Cases Best Fit on Corda?

What Use Cases Best Fit on Corda?

I remember when corda was an experiment and we didn’t even know if the ideas would work. In the R3 Lab and Research Center, we acted as a global incubator for our member banks and institutions sharing IP and completing joint experiments on broader DLT platforms. Most of these project efforts started on Ethereum, but we quickly found large enterprise integration gaps with the available tools and usability of new languages at our member banks.

We also found that most innovation groups at banks did not have incentives to build production-level applications — they wanted a blockchain portfolio while pushing the harder development work to larger systems integrators or convincing product lines for front office funding.

This blogpost and subsequent others from me will focus on solution designs. This is my interpretation of the initial design use case with the corda story.

Project Excalibur: The Original Proof Point

Corda was first built to record, manage and automate financial agreements. We used cash, corporate bonds and credit default swaps to guide the design. But the first practical implementation was a different instrument: the Interest Rate Swap (IRS). Corda’s suitability for this use-case was one of the data points that convinced us we had the right design.

This project was also known as “Smart Contract Templates” and has a great video presentation from Dr. Lee Braine from Barclays. We built it on the requirements of tracing the legal agreement and seeing the full chain of provenance between the parties involved with the IRS contract. The ability to do real-time negotiation and privately share instructions between platforms shaped a lot of the early use case experimentation.

As seen above, these transactions show that corda is providing an atomic transaction solution to the standard two-phase commit model. By using the point-to-point consensus mechanism, called the Flow framework, corda nodes can sign transactions and agree on changes before they are committed to their respective databases. Via the flow framework, CorDapp developers can customize the negotiations of signatures of transactions for different use cases.

The business benefit is a transparent chain of provenance for a legal document’s full life cycle from partial settlement to full maturity. The smart contract template portion of the use case showed the ability to create the parameters of the ISDA contract and reflect it on a DLT. The nested/combined transactions allow for any coordinated state machine update patterns between parties.

Following the completion of Smart Contract Templates, R3 and multiple institutions conducted a series of smart contract summits, which laid the foundation of many existing legal contract organizations.

Project Vega: Shared SIMM Calculations

Unlike Ethereum, corda’s architecture uses the traditional UTXO model “smart contract” design and not an execution of instructions. The smart contract code is written in the form of verify() checks to ensure an accurate evolution of the input to output states. To cover additional use cases, many members of R3 explored instruction-based processing patterns.

The specific use case to the “Standard Initial Margin Model” (SIMM) project was driven by regulatory Initial Margin calculation rules for Credit Support Annex (CSA). The usage of the oracle design pattern allows for two party’s common trade portfolios to get submitted to a common library calculation (in this case we used Open Gamma’s deterministic java library). As a result, the oracle corda node was able to receive multiple trade states, calculate the corresponding portfolio valuations, and republish them to the same parties associated with the trades without reconciliation.

This oracle design pattern has been often used for any deterministic calculations, but can also be used for reviewing market data confirmations.

It’s All Open Source!

The full code in the original smart contract templates and SIMM oracle was included in the samples repository open sourced in November 2016. It is still available and has been updated f
or the latest V3.1 releases.

While corda has significantly evolved since 2016, many of the design patterns still relate to the asset and cash interactions within atomic transactions. Assets are not exclusive to financial products, but have covered insurance and global trade finance in the business-to-business (b2b) space.

When running workshops with different institutions of the r3 ecosystem, I’ve often suggested starting from clearly understanding the parties sharing, receiving, and sending data related to the legal document’s life cycle. These privacy needs often shape the ultimate design of the CorDapp. From there, we dive into the edge cases and consider how we can change some of the deployment mechanisms to improve operational efficiency and start sharing infrastructure services costs.

Subsequent blogposts will focus on design patterns extrapolated from breaking down the functionality provided by different samples and going through the different types of design packages that generically apply to each industry.

—

Clemens Wan is a solution architect at r3 since February 2016. He’s been a platform lead for 10+ blockchain projects and built 40+ corda design docs to create a reusable design pattern library and tech sales corda curriculum.