DAML Development for Business: A Practical Guide to Building Multi-Party Applications

In other words, Daml ensures each party sees only what they are permitted to see. The sensitive data is not disclosed, so the participants are safe and sound. Daml’s architecture allows for a shared application state across all participants. This makes Daml and the Canton Network ecosystem it powers so appealing for the world’s major banks, exchanges, and financial enterprises.

PixelPlex has already developed several solutions in Canton, and our Canton Loop wallet has even appeared on the list of Canton Featured apps. We have consulted our Daml experts and asked them to help us with this guide. The explanations here provide a foundational understanding of Daml architecture key concepts. For a deeper technical examination or to discuss how these principles can be applied to your specific multi-party workflow, our team is ready to assist.

What is DAML, and how did it emerge?

Before going too technical, let’s plunge into history.

• Back in 1994, an American computer scientist, Nick Szabo, introduced the concept of a smart contract. In his paper, The Idea of Smart Contracts, he explains the smart contract using the example of a vending machine. A person drops a few coins in the vending machine, and it gives the change and the selected product. This works because the machine has a fixed set of pre-programmed rules. A smart contract also automatically executes the terms of an agreement because they are written into code.
• In 2002, Mr Szabo presented a paper, A Formal Language for Analyzing Contracts, where he discussed a “mini-language for professionals and researchers interested in drafting and analyzing contracts.”
• A bit earlier, in 2000, the paper Composing contracts: an adventure in financial engineering appeared. It was written by the creator of the Haskell programming language, Simon Peyton Jones. The paper describes how to build financial agreements with code. It uses simple programming pieces in Haskell, where each piece represents a basic financial building block. For example, one piece just pays one unit of a currency. Other pieces act like rules to combine these blocks into more complex agreements. You can use rules like “and”, “or”, or “expire after this date” to link them together. The idea is similar to Nick Szabo’s idea of building contracts from simple parts.
• Finally, inspired by Peyton’s work, a Swiss technology company, Elevence, developed the Digital Asset Modeling Language (DAML). The idea was to provide multiple financial companies with the possibility to share a single, trustworthy digital record of their agreements.

Digital Asset Holdings acquired Elevence in February 2016. Later the same year, they announced the intention to open-source Daml. On April 4, 2019, Digital Asset released the core language, its compiler, and the Software Development Kit (SDK) to the public under an Apache 2.0 license. This made it free for anyone to use, modify, and build upon.

Therefore, the DAML development services solve a problem for financial institutions and other businesses. The language handles legal agreements and the actions that result from them. It ensures that once a rule is set in a contract (like “a payment is released only after a delivery is confirmed”), every participant sees the same outcome, and the rule cannot be broken. Earlier versions of this idea could only work with two parties. However, in Daml, a smart contract can include any number of participants.

Foundational concepts

Businesses often work together on shared projects, like supply chains or financial trades. Managing these multi-party workflows is complex and expensive. Distributed ledger technologies aim to reduce that cost by automating these processes on a shared, trustworthy system. To do this well, a programming language for this “on-ledger” logic needs three key features:

1. It must capture the real legal rules of business.
2. It must have simple ways to control who can see or do what.
3. It must allow simple workflows to be connected into more complex ones, even after they’re already in use.

Daml smart contract language uses a core set of concepts that directly mirror how legal agreements work in the real world, making it easier to model business relationships. Here are these concepts summarized in a table:

DAML vs. traditional smart contract languages

There are several peculiarities that make Daml architecture stand out.

Multi-party focus

As we’ve already known, the core idea of modeling contracts as code began with research by Simon Peyton Jones, who created functional programming building blocks for two-party financial contracts. Later researchers expanded this model to handle agreements involving many parties at once. Daml connects simple, standard pieces to create complex, multi-party systems. In Daml, workflows are built from choices, and multiple actions can be combined into a single, secure transaction.

Privacy-by-design

Daml controls data access for every participant. Each party can only see and change the information they have permission for. Sensitive data is kept private and remains under the owner’s control. The system blocks any unauthorized access or tampering by other parties or bad actors. Daml’s design also makes it easy to build new services on top of existing agreements. This helps keep data private and finances secure across connected applications.

Platform agnosticism

Daml development process allows for the convenience of “write once, deploy anywhere”. The same Daml app can run on different blockchains or database backends (Canton, Besu, Fabric, etc.).

Business logic

Daml handles the rules and steps for how data is shared and updated. Developers write all agreements and processes into clear, working code. This makes everything transparent for everyone involved. The system gives every party the same, accurate view of the data, which helps all participants work together smoothly and reliably.

Automatic authorization

In Daml development, you define who owns data and who can control it right alongside the data itself. When a programmer writes the contract, they state which parties own the data and which parties have permission to update it, following the contract’s rules. The system then guarantees that every owner is automatically informed of any change made.

Regulatory compliance

The language helps meet legal and audit requirements by making business rules clear and transparent. Business rules are recorded into software and run automatically. Every action this software takes is permanently and securely logged in a perfect record. This creates a precise, verifiable audit trail of who did what and when, making it easier to prove compliance to regulators and blockchain smart contract audit companies without manual paperwork.

Now, let’s compare the above-mentioned Daml features with traditional smart contract languages:

Industry applications of DAML

Our DAML development services guide contains detailed information about Daml use cases across industries. In this overview, let’s just focus on the key facts.

• Capital markets: Daml helps to automate clearing and settlement. It reduces errors and speeds up transactions by codifying trade agreements. Exchanges use it to synchronize data across brokers, custodians, and regulators in real time. Regulatory reporting becomes simpler because every action is recorded immutably.

• Financial services: Financial institutions apply Daml development to tokenize assets like real estate or bonds. It defines the rules for ownership and transfers clearly. Besides, Canton Network wallet development allows for creating wallets that are used in complex business workflows and can manage various types of assets.
• Insurance: Insurers deploy Daml to automate policies and claims. A policy’s terms are written into code, which triggers payouts automatically when conditions are met. Claims management becomes faster and more transparent because all parties see the same records and rules.
• Supply chain: In supply chains, Daml tracks ownership and provenance of goods from origin to delivery. Logistics partners use it to coordinate movements and updates without sharing unnecessary data. Every step is recorded in a permanent audit log, providing clear visibility into the transaction history.
• Healthcare: Healthcare organizations apply Daml to process insurance claims securely and efficiently. Rules for approvals and payments are automated. Daml also enables secure data sharing between hospitals, insurers, and labs.
• Government: Governments use Daml to codify regulations and administrative workflows into executable code. This makes processes like permitting, licensing, or benefit distribution consistent and transparent. It reduces manual work and ensures rules are applied uniformly.
• Intellectual property and digital assets: The Daml programming language is used to create NFTs and digital assets with complex ownership logic. It can define rules for royalties, co-ownership, and access rights in a way that’s automatically enforced across platforms. This makes Daml a powerful foundation for secure NFT smart contract development.

Getting started with your first DAML model

Let’s break it down into simple, practical steps.

1. Setting up your tools

First, you download the Daml SDK (software development kit). This is your main toolbox. It comes with everything you need to compile your code, run a local ledger (a mini-version of the final system for testing), and use command-line tools.

The key parts are:

• The SDK itself: The compiler and core tools.
• The Digital Asset Package Manager (replaces Daml Assistant): This is the tool for running commands to build and test your projects. Note: The legacy Daml Assistant is now deprecated.
• The Daml Studio (integrated development environment): This gives you helpful features like highlighting errors and suggesting code, making writing Daml much easier.

2. Your first building block: the Template

In Daml 2.0, you model agreements. The core building block is called a Template. It’s a blueprint for a type of contract.

Let’s use a simple example: an IOU (I owe you) note.

   template Iou
  with
    issuer: Party  // Who is issuing the debt?
    owner: Party   // Who owns the Iou?
    amount: Decimal // How much is owed?
    dueDate: Date   // When is it due?
  where
    signatory issuer, owner
    observer []
 

Let’s decode this:

• `template Iou`: This declares a new contract type called “Iou”.
• Parameters (the `with` block): this is the data of the contract. Who are the parties? What are the terms? It’s like the blanks you fill out on a form.
• `signatory issuer, owner`: This is crucial. It states that for this Iou to exist on the ledger, both the issuer and the owner must digitally sign it. No signature means no contract. It ensures mutual agreement from the start.
• `observer []`: Observers can see a contract but can’t act on it. Here, the list is empty, so the agreement is just between the two parties.

This template defines what an Iou is. To create a real one, you should specify that, for example, Alice is the issuer, Bob is the owner, the amount is $100, and it’s due next week.

3. The contract’s lifecycle

The contracts are immutable after creation. That is, any change in the contract means you are creating a new contract. However, a Daml contract isn’t a static document. It evolves only through specific, pre-defined actions called Choices. Looking back at our template, using the Iou template as a blueprint, Alice and Bob both digitally sign to create an active Iou contract on the ledger. It’s now a shared, undeniable fact they both agree on.

Choices are the only allowed actions on a contract. Let’s add a Pay choice to our Iou:

   choice Pay: ()
    controller owner  // Only Bob can execute this
    do
     assertMsg "Payment must be triggered only on or after dueDate" (dueDate <= today)
     create CashPayment with payer = issuer, payee = owner, amount = amount
     return ()
 

Here is the lifecycle in action with our example:

1. Who can act? The controller owner line means only Bob (the owner) can choose to Pay.
2. What’s the rule? The assert line checks a business rule. Is today on or after the due date? If not, the action stops. This is how you encode logic.
3. What happens? If all is good, the ledger does two things:
   • Archives the old contract: the original Iou is marked as completed and moved to the historical record. It’s no longer active.
   • Creates a new contract: as a direct result, a new CashPayment contract is created, providing a permanent, auditable record that the payment occurred.

Let’s have an example: Bob’s application asks the ledger to exercise the Pay choice on his Iou. The ledger checks: Is Bob the owner? Yes. Is the date valid? Yes. It then archives the Iou and creates a new CashPayment record. The debt is settled.

This entire process follows a consistent, predictable lifecycle that every Daml contract goes through. This guaranteed lifecycle is what makes Daml contracts so reliable. You always know the possible states and exactly how to transition between them.

DAML’s architecture

The architecture of a Daml app is built on a clear separation between the shared business logic on the ledger and the external applications that interact with it. The core principle is that the rules (the what and who of an agreement) are encoded in Daml and enforced by a central ledger, while the user interfaces and integration logic are built using standard tools.

The ledger

Daml code does not run inside your application. It runs on a ledger, which acts as a synchronized, authoritative database for all participants. Your application sends commands (e.g., create this contract or exercise that choice) to the ledger via a participant node.

The ledger performs the following tasks:

• Validation: It checks every command against the rules written in the Daml code.
• Authorization: It verifies that the parties submitting the command have the required permissions (as signatories or controllers).
• Consensus and state update: Using the underlying technology (a database, VMware Blockchain, Hyperledger, etc.), it ensures all participant nodes agree on the outcome before updating the shared state.

Modularity and code reuse

Daml is designed for building complex systems from reusable, verifiable components.

• Packages and imports: The code of an app is organized into packages. Developers can import functionality from other packages. For example, one team publishes a standard financial contract (like an Iou), and another team later builds a complex trading application on top of it, without modifying the original.
• Data types: You define custom data types with certain fields (e.g., a Cash data type needs “currency” and “amount” fields). These types form the building blocks of your contracts.
• Interfaces: Template interfaces allow defining a required set of actions for a contract type without locking in the implementation. It enables even cleaner modular designs.

DAML interactions

Daml’s interaction with users, legacy systems, and data feeds happens through well-defined off-ledger components.

• The Ledger API: This is the universal gateway. All participant nodes expose a Ledger API (available as gRPC and HTTP JSON). Every interaction with the ledger flows through this API.
• External applications: Any user-facing apps (web/mobile apps, back-office systems) are written in standard languages like Java, TypeScript, or Python. They use the Ledger API to communicate with the Daml Ledger.

To sum up, you write the rules of the game in Daml (the templates and choices). The Daml Ledger is like an unbiased referee that enforces them. Your applications are the players, they send moves to the referee via the APIs and get updates on the game state.

Here are the main Daml development components:

Testing DAML applications

Testing a complete Daml application involves multiple layers to ensure both the backend logic and the frontend integration work correctly.

End-to-End (E2E) UI testing

It verifies that user interactions in the web interface (like clicking a button) correctly trigger commands to the ledger and display the updated results on the page. As shown in the Daml docs, this can be automated using standard web testing tools. A common and effective combination is Jest (as the test runner and assertion library) and Puppeteer (to control a browser and simulate user actions). This type of test ensures the full application stack works together.

Backend/DAML logic testing

This covers the core business logic and is typically broken down into:

• Unit testing: these are isolated tests for a single template’s logic and choices.
• Script testing: multi-step scenario tests that simulate actions by multiple parties on a temporary sandbox ledger. This is Daml’s primary method for multi-party interaction testing, as it validates how workflows play out between all involved parties.
• Integration testing: they are tests that run the entire application (Daml backend and sometimes frontend bindings) against a test ledger within a CI/CD pipeline.

The following table correctly summarizes the three standard, native testing approaches for Daml applications as documented by Digital Asset:

Deployment and platform choice

One of the core strengths of Daml development is its flexibility. You write your contracts once, and you can deploy them on a variety of different backends depending on your needs.

The same Daml application can run on:

• A simple, centralized database (like PostgreSQL), which is fast to set up and useful when a single organization manages everything.
• A distributed blockchain network, where multiple independent organizations participate and no single party has full control. This is useful for cross-company collaborations where trust is decentralized.
• As an additional layer on top of an existing blockchain, where Daml handles the complex business logic privately between participants, using the underlying chain only as a secure coordination layer.

This “write once, deploy anywhere” approach gives businesses a practical choice. They can start simple and later move to a more distributed setup without rewriting their core contracts. It’s a key reason Daml is used in large-scale, real-world systems across finance, healthcare, and supply chains.

Conclusion

Daml development has changed digital collaboration. It moves the focus from building isolated applications that later need complex integration to co-designing the shared rules of engagement first. With Daml, developers build multi-party agreements with inherent privacy and synchronization, which reduces costs and risks of cross-organizational coordination.

We believe the future of Daml development lies in the direction of orchestrating institutional ecosystems, particularly within frameworks like the Canton Network. Enterprises in finance, supply chain, or healthcare receive a huge competitive advantage from the ability to participate seamlessly in the synchronized, yet private, networks. At PixelPlex, we will continue to discover this promising language and participate in the development of the ecosystem. Contact us, if you are ready to bring your Daml development idea to life.