Daml is the Daml smart contract language, an Apache-2.0 licensed, Haskell-implemented language and SDK for building distributed-ledger and workflow-automation applications, aimed at developers who need to encode multi-party agreements as executable contracts.

What it is

Daml is an open-source smart contract language registered in the Productivity & Utilities / Automation category. The repository is written in Haskell and released under Apache-2.0, and it carries the topics daml, smart-contract, distributed-ledger, dlt, workflow-automation, privacy-by-design, sdk, and bazel. The project homepage is the developer portal at digitalasset.com/developers. Taken together, these facts place Daml in the distributed-ledger (DLT) ecosystem: it is the language-and-SDK layer for expressing contracts and multi-party workflows, built with Bazel as its build tooling, and treating privacy as a design concern rather than an add-on.

The concrete problem it solves is the expression of agreements between multiple parties as code that can run against a distributed ledger, with privacy-by-design as a stated property of that model. Rather than leaving contract logic and workflow coordination to be assembled in general application code, the project supplies a dedicated smart contract language plus an SDK for writing and building it. The supplied facts do not identify a specific competing product that Daml replaces; what the registry records is the language itself, its SDK, and its build tooling, which is what a reader should expect to find here.

Key capabilities

• A dedicated smart contract language, listed under the smart-contract topic, for writing contracts as a first-class construct rather than as a library pattern.
• Privacy-by-design as an explicit topic of the project, positioning confidentiality between counterparties as part of the contract model.
• Distributed-ledger and DLT targets, named directly in the distributed-ledger and dlt topics.
• Workflow automation for multi-party processes, reflected in the workflow-automation topic.
• An SDK shipped inside the repository, with instructions pointed at by the root README to sdk/README.md.
• Bazel as the listed build system, appearing in the repository topics and therefore in the build path a contributor meets.
• Haskell as the implementation language under an Apache-2.0 licence, which permits commercial and private use of the source.

Who uses it and how

• Developers building distributed-ledger applications that must keep counterparty data private, following the privacy-by-design topic.
• Teams modelling multi-party business processes as automated workflows rather than as one-off application logic.
• Contributors working in Haskell and driving the Bazel build, as indicated by the language and build topics.
• Projects evaluating the codebase before adoption: the repository shows 917 stars, 263 forks, and 753 open issues.
• Anyone tracking the project's cadence, which currently shows recent activity with a last push of 2026-09-18.

Getting started

The root README does not carry setup instructions itself; it points readers to the full documentation at sdk/README.md, which is where the SDK entry point lives. No published package, Docker image, or hosted option is named in the supplied facts, so the build path runs through the repository's Bazel tooling.

How it compares

The supplied facts provide no list of paid products that Daml replaces, and they name no comparable tools in this registry. On the record given here, it stands alone in the Productivity & Utilities / Automation category as a smart contract language and SDK. Any comparison beyond that would require facts this entry does not contain.

When to use it — and when not to

Pick Daml when the requirement is a purpose-built language for distributed-ledger contracts and multi-party workflows, and when a Bazel-based Haskell build is acceptable. Do not pick it if the intent is a hosted, turnkey smart contract service with a documented install command — the root README is a pointer to sdk/README.md rather than a quick-start, and no package, image, or deployment method is stated in the facts. A self-hoster should also weigh the operational load of building from source with Bazel, and the 753 open issues visible in the repository.