DAML Security

Daml removes many low-level smart contract risks, but it cannot fix a bad security model. The most serious Daml issues usually involve authority, privacy, economic rules, or workflows that look correct but fail in edge cases.

• Write down each party, what it may see, and what it may approve before defining templates.
• Keep signatory, observer, and controller roles separate; visibility does not automatically grant authority.
• Take controllers from trusted contract state, never from a party supplied by the caller.
• Use a proposal-and-acceptance flow when a new obligation needs another party's consent.
• Check whether archival, delegation, or a nonconsuming choice lets one party remove rights or repeat authority unexpectedly.

The SCAS guide to common Daml vulnerabilities explains caller-controlled authorization and unsafe delegation. For bilateral consent, use Digital Asset's Propose and Accept pattern.

• Remember that an observer sees the complete contract payload, not selected fields.
• Trace every nested fetch, exercise, and create to identify transaction views and unintended divulgence.
• Split private terms, public status, and audit data into separate contracts when their audiences differ.
• Avoid contract keys that reveal sensitive relationships or business identifiers to parties that can query them.
• Test visibility as each real party, including parties that should see only one part of a composed transaction.

The official Canton privacy model covers observers, divulgence, transaction views, timing leakage, and common privacy mistakes. The EVM-to-Canton guide also explains why public-chain privacy assumptions do not transfer cleanly to Canton.

• Reject zero, negative, oversized, duplicate, and self-dealing inputs at the point where they enter the workflow.
• Define units and rounding rules for prices, fees, rates, shares, and token quantities.
• Test conservation across mint, burn, split, merge, transfer, redemption, and settlement operations.
• Make one-time rights consuming and verify that retries or repeated exercises cannot create value twice.
• Test concurrent submissions and contract-key conflicts against the intended economic outcome.

Incorrect economic models often compile successfully. They fail through rounding, repeatable redemption, invalid states, or races. SCAS provides worked examples in Writing Correct Daml Contracts on Canton.

• Do not assume AI understands the business agreement behind a template.
• Give every AI-generated change a named human owner.
• Review every generated signatory, observer, controller, ensure, and nonconsuming line.
• Look for made-up APIs, outdated Daml syntax, and code that only appears correct.
• Check whether AI added a caller-controlled party or a broad observer list.
• Check whether AI changed a consuming choice into a repeatable choice.
• Do not paste private contracts, credentials, customer data, or audit findings into unapproved AI tools.
• Require tests written from the business rules, not tests that only confirm the generated implementation.
• Use AI to support review, never as the final reviewer.

Anthropic's coding security guidance recommends reviewing suggested commands and verifying changes to critical files. These controls matter even more when generated code defines ledger authority.

• Add an unhappy-path test for every authority rule by submitting as the wrong party.
• Test privacy with non-observers and partially informed parties, not only administrators.
• Test economic boundaries such as zero, maximum, rounding, duplicate, and repeated operations.
• Test concurrent submissions, retries, and exact deadline boundaries.
• Test package upgrades with old and new contracts together before production rollout.

Digital Asset's Daml Script testing guide shows how to test expected failures with submitMustFail.