A Generational Opportunity to Improve the Transfer of Value

A Generational Opportunity to Improve the Transfer of Value

By  Kelly Mathieson, Head of Enterprise Solutions at Digital Asset

10 years removed from the global financial crisis, can DLT deliver meaningful change in financial markets?


Financial markets today—structurally compressed

It goes without saying that the financial services sector broadly defined—banks, infrastructure providers, and other parts of the ecosystem—is a world which has been subjected to extraordinary change, certainly in the aftermath of the global financial crisis but really in the decades before then and since. Some of this change was fueled by the impact of financial regulatory reform, some by the advent of new technology, but the consequence of it all is an industry that has its fair set of challenges.

We’re dealing with an environment where revenues are lower than they’ve been in the past, or as some might say ‘structurally compressed,’ with generally low interest rates, low spreads, and high volatility that can be described as the painful kind that comes in fits and starts—and when it comes, is usually accompanied by a fair amount of illiquidity.

This low revenue environment is unfortunately coupled with a rising cost environment resulting in part from the ever-present need to reinvest in the suite of technologies that are necessary to keep businesses running, but increasingly from the need to comply with ever-changing regulatory requirements—which are very often being imposed on the back of infrastructures that were simply not designed or even contemplated to meet many of those demands, especially not in light of rising volumes. These factors are causing costs to rise continuously at a painful rate.

And at the same time, capital requirements for those required by statute to carry regulatory capital have been increasing more or less exponentially, so that the risk that you carry on balance sheet—and even those things not considered terribly risky on or off balance sheet—are now attracting far more capital than they ever did before.

Despite these issues there is nonetheless rampant competition, not only within the industry but also from newcomers to the industry who in many cases are not regulated, organized, or structured as conventional banks. The Fintech revolution has brought with it the emergence of many entities who enjoy an unlevel playing field where the unlevelness works in their favor.

So what does all this amount to? It amounts to an environment in which the ability to generate a return on equity that compares favorably with the actual long-term marginal cost of capital is extremely challenged—even for the best of class financial institutions.

That’s a pretty tough environment in which to operate, of course.

Even if you’re doing well running a market infrastructure that’s benefitted to an extent from increased centralization of certain activities—mandates for clearing, the increased value of data, and so on—it’s certainly the case that you have common customers around the world that are not entirely thrilled with the state of affairs, and so there’s a tremendous amount of pressure from this base to try to do things to reduce cost and improve the level of service.

DLT to the rescue?

It’s in this context that the innovation that was originally triggered by the invention of the Bitcoin blockchain and the introduction of cryptocurrencies facilitated by it—nowadays more broadly understood as a collection of distributed ledger technologies known generically as DLT—has entered the scene.

What we have here is the convergence of a coincidence of need on the one hand, and on the other availability of a new technology that has uniquely differentiated characteristics from what’s been there before—and when need meets opportunity in a resource-constrained environment, that’s when things begin to get interesting.

So what exactly is DLT? Simply put, it is nothing more sexy than a radical new form of secure database architecture which—when you put it out that way—sounds spectacularly boring and immediately causes you to wonder “why all the hype?”.

While in the early days there was a lot of hype that preceded real substance, the hype was born by the power of the idea of decentralization and the close affiliation of the space with cryptocurrencies, which were part of the original invention and are themselves going through an extraordinary cycle that’s drawing a lot of interest. There’s no doubt that during the early stages of the development of blockchain, the close connection between cryptocurrencies and blockchain served as a distraction because the noise around the inappropriate—and in many cases illegal—activity that was being undertaken using cryptocurrencies meant that the promise of the technology was much less well advertised and held back as a consequence.

It took a while for that perception to dissipate, but dissipate it has; the ability to distinguish between cryptocurrencies and other uses of blockchain technology has become better understood. In this light, can distributed ledger technology ever live up to the great expectations that have been raised around it? The short answer is yes.

When you first begin to imagine the potential of the technology in highly regulated market environments, it becomes very clear that many of the attributes of the original blockchain conceptualization that facilitated the creation of cryptocurrencies really need to be modified very materially in order for it to become suitable, applicable—or even legal—in the context of regulated financial services.

We’ve now had three or four years of extensive industry-wide research and development which has gone into making enterprise deployments of this technology viable. This work has addressed some of the design differences needed to diverge from the public blockchain concept in order to actually deploy this technology in an enterprise context, particularly around financial services that are regulated and involve the transfer of large amounts of value—where things like transparency (both to regulators and customers), auditability, reversibility, and capacity to process gigantic volumes and throughput rates of transactions are all critical, and where it is vitally important that confidential and sensitive market information be kept private where that is appropriate and necessary.

This work is not complete, but it’s materially advanced, and it is no longer informed to state that smart contracts and distributed ledgers can’t handle the needs of financial enterprises. Fascination with distributed ledger technology is more than a passing trend; it’s evolved from a frequent discussion topic among engineers and enthusiasts into a conversation shared between global financial institutions, central banks, regulators and business leaders around the world.

DLT is not about disintermediation—it’s about adding value

The birth of Bitcoin—which not coincidentally aligned with the global financial crisis—was driven by a desire for the peer-to-peer exchange of value, riding a wave of negative feelings towards financial intermediaries based on a perception that they exist in a way that purely adds friction to the system for the sole purpose of extracting profit for valueless or low-value service. While it is true that some in the financial services ecosystem do just that, many play very highly value-added roles. They form a regulated framework, bring capital to the table to ensure systemic stability, inject liquidity and credit capacity, provide advice, take custodial responsibility for people’s assets (and the legal consequences for mistakes in that area)—the list goes on and on. We need to collectively do a better job of conveying to the outside world the value that financial services drive in our economy.

You could imagine a world where all financial intermediaries are eliminated—and there may be cases where it would be beneficial to the endpoints of the system to have that happen—but the reality is that many who provide infrastructures and services actually would be thrilled and delighted to spend less cost, have less errors, better delight their customers and focus on the value-added aspects of their job. So if we merely enable intermediaries to do a better job, charge their customers less for useless services that they have to do—like reconciling two pieces of information that should be the same but for some inexplicable reason have become different—that’s an amazingly powerful opportunity.

It isn’t going to be the case that DLT puts everybody who’s an intermediary out of business. The technology is going to refine or sieve through the intermediation functions and ensure that the higher value-added ones remain and the others get jettisoned. If you don’t jump on that bandwagon then yes, you will get disintermediated, because someone else will come along and be a better intermediary.

No, DLT is not about disintermediation. The real problem to be solved is that there are significant bodies of transactional load involving multiple parties who have a shared interest in correctly reporting the transactional arrangements between them: there are clearing entities who have legal responsibilities; there are regulators who have reporting requirements; there are many different inputs to the correct processing of the transfer of value.

The obvious DLT value proposition for financial markets

In this context then, what does this new form of secure database architecture allow us to do? Well, simply this—for the first time, it allows independent entities who may be competitors, or even adversaries, that have a common interest in a workflow or process to be able to intentionally share a common record of that workflow or process for the premising of value—not just information, but the transfer of items of value: whether that is securities, derivatives, money, commodities, or anything else. And to do that in a cryptographically secure environment where no one party can unilaterally edit the contents of what is in that database.

Allowing transacting parties to rely on a shared, replicated, secure, independently validatable golden record of all activity enables some very important things.

It allows for the first time mutualization of infrastructure and the opportunity for massive cost savings by essentially being able to eradicate zero-value added work associated with reconciliation—the ticking and tying of different records across different entities which have to coordinate and agree. Materially reducing the need to reconcile all the complexities associated with trading can free up tens of billions of dollars a year in financial services alone. Operating from a common record will also reduce the number of errors that lead directly to reconciliation differences.


The mutualization of infrastructure leads to numerous opportunities for both efficiency and new value-add services.

This in turn has led to a quick realization that there is opportunity to improve efficiency and streamline workflows, to reduce delays, and speed up processes like settlement—which has knock-on implications for reducing capital requirements as assets are able to flow through these workflows at a higher speed and remain on expensive balance sheets for less time.

You don’t have to compromise by blindly trusting your counterparty or a third party to provide you with the truth of that record. You’re able to independently validate it with mathematical certainty. And you’re not required to compromise on the privacy and confidentiality of your proprietary activity. The efficiency gains in financial markets use cases—both the cost and the material risk reduction—can lead to margin and liquidity need reductions.

DLT has been regularly promoted as an enormous cost savings and efficiency tool—targeting not the 5%-10% yearly savings that we all squeeze out through normal efficiencies, but material cuts in the 30-50% territory by truly sharing things that aren’t value-added capabilities. Do this in an environment where revenues are low, costs are high, and capital requirements are high and this is a truly meaningful opportunity!

But that’s just the Version 1.0 story around DLT.

The non-obvious value of DLT for financial markets

This is a time of furiously paced technology-driven innovation, and what you hear about today from some of the world’s most advanced users of this technology goes well beyond the original understanding. We’re now talking about creating the opportunity to develop new services—value-added, revenue-generating services—that aren’t just about agreeing on simple facts.

It certainly wasn’t clear at the beginning of this journey that this would be the case, but it is increasingly evident that a foundation of accurate, synchronized data within financial infrastructures will unleash the sort of web-paced innovation that the advent of the Internet unleashed 20 years ago.

Data powers everything in the connected economy. Increasingly, financial firms are reorienting their strategies around digital transformations that speak to the imperatives of enhanced customer experience, process simplification, cost reduction, AI, machine learning, big data analytics, quantum computing, speed and accuracy—all of which has to have a foundation of accurate underlying data.

If you’re spending 90% of your time disagreeing with each other about the accuracy of the record that you both actually did, that as many as a dozen entities had a stake in depending on your market, how are you ever going to intelligently delight your customers?

DLT isn’t just about cutting costs, it’s about deeply connecting independent entities in a way that preserves privacy while coordinating multi-party workflows across those entities with guaranteed integrity, confidentiality at scale and enhanced quality of data.

The revolution that’s going on here is in many respects similar to the revolution that was triggered by the invention and popularization of the Internet. The only difference is that the internet started off being about the free flow of information, and what we’re talking about here is liberating the transfer of value and associated automated workflow processing around that—saving hundreds of billions of dollars of cost and unleashing unprecedented innovation.

Think about the platform businesses that were born out of the Internet era that have now become the giants—Facebook, Google, Amazon and so on—what they are at their core are technology-enabled platforms whose value derives from the activities that their customers conduct on those platforms. Obviously the things that have come from that have been mind-blowing in the scope and impact they’ve had on our world.

It is extraordinary that we haven’t seen something similar to that in financial services. But make no mistake, this change is coming.

The value of franchises are less described by the value of the transactions they process than by the value of the networks they create and the business they enable their customers to conduct. And who has better networks than financial markets?

The incumbent market infrastructures—exchanges, clearing houses, CSDs, and the like—and their major customers (the custodians, investment banks, broker-dealers) have significant existing connectivity to a very broad network of customers. In fact, they join at the dots in the financial ecosystem, particularly market infrastructure providers who are connected to both the buy side and the sell side, and the custodians, and so on and so forth.

And because they have the advantage of existing customers, trusted relationships—and very often the imprimatur of regulation that allows the rule of law to govern the activities that they oversee—there is actually an inherent advantage if they move sufficiently quickly to evolve and adapt this technology because they’re already positioned with the existing relationships, the existing revenues, the existing knowledge of the existing processes and problems.

Rather than aiming this technology at the far ends of their ecosystem and trying to take them out of the middle, they are front and center at the heart of a real transformation in how value is transferred.

It’s from this that the real excitement arises.

Digital Asset offers several paths forward

Digital Asset was founded in 2014 with a mission to unleash web-paced innovation for processing every asset, transaction, and workflow across companies. We believe that DLT platforms alone do not get you there; synchronized multi-party business process orchestration can only come about if there is a massive increase in developer productivity brought about by abstraction of distributed workflow execution. To this end we have developed a purpose built smart contract language, Daml, that abstracts away underlying complexities and synchronizes data across organizations. Our holistic approach focuses on rapid prototyping, continuous integration, continuous deployment and continuous audit.

This strategy is paying off in financial markets, as evidenced by two recent client announcements. At the end of 2018, the ASX committed to use our technology to develop a clearing and settlement solution (CHESS replacement) for the Australian cash equities market—this new system is on-target to go online in March or April of 2021. Also at the end of 2018, HKEX Chief Executive Charles Li kicked off Hong Kong Fintech Week by announcing a partnership with us to develop a blockchain-powered post-trade allocation platform for their Northbound Stock Connect program.

To illustrate the power of Daml in modeling key financial flows, we have built a set of functionally rich reference applications in Daml and will very shortly begin making these applications generally available at no charge. Use them to learn Daml modeling techniques, to generate ideas for innovative new services, or as the seeds for your own production-level workflows. A few examples of the applications we will be shipping include:

  • Derivatives Lifecycle – modeling of the margin management workflow, including margin call tracking, collateral availability, and the tagging or identification of assets on the DA Platform that facilitate collateral eligibility, allocation and mobility.
  • Swaps – models that provide the workflow foundation for basic swap ‘negotiated’ events (e.g. novations and term changes) and ‘derived’ events (e.g. resets and interest rate payments), as well as a basic UI to trigger negotiated events and highlight upcoming derived events.

And for those of you already on the path of building workflows in Daml, we will be rolling out a set of reusable Daml patterns and libraries for common use cases to help you accelerate your development. For example:

  • A rendering of the ISDA Common Domain Model (ISDA CDM™) in Daml. CDM is a digital blueprint for how derivatives are traded and managed across the trade lifecycle.
  • A Daml rendering of FpML (Financial products Markup Language) for OTC derivatives workflows.

As these applications and libraries roll out, we will use this blog series to provide more information on the individual use cases. Use these applications to kick-start your journey forward to capturing the promises of DLT.

Follow us on Medium or Twitter, or join the community and register to download the Daml SDK Developer Preview at www.daml.com.

About the author

Kelly Mathieson is Head of Enterprise Solutions at Digital Asset, the leading provider of smart contract and distributed ledger technology for business processes across financial services and a broad range of industries. She also serves on Digital Asset’s Executive Management team.

Prior to Digital Asset, Kelly spent 26 years at J.P.Morgan and 3 years at Goldman Sachs working across Corporate & Investment Bank, Asset Management and Treasury & Securities Services businesses. She was most recently Head of J.P.Morgan’s Global Collateral Management and Securities Clearing and played an instrumental role the Federal Reserve Bank of NY Repo Reforms in the wake of the 2008 global financial crisis.

Earlier in her career at J.P. Morgan, Kelly served as Head of Global Custody Product and Head of Online Brokerage Product Asset Management as well as other product management and marketing positions in securities lending, liquidity management, futures and options clearing, FX and commodities managed funds.

Kelly serves on the Greater NYC Board of the Susan J. Komen Foundation. She has been honored to receive several industry acknowledgments, including Global Custodian’s 2018 Person of the Year and American Banker’s Most Powerful Women in Banking to Watch 2011 and 2012.

Release of Daml SDK v0.12.22

Daml Studio

  • Scenario links no longer disappear if the current file does not compile. The location is adjusted but this is done one a best effort basis and can fail if the scenario itself is modified.

Daml Compiler

  • Support reading of Daml-LF 1.5 again.

Ledger API

  • BREAKING: Drop support for legacy identifier. The previously deprecated field name in Identifier message is not supported anymore. Use module_name and entity_name instead.

Ledger API



Release of Daml SDK v0.12.21

Daml Studio

  • Scenario links no longer disappear if the current file does not compile. The location is adjusted but this is done one a best effort basis and can fail if the scenario itself is modified.

Daml Compiler

  • Support reading of Daml-LF 1.5 again.

Ledger API

  • BREAKING: Drop support for legacy identifier. The previously deprecated field name in Identifier message is not supported anymore. Use module_name and entity_name instead.

Ledger API



Release of Daml SDK v0.12.20

Daml Studio

  • Scenario links no longer disappear if the current file does not compile. The location is adjusted but this is done one a best effort basis and can fail if the scenario itself is modified.

Daml Compiler

  • Support reading of Daml-LF 1.5 again.

Ledger API

  • BREAKING: Drop support for legacy identifier. The previously deprecated field name in Identifier message is not supported anymore. Use module_name and entity_name instead.

Ledger API



Release of Daml SDK v0.12.19

Daml Studio

  • Scenario links no longer disappear if the current file does not compile. The location is adjusted but this is done one a best effort basis and can fail if the scenario itself is modified.

Daml Compiler

  • Support reading of Daml-LF 1.5 again.

Ledger API

  • BREAKING: Drop support for legacy identifier. The previously deprecated field name in Identifier message is not supported anymore. Use module_name and entity_name instead.

Ledger API



Release of Daml SDK v0.12.18

Daml Studio

  • Scenario links no longer disappear if the current file does not compile. The location is adjusted but this is done one a best effort basis and can fail if the scenario itself is modified.

Daml Compiler

  • Support reading of Daml-LF 1.5 again.

Ledger API

  • BREAKING: Drop support for legacy identifier. The previously deprecated field name in Identifier message is not supported anymore. Use module_name and entity_name instead.

Ledger API



Get your feet wet with Daml: Web IDE online playground

Curious about the powers of Daml but don’t want to download and install something you aren’t sure of? Intrigued by the simplicity of Daml but having trouble downloading installers in the office? Well now you don’t have to, the Daml Web IDE is online! This is a playground for you to write and compile Daml, create and run interactive tests, called Daml scenarios, all from the comfort of your own browser. 

Read more

Synchronize New York 2019: Digital Asset and DLT in the Real World

Synchronize New York 2019: Digital Asset and DLT in the Real World

On April 17, more than 400 innovators met at Synchronize New York 2019 — the leading conference dedicated to enterprise and institutional applications of Distributed Ledger Technology (DLT), blockchain technology and smart contracts within financial services.  Digital Asset moderated or spoke on panels, hosted a fireside chat, and demonstrated real-world distributed applications that leverage Daml, the open source smart contract language created by Digital Asset.  Our takeaway – industry players are working together to prove that DLT is not just hype, it’s reality.


 VMWare Mike DiPetrillo⁩ kicked off Synchronize 2019 in New York by sharing his views in his opening keynote, “What is blockchain about? It’s all about trust.”


Digital Asset Chief Business Development Officer, Chris Church talks to Katie McDermott of the ASX, Thomas Sullivan of Societe Generale, Lata Varghese of Cognizant, and Gangesh Ganesan, CEO of Peernova about evaluating the best applications of distributed ledger technology and plotting a realistic implementation timeline. Bottomline: DLT is moving to production sooner than you think!


Katie McDermott, General Manager Equity Post-Trade ASX explains the roadmap to replacing the post-trade equity clearing and settlement system for Australia, CHESS, with DLT.


Digital Asset CEO, Yuval Rooz, talks to his former boss and Digital Asset founder, Don Wilson about the future of crypto assets.  “The work that Digital Asset is doing to put Daml on top of not just private blockchains, but potentially public blockchains, is a great example of the direction that companies in this space should be thinking about,” Don Wilson told Yuval.


Digital Asset co-founder and CTO Shaul Kfir joined Duncan Johnston-Watt, CEO of Blockchain Technology Partners and moderator Gabriel Wang of Aite Group for the final panel of the day, which explored the convergence of emerging technologies, including smart contracts, cloud services and machine learning.

“Smart contract design needs to abstract away the complexities of accessing and operating the underlying platform so that developers don’t have to be an expert in blockchain to build applications on top of it.”  – Shaul Kfir


The Digital Asset booth was a popular spot throughout the day. We demonstrated the following Daml-Driven solutions:

  1. Optimis demoed its Structured Rate Security App that allows a security  issuer to lock-in interest rate exposure at issuance, with the option to adjust interest rate exposure throughout the life of the security
  2. solution from  VDC  integrates with Microsoft SharePoint and solves the problem of audit and compliance through Daml’s built in privacy and disclosure mechanisms.
  3. Brillio demoed a  mortgage origination and securitization solution integrate IPFS with Daml (immutable, permanent IPFS links are stored into Daml contracts). Amistamp, an elegant solution by Kinnami showcased an application that delivers IP protection to the enterprise using Daml.
  4. No more costly reconciliations, latencies and process breaks! IntellecEU demonstrated a  solution that serves as a  blueprint for the future of multi-party, cross enterprise workflows enabled by Daml.
  5. The Catalyst solution from IntellectEU solves some of that for DLT by seamlessly translating the messages from your applications (including SWIFT messages) to Daml on the other side.
  6. GFT used a number of Google API and integrated them with Daml smart contracts to create a solution for insurance claims management. A Daml based solution created by Accenture to that allows multiple banks to exchange investor information about  without sacrificing privacy and confidentiality. The solution also achieves compliance with GDPRs Right to Forget and information sharing regulations.

For more details about the partner demos, please see the blog by Manish Gover on LinkedIn: Reaching Escape Velocity for DLT Innovation

Get in touch if you want to learn more about Daml or want to be part of the growing Daml community.

Did you miss Synchronize New York?  Join us at Synchronize Europe in London on June 18, 2019. Synchronize is the leading conference dedicated to enterprise and institutional applications of Distributed Ledger Technology (DLT), blockchain technology and smart contracts within financial services.  Register here!

Daml Driven Development: VDC Consortium

Guest post by Cecil (CJ) John, Chief Executive Architect of VDC Consortium

How do contract professionals assure auditors or litigators that digital records, signatures, and workflows are authentic and immutable? The answer may be blockchain-based records management, which Gartner lists as 1 of 4 key blockchain business initiatives, potentially impacting all record management processes by facilitating savings on costs and providing opportunities to generate revenue by extending capabilities.

To this end, VDC Consortium offers Formal Media™, a blockchain-enabled digital records management system that has been formally accepted into Microsoft’s commercial catalog. In this guest post, Cecil (CJ) John, Chief Executive Architect of VDC Consortium, explains how he integrated the Daml open-source smart contract development language as a critical component in the technology infrastructure of Formal Media™, and outlines a scenario for how multiple parties to a transaction voluntarily enter into a smart contract using Daml.

A peek at the author’s Daml Driven workspace

 Data regulatory compliance

Formal Media™ is the world’s first blockchain enabled Digital Workplace. Probably. It synchronizes the blockchain smart contract with digital records, workflows, and signatures, providing proof of record, process, and identity for multiple parties to a transaction. Formal Media™ has been formally accepted into Microsoft’s commercial catalog.

Figure 1: Integrating records management with blockchain

There’s been a significant growth of global cross-industry regulations over the past ten years. For government or industry regulatory compliance, or e-discovery, organizations may have to prove to auditors or the courts that there has been no malicious or negligent corruption of digital records, workflows, and logs.

Also, this is the era of smart contracts—transactional elements of a legal agreement executing as code on the blockchain. How do we reconcile the smart contract with the corresponding digital contract records? As the industry moves towards the execution of smart contracts, contract professionals (including lawyers and auditors) may need to be able to read and decipher them, if not learn how to write them.

In an earlier piece I did on Medium, I dove into the intersection of contracts and records management more deeply. What I’d like to do in this post is to focus more on one aspect of the technology that we used to provide our solution.

What is Daml—and why did we use it?

We were first attracted to blockchain technology because it provides a trusted, independent, and cost-efficient mechanism for multiparty transactional records management. Blockchain stores a cryptographic hash of the data, workflow processes, and signatures for each record, rendering it effectively immutable and authentic. However, the public permissionless blockchain conducts transactions pseudonymously—identities of parties can be hard to establish.

Regulatory compliance dictates that parties to a transaction are identifiable, and so we needed to work within the context of a permissioned ledger model. We were attracted to Daml, an open-source smart contract language for modeling rights and obligations in multi-party business processes in any business domain, because it is based on a permissioned ledger model that supported the essential elements of a smart contract that were important to us:

  • Proof of rights and obligations
  • Confidential execution
  • Evidentiary trail
  • Formally verifiable

We see this technology as appealing to auditors and litigators, as it effectively certifies proof of record and process. Daml also makes smart contracts development more open and flexible because there could be many potential physical deployment options (see for example the recent announcements regarding VMware and Hyperledger Sawtooth).

Smart contracts developed in Daml provide high integrity and privacy guarantees. Daml contracts encode the rights of parties as choices that they can exercise, and obligations as agreements. For the purposes of this post, let me zero in on one critical characteristic of contracts that really highlights the value of coding in Daml:

“For the consequences of a contract to be compulsory, entrance must be voluntary.”

It’s only when all parties enter into a valid contract voluntarily that they become obligated to perform to the terms of the agreement and can be compelled to do so by judgment in a court of law. Daml natively models the rights of each party to a contract, automatically managing how those rights change as a contract progresses through its workflow.

Daml is also an intuitive smart contract programming language that supports formal methods for catching design time errors and is accessible enough for lawyers and contract professionals to at least understand, if not write. Let’s look at a quick example of this in action.

Figure 2: a simple (and poorly coded) loan example

Figure 2 provides the Daml code for a simple loan application that intuitively makes sense but contains a fatal design-time flaw—it requires both the lender’s presentation of loan terms and the borrower’s acceptance to be simultaneous. Although the code does protect against unilateral actions by one of the parties, this is not the way things happen in real life!

We can easily and quickly test that Daml will protect against unilateral action during Daml development, using the built-in scenario testing language and in-memory ledger simulation provided as part of the Daml SDK.

Figure 3: A scenario for testing the loan application

Figure 3 represents a testing scenario, and we see that Daml has flagged an issue by highlighting the loanworkflow scenario. Hovering over the error gives the developer instant feedback that the smart contract is not valid due to a missing authorization from the lender (‘Bank’), as shown in Figure 4.

Figure 4: Real-time feedback provided during development

The contract works as intended, but there is a better and more realistic way to code contracts between parties.

The propose-accept design pattern

A very common pattern used in Daml to avoid such errors and ensure that all parties to a transaction have entered into it voluntarily is called the propose-accept pattern, and we use this pattern extensively in Formal Media. Figure 5 shows a full example of a simple workflow that uses this pattern to model how digital records and workflows in an enterprise portal synchronize with a Daml smart contract for multiple parties to a transaction.

Figure 5: Example Daml smart contract template leveraging the propose-accept design pattern

The solution involves two templates: the SPContract template, which defines an agreed-to contract signed by both parties (analogous to the Loan contract shown in my previous example). But in this pattern, we must include another contract, SPContractProposal, whereby the offer of a contract must be made and accepted prior to the SPContract being executed. Figure 6 provides a testing scenario to show how it works.

Figure 6: A scenario for testing the contract application

First, in our solution, a few things would happen outside of these contracts. Let’s say that Alice wants to send a contract to Bob for review and approval. Alice uploads a contract record into the records management repository—essentially a document library—and generates a URL (hyperlink) for the document. Alice then uses an API to generate a unique cryptographic hash for the document. We use Sphereon for these blockchain-based records management tasks. With the document thus prepared, Alice is ready to see if Bob wants to enter into an agreement defined by the document.

In our application, Alice would then use a UI to configure a records management workflow for the document, giving its URL and hash as unique references and specifying Bob as the reviewer. The under-the-covers contractual workflow is reflected in the code sample above by the test scenario lines 40-47. When Alice saves the offer in the UI, SPContractProposal is created on the Daml ledger and Bob would receive an email notification with a link to review the contract record, prompting him to accept or reject the contract proposal.

Lines 49-50 emulate Bob accepting the contract proposal (by exercising a Daml Accept choice). Looking at lines 18-23 of the code we see that the Accept triggers the creation of the actual SPContract. The application then redirects Bob to sign the contract record, and under the covers Daml will archive the original SPContractProposal and create the new, fully executed SPContract record on the ledger with the two parties as signatories.

An inspection of the ledger in the Daml SDK shows exactly what we expect: an archived SPContractProposal record and an active SPContract record.

Figure 7: Ledger contents for a properly executed contract

With both parties having entered voluntarily into the agreement, the smart contract is now synchronized with the contract record, united by a unique reference to the hash and the document URL.

In the Loan example, both parties had to immediately enter the loan agreement without any preparation—not a realistic scenario. In the SPContract example, the offer is first made via the SPContractProposal offer—which can be accepted or rejected. The SPContract is only formed when the offer is accepted. This is a more natural flow for contract formation.


The Formal Media™ solution architecture integrates a blockchain-based records management system to deliver a trusted and auditable mechanism for records management, and Daml-Driven smart contracts to deliver a permissioned blockchain infrastructure for progressing agreements against those documents. Documents and contracts are indelibly linked so that knowledge of who authorized what actions on the documents is preserved.

The propose-accept pattern, so critical to ensuring that agreements are entered into voluntarily, is quite easily implemented using Daml!

Join the community and download the Daml SDK at daml.com

About the author

Cecil (CJ) John is an architect, technologist, and innovator and has worked with some of the largest companies in the world including the IMF, US Federal Government and some of the top 5 consulting companies. He is the Chief Executive Architect of VDC Consortium, LLC, a Microsoft Silver Partner, and Goldman Sachs 10KSB alumni member. If you like what you have read, you can follow CJ on Medium for more great content. You can also sign up for his newsletter or contact him by emailLinkedin or Twitter.

Daml choice annotations

Update 2020-01-27

As of SDK version 0.13.47, the behaviour of preconsuming has changed. It is no longer an alias for a standard choice, but has the behaviour of a nonconsuming choice with an archive self as the first sub-action. There is no difference in behaviour, except that the privacy implications are subtly different. Observers see all consequences of a standard choice, whereas they only see the archive subaction of a preconsuming choice.

Introducing pre- and post-consuming choices

Choices in Daml can be ‘consuming’ or ‘non-consuming’ with respect to the contracts on which they are exercised. In short, a consuming choice on a contract leaves the contract inactive, a non-consuming choice does not. By default, a choice is assumed to be consuming. To indicate a non-consuming choice, Daml provides the nonconsuming keyword. Recently, Daml choice annotation syntax has been added to further categorize choices as ‘pre-consuming’ or ‘post-consuming’. This post reviews the consuming concept and explains the meaning of the newly added preconsuming and postconsuming keywords. The example code used here can be found in this Gist.

[Note: The code here uses the new ‘flexible controller’ syntax first introduced in this blog post.]

Consuming choices

Normally, exercising a choice on a contract amounts to actions that terminate the contract or replace the contract with one or more new contracts. For this reason, by default, exercising a choice on a contract is assumed to ‘consume’ the contract. For example, suppose a contract represents some kind of offer to purchase goods or services with provision for the provider to withdraw the offer:

Screen Shot 2019-11-14 at 9.42.58 AM
Daml guarantees that any Offer instance on which a Withdraw choice has been exercised is thereafter ‘inactive’—meaning any attempts to exercise further choices on that instance must fail. Exercising a Withdraw choice is said to ‘archive’ the contract.

Non-consuming choices

It’s sometimes the case though that exercising a choice on a contract instance does not imply the instance should be archived. For such a choice, we can indicate that with a nonconsuming annotation. To illustrate, here’s a simple model of a leasing agreement between a landlord and tenant. The landlord may like to, say, extend to the tenant the opportunity to ‘refer a friend’ in order to obtain a cash-premium—so we write that into the contract like so:

Screen Shot 2019-11-14 at 9.43.45 AM
In this case, no matter how many times a ReferAFriend choice is exercised on a Lease contract instance, that lease contract remains active.

Introducing pre- and post-consuming choices

Suppose we wish to write a clause into our Lease agreement allowing for its termination. Put yourself in the role of the developer contracted by the realtor to model their business process that mandates that, on termination, not only is the agreement archived but also a ReferAFriendOffer is issued. That would lead us to try to write something like the following.

Screen Shot 2019-11-14 at 9.44.10 AMAs indicated by the comment though, what we wrote won’t cut it. The reason is, at the point at which we try to exercise the ReferAFriend choice on the lease contract, the lease has already been archived! The semantics of this auto-archiving are ‘pre-consuming’. The contract on which the choice is being exercised is archived before the choice body is executed—and so the attempt to exercise the ReferAFriend choice on the lease in the Terminate choice body fails because the lease is inactive.

In fact, the newly introduced preconsuming choice annotation is provided for those that wish to be explicit in their definitions. That is,

Screen Shot 2019-11-14 at 9.44.52 AMand,
Screen Shot 2019-11-14 at 9.44.57 AMmean the same thing and, as we have seen, the semantics of this archival scheme hinder our ability to naturally express the business process.

What’s lacking here is a choice archival scheme with slightly different semantics—one that auto-archives its contract but not before the choice body has been executed. This is provided for by the newly added postconsuming annotation. Now we have the tools to express our intent. 

Screen Shot 2019-11-14 at 9.44.10 AMWhat we see here is that the postconsuming annotation, in contrast to a preconsuming annotation, means that the contract remains active for the duration of the choice body and is archived thereafter.

There is one subtlety left to explain regarding privacy rules with respect to post-consuming choices. Like non-consuming choices, contracts created in the choice body are known only to the signatories and controllers of the contracts and not made known to the observers of the contract on which the choice was exercised. That means, in terms of the example, a guarantor will not be privy to the creation of a ReferAFriendOffer raised by exercising Terminate on a lease but, as a stakeholder, will be privy to the archiving of the Lease itself.

A remark for ledger writers

In practice, Daml-LF only has pre-consuming choices. Post-consuming choices are implemented by code generation during the Daml to Daml-LF desugaring process. Don’t worry if this remark doesn’t mean anything to you as a Daml developer—you can safely ignore it!


In this note, we have revisited the notions of ‘consuming’ and ‘non-consuming’ choices. Consuming choices render their contracts inactive; non-consuming choices have no effect on their contracts. Consuming choices can be further nuanced into ‘pre-consuming’ and ‘post-consuming’ choices. Pre-consuming choices archive their contracts before their bodies are executed, and post-consuming choices archive their contracts after their bodies are executed. Annotations preconsumingnonconsuming, and postconsuming can be attached to choice definitions to select between the different possibilities. If you don’t annotate a choice then it defaults to preconsuming.

Join the community and download the Daml SDK at daml.com

About the author

Shayne Fletcher, B.Sc. – Language Engineer – Daml Language Team, Digital Asset

Shayne joined Digital Asset’s language engineering team in 2018 where he works on the Daml compiler. Shayne has 20+ years experience with C++ and OCaml. He has a deep understanding of programming language theory and a wealth of experience in finance and building language based-products. In a previous role with Bloomberg, Shayne led the team that built the BLAN language for modeling exotic derivative securities. @shayne_fletcher