Daml simplifies development of DLT-based markets

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.

An example from the financial world

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:

• There is no need to manually check the rights and obligations of involved parties. As Martin and Jost explained in their post, Daml simplifies this task for the developer by automatically ensuring that all contracts and choices are entered into voluntarily. For example, only the owner of a security has the right to transfer it to someone else. The seller voluntarily agreed to the creation of the DvP contract and hence delegated its right to authorize the transfer of securities upon settlement.
• There is no need to explicitly handle the case where the system of a party is not available. As Alex and Ratko described in their post, Daml gives the workflow modeler the tools and flexibility required to clearly express who decides how to proceed, when those rights are delegated to a market operator per an on-ledger master agreement, and who is responsible for validating contract compliance. This helps to improve efficiency and reduce interdependency risk by limiting the number of parties involved in transactions in a way compatible with the business processes being modeled.
• There is no concern about maintaining privacy. As Ognjen and Robin discussed in their post, Daml automatically preserves privacy by ensuring that only the parties affected by the contract can have the right to view contract details. Interested parties will be provided with precisely the level of information to which they are authorized by the contract. In this example the central bank only has visibility to the exchange of cash but not to any other details of the DvP contract.
• There is no need to code ledger commits or to deal with cryptography. As Sören described in his post, Daml automatically maintains a comprehensive evidentiary trail that ensures contract enforceability by preserving incontrovertible evidence of contract authorization by all stakeholders. The process of cryptographically signing a transaction and writing its audit trail to the ledger is abstracted away from the developer.
• There are no ‘open doors’ to hack. As Andreas pointed out in his post, Daml contains a number of safeguards steeped in formal methods theory that help ensure that a contract will perform as expected. The two pairs of checks and transfers in our example Daml code can only be completed atomically; there is no way, for example, for a hacker to break into the process after the equity check and substitute different values, or to stop the process after the transfer of shares but prior to the transfer of cash.

The last word

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:

• Build. The SDK provides a rich experience for building Daml models. It includes the typical productivity features that developers expect, along with Daml-specific behaviors that allow the correctness of models to be verified while they are being built.
• Test. Daml contains language extensions that allow the developer to write test scenarios that can be seamlessly exercised within a fast-loading simulation of the DA Platform, enabling the results of Daml model execution to be rapidly checked during development. The tooling provides a full view of the ledger contents, both active and archived contracts, and the transactions under which these contracts were written to the ledger.
• Demonstrate. It is often necessary to put a user-friendly face on the manipulation of the ledger simulation — for example when conducting demonstrations, briefings with clients or management, or when soliciting real-time functionality feedback from business analysts and subject matter experts. For these purposes, the Daml SDK contains a browser-based front-end that can be connected to the ledger at any time during Daml development to explore the flow and implications of Daml models.

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

About the authors

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.