Development Fund Proposal: Canton Application Metadata and Deployment Standardization
| Field | Value |
|---|
| Author | Semyon Protas, Yury Korzun (PixelPlex), David Richards (Digital Asset) |
| Org | PixelPlex & Digital Asset |
| Status | Draft |
| Created | 2026-07-29 |
Abstract
Unlike monolithic layer-1 protocols where smart contract artifacts reside uniformly on-chain, the Canton Network requires node operators to independently ingest and host Daml Archive (DAR) packages to support decentralized applications (dApps). This structural paradigm introduces a critical bottleneck for dApp developers seeking node operator support. This proposal establishes a formalized, open standard (via CIP) and automated validation tooling to standardize how DAR metadata, security audits, and dependencies are published. Executed jointly by PixelPlex and Digital Asset, this initiative ensures ecosystem plurality by removing the operational friction of DAR deployment, culminating in verifiable adoption by 10 independent ecosystem partners.
RFP Alignment
RFP Category: Automated Application Management (Roadmap RFP #3, Protocol, Infrastructure, Scalability & Resilience)
This proposal responds directly to the RFP's call for "new Validator node tooling that integrates mechanisms for Daml application management including application discovery, review & security analysis; approval, installation and upgrading," and for enabling parties to "vet and/or unvet Daml packages... across all Validators with hosting rights." The metadata/audit schema and CI/CD validation suite proposed here are the concrete implementation of that vetting workflow.
Ecosystem need and adoption:
- Node operators / wallet providers get a machine-verifiable way to decide whether to host a third-party DAR, replacing today's manual, ad-hoc trust judgment (the exact failure mode described in Motivation & Rationale — the missing Splice dependency incident).
- dApp builders get a standard path to get their packages hosted without bespoke, one-off conversations with every operator.
- Security auditors get a reusable publication format so one audit can be trusted by many operators instead of being redone per relationship.
- Adoption is directly measured in Milestone 3: 10 independent entities (4 wallets, 4 dApps, 2 auditors) publishing conformant metadata is the proposal's built-in adoption gate, tying 40% of funding to real network-effect usage rather than just shipped code.
Motivation & Rationale
Why is this valuable:
In the Canton ecosystem, dApp builders do not deploy code to a neutral chain state; they rely on node operators to host their specific application DARs. Without a unified standard, this creates a severe bottleneck and forces fragmented, manual deployments for every new decentralized application and upgrade.
Recent ecosystem feedback solicited from 10 wallet providers who host validator nodes, carried out by Digital Asset, identified three critical deployment blockers:
- Security Liability: Operators highlight severe concerns regarding malicious code that could compromise validator environments or trick end-users into signing malicious transactions.
- Audit & Source Verification: Infrastructure providers mandate formal security assessments, but the artifact they are asked to host is compiled Daml-LF. Two opposite approaches close that gap. Verification by recompilation starts from publisher-provided sources, rebuilds them, and compares the result to the DAR; it answers "do these sources produce this artifact", and it answers nothing when the vendor ships binary-only, embeds
.daml files that no longer correspond to the code that will execute, or is simply not trusted to supply the sources at all. The other direction starts from the artifact that will actually execute and reconstructs reviewable Daml from its compiled Daml-LF. That direction needs no cooperation from the publisher, and it is the one this proposal implements.
- Dependency Management ("Version Hell"): Unverified version compatibility and manual DAR loading introduce unsustainable operational overhead. This architectural flaw materialized recently when an application DAR failed due to a missing, un-deployed Splice dependency on MainNet.
Digital Asset has already witnessed the manual process and difficulty that application builders have in trying to get their DARs hosted by wallet providers and node operators. It's important to resolve the issues highlighted here before more application builders experience the same difficulty on the Canton Network.
Why is this the right approach to deliver that value:
This approach is optimal for three operational reasons:
- Verifiable Risk Mitigation: Currently, node operators rely on manual, high-liability heuristics to determine if a third-party DAR is safe to host. By enforcing a standardized schema for dependencies and security audits, we give the option for node operators to move to more automated, programmatic CI/CD validation.
- Ecosystem Plurality & Anti-Rent-Seeking: Distributing the attestation of DAR safety across multiple independent ecosystem partners (wallets, auditors, and dApp builders) creates a verifiable web of trust.
- Compounding Public Goods: When an independent security firm or wallet provider publishes a DAR review to this open standard, the data becomes a reusable public good. Node operators instantly gain the cryptographic and operational confidence required to host the application, reducing developer friction and accelerating network-wide dApp deployment without compromising infrastructure security.
It is expected that once longer-standing, more trusted node operators post the DARs which they support, it will give newer node operators a starting set of applications which they are more likely to trust to host.
By enforcing that 40% of the capital is locked behind the verifiable use of the standard by 10 independent entities (Wallets, dApps, Auditors), the Foundation ensures it is buying a functioning network effect, not just a static repository of code.
Specification & Implementation
1. Objective
To design, implement, and drive adoption of a standardized metadata and DAR deployment architecture that allows any Canton network participant to programmatically verify and host dApp packages. A draft CIP has already been proposed and is receiving feedback, and PixelPlex has a working proof of concept for reconstructing reviewable Daml from compiled Daml-LF, covering Daml-LF 2.x and validated on 23 MainNet packages, which the Milestone 2 estimate extends into a production tool. The proposal covers the operator's half of the DAR lifecycle: independent inspection of the executable artifact, and the automation that places the accepted DAR onto a participant node.
2. Implementation Mechanics
The implementation of this proposal is bifurcated into two parallel technical and operational workstreams executed jointly by Digital Asset (DA) and PixelPlex:
- Standardization & Protocol Design: The metadata schema will be formalized via the CIP process, defining the strict data structures for dependencies, security audits (
audit-report.json), and build provenance (build-config.json). build-config.json is a reference field, not a build system: it records which external build-verification system can replay a package's build and the inputs required to do so. Implementing that verification is out of scope (see Scope Boundaries). This establishes the standardized Git repository architecture required for machine-readable package verification.
- Tooling & Automation Engineering: Develop the open-source CLI tooling and CI/CD GitHub Actions. This software will programmatically parse the standardized Git repositories, validate the application data, reconstruct reviewable Daml from a package's compiled Daml-LF so that an operator can inspect and verify a DAR without relying on publisher-supplied sources, and execute the DAR upload sequence to Canton validators via the Ledger API without manual intervention.
- Ecosystem Integration: Following the tooling release, the integration of this schema will be driven across a target matrix of 10 independent ecosystem partners (4 Wallets, 4 dApps, 2 Auditors) to establish the verifiable network effect.
3. Scope Boundaries
This proposal starts where an operator receives a compiled artifact. It does not build, and will not build:
- a package registry or package distribution ecosystem;
- a publisher or auditor identity registry, key-management service, or signing consortium;
- a package manager, or a replacement for existing package-management tooling;
- a reproducible-build verification service.
Where that infrastructure exists, this tooling consumes it rather than competing with it: audit-report.json references audits wherever they are published, signature verification resolves keys from the trust infrastructure an operator already uses instead of from a registry of ours, and build-config.json points at an external build-verification system. An operator already running such infrastructure gains an additional, independent check, not a second ecosystem to adopt.
What this proposal does build is the other side of the same interface: inspection of the executable Daml-LF artifact without reliance on a publisher-supplied source tree, and operator-side automation that validates dependencies and uploads the accepted DAR to a participant node over the Ledger API.
4. Architectural Alignment
This standardizes the interface for communicating DAR information between application developers, security auditors, and node infrastructure providers. It strictly enforces decentralization by providing open-source, non-proprietary tooling for DAR package verification.
5. Backward Compatibility
This proposal introduces a net-new metadata standard and therefore no backward compatibility is needed. The schema may need to be adjusted in the future as the network evolves. Any changes will ensure that older schemas remain backward compatible.
Milestones and Deliverables
Milestone 1: CIP Submission & Initial Automations MVP
Estimated Delivery: 1 month after proposal approval
Focus: Formalizing the standard and establishing the baseline tooling infrastructure.
- Deliverable 1.1 — Finalize the CIP: Submit the CIP to the
canton-foundation/cips repository.
- Acceptance Criterion: PR is open, passes initial formatting checks, and is actively under review by the CIP editorial team.
- Deliverable 1.2 — MVP of DAR uploading automations.
- Acceptance Criterion: A CLI tool/script is published to a public repository capable of parsing the proposed metadata schema and executing a successful Ledger API upload on a local Canton sandbox without errors.
Milestone 2: Automation Hardening & Release
Estimated Delivery: 6 months after the delivery of Milestone 1
Focus: Production-ready automation workflows for ecosystem consumption.
- Deliverable 2.1 — Production release of the automation suite.
- Acceptance Criterion: V1.0 of the automation tooling is released. Includes automated CI/CD GitHub Action templates that parse the DAR dependency tree and output a strict pass/fail validation against the CIP schema. The release additionally verifies a DAR that carries no embedded
.daml sources: the tooling reconstructs a buildable project from the package's Daml-LF, compiles it with a pinned damlc targeting the package's LF version, and emits a structural comparison against the original covering data types, template and choice signatures, top-level value types, and expression bodies after alpha-normalisation. Published over a corpus of at least 20 MainNet packages, with the per-package table and every residual difference listed.
Milestone 2 Engineering Estimate (CC price assumption: $0.15 / CC)
| Task | Task Details | Hours | Funding Required (CC) |
|---|
| DAR Dependency Analysis Engine | DAR parsing, Dalf package extraction, recursive dependency resolution, package fingerprinting, dependency graph construction, compatibility analysis against deployed Canton packages | 180 | 120,000 |
| Metadata & Schema Validation Engine | Validation of application metadata, CIP schema enforcement, audit artifact verification, consistency checks between declared metadata and DAR contents, validation reporting framework | 140 | 90,000 |
| Daml-LF Decoding Layer | Archive/payload parsing for Daml-LF 1.x and 2.x, interning resolution, version detection, support for packages served by participant APIs, performance tuning for large packages | 140 | 93,000 |
| Decompilation Engine | Removal of compiler-generated code (typeclass dictionaries, specialised helpers, join points, temporaries), capture-safe rewriting, reconstruction of patterns, do blocks, records, conditionals and template/choice structure | 240 | 160,000 |
| Source Generation & Type Recovery | Layout-correct Daml output, module and import resolution, Prelude/stdlib mapping, recovery of type applications and annotations needed for compilable output | 200 | 133,000 |
| Project Reconstruction | Buildable project generation, dependency closure and packaging, upgrade-chain linkage | 100 | 67,000 |
| Round-trip Verification Framework | Decompile to compile to structural comparison pipeline, reference corpus of public packages, CI across SDK versions and platforms | 130 | 87,000 |
| DAR Integrity & Signature Verification | DAR integrity validation, signed metadata support, verification of signatures against externally published keys, trust-chain validation against existing ecosystem key infrastructure (consumed, not built) | 60 | 40,000 |
| Production Automation CLI | Production-grade CLI implementation, configuration management, structured logging, error handling, packaging, release management, cross-platform support | 120 | 80,000 |
| GitHub Actions & CI/CD Automation Suite | Reusable GitHub Actions, PR validation workflows, release validation workflows, automated compliance reporting, reference CI templates | 100 | 65,000 |
| End-to-End Testing & Security Hardening | Canton sandbox infrastructure, automated integration testing, negative testing, parser hardening, security validation, regression test suite | 100 | 65,000 |
| Documentation & Reference Implementations | Integrator guide, operator guide, architecture documentation, schema reference, example repositories, reference implementations | 60 | 40,000 |
| Total | | 1,570 | 1,040,000 CC |
Milestone 3: Ecosystem Adoption (The "Public Good" Trigger)
Estimated Delivery: 2 months after the delivery of Milestone 2
Focus: Verifiable, cross-ecosystem integration of the standard.
- Deliverable 3.1 — Provable adoption by 10 distinct ecosystem entities.
- Acceptance Criterion: 4 Wallet Providers, 4 dApp Builders, and 2 Security Auditing Firms successfully publish their application information, strictly conforming to the standard defined in Milestone 1, via a public Git repository. The automation suite (Milestone 2) must return a
Validation: SUCCESS state for all 10 repositories.
- Deliverable 3.2 — Publish Blog Article.
- Acceptance Criterion: Publishing a joint technical case study explaining the standard and the problem that it solves, demonstrating the 10 adoption repositories and open-sourcing the CI/CD templates for the broader developer community.
Funding
- Total Funding Request: 2,500,000 Canton Coin (CC)
- PixelPlex Allocation: 1,500,000 CC
- Digital Asset Allocation: 1,000,000 CC
Payment Breakdown by Milestone:
| Milestone | Funding | PixelPlex / Digital Asset Split |
|---|
| Milestone 1: CIP Submission & Initial Automations MVP | 460,000 CC | 260,000 PP / 200,000 DA |
| Milestone 2: Automation Hardening & Release | 1,040,000 CC | 1,040,000 PP / 0 DA |
| Milestone 3: Ecosystem Adoption | 1,000,000 CC | 200,000 PP / 800,000 DA |
Payments are released upon committee acceptance of each milestone's deliverables, with Milestone 3 released upon final release and verifiable adoption.
Volatility Stipulation
Should the project timeline extend beyond the Estimated Delivery schedule set out above due to requested scope changes by the Committee, the remaining un-minted milestones must be renegotiated to account for any significant USD/CC price volatility.
Timeline Risk Management
- Acceleration Bonus: If Milestone 3 is delivered and verified more than 1 month ahead of the Estimated Delivery schedule, the final payout will receive a +20% adjustment (to 1,200,000 CC for Milestone 3).
- SLA Penalty: For every 30 days of delay beyond the Estimated Delivery date for Milestone 3, the final milestone payout decreases by 25%.
- Fallback Logic: Should a Canton Network core upgrade introduce breaking changes to the Ledger API during the execution of Milestone 2, the delivery timeline will automatically pause for up to 30 days to allow PixelPlex to refactor the automation suite without incurring SLA penalties.
Co-Marketing
Upon release, PixelPlex and Digital Asset will collaborate with the Foundation on publishing a joint technical case study explaining the standard and the problem that it solves, demonstrating the 10 adoption repositories and open-sourcing the CI/CD templates for the broader developer community.
