Daml vs Solidity audits: 3 scope decisions before a security review

App Development
, , , ,
1

Hi all,

We published a piece on how scoping a Daml security review differs from scoping an EVM audit. Every audit starts with understanding how the application executes, manages state and authorizes actions, and on Canton each of those works differently. Here are the three decisions, in short:

1. Review Daml’s authorization model
In Solidity, access control lives in code, and the reviewer traces it through execution paths. In Daml, signatories, observers and controllers are declared in the template, and the protocol enforces them. They can’t be bypassed through API manipulation. So part of the access-control analysis moves into the template model.

template Contact
  with
    owner : Party
    party : Party
    address : Text
    telephone : Text
  where
    signatory owner
    observer party

    choice UpdateTelephone
      : ContractId Contact
      with
        newTelephone : Text
      controller owner
      do
        create this with
          telephone = newTelephone

A Daml Script test confirms that a party who isn’t the controller can’t exercise the choice:

submitMustFail party do
  exerciseCmd contactCid UpdateTelephone with
    newTelephone = "098 7654 321"newTelephone

2. Define the coverage model
Daml test coverage measures templates created and choices exercised. It isn’t EVM-style path coverage. In the article’s example, the report shows 3 of 3 templates created (100%) but 2 of 5 choices exercised (40%). The 40% means two of the five defined choices were tested, nothing more.

3. Pin the SDK and Daml-LF target
Feature availability changes between versions. In the article’s test, a template with contract keys failed to compile under SDK 3.4.11 and compiled under SDK 3.5.2 with --target=2.3. The documentation you rely on also has to match the runtime you’re reviewing.

Scoping checklist

  • Runtime: record the SDK version and Daml-LF target.
  • Authorization: identify signatories, observers and controllers.
  • Coverage: define what the test runner’s coverage figures measure.
  • Feature behavior: tie security claims to the relevant documentation and runtime version.
  • Testing methods: identify Daml and Canton methods separately from EVM techniques.
  • Initial assessment: use an automated review, such as the Hacken AI Auditor, to map the security surface.

The resulting scope should describe the Daml ledger model, the application’s contract behavior, its party authorization rules, and the runtime-specific properties that affect security.

Full article with the code and test output: