A DAML audit is not an EVM audit
with the names changed

You cannot forget an access-control check

The ledger computes authority from the parties on the contracts in a transaction and rejects an under-authorized submission before any code runs. There is no onlyOwner to leave off, and no modifier to forget. That entire bug class is gone.

What replaces it is harder to see: authority wired to the wrong party, which the ledger then enforces faithfully, forever, without ever erroring. Nothing fails. The workflow runs exactly as written, for the wrong person.

• A signatory consented and is bound by the contract. An observer can see it and agreed to nothing. An obligation on an observer is an agreement nobody made — visibility is not agreement, and treating it as though it were is a live bug class.
• Choices are consuming by default, so an explicit nonconsuming on a single-use right is a replay bug wearing a deliberate-looking annotation.
• A controller taken from a choice argument rather than from the contract lets the submitter name their own authority.

Who can see, and who can proceed

Privacy is the signature risk class here

A public chain discloses everything by construction, so over-disclosure is only a defect on a shared ledger — where leaking to the wrong participant is frequently worse than an authorization slip. There is no EVM analogue to import, and no EVM tool that looks for it.

• We look for divulgence — a party learning the contents of a contract they are not a stakeholder of, typically through a fetch — and for observer sets wider than the workflow actually needs.
• Divulged data cannot be un-disclosed afterwards. This is the one class where the harm is complete the moment the contract is created.

Contention is a correctness property, not an operational one

A consuming exercise archives rather than queues. So one shared contract that every participant must consume fails under ordinary honest load, with no attacker involved anywhere. That is the defect that works perfectly with one user and collapses with fifty — and it will not show up in your tests.

• Alongside it, liveness: a workflow nobody can advance, or a choice controlled by a party who cannot even see the contract they are meant to act on.

Five lenses for a language the tools forgot

There is no Slither for DAML. No Mythril, no Echidna, no Solhint — no static analyzer exists for the language at all, which is why most DAML packages go to production reviewed by nobody but the team that wrote them. That gap is the reason this exists.

Five independent lenses read your package concurrently, each with its own rulebook:

• authorization — who can act
• privacy — who can see
• contention and liveness — who can proceed
• two gap hunters, one over authorization × privacy, one over interfaces, upgrades and first principles

They run across three different AI model families, and authorization and privacy are deliberately routed away from the family that holds two jury seats and the devil's advocate — so the panel that raises a finding is never the only voice confirming it. Five lenses either way, but not the same five an EVM audit runs, because the two languages fail in completely different places.

Every candidate faces the same three-juror panel and devil's advocate as an EVM audit. Nothing reaches your report on one model's opinion.

The ledger's own answer is the evidence

An authorization finding is replayed against a real, disposable Canton ledger — not a fork, and not a simulation. The exploit is submitted as the party who should not be able to act.

Only the authorization axis is mechanically verifiable, and we say so rather than implying more. A privacy finding has no attack sequence — the harm is disclosure, complete at creation. A liveness finding may have no attacker at all. Your report says which is which per finding, instead of sending you off to reproduce something that cannot be reproduced.

Same jury, same price, same remediation

DAML is a skill on the same rails, not a separate product.

• The same three-juror panel — skeptic, attacker, economist — and the same devil's advocate that can still demote a verdict the jury confirmed.
• Priced identically: per contract, per round, with the same re-check pricing.
• The same multi-round remediation engagement. Mark a finding fixed or accept the risk with a reason, and both are checked rather than taken on your word.
• Reports in Markdown, PDF and DOCX, signed the same way.

Built for Daml 3, not a toy subset

• Compiled with Daml SDK 3.4 — the version you are actually shipping on, including interfaces and smart contract upgrades, which the older security literature predates entirely.
• Daml.Script is supplied from the SDK, so your test and setup modules compile as they are — nothing to strip out or comment away before you upload.
• Daml 3.4 rejects some perfectly valid packages on upgrade-safety grounds — an interface defined and implemented together, for instance. Those are relaxed for the audit and reported as findings where they matter, instead of failing your package at the door.
• Directory structure is preserved, so a multi-module package resolves exactly as it does in your repo and cross-template workflows are reviewed together rather than file by file.
• Upload one module or a hundred, or point it at a public GitHub repo — the whole package enters the review as one source.

What your next version would break

Daml 3 packages can be upgraded, and a contract created under one version can be exercised under another. Almost every piece of smart-contract security thinking predates that idea entirely — so upgrade safety is a whole risk axis here, with its own lens and its own finding category, not a footnote.

Give us the version you are replacing and the compiler itself checks the two — the same check the participant runs when you upload the DAR. Not our opinion about your change: the answer your own deployment will give.

• It catches what an upgrade requires: fields added without being Optional, changed field types or ordering, removed fields, choices whose controller or return type moved — and the expression changes that pass silently.
• Interfaces get the same treatment. An interface choice or view wider than the template implementing it means the real authorization surface is not visible from the template alone.
• Every finding says whether it is proven or reasoned, so an upgrade risk never arrives dressed as something we watched happen.