If you work in web3 security, your mental model of smart contract risk was almost certainly built on Solidity.
Reentrancy. Integer overflow. Access control failures. Flash loan attacks. These are the vulnerabilities that have defined the discipline and for good reason. They have collectively cost the industry billions.
But the blockchain infrastructure that institutional finance is building on doesn’t run Solidity. It runs Daml.
Canton Network, the blockchain that DTCC, Goldman Sachs, BNP Paribas, Citadel, Broadridge, and JPMorgan have chosen is powered by Daml, a purpose-built smart contract language developed by Digital Asset. And as over $8 trillion in tokenised assets flow through the network monthly, the security community needs to confront a straightforward reality: the tools, taxonomies, and threat models built for Solidity do not transfer cleanly to this environment.
This article is the first in CredShields’ Daml Security Decoded series. It covers what makes Daml architecturally distinct, how that changes the security surface, and why auditing Daml requires a fundamentally different methodology.
What is Daml?
Daml (Digital Asset Modeling Language) is an open-source smart contract language built on a typed functional core derived from Haskell. It was designed from the ground up with a specific mandate: to model real-world, multi-party financial and legal workflows in a way that is private by default, authorisation-aware by design, and composable across organisations.
Where Solidity was built to run on a transparent, permissionless execution environment, Daml was built for the opposite: regulated institutions that need precise control over who can see what, who can act on what, and under what legal conditions.
Daml operates on a “privacy by default” model. Nothing is broadcast publicly. Instead, contract details are strictly opt-in, visible only to the parties explicitly authorised by the contract’s own logic.
Unlike general-purpose smart contract languages like Solidity, Daml was built from the ground up with privacy, authorisation, and composability as core features. Daml’s type system catches many errors at compile time rather than runtime crucial for financial applications where bugs can be extremely costly. Every Daml contract explicitly defines who can do what. The language enforces these rules automatically, preventing unauthorised actions.
This design philosophy has significant implications for security both in the vulnerabilities it eliminates and the new ones it introduces.
The Authorisation Model
In Solidity, access control is something developers implement. Modifiers, role-based access patterns, require statements, these are conventions layered onto a language that doesn’t enforce them. A developer can implement them well or badly. The security audit has to verify that the implementation is correct.
In Daml, authorisation is part of the language itself.
Daml’s privacy model is based on the principle of need-to-know: Signatories are parties who must authorise the creation of a contract and always see it. Observers are parties who can see the contract but didn’t need to authorise it. Controllers are parties who can exercise specific choices on a contract. When a transaction occurs, only the parties who are signatories, observers, or controllers of the affected contracts learn about it. Other parties on the network see nothing.
Daml defines who is entitled to see, and who is authorised to change any given contract. Canton enforces these visibility and authorisation rules, and ensures transaction integrity with very high levels of privacy, even in the presence of malicious actors.
This shifts the security question fundamentally.
In Solidity, the auditor asks: did the developer implement access control correctly?
In Daml, the auditor asks: is the authorisation model itself correctly designed? Are the right parties designated as signatories? Are controller assignments logically sound? Are observer disclosures appropriate given the financial and legal intent of the contract?
These are different questions. They require a different lens.
Additional Read: 5 Common Daml Authorization Mistakes
Sub-Transaction Privacy: The Feature That Changes the Audit Surface
Canton’s most distinctive capability and the one that makes it viable for institutional finance is sub-transaction privacy.
The Canton protocol supports sub-transaction privacy, meaning that parties can only see the part of a transaction that specifically applies to them. It is built around the principle of data minimisation and enables adhering to the right to be forgotten regulations.
In practice, this means that when a complex multi-party transaction executes on Canton a Treasury settlement, a repo trade, a collateral movement each participant sees only the legs of that transaction that involve them. The bank sees its side of the trade. The custodian sees the settlement instruction. The regulator can be given observer access without seeing commercially sensitive positions.
Transaction views are encrypted per-recipient, and the sequencer and mediator coordinate consensus without ever seeing transaction content.
This is the architecture that allows Goldman Sachs and its counterparties to settle on a shared ledger without broadcasting their positions to the world. It solves the fundamental problem that has prevented institutional adoption of public blockchains: you cannot have a trading house’s margin and collateral movements visible to competitors.
For security, this creates a distinct audit surface that does not exist in Solidity-based environments. The auditor must validate not just that the contract executes correctly, but that the privacy model holds that disclosure boundaries are correctly defined at the contract level, that no unintended disclosure paths exist, and that the model is resistant to adversarial circumvention.
A flawed disclosure boundary in a DeFi protocol is a vulnerability. A flawed disclosure boundary in a system settling institutional Treasury positions is a systemic failure with potential market-wide consequences.
The Execution Model: What Daml Eliminates
One of the more striking aspects of auditing Daml is what you don’t have to look for.
Reentrancy cannot occur because the execution model does not allow arbitrary external calls within a transaction. MEV extraction is not possible because there is no public mempool and the sequencer only sees encrypted payloads. The sequencer cannot reorder based on content it cannot read. The oracle-manipulation surface is narrower than on public blockchains: the privacy model limits attacker visibility into contract state, and no flash loan facility currently exists in the Canton ecosystem to amplify capital-free attacks.
Entire categories of Solidity vulnerability simply do not apply. This is not a minor point reentrancy, front-running, and flash loan attacks represent a significant proportion of total losses in Web3 security history. Their absence in Daml reflects deliberate architectural choices rather than luck.
Daml is based on functional programming principles, similar to Haskell. This makes contracts easier to reason about and test, reducing the risk of bugs that could lead to financial losses.
The contract model itself reinforces this. Contracts are immutable records that represent agreements or assets. Choices are actions that can be performed on contracts by authorised parties. When a choice is exercised, the original contract is archived and new contracts may be created. This creates an append-only ledger where the current state is the set of all active non-archived contracts.
There is no shared mutable state in the way Solidity developers encounter it. The patterns that enable reentrancy do not exist.
What Daml Introduces: A Different Class of Bugs
Eliminating one class of vulnerability does not mean eliminating vulnerability. It means the bugs are different.
This does not mean that Daml contracts are free of bugs. It means that the bugs are different from those found in Solidity contracts.
The security risks specific to Daml fall into several distinct categories:
Authorisation logic errors
Because authorisation is designed at the contract level rather than implemented in code, errors in who is designated as signatory, observer, or controller can result in incorrect access grants that are structurally correct from the language’s perspective but commercially or legally wrong. These are subtle and do not produce compile-time errors.
Disclosure boundary failures
The privacy model is as strong as the contract logic that defines it. Incorrectly specified observer lists, unintended disclosure through interface usage, or flawed privacy propagation in complex multi-party workflows can expose data to parties who should not see it. In a financial context, this is a critical failure.
Workflow logic errors
Daml contracts model real financial and legal obligations. A contract can execute perfectly at the language level while misrepresenting the intended business workflow: wrong settlement amounts, incorrect sequencing of obligations, improper archival logic. These require understanding the financial intent, not just the code.
Interface misuse
Daml’s interface system allows composability across applications, a powerful feature that introduces a surface for incorrectly specified contracts to interact with interfaces in ways their authors did not intend.
Choice controller misconfiguration
Incorrectly assigning which parties can exercise which choices on a contract can allow actions by parties who should not be able to perform them, or prevent actions by parties who should.
Each of these requires an audit methodology built specifically for Daml’s model not adapted from a Solidity checklist.
The Compliance Surface
Daml deployments in institutional settings operate within a compliance environment that has no equivalent in standard Web3 security.
Domain-specific languages such as Daml embed regulatory constraints directly into the syntax and semantics of smart contracts, enforcing policies such as transaction limits, audit trails, and GDPR-compliant access controls, supporting adherence to standards such as MiFID II.
This means a complete audit of a Canton deployment must extend beyond the on-chain contract logic to cover the regulatory and operational framework the contracts operate within. How does the deployment handle regulatory observer access? Does the privacy model align with GDPR data minimisation requirements? Are audit trails correctly structured for the applicable regulatory standard? How does the contract logic interact with off-chain systems and counterparty agreements?
These are questions that a Solidity auditor, however skilled, is not positioned to answer without deep familiarity with both the Daml environment and the institutional compliance context.
Why This Matters Now
The stakes in Daml security are categorically different from standard Web3 security not because the language is more dangerous, but because of what it is being used for.
A vulnerability in a DeFi protocol affects the assets deposited in that protocol. A vulnerability in a Daml-based system settling Goldman Sachs’ Treasury positions, DTCC’s clearing workflows, or institutional repo trades affects the infrastructure of financial markets.
The security of cross-organisation distributed applications critically depends on proper authorisation. Inadequate authorisation features in languages used in existing smart contract platforms resulted in several high-profile incidents.
Daml was built partly in response to those incidents. But building a more secure language does not guarantee secure contracts. It shifts the locus of risk from language-level exploits to design-level errors and design-level errors in institutional financial infrastructure are precisely the errors that require experienced, specialised audit to catch.
That is the security problem CredShields is built to solve.
What a Daml Security Audit Involves
A rigorous Daml smart contract audit covers three distinct layers:
The authorisation model verification that signatory, observer, and controller designations correctly reflect the intended legal and financial relationships. This is the layer most unique to Daml and most frequently overlooked by teams applying standard audit approaches.
The privacy model validation that disclosure boundaries are correctly defined, enforced, and resistant to circumvention across all contract interactions and workflows. This includes examining interface usage, multi-party workflow disclosure propagation, and observer list correctness.
The compliance and business logic surface review of whether the contract logic correctly models the intended financial and legal obligations, and how it connects to the broader regulatory and operational environment the deployment sits within.
The next article in this series will go deeper on the specific vulnerability classes that appear in Daml contracts with technical detail on where they arise and what they look like in practice.
Conclusion
Daml is a more principled smart contract language than Solidity in many important respects. It eliminates entire categories of vulnerability by design. It makes authorisation and privacy first-class concerns rather than implementation choices.
But it is not a safe language in the sense of eliminating security risk. It is a language where the risks are different, more subtle, and more consequential because they manifest in the design of financial and legal logic operating on institutional-scale assets.
Understanding those risks requires practitioners who have built their expertise in this environment from first principles. That is what CredShields is here to provide.
CredShields is the official Audit Partner of the Canton Network, bringing smart contract audits, AI-powered risk detection, and continuous monitoring to institutional blockchain deployments.