Audit and design acknowledgements

Decentralization Manager security architecture

What this audit covers

Quantstamp reviewed the Daml governance packages that implement threshold voting and selected governed actions for Decentralization Manager. The report does not certify the complete application or a production deployment.

Record	Repository evidence
Auditor	Quantstamp
Review period	20 May 2026 to 22 May 2026
Report and fix-review date	22 May 2026
Language	Daml
Methods	Architecture review, unit testing, functional testing, computer-aided verification, and manual review
Source revision on the report front page	c3f578b67848441c1782ce0198e46ae1fef121bb
Revision shown in the report scope section	80b502d01b214f8c22a7d6f52b967274043aba2e

The report front page identifies c3f578b as the source revision, while the scope section labels included and excluded files with 80b502d. Review both revision references when assessing the audited scope and fix-review coverage.

Included and excluded components

The report lists these included paths:

• daml/governance-core/
• daml/governance-action-v0/
• daml/governance-token-custody/
• daml/governance-utility-onboarding/

The report explicitly excludes daml/dars/*.

The report does not list the Rust backend, web interface, identity-provider configuration, database, deployment manifests, container images, infrastructure, peer protocol, or production operations as audited components. The appendix includes Rust and Daml test output, but test output does not expand the stated audit scope.

An audit applies only to its stated files and revisions. It does not cover later changes, local configuration, dependencies, deployment controls, host security, or operator procedures unless the report explicitly includes them.

Results

The executive summary records five findings:

• No high-severity findings.
• No medium-severity findings.
• Three low-severity findings, all recorded as fixed.
• Two informational findings, one recorded as fixed and one as acknowledged.

The report also records five auditor suggestions. S1, S2, and S5 are recorded as fixed. S3 and S4 are recorded as acknowledged.

The fix-review update states that the team addressed the reported issues and that the fixes aligned with the recommendations. It also identifies DLC-5, S3, and S4 as deliberate design acknowledgements rather than code changes.

Finding index

ID	Summary	Severity	Report status	Referenced change
DLC-1	Permissionless creation of unarchivable confirmations	Low	Fixed	0edb57f
DLC-2	Suboptimal InstrumentID setup	Low	Fixed	8733d06
DLC-3	Governance execution audit trail lacks sufficient proposal context	Low	Summary table: Fixed
Finding detail: client-marked Mitigated	d2309cf
DLC-4	Expired confirmations can still be consumed directly	Informational	Fixed	59864eb
DLC-5	GovernanceRules permits 1-of-1 configurations	Informational	Acknowledged	Operational control, not a code change

The report summary marks DLC-3 as fixed, while its detailed update says the client marked it mitigated. Read the summary and detailed finding together when evaluating its status.

Auditor suggestions

ID	Summary	Status	Referenced change or treatment
S1	Improve on-ledger validation	Fixed	f3aa5af
S2	Clarify the self-confirmation expiry choice name	Fixed	688c43f
S3	Governable actions cannot return typed execution artifacts	Acknowledged	Handled through design and documentation
S4	Missing generic archive actions	Acknowledged	Use narrowly scoped actions when cleanup is required
S5	Minor code improvements	Fixed	9b5dba3

Design acknowledgements

1-of-1 governance configurations

GovernanceRules permits one member with a threshold of one. The repository acknowledgement says this supports bootstrap and development environments. A production deployment must transition to at least two members and a threshold of at least two before it goes live. Teams that require an enforced minimum must apply that rule through their deployment or admission process.

Execution artifacts

The Daml GovernableAction_Execute and executeImpl interfaces return Update (). They do not directly return typed artifacts created by the governed action. Downstream systems may need to inspect ledger events or reconstruct resulting state. The acknowledgement says a future HTTP delegation layer is intended to own the result shape outside the on-ledger interface.

Treat the delegation layer as planned work unless the supported release documentation states that it is available.

Archive actions

The implementation does not provide one generic governance action that can archive any contract signed by the governance party. The acknowledgement rejects that broad authority because one approved vote could archive unrelated contracts. The documented alternative is to add a dedicated, narrowly scoped GovernableAction when a specific cleanup capability is required.

Operational considerations from the report

The report identifies properties that operators and integrators must account for:

• A GovernanceExecutionResult records a governance outcome, but historical reconstruction may require the transaction graph.
• A change to actionConfirmationTimeout applies to new confirmations, not existing confirmations.
• Some governed actions require confirmers to perform off-ledger validation.
• Action inputs may become invalid between proposal and execution.
• Membership and threshold changes apply to actions already in progress. They may block an action that was executable or make a previously unsuccessful action executable.
• Governed token actions in the reviewed implementation pass empty requirements and credentials. The report says these actions support permissionless tokens only.
• Free-text descriptions and metadata can be supplied by the proposer. Confirmers must inspect structured fields rather than rely only on the description.
• The reviewed contracts do not provide an on-ledger emergency pause, partial-quorum revocation, or time-bounded delegation.

How to use the report

1. Identify the exact release, tag, image, and Daml packages you plan to run.
2. Compare them with the audited revisions and file signatures.
3. Read the scope, exclusions, findings, suggestions, and operational considerations.
4. Confirm which remediation commits are included in your release.
5. Apply the deployment, authentication, peer, backup, monitoring, and hardening guidance for the parts of the application outside this audit.
6. Review the design acknowledgements before approving a production configuration.

Report integrity and source links

• Quantstamp final report at the reviewed repository snapshot
• Design acknowledgements at the reviewed repository snapshot
• PDF SHA-256: 40f6bb26b91a92b5ba264b2e00bc2fbf438ea0b942315d7cbc4ea39a49c1d577
• Audited source revision from the report front page: c3f578b67848441c1782ce0198e46ae1fef121bb
• Scope-section revision: 80b502d01b214f8c22a7d6f52b967274043aba2e

Next step

👉 Place the report in context: Decentralization Manager security architecture.