Given a choice, most developers would prefer to use tools that allow them to complete a given task as quickly and easily as possible.
With particular respect to DLT, as Ben and Edward noted in their blog post A new language for a new paradigm: smart contracts, “most smart contract programmers prefer to focus on business logic, rather than low-level details such as hashing, cryptography and consensus protocols.”
If you’ve been following this series closely (start here if you want to review the series from the beginning), you now have a grounding in Daml concepts and some understanding of the power that the language provides for building DLT-based smart contracts. We hope you agree that Daml is uniquely positioned to meet the needs of developers looking to model complex multi-party business processes for distributed ledgers.
But we haven’t shown any Daml code yet. Since we just launched our private beta in April, if you’re not part of the developer program it’s hard to appreciate the elegance of the language without hands-on access to the Daml SDK. However, in this blog post we’d like to offer up a small bit of code that is both very self-evident and illustrative of how easy it is to use Daml to tackle some of the toughest problems that you’ll find in multi-party workflows.
We thought it would be instructive to work through an example from finance as most people have personal familiarity with simple financial transactions, and the corresponding use cases tend to present some of the most difficult problems to solve — in part because modern financial markets have been set up to provide as many protections as possible for buyers, sellers, and all interested parties. These protections, when not implemented correctly, can add significant friction to workflows that involve the transfer of value. The automation of these workflows in a DLT system has the potential to minimize this friction by ensuring that all interested parties adhere to the same rules of the market — but only if the language used to model these workflows is up to the task.
We’ve picked one of the most fundamental use cases in finance, the exchange of securities for a cash payment on an agreed-to settlement date — the Delivery vs Payment (DvP) workflow — and will illustrate how Daml simplifies the encoding of DvP contracts.
From the edges, DvP seems simple enough: Alice has cash and wants to use it to buy some shares of BigCorp, Bob has some BigCorp shares that he wants to sell, they agree on a price and make the exchange. What ends up turning DvP into a complex workflow begins with the fact that such transfers carry principal risk — the risk that either the seller of the security receives payment but does not deliver the security, or vice versa. Principal risk is of huge concern in the securities industry, as such risk is not limited to the parties directly involved but can reverberate through the entire system. Indeed, according to the 1992 paper Delivery versus payment in securities settlement systems, “principal risk in securities clearance and settlement systems is generally recognized to be the largest potential source of systemic risk, that is, the risk that the inability of one institution to meet its obligations when due will cause other institutions to fail to meet their obligations when due, ultimately jeopardizing the stability of payment systems and of financial markets.”
In other words, DvP is something that must be done correctly or really bad things can happen to a market.
In the aftermath of the worldwide markets crash of 1987, settlement procedures around DvP were strengthened to control principal risk in a DvP transaction. As just one example of how much effort is put into streamlining DvP, consider the European T2S (TARGET2-Securities) project — a massive, 9-year project to build a single settlement system capable of offering centralized DvP settlement in central bank money across all European securities markets.
When two parties meet in an equities market and look to exchange some units of stock against cash — it doesn’t matter if it’s an organized exchange or an OTC venue — the process that is needed to complete the legal, final arrangements such that the trade is agreed to is surprisingly complex and involves multiple parties in various roles. Each party to the trade could have an executing broker, which might be under the umbrella of a larger organization. There’s a clearinghouse involved, as well as the members that facilitate access to that clearinghouse. There are settlement agents which facilitate the connection of the securities transfers with the cash that needs to change hands. Cash can be held in bank or brokerage accounts, and banks can have accounts with a central bank (CB) to move funds between themselves. There are custodians on behalf of each side of the trade with fiduciary responsibility to control the securities and to preserve the customers’ interests during this process. Finally, custodians have accounts with a central securities depository (CSD) that ultimately holds the securities and facilitates ownership transfers through a book entry rather than the transfer of physical certificates.
It’s not a short list!
Today, every one of those entities uses traditional technology to maintain its own independent record, which it uses to keep track of and ensure the validity of transactions that are being executed and in which they have an interest.
For the purposes of this blog, let’s strip down the players in a DvP to the bare essentials: the buyer Alice, the seller Bob, a CSD that holds the securities accounts and a CB that holds the cash accounts. A DvP between Alice and Bob requires the atomic movement of securities from the seller to the buyer, and cash from the buyer to the seller, through the accounts held at the CSD and CB, as shown in this simple illustration:
What makes this workflow difficult to code in practice is the need for a single transaction to atomically effect updates to the parties’ accounts in both the CSD and the CB systems — that is, to either perform the transfers in both databases or not to perform them at all. Additionally, that transaction should be executed in a privacy-preserving manner such that neither the CSD nor the CB learn about any more details of the transaction than they need to.
Ognjen and Robin have already taken a look at DvP processing from a privacy point of view in their blog entry, Keeping smart contracts private is hard — unless you truly understand them. The following illustration from their blog shows that, in the sale of BigCorp shares from Bob to Alice, the central bank should only have visibility to the exchange of cash; the CSD should only have visibility to the exchange of equities; and neither of them should learn about the details of the DvP contract. Alice and Bob, on the other hand, should see everything:
Because Daml automatically manages the rights and obligations of a contract, and — as just discussed — automatically preserves privacy by ensuring that only the parties affected by the contract have the right to view contract details, turning this DvP into executable code requires only the following six lines of Daml:
Aside from a few type declarations, defining the terms of the DvP contract, who the involved parties are, and which parties control the transaction (around two dozen additional lines, not shown), this is all the code necessary to effect an atomic, privacy-preserving DvP using Daml.
That’s it.
What you see. The first three lines of code retrieve the seller’s equity details from the ledger, check to ensure that the equity and amount are what was agreed-to, and exercise a transfer choice sending the equity from the seller to the buyer. The next three lines do the same for the validation and movement of cash from the buyer to the seller. All six lines reside in the body of the choice to settle the DvP contract and can hence only be executed as a whole or not at all. This is pure business logic completely expressing the exchange of value in the DvP example.
What you don’t see. This example is most powerful when you consider what is happening behind the scenes, things that the developer does not have to worry about or code:
The Daml SDK is an integrated suite of tools specifically designed to provide an unencumbered experience for anyone wishing to develop their own Daml Driven applications for the Digital Asset Platform. Using the SDK, you can:
This concludes our series on Daml. The Daml SDK is currently in the hands of hundreds of developers from our client and partner base, who are helping us perfect both the language and the tooling as they build out enterprise-grade applications for the DA Platform. We plan to make the Daml SDK freely available to all — which means that you, too, will soon be able to take advantage of the power of Daml (if you’d like to request access to the preview program, stop by the Daml website and fill out the form to request access or be notified of the upcoming open beta).
New to this series about Daml? Click here to read from the beginning!
Join the community and download the Daml SDK.
This story was originally published 22 August 2018 on Medium
Darko Pilav, Senior Product Manager, Digital Asset
Darko heads the product organization in Switzerland. Before working in fintech, he co-founded a successful IT consultancy company. Later Darko was part of the engineering team at Elevence, a startup that was acquired by Digital Asset. There he was a member of the team that designed and developed the smart contract language that has evolved into Daml.
Darko holds a master’s degree in Physics from ETH Zurich with specializations in Theoretical Physics’ branch of Computational Astrophysics.
Silvan Villiger, Senior Product Architect, Digital Asset
Silvan leads the product team responsible for the Daml SDK and the Application Development team in EMEA. Prior to joining DA, he was a Director at Credit Suisse where he worked as a Quantitative Strategist for ten years. He led the Analytics Platform team in Zurich and worked with the equity derivatives, share-backed lending, and structured products businesses.
Silvan has a master’s degree in Computational Science and Engineering from ETH Zurich with specializations in fluid dynamics and mathematical finance.