CCPEDIAby Unity Nodes
Proposals/canton-foundation/canton-dev-fund/#130GitHub ↗
#130Approved Pull Request2.0M CC requested

Proposing Daml Package Analyzer

jordan-s-certora23-03-2026Last activity 5mo ago
daml-toolingApproved

Development Fund Proposal: Daml Package Analyzer

Author: Certora
Status: Draft
Created: 2026-03-19

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:

  • Inspect the .dar file and identify all the packages used
  • For every package, identify every location where the code exercises choices defined on a template or interface from another package.
  • Additionally, report cross-package template usage as a sign of dependency.
  • For each such interaction, report:
  1. the source file path
  2. the exact line number (and column range where available)
  3. the calling package and package version
  4. the referenced package/interface and the version
  5. the template/interface and choice involved
  6. If it is a non-consuming or consuming choice
  • Additionally, report where there are templates that implement specific interfaces
  • 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.

In addition, the tool will be added to dpm, to make the usage of the tool even easier for Daml engineers.

4. 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

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.

Milestone 2,3 and 4 : Adoption & Ecosystem Validation

Estimated Delivery: 1 month each

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 15 member companies or representative Canton deployment
  • 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.

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.

Adoption & Ecosystem Validation - Milestones 2, 3 and 4

Milestone 2

  • Run the tool on Splice
  • 5 Canton Foundation member companies have run the tool on their codebases
  • Certora has supported these teams in onboarding and usage
  • 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:

  • The tool is run on 5 production-scale or representative Canton deployment
  • Certora has supported these teams in onboarding and usage
  • 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:

  • The tool is run on 5 additional production-scale or representative Canton deployment
  • Certora has supported these teams in onboarding and usage
  • 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: 30th March 2026
    Finishing Date: 31th May 2026

  • Milestone 2 (Adoption & Ecosystem Validation): 335,000 Canton Coin
    Duration: 1 months
    Potential Start Date: 1st April 2026
    Finishing Date: 30th April 2026

  • Milestone 2 (Adoption & Ecosystem Validation): 670,000 Canton Coin
    Duration: 1 months
    Potential Start Date: 1st May 2026
    Finishing Date: 31st May 2026

  • Milestone 2 (Adoption & Ecosystem Validation): 670,000 Canton Coin
    Duration: 1 months
    Potential Start Date: 1st June 2026
    Finishing Date: 30th June 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.

← Back to Proposals