Barclays and ISDA DerivHack 2019

Following last year’s success, Digital Asset is partnering with Barclays and ISDA for DerivHack 2019 to provide participants with a ledger-as-a-service to simulate a common repository for CDM-based applications. This year, we invite you to leverage our platform and build atop of it using Daml with the support of Digital Asset subject-matter experts to compete for first place.

In order to empower competing teams with the tools they need to succeed, Digital Asset will be hosting a series of pre-event webinars to give participants insight into the power of Daml, and how it can be used to seamlessly and elegantly solve for each of the DerivHack use cases. Sign up using the links below to join us for three structured webinars that will enable you to become the Daml experts!
Read more

Release of Daml SDK v0.13.27


Daml Assistant

  • daml start now supports --sandbox-option=opt--navigator-option=opt and --json-api-option=opt to pass additional option to sandbox/navigator/json-api. These flags can be specified multiple times.

Daml Compiler

  • Fix a bug where generic templates could crash the compiler.


  • Fix release signing process.

0.13.26 (not published)


  • /contracts/search now supports a query language for filtering the contracts returned by matching fields. See issue 2778.

Daml Compiler

  • Fix a bug where .dar files produced by daml build were missing all .daml files except for the one that source pointed to.
  • Fix a bug where importing the same module from different directories resulted in an error in daml build.
  • damlc migrate now produces a project that can be built with daml build as opposed to having to use the special and build.cmd scripts.

Daml Integration Toolkit

  • 30 more test cases have been added to the transaction service test suite.


  • Starting with this one, releases are now signed on GitHub.

Committed Settlement: Adoption under UK Law, an analysis by Linklaters

Blockchain image 2-1

Digital Asset’s Committed Settlement: Adoption under UK Law, an analysis by Linklaters

By Charlie Yeh, Assistant General Counsel, Digital Asset

In July we wrote a blog about Committed Settlement, a smart contract-based methodology that effortlessly and near instantaneously creates control accounts on a distributed ledger.  Control accounts have been used for decades to hold collateral from a pledgor and protect a secured party against the default or bankruptcy of the pledgor. 


With the right legal framework, Committed Settlement can give you the ability to create, record, notify and/or perfect security interests (depending on the jurisdiction) in a fraction of a millisecond, with minimal cost and just a few lines of Daml code.  With these efficiencies, the way we approach bankruptcy proceedings, collateral and risk management – and potentially all financial transactions in general – could change. 

Working with King & Wood Mallesons, we analyzed whether our Committed Settlement methodology would work under the legal framework in Australia and Hong Kong to validate that this is more than just a smart technical concept, but a method that could actually hold up under local bankruptcy law.

Now, we’ve collaborated with the leading global law firm Linklaters to analyze how the Committed Settlement would work under existing UK law.  Linklaters just published a report that considers the key issues from an English law perspective. 

When developing the technical details of Committed Settlement, our guiding principle is that technology should support the existing legal frameworks governing business transactions and exchanges of value. Technology should not assume or attempt to change statutes and caselaw in order to support the value exchange it enables. It’s with this in mind that Linklaters outlines in a new thought piece the key legal and regulatory considerations relevant to the implementation of our Committed Settlement technology from an English law perspective.


Download the Linklaters report here.

Charlie Yeh is an assistant general counsel at Digital Asset where he helps clients understand how distributed ledger and smart contract technology align with prevailing legal frameworks.  Previously Charlie served as legal counsel to JPMorgan’s prime custody, clearing and collateral management businesses. He helped JPMorgan reduce its trillion dollar intraday exposure to clearing repurchase agreements and establish segregated IM control accounts on behalf of it clients. 

Release of Daml SDK v0.13.25


  • Suppress instance documentation when --data-only mode is requested.


  • Change signature of MUL_NUMERIC and DIV_NUMERIC.

Daml Integration Kit

  • Fix contract key uniqueness check in kvutils.
  • Preload packages in a background thread in kvutils.


  • ActiveContractsService now specifies to always return at least one message with the offset. This removes a special case where clients would need to check if the stream was empty or not.
  • Dramatically increased performance of the ActiveContractService by only loading the contracts that the parties in the transaction filter are allowed to see.

How can we eliminate reconciliation in financial markets?

Guest post by Vidyasankar Ramalingam, Senior Consultant at Atos, a global leader in digital transformation with over 110,000 employees in 73 countries and annual revenue of over € 11 billion.

Reconciliation is a natural process that must be run periodically to ensure that parties to a transaction have the same view of the data. Inherent to this process are the characteristics of cost and latency because processes must be run to process and match large amounts of data, across multiple entities and applications with disparate technology and process infrastructures. In addition, and unfortunately, trade breaks and process errors are still not prevented unless they are performed with the same latency as well.

In this post we will:

  • Show how we can minimize and even eliminate reconciliation using DLT and Daml smart contracts.
  • Dispel a common privacy myth of lack of privacy by showing that Daml & DLT allow for granular, sub-transaction level privacy between organizations and applications.


Current business scenario

Traditionally, any entity – application or organization – has communicated with another entity using an “exchange of data” – either through APIs, or by file transfers. For example, investment and the custodian banks in the settlement value chain maintain their own databases with the transaction details, account level details, customer data and other reference data.

They rely on messaging architectures to carry the data sent from their counterparty, Central Securities Depository and sub custodians to do reconciliation. However, this architecture only serves to update multiple copies of the original data and does not provide any single golden source of truth.

Hence reconciliation must be carried out. The reconciliation can be at a bilateral level or multilaterally based on the number of parties involved in the settlement value chain. This is an error prone process with high effort and cost involved. Also, there is a lack of trust on the data used for reconciliation. Every party maintains its own parallel set of storage and data access infrastructures.

We considered 4 participants in the settlement value chain, Bank A, Bank B, CSD and a Central Bank. Bank A and Bank B does the transaction on behalf of their clients. CSD issues the shares to Bank A and Central Bank issues the money (Central Bank Money) to Bank B. Bank B (Buyer) initiates the DVP proposal transaction to the Bank A (Seller). Once the Seller accepts the DVP proposal, the Seller settles the shares initiating the atomic swap of shares and cash between the Buyer and the Seller.

In the current model, post the settlement of the trades the banks receive MT 535 and MT 536 SWIFT messages to denote the transaction settled and the corresponding change in the account holdings.

The banks would then compare the data from their database against the messages through the reconciliation process. The complexity of the reconciliation is bound to increase when there are more parties involved. Ex: Bank A and Bank B utilize a sub custodian to process their transactions.

Similarly, reconciliation also need to be carried out with respect to the movement of the cash.

The same data has been stored across multiple parties leading to a highly time consuming and expensive reconciliation process.

Our experiment with distributed ledgers to reduce reconciliation

We chose Daml, a smart contract based multi-party workflow language created by Digital Asset to replicate the settlement value chain. 

The goal was twofold:

  1. Can we eliminate the need for reconciliation?
  2. Can we maintain privacy in ensuring that the data isn’t visible to all the participants of the chain – only visible to those who are supposed to see it?

Each participant was modeled as a Daml party, which is a built-in type in Daml. This allows the participants to avoid having to deal with the underlying ledger complexities in their business applications.

Next, we defined Daml smart contracts that represented the business rules and the business workflow that was defined between our participants. These contracts also served to model the underlying workflow. The participants of the distributed ledger each shared the smart contracts – business rules only, no data. And they exercised actions on these smart contracts to progress their workflow. The permissions to exercise actions were defined in the Daml smart contracts and enforced by the Daml runtime.  

The most interesting outcome of this experiment was that each participant saw only the data it was privy to thus guaranteeing the data privacy requirements. The Daml runtime also does not allow the data visible by one participant to be out of sync with the data seen by another participant, even if they “see” different data elements depending on their privacy settings. That’s because the global state is a combination of the data contained at each of these Daml parties, and it can be verified at any time through cryptographic methods. This situation however, never arises because of the way the data is constantly verified and synced between participants. In effect, you can assume that real time reconciliation and synchronization is happening behind the scenes rather than the business applications doing external, post facto reconciliation.

Each participant thus relies on the so called “shared ledger” which still provides full privacy and confidentiality. This creates an authoritative and validated record to eliminate the need for external reconciliation efforts. In addition, one of the big advantages of using this approach is that the participants have access to real time data as it happens – a golden source.

This eliminates the need for sending MT 535 / MT 536 or the equivalent 20022 messages, which can be replaced by the real time updates to the participants. It can also remove the need for trade data enrichment, reconciliations and even the resolution of conflicts or disputes between the counterparties.

Our experiment, and also several visible projects in this space, showed that Distributed Ledger Technology (DLT) using Daml provides a great solution for the reconciliation issues and reduces the operation cost. It also solves the challenge of maintaining the privacy of data by custodians, like the customer information, collateral data and other specific information. The transactions which are just Over the Counter (OTC) agreed between two participants are visible only to the designated participants in the network. That’s because, Daml segregates the data with respect to participants and it is shared only if needs to be on a need to know basis.

Market-wide rules, encoded in Daml, are shared with all market participants, but the actions taken by participants and their data are private. Hence, during a Settlement Transaction for a T2S specific market regulation the data is shared only across the participants who need to know. E.g., movement of shares from Bank A to Bank B is visible to the respective banks and the CSD. Similarly, the movement of cash from Bank A to Bank B is visible to the respective banks and the Central Bank. This ensures that the participant who is not part of a particular transaction, doesn’t have access to view the data.

The CSD has access only to the movement of the Shares across participants and not the Cash legs.


Financial Institutions face challenges in reconciliation due to inadequate information and communication mismatch due to timing with the parties in a settlement value chain. This reconciliation is costly and often causes undesirable latencies in executing business processes.

In fact, business processes are often built around these latencies. Daml, by bringing in the solution to access real time data eliminates reconciliation thereby reducing operational risk, cost, delays and inefficiencies. Daml not only solves the inter-company reconciliation issues, it also solves intra-company reconciliation. In addition, by being portable across ledgers and by exposing a common API, Daml allows for a simpler overall architecture which ensures that business and technology teams can operate as a single unit to bring best in class products to market much quicker.

Download the Daml SDK now!

Release of Daml SDK v0.13.24

Java codegen

  • If the DAR source cannot be read, the application crashes and prints an error report.

Daml Assistant

  • Java and Scala codegen is now integrated with the assistant and distributed with the SDK. It can be run via daml codegen. You can find more information in the `Daml Assistant documentation

Daml Compiler

  • Fix bug with qualified imports of generic templates.


  • Upgraded ledger-api server H2 Database version to 1.4.199 with stability fixes including one to the merge statement.

Daml Integration Kit

  • One more test case added. Transaction service tests are not multi-node aware.
  • Semantic tests now ensure synchronization across participants when running in a multi-node setup.

What Daml app can an intern build in 6 weeks?

This summer, I spent six weeks working at Digital Asset (DA) on the Enterprise Solutions team. As a rising junior computer science student at Duke University, I was excited about the opportunity to not only learn about smart contracts and secure multiparty workflows, but also put my skills to practical use. In the short time I spent at DA this summer, I was able to learn Daml and create a functioning reference application, which would have been very difficult to do had I been using another language.

I brought to this project my personal experience of the friction and frustration in dealing with the healthcare system as both my mother and sister have Type 1 diabetes. Timely access to personal medical data is a huge problem. Each healthcare system has their own siloed data store of electronic medical/health records (EHR’s). Getting information to physicians outside a single health system can be complicated, a process still relying on fax machines in many cases. In cases of emergencies, valuable health information is often inaccessible to emergency physicians.  In my own personal experience, there have been situations where my diabetic family member’s blood sugar has dropped so dramatically that they cannot communicate with anyone and require immediate medical attention. In a specific occurrence, a member of an emergency room team thought it was a good idea to give my mother bread to bring her blood sugar back up. However, this would have been a mistake as she also has Celiac Disease and cannot consume gluten. These vital pieces of information were not accessible to the emergency physicians. But for my family being present to communicate this information, this could have ended in disaster. 

Responding to my own experiences, I ideated, designed, and modeled a way for patients themselves to securely give permission and share their medical information and records with physicians or other service providers using Daml. Coming into the summer, I had very minimal exposure to Daml and functional programming in general. As such, a major component of building the reference application was self-teaching Daml by reading the Daml SDK documentation with a bit of help from the experts at DA. 

It was a very fulfilling, albeit at times challenging experience learning Daml. Even after my initial understanding of the features of Daml, it was a continuous learning experience as I built the application. For example, I learned the theoretical application of contract keysbut it wasn’t until I used them in practice and understood the ability to fetch them “globally” without there needing to be template input fields that I appreciated their usefulness. 

I learned that Daml is simple, yet powerful. Reading the reference applications’ code, I am struck by Daml’s readability, extensibility, and its concision. In a just a few lines of code, I could specify very complex and secure multiparty interactions. In building this reference application, I found that Daml simplified application design, abstracting away complexities that are not core to the business logic. Instead, I could focus on the essential value of the application: the ability for patients to securely share essential medical data with healthcare providers across the continuum of care. 

My reference application addresses the problems of inaccessible health data by empowering the patient to create a secure network of healthcare providers who are granted permission to view consumer healthcare data. The key is the individual patient’s consent to share their discrete health information. The workflow is as follows, including Daml code snippets. 

  • The patient proposes permission decisions to each health care professional (HCP) in the system stating what data they will receive whenever new data is available. This ensures that HCPs will always only receive personal health information (PHI) that the patient allows.

Alternately, HCPs may also counter-propose different permission decisions if they feel it is necessary:

Importantly, note that the application respects the patient as the owner of the data and the sole party who can give permission for its dissemination. The patient can thus revoke an HCP’s access to their data as they see fit. If they would also like for a new HCP to have access to their data based on already-determined permission decisions, they can consequently use their master contract to share the aforementioned data.

These are the vital components of the patient data propagation workflow that instill confidentiality, immutability, and thus reliability. By using Daml, we are able to provide a significantly more efficient and reliable overall experience for all parties involved.

This reference application can serve as an essential foundation for many other patient health data use-cases. First, as wearable health-focused technology becomes ever more mature including for example, Continuous Glucose Monitors (CGMs) or Apple Watches, this application could incorporate automated wearable feeds and distribute that information to the patient-defined network of HCPs. This also has utility in remote monitoring or home care situations. Even further, the long-standing problem of medical interoperability could be addressed through Daml patient permission templates. 

By using Daml vs. other traditional coding languages, I was able to build a reference application in only six weeks. It is pretty amazing being able to learn an entirely new programming language and write real-world, useful applications in a mere matter of weeks. Building the reference application was made much easier due to Daml’s capabilities that are otherwise not available or very difficult to construct in other languages. I definitely see myself continuing to utilize Daml to model other workflows that also pique my interest as the use-cases that fit within the scope of Daml’s capabilities are seemingly endless. I look forward to seeing all that will be created with such a powerful tool.

Install the Daml SDK now and try for yourself.

Jordan Mittleman is a third year computer science student at Duke University

DLint : Expert help writing Daml

For developers of all skill levels, it’s a constant challenge to keep in mind the myriad of ways the code we write could be better. For Daml developers it’s not different. We wish to produce programs that are elegant, efficient, readable by others … the list goes on. With each PR, we look to our code reviewers to advise us on (at least) the most obvious improvements we could make. This is especially true for Daml newcomers.

One of our main goals with Daml is to make developers extremely productive, and to make it easy for them to build high quality and secure code. The faster a developer gets feedback, the more productive they are. Relying on code review has an unfavorable feedback latency and getting full value can be “hit and miss”. Wouldn’t it be ideal if, while programming, you had an expert at your shoulder offering advice?

With the linting features we are integrating into the Daml IDE, the developer gets that advice as they type. DLint analyzes your code while you’re typing it, looking for issues and making suggestions on how you might care to improve it. It’s highly configurable (you can turn warnings off and on with granular scope control). The suggestions are easy for programmers of all levels to understand and where it makes sense, provides suggested code. Taking advantage of it is very easy and its use improves code quality!

The image below shows DLint in action. The IDE is warning that it found a block of duplicated code (suggesting an improved version would “factor out” the common block into a function).

mainHere’s another example of the sort of thing it can do. Given this function,

negateDLint provides the following suggestion:

The suggestion here is that we replace our multi-equation recursive function with a one line version using the idiomatic standard library function foldr.

This is an engineering note, so now let’s get a little into how it’s implemented.

DLint is achieved by the adaption and integration of Neil Mitchell‘s celebrated HLint package. HLint is a venerable program with over 15+ years of active development and HLint’s use by the Haskell community is ubiquitous. The integration is made possible by the fact that we wrote the Daml IDE in Haskell and that the Daml compiler uses the GHC stack “under the hood”.

We do a lot of cool open source work at DA. Part of getting this functionality into the IDE means submitting lots of updates to upstream hlint (to use the ghc-lib-parser package). Also, check out the ghcide project where we’re contributing parts of this technology to the Haskell community! Daml itself is completely open source here.

We are super proud of how the Daml IDE is coming along. Try the new DLint features for yourself! You can download the Daml SDK here and this git repository will give you a quickstart exploring some of DLint’s capabilities.

Release of Daml SDK v0.13.23

Daml Integration Kit

  • The reference implementation can now spin up multiple nodes, either scaling a single participant horizontally or adding new participants. Check the CLI --help option.
  • The test tool now runs the double spend test on a shared contract in a multi-node setup (as well as single-node).
  • The test tool can now run all semantic test in a multi-node setup.

Daml Standard Library

  • BREAKING CHANGE The (/) operator was moved out of the Fractional typeclass into a separate Divisible typeclass, which is now the parent class of Fractional. The Int instance of Fractional is discontinued, but there is an Int instance of Divisible. This change will break projects that rely on the Fractional Int instance. To fix that, change the code to rely on Divisible Int instead. This change will also break projects where a Fractional instance is defined. To fix that, add a Divisible instance and move the definition of (/) there.

Daml Assistant

  • The HTTP JSON API is now integrated with the assistant and distributed with the SDK. It can either be launched via daml json-api or via daml start. You can find more information in the README.
  • The daml.yaml file now supports an additional field build-options, which you can use to list cli options you want added to invocations of daml build and daml ide.


  • BREAKING CHANGE The /contracts/search request payload must use "%templates" in place of "templateIds" to select which templates’ contracts are returned. See issue #2777.

Daml Compiler

Quantum Daml: Amazon QLDB goes GA

Today, Amazon announced the General Availability of QLDB, or Quantum Ledger Database. We are excited to share that we are working with Amazon to add QLDB to the list of platforms supporting Daml smart contracts as a seamless and easy option to build and operate tamper-proof and auditable applications.

This will be the sixth, yes sixth!, major Daml deployment option following Hyperledger Fabric and Sawtooth, R3’s Corda, Amazon Aurora and VMware Blockchain.

daml-qldbWhat is Amazon QLDB?

QLDB is a new type of cloud database service provided by Amazon Web Services. It’s a fully managed, serverless database with an immutable and cryptographically verifiable transaction log so that all data updates can be easily audited by third parties when desired.

While not decentralized and replicated across parties like many blockchain implementations,  QLDB’s immutable transactional log, known as a journal, maintains an independently verifiable history of all changes over time, which gives it blockchain-like properties.

Since QLDB is delivered as a serverless cloud service, it automatically scales, you only pay for what you use, and it abstracts away the underlying complexity of managing servers.

What is Daml?

Daml is an open source, platform-agnostic smart contract language that similarly abstracts away the complexities of the underlying deployment target, be it a blockchain, distributed ledger, or traditional database. This allows developers to focus solely on the business logic of the application they are trying to build. Below is a simple example of an IOU written in Daml (see our SDK documentation for the complete example):

As you can see, there’s no boilerplate or systems code dealing with cryptographic signatures, data schemas, notifications, private data distribution, or really anything other than an executable version of what an IOU is.

This level of abstraction doesn’t just allow developers to write distributed applications much more quickly, but also decouples them from the runtime platform to which these applications are ultimately deployed. By breaking the link between logic and systems code, Daml enables distributed application portability.

Distributed applications are also notoriously difficult to write, and small mistakes can have huge implications across multiple entities. When a contract involves many parties and data types it can be extremely difficult to define fine-grained data permissions in a general-purpose language. Daml allows you to define explicitly in code who is able to see which parts of your model, and who is allowed to perform which updates to it, providing real time feedback at development time.

Why choose Daml and Amazon QLDB?

QLDB tracks all data changes. Daml enforces who can change it and how. Together, Daml and QLDB let you write and run your business logic with ease and confidence.

But aren’t blockchains supposed to be decentralized?

Honestly, it depends on your use case. There are a lot of blockchain applications out there that could really just be a SaaS product. There are plenty that can’t. So you need to pick the right deployment option for your needs. Is there a centralized operator everyone trusts? Is there a natural authority but the need to ensure they haven’t tampered with the data? Are there no natural authorities or the need to decentralize the storage and validation of different transactions across different entities?

If you need full blown decentralization, a blockchain platform like VMware Blockchain, Hyperledger Fabric, Hyperledger Sawtooth or a more point-to-point DLT like Corda are the most suitable. But if you don’t, they may be overkill, adding complexity when a simpler architecture may do. Amazon QLDB and Daml are a new class of database and multi-party business process solution that provides many, but not all, of the benefits of true blockchains. Not sure which one you need at this stage? You’re in luck! Daml will support them all, so you can write your application once and migrate later. We even provide a serverless Daml hosting environment for development and testing before a deployment target is chosen.

Next steps

Head on over to the Daml docs to install the SDK and start building platform-agnostic distributed applications today. Everyone with an AWS account now has access to QLDB. Learn more and spin up an immutable database here. To be notified of when the combined Daml on QLDB offering will be available, sign up to our mailing list below.