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.Over-disclosure only matters on a shared ledger, where a leak can be worse than an authorization slip. No EVM tool 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.We look for divulgence, usually through a fetch, and for observer sets wider than the workflow 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.A consuming exercise archives rather than queues: one shared contract fails under ordinary load — fine with one user, broken with fifty.
- 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.
Built for how DAML actually fails
Smart-contract tooling grew up around the EVM, and DAML fails in different places. A DAML package is easy to ship reviewed only by the team that wrote it; this gives it an independent review in minutes, at the same price as an EVM audit. No third-party analyzer is run on a DAML package, so every finding comes from the review and says what backs it.EVM tooling misses how DAML fails. Get an independent review in minutes, at EVM prices.
Our review reads your package for what fails in DAML:
- authorization — who can act
- privacy — who can see
- contention and liveness — who can proceed
- interfaces and upgrades — what changes underneath you
The review is written for DAML, not borrowed from an EVM audit, because the two languages fail in completely different places.Written for DAML, not borrowed from EVM.
Your package must build before the review starts, so every finding is against code that actually compiles. Each finding then tells you whether it is proven or reasoned, so you always know how much weight it carries.Your package must build first, so the review covers real code. Each finding says what backs it.
Every potential finding is verified exactly as in an EVM audit. Nothing reaches your report on a single opinion.
Proven, not argued
An authorization finding is proven by execution: the exploit is attempted as the party who should not be able to act.
A command that goes through when it should have been rejected is the proof. Not an inference — the outcome itself.
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.Only authorization is mechanically verifiable, and we say so. Your report marks, per finding, what can and cannot be reproduced.
Same checks, same price, same remediation
DAML is a skill on the same rails, not a separate product.
- The same verification, so no finding rests on a single opinion.
- 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.
| In the report | EVM audit | DAML audit |
|---|---|---|
| Access map | Privileged-access map | Authorization topology — signatory, observer and choice controller per template |
| Emergency controls | Pause, upgrade, timelock review | No section — DAML has no deployed code to pause or upgrade |
Built for Daml 3, not a toy subset
- Supports Daml SDK 3.4 — the version you are actually shipping on, including interfaces and smart contract upgrades, which the older security literature predates entirely.Supports Daml SDK 3.4 — the version you ship, interfaces and upgrades included.
- 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 reported as findings where they matter, instead of failing your package at the door.Daml 3.4 rejects some valid packages on upgrade-safety grounds. We report them where they matter.
- 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.Folders are kept, so a multi-module package resolves as it does in your repo and workflows are reviewed together.
- Upload one module or a hundred, or point it at a public GitHub repo — the whole package enters the review as one source.
Contract keys were removed from the language in Daml 3.x, so a package still using
key/maintainer targets 2.x and will not build here.
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 review and its own finding category, not a footnote.A contract can run under a newer package version, so upgrade safety is its own risk axis and finding category.
The dangerous change is not the one that fails. A changed
signatory, observer or ensure expression is not a
deployment error — it quietly alters who is bound by, and who can see, contracts that are
already live on the ledger. Nothing in your pipeline announces it.The dangerous change does not fail: a changed signatory, observer or ensure expression silently changes contracts already live.
Give us the version you are replacing and we check the two together — the answer your own deployment will give, before you deploy.Upload the version you are replacing and we check both — before your deployment does.
- 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.It catches new fields that are not Optional, changed or removed fields, moved controllers or return types, and silent expression changes. - 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.Interfaces too: a choice or view wider than its template hides the real authorization surface.
- Every finding says whether it is proven or reasoned, so an upgrade risk never arrives dressed as something we watched happen.
Pick the DAML skill and this is what runs
Same workspace, same price, same multi-round engagement. Upload a package or point us at a public GitHub repo.