Seeking Tech & Ops Committee Champion for PR #77 (Cantool — Canton Developer CLI)
The announcement of the first two Development Fund awards today clarifies that proposals need a Tech & Ops Committee sponsor to advance to review. I'm looking for a champion for PR #77 — Cantool, an open-source Canton developer CLI.
The proposal addresses the gap identified as the single highest-urgency item in the Canton Network Developer Experience and Tooling Survey: a unified CLI toolchain for scaffolding, testing, and deployment (the "Hardhat for Canton" that survey respondents asked for by name). The scope is complementary to DevKit (PR #18) and the Daml Code Assistant (PR #10) — Cantool delegates to DevKit for local environment management and focuses on the application lifecycle layer above it.
I have production Canton experience (Ledger API, PQS, cn-quickstart, DAML contracts, Go service architecture) and have built internal Canton CLI tooling that informs this proposal's design. Full details are in the PR.
If anyone on the committee is interested in sponsoring or would like to discuss the proposal, I'd welcome the conversation. I'm also happy to refine scope, milestones, or anything else as part of the championing process — that's exactly what the process is for.
- toggle quoted message Show quoted textFollowing up on my earlier message regarding the Cantool proposal (PR #77).I had held off on building beyond the initial project scaffolding due to statements in the Development Fund FAQs that funding would not be retroactive for projects. However, given that other proposals have since been submitted with working code — in some cases directly implying they subsume the capabilities of proposals submitted earlier in the queue — it felt appropriate to prove out the proposed functionality and architecture sooner rather than later.An early "alpha" release of Cantool (v0.1.0) is now published: https://github.com/DisplaceTech/Cantool/releases/tag/v0.1.0As described, this is a Go-based CLI that ships as a single statically-linked binary with zero runtime dependencies — no Node.js, no npm, no JVM required for the CLI itself. Cross-platform binaries for Linux, macOS, and Windows are available on the release page, and Cantool is installable via Homebrew (brew install displacetech/tap/cantool).v0.1.0 includes 10 working commands covering the core local development lifecycle:- cantool init — project scaffolding with embedded templates (basic, token)- cantool build / build --watch — DAML compilation with file watching- cantool test — structured test execution with pass/fail parsing- cantool dev — local sandbox with health polling, party provisioning, and hot-reload- cantool env — named environment profiles for multi-target development- cantool status — node health and metadata inspection- cantool doctor — prerequisite checking (Java, SDK, Docker, ports)- cantool clean — build artifact management- cantool mcp serve — MCP server exposing Canton operations to AI development assistants- cantool plugin list — plugin system foundation for extensibilityThe MCP server is, to my knowledge, the first Canton development tool that integrates with AI assistants. This enables AI-assisted development and lays the foundation for contract development, ledger inspection, and party management directly from editors and tools that support MCP.The plugin architecture is baked into the binary from day one. Plugins are standalone executables communicating via JSON-RPC over stdio, making the system language-agnostic and extensible without modifying the core.A key architectural decision: Go produces a single static binary per platform. For institutional environments with locked-down package managers or air-gapped networks, this means Cantool works out of the box with a single file copy. No dependency resolution, no container images required for the CLI itself.The project is still seeking Development Fund support. I will be updating the proposal in PR #77 shortly to reflect the v0.1.0 work and refining the roadmap. The project still needs a champion from the Tech & Ops Committee; I am available to discuss the technical approach, roadmap, and differentiation from other tooling proposals at any time.On Monday, March 23rd, 2026 at 10:43 AM, Eric (Displace Tech) via lists.sync.global <emann=displace.tech@...> wrote:
The announcement of the first two Development Fund awards today clarifies that proposals need a Tech & Ops Committee sponsor to advance to review. I'm looking for a champion for PR #77 — Cantool, an open-source Canton developer CLI.
The proposal addresses the gap identified as the single highest-urgency item in the Canton Network Developer Experience and Tooling Survey: a unified CLI toolchain for scaffolding, testing, and deployment (the "Hardhat for Canton" that survey respondents asked for by name). The scope is complementary to DevKit (PR #18) and the Daml Code Assistant (PR #10) — Cantool delegates to DevKit for local environment management and focuses on the application lifecycle layer above it.
I have production Canton experience (Ledger API, PQS, cn-quickstart, DAML contracts, Go service architecture) and have built internal Canton CLI tooling that informs this proposal's design. Full details are in the PR.
If anyone on the committee is interested in sponsoring or would like to discuss the proposal, I'd welcome the conversation. I'm also happy to refine scope, milestones, or anything else as part of the championing process — that's exactly what the process is for.
- toggle quoted message Show quoted textEric, there is already a CLI called dpm (see https://github.com/digital-asset/dpm). Let's not fracture and duplicate things. Please orient any CLI contribution around the existing tooling.It is rather concerning that you didn't make reference to it.On Wed, Apr 1, 2026 at 2:27 PM Eric (Displace Tech) via lists.sync.global <emann=displace.tech@...> wrote:Following up on my earlier message regarding the Cantool proposal (PR #77).I had held off on building beyond the initial project scaffolding due to statements in the Development Fund FAQs that funding would not be retroactive for projects. However, given that other proposals have since been submitted with working code — in some cases directly implying they subsume the capabilities of proposals submitted earlier in the queue — it felt appropriate to prove out the proposed functionality and architecture sooner rather than later.An early "alpha" release of Cantool (v0.1.0) is now published: https://github.com/DisplaceTech/Cantool/releases/tag/v0.1.0As described, this is a Go-based CLI that ships as a single statically-linked binary with zero runtime dependencies — no Node.js, no npm, no JVM required for the CLI itself. Cross-platform binaries for Linux, macOS, and Windows are available on the release page, and Cantool is installable via Homebrew (brew install displacetech/tap/cantool).v0.1.0 includes 10 working commands covering the core local development lifecycle:- cantool init — project scaffolding with embedded templates (basic, token)- cantool build / build --watch — DAML compilation with file watching- cantool test — structured test execution with pass/fail parsing- cantool dev — local sandbox with health polling, party provisioning, and hot-reload- cantool env — named environment profiles for multi-target development- cantool status — node health and metadata inspection- cantool doctor — prerequisite checking (Java, SDK, Docker, ports)- cantool clean — build artifact management- cantool mcp serve — MCP server exposing Canton operations to AI development assistants- cantool plugin list — plugin system foundation for extensibilityThe MCP server is, to my knowledge, the first Canton development tool that integrates with AI assistants. This enables AI-assisted development and lays the foundation for contract development, ledger inspection, and party management directly from editors and tools that support MCP.The plugin architecture is baked into the binary from day one. Plugins are standalone executables communicating via JSON-RPC over stdio, making the system language-agnostic and extensible without modifying the core.A key architectural decision: Go produces a single static binary per platform. For institutional environments with locked-down package managers or air-gapped networks, this means Cantool works out of the box with a single file copy. No dependency resolution, no container images required for the CLI itself.The project is still seeking Development Fund support. I will be updating the proposal in PR #77 shortly to reflect the v0.1.0 work and refining the roadmap. The project still needs a champion from the Tech & Ops Committee; I am available to discuss the technical approach, roadmap, and differentiation from other tooling proposals at any time.On Monday, March 23rd, 2026 at 10:43 AM, Eric (Displace Tech) via lists.sync.global <emann=displace.tech@...> wrote:
The announcement of the first two Development Fund awards today clarifies that proposals need a Tech & Ops Committee sponsor to advance to review. I'm looking for a champion for PR #77 — Cantool, an open-source Canton developer CLI.
The proposal addresses the gap identified as the single highest-urgency item in the Canton Network Developer Experience and Tooling Survey: a unified CLI toolchain for scaffolding, testing, and deployment (the "Hardhat for Canton" that survey respondents asked for by name). The scope is complementary to DevKit (PR #18) and the Daml Code Assistant (PR #10) — Cantool delegates to DevKit for local environment management and focuses on the application lifecycle layer above it.
I have production Canton experience (Ledger API, PQS, cn-quickstart, DAML contracts, Go service architecture) and have built internal Canton CLI tooling that informs this proposal's design. Full details are in the PR.
If anyone on the committee is interested in sponsoring or would like to discuss the proposal, I'd welcome the conversation. I'm also happy to refine scope, milestones, or anything else as part of the championing process — that's exactly what the process is for.
--
Curtis Hrischuk curtis.hrischuk@... Principal Technical
Product ManagerCreators of Canton Network 
This message, and any attachments, is for the intended recipient(s) only, may contain information that is privileged, confidential and/or proprietary and subject to important terms and conditions available at http://www.digitalasset.com/emaildisclaimer.html. If you are not the intended recipient, please delete this message. - toggle quoted message Show quoted textHi Curtis, thanks for the feedback.Cantool does reference dpm directly — the proposal's Package Management section describes it as wrapping dpm for DAML compilation: "Cantool does not reimplement DAML compilation — it invokes `dpm build` and manages the artifacts." The SDK detection layer in the v0.1.0 alpha checks for dpm on PATH first and delegates to it, falling back to the daml CLI if dpm isn't available.The intended relationship is complementary. dpm is the package manager for DA's SDK components; Cantool is the application development lifecycle layer that sits above it — project scaffolding, environment management, deployment orchestration, and the MCP server for AI-assisted development. The analogy I'd draw is something like rustup (toolchain management) vs cargo (project lifecycle). They're different layers of the stack, and Cantool is designed to lean on dpm more heavily as it matures.That said, I'd welcome the chance to discuss how Cantool can best align with DA's tooling direction. If there are integration points or conventions in dpm that Cantool should be respecting more directly, I'd rather get that right early.On Wednesday, April 1st, 2026 at 12:08 PM, Curtis Hrischuk via lists.sync.global <curtis.hrischuk=digitalasset.com@...> wrote:
Eric, there is already a CLI called dpm (see https://github.com/digital-asset/dpm). Let's not fracture and duplicate things. Please orient any CLI contribution around the existing tooling.It is rather concerning that you didn't make reference to it.On Wed, Apr 1, 2026 at 2:27 PM Eric (Displace Tech) via lists.sync.global <emann=displace.tech@...> wrote:Following up on my earlier message regarding the Cantool proposal (PR #77).I had held off on building beyond the initial project scaffolding due to statements in the Development Fund FAQs that funding would not be retroactive for projects. However, given that other proposals have since been submitted with working code — in some cases directly implying they subsume the capabilities of proposals submitted earlier in the queue — it felt appropriate to prove out the proposed functionality and architecture sooner rather than later.An early "alpha" release of Cantool (v0.1.0) is now published: https://github.com/DisplaceTech/Cantool/releases/tag/v0.1.0As described, this is a Go-based CLI that ships as a single statically-linked binary with zero runtime dependencies — no Node.js, no npm, no JVM required for the CLI itself. Cross-platform binaries for Linux, macOS, and Windows are available on the release page, and Cantool is installable via Homebrew (brew install displacetech/tap/cantool).v0.1.0 includes 10 working commands covering the core local development lifecycle:- cantool init — project scaffolding with embedded templates (basic, token)- cantool build / build --watch — DAML compilation with file watching- cantool test — structured test execution with pass/fail parsing- cantool dev — local sandbox with health polling, party provisioning, and hot-reload- cantool env — named environment profiles for multi-target development- cantool status — node health and metadata inspection- cantool doctor — prerequisite checking (Java, SDK, Docker, ports)- cantool clean — build artifact management- cantool mcp serve — MCP server exposing Canton operations to AI development assistants- cantool plugin list — plugin system foundation for extensibilityThe MCP server is, to my knowledge, the first Canton development tool that integrates with AI assistants. This enables AI-assisted development and lays the foundation for contract development, ledger inspection, and party management directly from editors and tools that support MCP.The plugin architecture is baked into the binary from day one. Plugins are standalone executables communicating via JSON-RPC over stdio, making the system language-agnostic and extensible without modifying the core.A key architectural decision: Go produces a single static binary per platform. For institutional environments with locked-down package managers or air-gapped networks, this means Cantool works out of the box with a single file copy. No dependency resolution, no container images required for the CLI itself.The project is still seeking Development Fund support. I will be updating the proposal in PR #77 shortly to reflect the v0.1.0 work and refining the roadmap. The project still needs a champion from the Tech & Ops Committee; I am available to discuss the technical approach, roadmap, and differentiation from other tooling proposals at any time.On Monday, March 23rd, 2026 at 10:43 AM, Eric (Displace Tech) via lists.sync.global <emann=displace.tech@...> wrote:
The announcement of the first two Development Fund awards today clarifies that proposals need a Tech & Ops Committee sponsor to advance to review. I'm looking for a champion for PR #77 — Cantool, an open-source Canton developer CLI.
The proposal addresses the gap identified as the single highest-urgency item in the Canton Network Developer Experience and Tooling Survey: a unified CLI toolchain for scaffolding, testing, and deployment (the "Hardhat for Canton" that survey respondents asked for by name). The scope is complementary to DevKit (PR #18) and the Daml Code Assistant (PR #10) — Cantool delegates to DevKit for local environment management and focuses on the application lifecycle layer above it.
I have production Canton experience (Ledger API, PQS, cn-quickstart, DAML contracts, Go service architecture) and have built internal Canton CLI tooling that informs this proposal's design. Full details are in the PR.
If anyone on the committee is interested in sponsoring or would like to discuss the proposal, I'd welcome the conversation. I'm also happy to refine scope, milestones, or anything else as part of the championing process — that's exactly what the process is for.
--Curtis Hrischuk curtis.hrischuk@... Principal Technical
Product ManagerCreators of Canton Network
This message, and any attachments, is for the intended recipient(s) only, may contain information that is privileged, confidential and/or proprietary and subject to important terms and conditions available at http://www.digitalasset.com/emaildisclaimer.html. If you are not the intended recipient, please delete this message.
