Proposing Daml Package Analyzer
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
