Update 2026-03-Certora-daml_package_analyzer_proposal .md

Development Fund Proposal

Field	Details
Author	jordan-s
Organization	Certora
RFP	N/A
Champion	Not recorded
Total Funding Request	2,010,000 CC
Project Duration	5 months
Status	Approved
PR	#130
Created	2026-03-19
Approved	2026-04-01

---

Abstract

We propose a lightweight static analysis tool that inspects a Daml project to compute and present information about cross-package interactions in a developer-friendly way. Unexpected references across packages can increase the risk of misuse of sensitive functionality and broaden the attack surface. Being able to precisely compute the dependencies gives users a way to inspect it statically and redesign the system if needed.

---

Specification

1. Objective

As it stands today, Daml security researchers, developers, and node operators who vet packages must manually analyze packages used in a Daml project to understand how they might interact. This leads to longer security reviews and development time. For example, if package A can exercise choices or create templates from package B , it might give A control over money movement, approvals, etc. which may be undesirable. Examples of behavior that the tool should prevent:

1. A .dalf cannot be used to steal assets
2. A .dalf does not negatively affect any app from another provider

We propose a tool to statically analyze a Daml project and produce a visual output that will show the various ways packages can interact with each other. The output will also be available as a JSON file so that other tools can leverage its output, similar to the graphviz tool.

The goal is to help auditors and other users analyze a .dalf and precisely identify all places in the source code where a package has the authority to call into another package, including the relevant source file and line number for each interaction. This analysis will be for the entire dependency tree or to a pre-specified depth. This will help the auditor focus on the most security critical areas that may inadvertently delegate authority.

2. Implementation Mechanics

The input to the tool will be a project’s compiled .dar which contains the main package, its source code, and its dependencies. To a first approximation, the tool will:

1. Inspect the .dar file and identify all the packages used
2. For every package, identify every location where the code exercises choices defined on a template or interface from another package.
3. Additionally, report cross-package template usage as a sign of dependency.
4. For each such interaction, report:

• the source file path
• the exact line number (and column range where available)
• the calling package and package version
• the referenced package/interface and the version
• the template/interface and choice involved
• If it is a non-consuming or consuming choice

5. Additionally, report where there are templates that implement specific interfaces
6. Aggregate the results and present the information in both a structured machine-readable JSON form and an intuitive graph-like visualization. The structured output will allow auditors to navigate directly from an interaction to the relevant source location.

3. Architectural Alignment

The tool’s design aligns well with Canton’s architecture because it operates directly at the package level. The tool will use the same compiled Daml artifact that is deployed. The analysis will be done statically, and not require executing the actual code. It should be easy to integrate with existing build systems and CI of the project being analyzed.

Additionally, we intend to integrate the tool into dpm, as an alpha feature, subject to coordination and feasibility. This is not a milestone or requirement.

4. Open-Source

The tool will be released as open-source software under the Apache 2.0 license, making it freely available to the entire Canton ecosystem.

5. Backward Compatibility

The tool should not affect existing Daml applications or their runtime behavior. It will not modify code. It is intended to only analyze code and produce an output for developers and security researchers to inspect.

---

Milestones and Deliverables

Milestone 1: Core Analysis Engine

Estimated Delivery: 2 months from start

This milestone delivers the core functionality of the tool. It will accept a .dar file as input and produce a structured output describing all detected cross-package interactions, including choice exercises and template usage.

For each reported interaction, the output will include the relevant source file and line number where the interaction occurs, allowing auditors and developers to immediately inspect the corresponding code.

The output format will be documented and stable, and the implementation will be validated against representative Daml projects to ensure correctness and consistency. It will include a machine readable output in JSON format and a visual representation of the calls.

Example for a single output in JSON format:

Example Output for Visual Diagram:

Milestone 2: Initial Adoption & Ecosystem Validation

Estimated Delivery: 1 month after milestone 1 completes

This milestone focuses on validating the tool in real-world Canton deployments and ensuring its usability across diverse applications. Certora will:

• Run the tool on Splice
• Collaborate with the Canton Foundation to onboard 5 voting member companies or representative Canton deployments
• Support these teams in running the tool on their codebases and interpreting the results from a security perspective
• Collect feedback and refine the tool’s output and usability

Deliverables:

• Evidence of successful runs across participating projects
• Improvements based on real-world usage
• Documentation incorporating best practices from these engagements
• Continued support for CI integration

The goal of this milestone is to demonstrate that the tool is not only technically correct, but also practically useful and adopted within the Canton ecosystem.

Milestone 3: Expanded Adoption

Estimated Delivery: 1 month after milestone 2 completes

• Run the tool on 5 production-scale or representative Canton deployments
• Collaborate with the Canton Foundation t o facilitate introductions to additional member companies
• Support these teams in onboarding and usage
• Collect feedback and incorporate improvementsUpdated documentation reflecting lessons learned

Milestone 4: Broad Ecosystem Adoption

Estimated Delivery: 1 month after milestone 3 completes

• Run the tool on 5 additional production-scale or representative Canton deployments
• Collaborate with the Canton Foundation to facilitate introductions to additional member companies
• Support these teams in onboarding and usage
• Collect feedback and incorporate improvements
• Updated documentation reflecting lessons learned and best practices

Milestone Timeline

Milestones are sequential, each month begins after the prior milestone is complete and accepted.

Milestone	Duration	Start	End
M1: Core Analysis Engine	2 months	7th April 2026	6th June 2026
M2: Initial Adoption	1 month	7th June 2026	6th July 2026
M3: Expanded Adoption	1 month	7th July 2026	6th August 2026
M4: Broad Ecosystem Adoption	1 month	7th August 2026	6th September 2026

Ecosystem Collaboration

Successful completion of the adoption milestone depends on collaboration with the Canton Foundation.

In particular, the Foundation’s support will be important for introducing Certora to relevant member companies, facilitating initial engagement and coordination and supporting adoption across the ecosystem.

Certora will lead all technical onboarding and analysis, while the Foundation’s involvement will help ensure broad and effective adoption.

---

Acceptance Criteria

Milestone 1: Core Analysis Engine

• A working CLI tool is delivered that accepts a .dar file as inputs and identifies their dependencies. The CLI can run on Linux, MacOS, and Windows.
• The tool detects and reports cross-package interactions:
  • Exercising choices on templates defined in another package
  • Usage of templates defined in another package
• For each reported interaction, the tool includes:
  • source file path
  • exact line number(s) of the interaction
  • the packages involved and its version
  • the referenced template, its version, and the choice where applicable
  • If it is a non-consuming or consuming choice
• Both outputs are available:
• Structured JSON output
• Visual representation of package interactions
• Documentation is provided explaining how to run the tool and interpret its output.
• 3 voting member companies have reviewed the tool and accepted it.
• The tool is released as open-source under the Apache 2.0 license.

Milestone 2: Initial Adoption

• Run the tool on Splice
• 5 voting member companies or representative Canton deployments have run the tool on their codebases
• Certora has supported these teams in onboarding and usage
• Each participating company expresses interest in continuing to use the tool and endorses release of this milestone
• Feedback from participating teams is collected and incorporated into the tool
• The tool demonstrates usability across multiple real-world projects
• Updated documentation reflects lessons learned and best practices

Milestone 3: Expanded Adoption

• The tool is run on 5 production-scale or representative Canton deployment
• Certora has supported these teams in onboarding and usage
• Each participating company expresses interest in continuing to use the tool and endorses release of this milestone
• Feedback from participating teams is collected and incorporated into the tool
• The tool demonstrates usability across multiple real-world projects
• Updated documentation reflects lessons learned and best practices

Milestone 4: Broad Ecosystem Adoption

• The tool is run on 5 additional production-scale or representative Canton deployment
• Certora has supported these teams in onboarding and usage
• Each participating company expresses interest in continuing to use the tool and endorses release of this milestone
• Feedback from participating teams is collected and incorporated into the tool
• The tool demonstrates usability across multiple real-world projects
• Updated documentation reflects lessons learned and best practices

---

Funding

Total funding request: 2,010,000 Canton Coin

Payment Breakdown by Milestone

• Milestone 1 (Core Analysis Engine): 335,000 Canton Coin
  Duration: 2 months
  Potential Start Date: 7th April 2026
  Finishing Date: 6th June 2026

• Milestone 2 (Initial Adoption): 335,000 Canton Coin
  Duration: 1 month
  Potential Start Date: 7th June 2026
  Finishing Date: 6th July 2026

• Milestone 3 (Expanded Adoption): 670,000 Canton Coin
  Duration: 1 month
  Potential Start Date: 7th July 2026
  Finishing Date: 6th August 2026

• Milestone 4 (Broad Ecosystem Adoption): 670,000 Canton Coin
  Duration: 1 monthPotential Start Date: 7th August 2026
  Finishing Date: 6th September 2026

---

Co-Marketing

Upon release, we will coordinate with the Foundation on announcement and communication. This will include a technical blog post explaining the security implications of cross-package interactions, as well as example analyses demonstrating how the tool can be used by developers and auditors. To the extent possible, it will highlight any security design choices made in Daml and Canton that enable improve the ability of such tools to improve users’ security posture. The goal is to ensure the tool is both understood and adopted within the ecosystem, as well as educate on any security benefits of Daml and Canton.

---

Motivation

This project improves both security and developer efficiency in the Canton ecosystem. By making the process of analyzing the packages relationships automatic, the time required for audits is reduced and lowers the likelihood of subtle but critical security issues. It is especially relevant for teams working with third-party packages or building multi-party applications, where unintended authority delegation is harder to detect.

---

Rationale

A static analysis approach at the .dar level is the most reliable way to capture real system behavior, since it reflects the exact artifacts that are deployed and what they are allowed to do. Compared to runtime monitoring or manual review, this approach is faster, more consistent, and easier to integrate into existing workflows.

Other approaches, such as analyzing source code or relying solely on audits, either miss important details or do not scale well. By contrast, this design provides deterministic results with minimal overhead, making it a practical and effective solution for improving security across the ecosystem.