SCAuditStudio

DAML Security

Lesson 01

Authority Model

Daml removes many low-level smart contract bugs, but it cannot rescue a weak authority model. Start by making consent, signatories, and choice control explicit.

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.

Choice Review
01choice Withdraw : ()02  with03    requestor : Party04    amount : Decimal05  controller requestor06  do07    pure ()
01choice Withdraw : ContractId Vault02  with03    amount : Decimal04  controller owner05  do06    assertMsg "Invalid amount" (amount > 0.0 && amount <= balance)07    create this with balance = balance - amount
Useful Links
Common Daml vulnerabilitiesPropose and Accept pattern
Lesson 02

Privacy Rules

On Canton, privacy is part of the application design, not a default outcome. You need to reason about who can see payloads, transaction structure, and inferred business data.

  • 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.

Privacy Split
01template TradeTerms02  with03    buyer : Party04    seller : Party05    privatePrice : Decimal06  where07    signatory buyer, seller08 09template TradeStatus10  with11    operator : Party12    viewers : [Party]13    status : Text14  where15    signatory operator16    observer viewers
Useful Links
Canton privacy modelEVM-to-Canton guide
Lesson 03

Economic Safety

Code that compiles can still leak value through replay, rounding, invalid state transitions, or missing conservation rules. Economic safety needs to be designed and tested directly.

  • 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.

Token Example
01template Token02  with03    issuer : Party04    owner : Party05    amount : Decimal06  where07    signatory issuer08    observer owner09    ensure amount > 0.010 11    choice Split : (ContractId Token, ContractId Token)12      with splitAmount : Decimal13      controller owner14      do15        assertMsg "Split must be positive" (splitAmount > 0.0)16        assertMsg "Split must be below balance" (splitAmount < amount)17        left <- create this with amount = splitAmount18        right <- create this with amount = amount - splitAmount19        pure (left, right)
Useful Links
Writing Correct Daml Contracts on Canton
Lesson 04

AI Risks

AI can accelerate development, but it does not understand the business agreement behind a workflow. Generated Daml should be reviewed with the same suspicion as third-party code.

  • 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.

Useful Links
Coding security guidance
Lesson 05

Workflow Tests

Most real failures appear at workflow boundaries: wrong parties, partial visibility, retries, concurrent submissions, package upgrades, and off-ledger application logic.

  • 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.

Simple unhappy-path test
01submitMustFail stranger do02  exerciseCmd vaultCid Withdraw with amount = 10.0
Useful Links
Daml Script testing guide
Lesson 06

Launch Checklist

Use this as a final review pass before launch, release approval, or internal sign-off.

  • [ ] Every party and role is documented.
  • [ ] Every signatory is necessary.
  • [ ] Every observer needs the full contract payload.
  • [ ] Every controller comes from trusted contract state.
  • [ ] Every multi-party obligation uses clear consent.
  • [ ] No party can remove another party's rights unexpectedly.
  • [ ] Sensitive data has been traced through the full transaction.
  • [ ] Private and public data are separated where needed.
  • [ ] Every permanent state rule is enforced with ensure.
  • [ ] Every numeric input has clear bounds and units.
  • [ ] Rounding and conservation rules are tested.
  • [ ] Every one-time action is consuming.
  • [ ] Contract keys and concurrent submissions are handled safely.
  • [ ] AI-generated code received full human review.
  • [ ] Wrong-party and partial-visibility tests exist.
  • [ ] Repeated, concurrent, and boundary cases are tested.
  • [ ] Application users map to minimum ledger rights.
  • [ ] Package upgrades and mixed versions are tested.
  • [ ] SCAS research and current Digital Asset documentation were reviewed.
  • [ ] Manual security review was completed before production.