Roles in Daml – Introducing Multi-party submissions


What is a Daml party? It’s a great question to which there is a precise technical answer, of course, but that answer would help us as little in designing a multi-party application as a precise technical understanding of database users would help us in designing a web application.

In our examples, we often use party names like “Alice” and “Bob”, or organisations like “Bank”, suggesting that parties represent individuals or business entities. This is an oversimplification for examples. Looking top down, it’s not so much a bank that acts in a transaction, but a legal entity within that bank. And maybe a particular desk within that legal entity. Ultimately paper gets signed by an individual within the responsible team. Similarly, looking at the situation bottom up, an individual rarely acts purely as an individual. We act as members of teams, using authority bestowed by the surrounding organization. In some businesses and cultures this concept of acting on behalf of an organization still has a physical manifestation in the form of a stamp.

In short, agents, be they human or machine, take on roles. The role can be that of an individual, or as a member or a team or organisation. It’s the mantle of the role that we take on that gives us access and authority. And access and authority are exactly what Daml parties are about via observers, signatories and controllers. Thus, a good way of thinking about Parties in Daml is to think of them as roles. Parties Alice and Bob represent individuals acting simply on behalf of themselves. A party Bank represents something or someone acting on behalf of a Bank.

Now in reality, we rarely act in only a single role. Just in your day-to-day professional activities you are probably acting as an individual, a team member, and a member of an organisation all at the same time. Multi-party submissions now make it possible to do just that in Daml, allowing you to translate business roles into Daml applications much more easily, and improving development and performance of several important use cases.

Use case 1: reference data

Let’s assume that we want to create a digital market where parties exchange items at a fixed price given by the market operator. The operator can update the price at any time, and we want the parties to automatically use the current price in their agreements.

The current price could be stored on the ledger in a simple contract where the price for a given item can be looked up by key. 

But how do the market participants look up the current price? The CurrentPrice contract as defined above is only visible to the operator.

We could make every party observer on all CurrentPrice contracts by storing a list of observers in the CurrentPrice contract. But maintaining a list of n parties on m price contracts gets expensive and cumbersome fast. Adding a single new party requires a transaction of size O(m * n). There are some possible optimizations, but ultimately this approach doesn’t match the obvious mental model for read access. We want to express the role of being able to read the prices. In line with the party/role equivalence, that means we add a new party and give it the right to read the prices:

Now with multi-party submissions, all that’s needed is for agents that should be able to read and use that price data to get the authorization to read as “reader”. For example, here’s the payload of an access token for the DAML sandbox that allows Alice to act on behalf of herself, while also reading all contracts of the “reader” party. 

Full code snippet for the described use case can be found here.

Use case 2: role-based access control

In this section, we will have a look at how to implement role-based access control in Daml. We’ll do so quite generically by showing how multi-party submissions can be used to model groups of parties (think of them as individuals) and give those groups some special access.

First, we define a template that captures the fact that a given party is a member of a group.

where org is the Daml party representing the entire organisation (the root of trust for current group hierarchy), group is the Daml party representing the group membership role, and member is a Daml party representing an individual person. Group membership can be checked through a fetch by key operation:

which will fail if the given party is not a member of the given group. Now let’s give a group special permissions by modeling one group being able to administer another.

Here adminGroup is the Daml party representing the group admin role. Note that the AddMember choice uses flexible controllers and can be exercised by anyone. The assertMember call is used to make sure the party exercising the choice is indeed a member of the adminGroup role. In an organisation where Alice is the administrator of the legal team, she could use the following Daml Script to add Bob to the legal team:

Note how Alice has read-only access to the legalTeamAdmins contracts, which allows her to access the GroupAdmin contract. Similar to the first use case, the read delegation was partially moved to the access token provider – in the above example, all administrators of the legal team would need an access token that allows them to read on behalf of the legalTeamAdmins party (e.g., “readAs”: [“legalTeamAdmins”]). However, administrative actions are still validated in the Daml model, and the ledger remains the single source of truth for who can administer what group, and which individual triggered changes.

Use case 3: Ledger Initialization

A more administrative use-case is that of ledger initialization. For example, imagine you are implementing a new workflow in Daml, where the core of your workflow are simple IOU contracts:

The Iou contract has multiple signatories. Previously, if you wanted to test your template using Daml Script, you had to implement a propose-accept workflow and submit multiple commands in order to create a single Iou contract. With multi-party submissions, you can instead send a single create command with both the issuer and the owner as act_as parties.

Not only is this shorter to write, but you can also start testing your code before fully implementing all propose-accept workflows. 

Summary of API changes

To let you jump right in and try out these new features yourself, here is a brief summary of the API changes that you need to use muli-party submissions.

Previously, submitted commands had a single party field, which was the party on whose behalf the command should be executed – ie the single role the submitting agent was acting in. This field has been deprecated and replaced by the following two fields:

  • actAs: The set of parties on whose behalf the command should be executed. All of these parties jointly authorize the command for the purpose of the ledger model authorization rules.
  • readAs: The set of parties on whose behalf (in addition to all actAs parties) contracts can be retrieved. These parties do not authorize any changes to the ledger. They affect Daml operations such as fetch, fetchByKey, lookupByKey, exercise, and exerciseByKey, which only “see” contracts visible to the submitting parties.

Ledger API

The commands object contains new actAs and readAs fields as described above. The change is backwards compatible, any party specified in the party field is merged into the actAs parties.

DAML Script

There is a new submitMulti command in DAML Script.


Note that most production ledgers will secure their ledger API access and users will have to add access tokens to their ledger API requests. If an application wants to submit a multi-party command, it needs an access token which authorizes it to act on behalf of all readAs parties and to read on behalf of all readAs parties.

For the DAML sandbox, the access token payload contains actAs and readAs fields, which need to contain at least all of the parties mentioned in the corresponding command fields.

Improve Pharmaceutical Efficiency and Transparency with Daml Driven Solutions for Supply Chains and Patient Data

Chander Damodaran from Brillio discusses how Daml smart contracts can accelerate the collaboration and automation of multiparty business processes in clinical trials and pharma supply chains

As 2021 begins to take flight, the entire world has turned their attention to Moderna, Pfizer-BioNTech, and many other pharmaceutical organizations to slow the spread of COVID-19 and its variants. The speed with which the vaccine was researched, developed, and trialed shows the paramount effort and collaboration required among external entities to create and mass distribute a vaccine. 

While this is a unique time for pharmaceutical companies, it also sheds light on the continued need for digital transformation within healthcare to improve patient care. From audits to supply chain logistics, the entire pharmaceutical industry runs on disparate platforms that create data islands, increasing errors across research data and complicating the track and trace procedures of drugs. Now, more than ever, pharma teams need a way to access patient data for clinical trials, efficiently track trial consent, distribute trial data with external parties, enact drug recalls quickly, and ensure quality along the supply chain all while maintaining compliance with an ever growing list of regulations. This can only be done by enabling communication and data sharing between the multiple parties involved. 

Digitally transact in a secure and permissioned environment 

Smart contracts offer a path for more automated and secure multiparty business transactions, and provide a means for pharmaceutical entities to view and share data with parties based on permissions defined in the code. Brillio’s innovation team uses Daml smart contracts across multi-party optimization projects for several reasons:

  • Daml smart contracts are unique in their ability to abstract away the underlying infrastructure across databases and distributed ledgers, enabling pharmaceutical companies to leverage the systems they currently have and build multiparty applications that easily port to blockchain (if the company moves in that direction).
  • Daml interoperates across blockchains and databases, enabling integrations with multiple infrastructure providers and communication between segregated domains. This creates more connected and seamless clinical research and supply chain operations.
  • Daml was built from the ground up to support distributed logic, so the code automatically handles distributed concerns while developers only have to code business logic. This means rights, obligations, and authorization are inherent in the code and ensures the right information is shared with the right party at the right time.

A trial patient portal for improved clinical research processes and data sharing

In the recent “Innovative Healthcare Systems for Clinical Trials and Drug Delivery” e-book, Brillio and Digital Asset proposed multiple Daml-driven solutions, including an end-to-end trial patient portal for clinical research teams. This solution uses the Daml smart contract development framework to build a distributed application with the following features:

  1. A secure patient portal for collecting and storing patient records (necessary for future audits and data sharing with healthcare providers). Through Daml’s privacy-first framework, clinical trial participants can log their drug reactions, digitally engage with the research team, and receive notifications in a trusted environment. Daml enables the research team to share information with healthcare providers on a need-to-know basis, hiding information they are not permissioned to receive via Daml’s framework.
  2. A patient consent model where patients accept the terms of the trial in real-time through the application interface. The application stores all patient trial data without the risk of losing paperwork for audits. This ensures the research data is accurate and provides a more transparent log of actions throughout the clinical trial.
  3. A report configuration interface where research teams can provide documentation and data that adheres to industry regulations. 
Example of the patient portal solution

A supply chain track and trace solution to speed up recalls

Another solution proposed in the “Innovative Healthcare Systems for Clinical Trials and Drug Delivery” is a track and trace application that identifies counterfeit ingredients and enacts speedy drug recalls. This solution would allow manufacturers to notify all stakeholders along the supply chain of contaminated drug batches. It would also cancel all future shipments while notifying patients of the adverse effects prior to consumption. Daml enables the following:

  1. Track the drug through the entire supply chain from supplier to point of sale, creating a completely transparent end-to-end view of the drug’s lifecycle.
  2. Facilitate collaboration between all supply chain participants by allowing manufacturers, logistics providers, distributors, hospitals, and pharmacies to transact in real-time with one another, send notifications, and view data based on the rights and obligations outlined in the code for each party.
  3. Provide direct access to supply chain data for regulators and other industry participants needing to review drug recall notifications. 

As we enter an era where technology and healthcare merge, the possibilities are endless. Pharmaceutical companies can leverage cloud technology and smart contracts to support distributed business models that increase the speed of clinical trials, data sharing, and drug delivery. The ability to share data across a shared network without losing the integrity and privacy of that information is only achieved through Daml smart contracts. Brillio’s team of Daml certified engineers can develop custom solutions that not only eliminate manual, expensive processes, but also accelerate innovative care to patients on a global scale. 

Learn more about how Brillio and Digital Asset are transforming the pharmaceutical industry in the “Innovative Healthcare Systems for Clinical Trials and Drug Delivery” e-book. Various solutions and workflows are outlined to demonstrate the possibilities for business transformation in pharma. 

DAML connect launch

Introducing Daml Connect

Our mission at Digital Asset is to give systems of record the ability to safely cross organizational, legal, or other boundaries and to create seamless economic networks.

The open source Daml smart contract language and its drivers run on leading blockchains, distributed ledger technologies (DLTs) and databases to form a solid foundation for accomplishing that mission. With Daml, the core of systems of record are written in a portable, purpose-built language that future-proofs investment and reduces development cost. Daml language and drivers are to shared systems of record what Java is to applications, and they are to blockchains, what ODBC/JDBC is to databases.

But Daml has always been more than a smart contract language, just as real-world systems of record are much more than SQL statements that manipulate databases. In order to form holistic solutions, the shared core of these systems must be embedded in the broader enterprise. In many projects, this integration component dwarfs the development of the core. And to end up with composable solutions that deliver on the blockchain vision for economic networks and provide optimal long-term returns on project investment, this integration needs to be done well. Daml supports this not only through developer tools that go beyond smart contracts, but through mission-critical libraries and runtime components that take care of common development tasks and encourage composable solution architecture.

With Daml Connect, Digital Asset is now introducing an umbrella for all the tooling required to build full stack Daml solutions, deploy them to any of Daml’s many deployment targets, and support them through the full software development lifecycle. We continue to stand behind our strong commitment to open source software and our community with the Daml Connect Community Edition and the Daml forums, which will continue to offer the tools and community support needed to build free and open source solutions using Daml without friction. The commercial Enterprise Edition builds on the Community Edition by including advanced developer tools, integration features, and deployment tooling geared towards reducing the development and operational costs of complex solutions in enterprise contexts. It also offers 24/7/365 ticket-based support from Digital Asset.

Daml Connect high level architecture
Daml Connect high level architecture

Daml Connect complements Digital Asset’s existing product offerings with a complete solution for those wanting to join an existing network. It contains everything you need to connect to running networks, plus a comprehensive set of tools for building, testing, deploying, integrating, and maintaining your Daml applications.

Digital Asset's products
Digital Asset’s products

Enterprise Integration

Daml Connect’s primary purpose is to speed up time-to-market of fully integrated solutions. This requires a comprehensive set of tools for automation, integration, and presentation. But for Digital Asset, enterprise integration means integrating with whatever technology is already present. Daml slots into any given enterprise environment rather than expecting environments to adapt to Daml. 

To provide both a comprehensive toolset as well as high adaptability, Daml Connect provides a holistically designed modular “recommended” stack. Daml Connect as a whole supports the majority of common integration tasks, from automation to presentation. But it delivers this functionality in a highly flexible fashion. Components of Daml Connect encapsulate pieces of functionality and communicate only through documented, public APIs. Developers can choose to use as much or as little of the toolchain as makes sense for their context and can complement the chosen subset with custom integrations that connect to the same stable APIs.

The recommended stack is built around technologies with the broadest adoption and high stability. This includes APIs that use gRPC for high performance streaming and higher-level APIs like HTTP/JSON, and Websockets. It includes JavaScript/TypeScript and Java — the best supported integration languages, React.js as the UI framework of choice, and OAuth2 for the default authentication framework. This design adds to developer productivity, maximizes compatibility, and reduces the amount Daml solutions or their environments have to be adopted to deliver fully integrated solutions.

Typical architecture of an application built with Daml Connect
Typical architecture of an application built with Daml Connect

Developer Productivity

Systems of record running on distributed ledgers and spanning across entities and boundaries are a new kind of application. Developing them effectively not only requires purpose-built languages and integration toolkits but also tooling that allows developers to put these pieces together with minimum friction.

Developer experience has been one of Digital Asset’s focus areas from the very creation of Daml. Now, Daml Connect’s comprehensive suite of developer tools enables developers to build Daml applications rapidly and iteratively, following best practices like test-driven development (TDD) or behavior-driven development (BDD).

At the core of this is the Daml smart contract language with its primitives carefully designed to capture core business logic safely and easily. Smart contract development is facilitated by Daml Studio, a fully featured IDE. It provides real-time compiler feedback and helpful suggestions to improve code quality. Test- and behavior-driven development are enabled through script-based testing that visualizes the effect of code changes on application behaviors in real time. The same scripts can be reused for testing in continuous integration or to manipulate production ledgers, leading to high code reuse. Code reuse is further enabled through code generation for JavaScript/TypeScript and Java, and by allowing ledger automation to be written directly in Daml.

Application and integration testing are supported through a full suite of Daml Connect runtime components and a lightweight test ledger. These tools allow full test environments to be spun up with single commands, using Daml’s command line Assistant. The assistant further aids developers with common development tasks throughout the software development lifecycle, like project management, administering Daml ledgers, or managing developer tools.

To aid manual testing, debugging, and the rapid development of PoCs or Pilots, Daml Connect SDK contains tools for visually exploring, presenting, and interacting with Daml ledgers.

Typical architecture of an application built with Daml Connect
Typical architecture of an application built with Daml Connect

Get Daml Connect

Daml Connect Community Edition is available for download without charge on daml website. Also, for more information about the Enterprise Edition, please contact Digital Asset Sales

Download Daml Connect

Digital Asset is working with IntellectEU to improve corporate actions processing

Untying the Knots: How DLT and Daml Can Transform Corporate Actions

In collaboration with IntellectEU, we explored numerous ways distributed ledger technology (DLT) and Daml can transform securities services, including clearing and settlement, KYC processes, corporate actions and more. Through a series of blogs we are sharing our analysis, highlighting what DLT and Daml can do for you today.

Corporate actions processing has plagued capital markets for decades with high levels of inefficiency and risk. While great strides have been made to improve straight through processing in other areas of the investment ecosystem, corporate actions have been left behind as too difficult to automate with its complex chain of communications, multiple touchpoints, and lack of structured data at the source. It’s also a place where IT spending offers little tangible return on investment. All of this has left issuers and investors grappling with how to best communicate and capture that golden source of truth.

What is a corporate action and why should I care?

A corporate action is any activity from a publicly-traded company that brings material change to an organization and impacts its stakeholders. Corporate actions include stock splits, dividends, mergers and acquisitions, rights issues and spin-offs. All of these are major decisions that typically need to be approved by the company’s board of directors and authorized by its shareholders. A corporate action notification error can be catastrophic to a company and its shareholders. Processing failures can arise anywhere in the corporate action chain, and all market participants run the risk of failures. A simple mistyped data input at any point in the process could result in significant financial losses to both the company and the shareholder.

Example of a Holding Chain
Example of a Holding Chain

Traditional processing of corporate actions is costly and complex

Corporate actions demand accurate event details to be received in a timely manner with accurate (fully reconciled) holding records to ascertain a controlled and risk-free processing in current holding chains (the chain of “custody” service providers).

Even the simplest corporate action can be a challenge from a processing perspective. What increases cost and complexities further is that processing has to be performed and executed at each step of the holding chain. This results in a global cascaded process from the issuer (and its agent) to the investors (or bottom-up when processing investors’ elections).

Processing also takes time, generally spanning three main steps performed at predefined dates or periods:

  1. Information dissemination / collection (including eligibility assessment)
  2. Eligible balance determination and entitlement calculation
  3. Corporate action processing (including investors’ instructions processing, execution of cash and securities movements) and respective confirmation

All of the complexities described above often result in delayed notification, incomplete or inaccurate data quality, and conservative election deadlines. In addition, traditional processing of corporate actions heightens operational risks, which worsen with the length of the holding chain.

How to move corporate actions processing to a distributed ledger powered by Daml smart contracts

It’s worth noting that Daml fits particularly well within the implementation of corporate action workflows.

Why? Because, Daml is specifically designed to develop smart contracts supporting the performance of the rights and obligations defining the corporate action. As such, the language facilitates a clear definition of the involved stakeholders and role enforcement.

A Daml corporate actions application implements a single place of processing built on a “corporate action” distributed ledger. It involves two main workflows:

  1. Set-up the corporate action as a shared record (“the golden record”): The corporate action creates rights and obligations – for the issuer, investors and/or offeror – described in binding legal documents. In essence, this establishes a “data-driven” process in place of the current “document-driven” process (as most of the corporate actions combine known and standard features that are easy to parameterize). The key data/parameters defining the corporate action can then be used to generate the related legal documentation.
  2. Perform the entitlement calculation, simultaneously throughout the holding chain. This calculation will be performed according to the same principles used in “simultaneous settlement”, a Daml workflow that atomically settles inbound and outbound cash and securities movements (you can read more about simultaneous settlement in a separate blog on the topic here).

By implementing the first workflow on a distributed ledger, all the stakeholders involved in the set-up of a corporate action (e.g. issuer, agencies, lawyers, central securities depository, investment banks) will be able to contribute to the shared record as per responsibilities. This shared record will be instantly available to the market participants, while the liability of each stakeholder will be clear as all contributions will be traced in the DLT immutable audit. Beyond process simplification and risk mitigation, market participants will have the advantage to instantly access the information whether it is preliminary, incomplete, or complete and confirmed. The ability to have earlier access to corporate action information might be crucial for investors.

Similarly, the entitlement calculation workflow provides a number of cost and risk-mitigation benefits. It effectively relieves the intermediaries from calculating the entitlement themselves and implements a one-place processing for the corporate action. In case of elective corporate action, the beneficial owner instruction will be made in direct interaction with the corporate action processing workflow. On the payment/effective date, the asset movements will be performed using the “simultaneous settlement” mechanism. Investors will be immediately aware of the corporate action processing completion as the DLT makes the process progress fully transparent to all authorized stakeholders.

To learn more about what DLT and Daml can do to improve corporate actions processing, download the IntellectEU and Digital Asset e-book today.

Download for Free

Download the “Digitally Transforming Securities Services” e-book by Digital Asset and IntellectEU on DLT, smart contracts and their practical applications in the Financial Services Industry, from account onboarding to post-settlement and treasury services.

Release of Daml Connect 1.8.1

Daml Connect 1.8.1 has been released to fix a bug in shared Daml Driver components (“The Integration Kit”) where contract keys were not correctly updated . This could cause incorrect contract key lookups. No ledgers are affected. You can install it using:

daml install 1.8.1

Complete release notes for the 1.8.x release can be found here.

Release of Daml Connect 1.9.0

Daml Connect 1.9.0 has been released on January 21st. You can install it using:

daml install 1.9.0

Want to know what’s happening in our developer community? Check out the latest update for this month.

Note: This release fixes 2 bugs in the 1.9.0 RCs. One where the default contract id seeding mode in sandbox classic was erroneously set to testing-weak this was corrected to the previous default value of no. The other is the same as the recent 1.8.1 release to fix a bug in shared Daml Driver components (“The Integration Kit”) where contract keys were not correctly updated which could cause incorrect contract key lookups. No ledgers were affected by this bug.


  • Multi-party submissions which allow new forms of data sharing and use-cases including public reference data and better role-based access controls. 
  • Daml-LF 1.11 is now in Beta, bringing Choice Observers and Generic Maps.
  • Introduction of Ledger API version 1.8.

Impact and Migration

  • Multi-party submissions add new optional fields to the Ledger API and some interface definitions in Java. If you compile your own gRPC service stubs, or maintain your own implementation of some of the provided Java interfaces, you may need to add the new fields or methods. Details under Multi-Party Submissions.
  • Daml-LF 1.11 will not be compatible with the deprecated Sandbox Classic’s default --contract-id-seeding=no mode. If you use Sandbox Classic, you will need to either switch to a different contract seeding mode, or pin Daml-LF to 1.8. Details under Daml-LF 1.11.
  • Daml’s main development branch has been renamed from master to main to be more inclusive. If you had a source code dependency on the repository you need to switch to the new branch.

What’s New

Multi-Party Submissions


Privacy and identity are core concerns of Daml. Users always act and read as parties, and events and contracts are authorized by and shared with those parties on a strict need-to-know basis. This uniquely strong privacy and authorization model is crucial for many of the core use cases for which it was designed. Multi-party submissions now extend this model to allow users to act and read on behalf of more than a single party at a time, adding support for important new use patterns without compromising Daml’s inherent privacy or security.

One pattern is the distribution of reference data such as pricing information coming from a trusted party (sometimes called an oracle). The oracle can now share reference data with a single dedicated broadcasting party PriceObserver and give all users that should be able to use the pricing information read access to that party. This drastically reduces the storage and management overhead of having to maintain lists of observers on the price contracts.

Another pattern that is enabled by multi-party submissions is bulk delegation and role-based access controls. It is easy to write a contract that allows an organisation ACME to delegate the right to ship widgets to an employee Alice, but without Alice being able to see the inventory of widgets, she can not make use of that right. As with the oracle pattern above, the need for Alice to be added as an observer to all inventory contracts as an individual can now be replaced by giving Alice read access to a dedicated `InventoryManager` party that is an observer on the inventory.

A blog post will follow these release notes to explore these and other use cases in more detail, and provides an example of how this can be used for role-based access control.

Specific Changes

  • The Ledger API version is now at 1.8.
  • The gRPC Ledger API has new optional fields act_as and read_as on the Commands object, which each take a list of parties. The parties need to be hosted on the participant the submission is sent to, and if authentication is enabled, the authentication token must include the parties in the corresponding actAs and readAs fields.

    The meaning of these fields is that the parties in act_as are the requesters as defined in the Daml Ledger Model. Top level actions are authorized by all parties in this list. For example, if act_as = [Alice, Bob, Carol], an action creating a contract with signatories Alice and Carol would be well-authorized.

    In addition any contracts visible to any party in act_as or read_as may be accessed during interpretation. For example, if act_as = [Alice], readAs = [PricingObserver], Alice can submit a transaction with a Fetch on a price contract only visible to PricingObserver.

    The party field on Commands is now optional and implicitly added to the act_as list if set, meaning the effective act_as is the union of the act_as field and the party field.
  • Daml Script exposes the new functionality through a function submitMulti. submitMulti [alice, bob] [carol] do ... sets Alice and Bob in act_as and Carol in read_as.
    A submitMultiMustFail function is provided as a counterpart to submitMustFail.
  • The Java Ledger API Bindings and Codegen have been expanded with the new fields.
  • The JSON API infers the act_as and read_as fields from the supplied JWT token.

Impact and Migration

This is an additive change, but the following should be noted:

  • JSON API and Daml Script always use the first party from act_as to set the party field on the Commands object. That means new versions of the API server and Script still work against old Ledger API versions. However, any attempt to use multi-party submissions against Ledger API version <= 1.7 will result in any additional parties being silently ignored by the Ledger API, most likely resulting in authorization or visibility errors.
  • Since the Javascript client libraries treat JWT tokens as opaque and connect to the JSON API, they fully support the new feature without change.
  • Since this feature adds new fields to the Ledger API and some interfaces in the Java rxbindings, setups with custom compiled client stubs, or custom implementations of the Java interfaces LedgerClient, CommandClient, or CommandSubmissionClient may experience compile time errors. Since the new fields are optional, implementations can be stubbed (e.g., by throwing an UnimplementedException) for immediate migration.

Daml-LF 1.11 in Beta


Daml-LF is Daml’s intermediary language, analogous to Java bytecode. Daml Connect 1.9 introduces Daml-LF 1.11 in Beta. That means Daml-LF 1.11 will only change if bugs are discovered. Daml-LF 1.11 introduces two new language features (also in Beta): Choice Observers and Generic Maps. In addition, Daml Script, REPL and Triggers now properly convert from ContractId a value to Text using the show function.

To use the new features, your project has to explicitly target Daml-LF 1.11. You can enable this in your daml.yaml file by adding stanzas:

  - --target=1.11
  - --early-access-unsafe

Specific Changes

  • The Daml compiler can now target Daml-LF 1.11 by setting --target=1.11.
  • The Sandbox and Sandbox Classic have new command line flags --early-access-unsafe which enables Daml-LF 1.11. This is deemed unsafe, because if Daml-LF is used with PostgreSQL backing, and Daml-LF 1.11 were to change, this may leave the database in an unusable state.
  • Choice observers, documented on the reference page for choices, add an additional keyword observer to the choice … syntax. Parties designated choice observers using that keyword are guaranteed to see the exercise of the choice. This can be useful for defining custom events, for example:
nonconsuming choice MyEvent : ()
    message: Text
    sender: Party
    receivers: [Party]
  observer receivers
  controller sender
    return ()

Here the parties in receivers will all see an exercise node of type MyEvent with a payload containing message.

  • Generic maps add a type GenMap and standard library module DA.Map allowing maps with arbitrary serializable types as keys. This supersedes the TextMap type and standard library module DA.Next.Map, which required conversion functions between the key type and Text.
    Note that the representation on the APIs is different. Generic maps are represented as lists of tuples on the API. For users of the JSON API in particular, the continued use of TextMap may therefore be attractive as this is represented as a JSON object.
  • All inbuilt and derived instances of Show now return the actual contract id in Daml Script, REPL, and Triggers, rather than the opaque ”<contract-id>” that’s returned in Daml contracts.

Impact and Migration

Note: Neither the regular Sandbox you use through daml sandbox or daml start, nor any production ledgers are affected by this change and require no action.

Sandbox Classic’s default contract seeding mode no is not compatible with Daml-LF 1.11. Once Daml-LF 1.11 becomes stable, it will become the default, so if you use Sandbox Classic, you need to either pin the Daml-LF version to <=1.8 or switch contract seeding mode. If you do neither, Sandbox Classic will present you with an error informing you that you need to do one or the other. 

We recommend doing one of the following in preparation for the rollout of Daml-LF 1.11:

  1. If you are relying on the human-readable, stable contract-ids for demo purposes, pin the Daml-LF version by adding this stanza to your daml.yaml:
  - --target=1.8

2. If you would like Sandbox Classic to resemble production ledgers more closely, switch contract id seeding mode by adding:

  - --contract-id-seeding=strong

Removal of Navigator Console


The “Labs” Early Access feature Navigator Console has been superseded by the stable Daml REPL. It has therefore been removed from Daml Connect 1.9.

Specific Changes

  • The daml navigator console command has been removed.

Impact and Migration

We recommend Daml REPL for shell-based interaction with Daml ledgers.

Minor Improvements

  • Daml Connect development is now conducted from the main branch, rather than the master one. If you had any dependency on the digital-asset/daml repository, you will need to update this parameter. See the forum thread for background and migration steps. 
  • The Daml Assistant’s update-check is disabled by default for new installations. In addition, auto-install is disabled by default on Windows. See here for instructions on how to configure these settings manually:

    This measure prevents issues in locked-down environments where the assistant cannot contact remote servers to check for updates.
  • TypeScript code-generated code has gained convenient aliases for the full types of query results that are sometimes needed to inform the TypeScript compiler. In places where you previously had to write:
    const allUser: QueryResult<User.User, User.User.Key, typeof User.User.templateId> = useStreamQueries(User.User);

    you can now write:
    const allUser: User.User.QueryResult = useStreamQueries(User.User);


  • Fixed a rarely occurring issue that caused transactions to be sent out of order from the Ledger API. See #7521
  • Fix a bug in the JavaScript client libraries where in some cases calls to exercise and createAndExercise failed to typecheck with a mismatch in the key type.
  • Fix a bug in Daml Script where queryContractKey incorrectly returned None despite there being an active contract with the given key. This affected Daml Script over gRPC, and keys with record types.
  • Fix a bug in Daml REPL where bindings with very long types sometimes resulted in parse errors on following lines. See #8213

Integration Kit

  • kvutils no longer supports fingerprints directly. Instead, if the ledger fingerprints the code, you can use the newer, more generic APIs to transform the state values to include those fingerprints, if necessary.
  • Emit OpenTelemetry spans and events for index DB reads.
  • Emit OpenTelemetry events for transactions streamed to the client from the Ledger API.
  • Enabled asynchronous commits in JdbcIndexer for improved performance when consuming state updates from the ledger.

What’s Next

  • The Trigger Service is getting ever more robust and is likely the next big feature to come to Daml Connect.
  • Improved exception handling in Daml didn’t make the cut for Daml-LF 1.11, but remains a high priority.
  • We have started work on a new features targeted at the Enterprise Edition of Daml Connect:
    • A profiler for Daml, helping developers write highly performant Daml code.
    • A mechanism to verify cryptographic signatures on commands submitted to the Ledger API, improving security in deployment topologies where the Ledger API is provided as a service.
    • Oracle DB support throughout the Daml Connect stack in addition to the current PostgreSQL support.

Daml Developer Monthly – January 2021

What’s New

The results of the third community recognition ceremony are in. Congratulations to Emil and Matt for winning and thank you both for your excellent contributions to our community.

Daml’s default branch name is changing from master to main to have more inclusive naming. Read more about the steps and the reasoning behind it here.

Happy 5 year anniversary to Hyperledger!  We’re proud to be a member and look forward to what the next 5 years will bring!

And we’ve got a new name for the community update, one that we feel better reflects our goals with these posts which is to highlight Daml developers and the ecosystem around them.

Upcoming Events

Andreas and the gang will be at POPL 2021’s Certified Programs and Proofs conference next week (and presenting next Tuesday the 19th). If you’re interested in practical and theoretical topics around formal verification and certification you should definitely check it out.

Anthony will be showing off Daml’s write-once deploy-anywhere ability at the next Hyperledger Tech Study circle this Friday the 15th where he will be deploying the same application to both Fabric 2.2 LTS and Sawtooth.

Anthony will also be presenting on Why Daml at Hyperledger NYC on January 26th at 12PM EST. Join to learn about Daml’s tech stack along with a live demonstration of Daml’s unique ability to be written once and deployed anywhere including Hyperledger Fabric and Sawtooth.

What We’re Reading

György breaks down all the different mental model we have around “blockchains” and “smart contracts” in his latest post where he rightfully puts these terms in quotes because they’ve come to mean a lot of different things.

Richard’s latest security and privacy news covers newly discovered malware involved in the Solarwinds fiasco, why Parler’s deleted data isn’t deleted, and the secret history of ZIPFolders among many other excellent stories.

Richard is also going to be turning these blog posts into podcasts so make sure to check them out when they’re live on the forum!

György shows us how to be happy developers by building Daml frontends in Elm

Olusegun published his MSc FE paper on OTC swaps using Daml.

Community Feature and Bug Reports

As you’ll see below we now have support for multi-party submissions, allowing for better role-based access that many in our community have asked for including Jean, Emil, and Zohar. So thanks everyone for pushing for this important and highly useful feature.

Big thanks to James and Luciano for tracking down a bug in our Bond Issuance refapp!

Other Fun

Congrats to György for becoming a EU Blockchain Observatory and Forum expert panel member

Bernhard’s secret santa project is complete and some of us have already started receiving our gifts.

Daml Connect 1.9


  • Multi-party submissions allow new forms of data sharing and use-cases including public reference data and better role-based access controls. 
  • Daml-LF 1.11 is now in Beta, bringing Choice Observers and Generic Maps.
  • Introduction of Ledger API version 1.8.

The full release notes and installation instructions for Daml Connect 1.9.0 can be found here.

Impact and Migration

  • Multi-party submissions add new optional fields to the Ledger API and some interface definitions in Java. If you compile your own gRPC service stubs, or maintain your own implementation of some of the provided Java interfaces, you may need to add the new fields or methods. Details under Multi-Party Submissions.
  • Daml-LF 1.11 will not be compatible with the deprecated Sandbox Classic’s default --contract-id-seeding=no mode. If you use Sandbox Classic, you will need to either switch to a different contract seeding mode, or pin Daml-LF to 1.8. Details under Daml-LF 1.11.
  • Daml’s main development branch has been renamed from master to main to be more inclusive. If you had a source code dependency on the repository you need to switch to the new branch.

What’s Next

  • The Trigger Service is getting ever more robust and is likely the next big feature to come to Daml Connect.
  • Improved exception handling in Daml didn’t make the cut for Daml-LF 1.11, but remains a high priority.
  • We have started work on a new features targeted at the Enterprise Edition of Daml Connect:
    • A profiler for Daml, helping developers write highly performant Daml code.
    • A mechanism to verify cryptographic signatures on commands submitted to the Ledger API, improving security in deployment topologies where the Ledger API is provided as a service.
    • Oracle DB support throughout the Daml Connect stack in addition to the current PostgreSQL support.