Proposal: Cantool — Open-Source Canton Developer CLI

Status Update: Cantool v0.1.0 Alpha Published

To demonstrate the proposed architecture and execution direction, an early alpha of Cantool is now available:

• Release: https://github.com/DisplaceTech/Cantool/releases/tag/v0.1.0
• Install: brew install displacetech/tap/cantool or download a binary from the release page

What the alpha covers

Cantool is a Go-based CLI that compiles to a single statically-linked binary with zero runtime dependencies. v0.1.0 implements 10 commands covering the core local development loop:

What this proves

The alpha validates three architectural decisions that are central to the proposal:

1. Single binary, zero dependencies. Go's static compilation produces one file per platform. For institutional environments with locked-down package managers or air-gapped networks, this is a meaningful advantage over tooling that requires Node.js or other runtimes.

2. MCP integration. cantool mcp serve is, to my knowledge, the first Canton development tool that integrates with AI assistants via the Model Context Protocol.

3. Plugin architecture. Baked in from v0.1.0 — plugins are standalone executables communicating via JSON-RPC over stdio, making the system language-agnostic and extensible without modifying the core.

What the alpha does not yet cover

v0.1.0 is a proof of architecture, not a production release. Significant work remains:

• Deployment pipeline — remote deployment with dry-run, migration planning, and rollback is not yet implemented
• Multi-node topology — cantool dev --full with Docker Compose for realistic multi-participant environments
• Interactive console/REPL — for live contract interaction and ledger queries
• Auth and credential management — JWT handling across environments
• Deeper MCP capabilities — the current server exposes foundational tools; production use requires richer contract introspection, template analysis, and party topology resources
• Additional templates — only basic and token ship today; DeFi, API service, and community template support are on the roadmap
• Integration testing against real Canton nodes — current test coverage exercises the architecture with mocks; end-to-end validation against sandbox and testnet environments is needed
• Documentation — command reference, getting started guide, architecture docs, and contributor onboarding
• Hardening and edge cases — error handling, recovery from partial failures, and graceful degradation across SDK versions

Proposal update incoming

I will be pushing a revised proposal to this branch that:

• Acknowledges v0.1.0 as completed groundwork demonstrating the architecture and execution approach
• Restructures milestones so that funding is directed toward the unfinished work listed above
• Adjusts the funding ask to reflect the self-funded alpha work
• Adds a differentiation section addressing the Go/single-binary architecture, MCP integration, and plugin system relative to other tooling proposals in the queue

Still seeking a Tech & Ops Committee champion. Available to discuss the technical approach and roadmap at any time.

@ericmann I think cantool package part should probably live inside dpm. I see this PR lives in between dpm and half with application CLI which can be a bit problematic.

Also I see around 40% Overlap with PR-18 , Almost 50% overlap with PR-105. Idea is good but it feels too broad

@srikanth-bitdynamics Thanks for the review! This is the kind of feedback that sharpens the proposal.

On package commands belonging in dpm: agreed, and this is how Cantool is already scoped to work. cantool build detects dpm on PATH and invokes dpm build under the hood; cantool test and cantool clean do the same. Cantool doesn't reimplement dpm's compilation or test execution — it wraps them with watch mode, structured JSON output, and consistent error formatting. The proposal's "Relationship to Existing Tooling" section documents this, but I recognize the layering wasn't visually obvious. If DA wants to upstream any of those UX improvements into dpm directly, that's a good outcome for the ecosystem.

On overlap with PR #18 (DevKit): the proposal already specifies that Cantool delegates to DevKit as its primary backend for local environment lifecycle when installed, falling back to minimal cn-quickstart Docker management only if DevKit is not available. The relationship is the same pattern as with dpm: Cantool is the developer-facing entry point, DevKit handles the infrastructure underneath. Again, documented but not immediately scannable.

On overlap with PR #105 (dpm DevKit): I've now reviewed PR #105 in detail. The overlap is significantly smaller than it appears at the surface level. PR #105 extends dpm with Cargo-style dependency management (lockfiles, version pinning, dpm pkg discover), documentation extraction from DAR metadata (dpm docs), transaction tracing and diagnostics (dpm trace, dpm inspect), and built-in AI diagnostic skills that analyze trace outputs. Cantool does none of these things — not in v0.1.0 and not in any proposed milestone. Cantool's scope is project scaffolding, dev environment orchestration, named environments, health monitoring, an MCP server for external AI assistants, and a plugin system. The tools compose naturally: a developer would use PR #105's dependency management to resolve packages, then use Cantool's scaffolding and dev orchestration to build and test an application consuming those packages. And since Cantool delegates build/test to dpm, any new dpm commands that PR #105 adds can be made available to Cantool users (but ideally they could use them directly as well).

On the "too broad" concern: I hear that, and it's the most actionable signal here. The proposals are doing different things, but the text didn't make that obvious enough. I'm pushing a revision that makes the layering impossible to miss:

1. An ecosystem positioning diagram showing where Cantool, DevKit (#18), dpm DevKit (#105), the Daml Code Assistant (#10), and dpm sit in the tooling stack, specifically showing delegation direction
2. A delegation table mapping every Cantool command to what it calls underneath (dpm, DevKit, or neither — i.e. greenfield)
3. An expanded relationship table now including PR #105 with a specific breakdown of which capabilities belong to which tool

The greenfield surface — MCP, plugins, named environments, doctor, status, opinionated scaffolding — is where no other tool operates, and it's what the developer survey identified as the top gap.

Pushing the revision now.

The revised proposal is much better at explaining delegation to dpm and DevKit, but the practical user surface still overlaps heavily with them. If cantool build, cantool test, cantool dev, package inspection, package upload, and local environment management are all fronted by Cantool, then the “entry point” ends up owning the user relationship even if the lower layers do the work. That is still meaningful overlap with dpm, PR #18, and PR #105, even if the implementation delegates internally.

The README’s binary install command points to releases/latest/download/cantool-$(uname -s)-$(uname -m), while the actual release assets are tarballs named like Cantool_0.1.0_darwin_arm64.tar.gz; that install path does not match the published assets. The README also sells “single binary, zero dependencies,” while doctor still checks Java, SDK, Docker, and Go, which weakens the “works out of the box” story for non-Go users.

I think you can keep the scope narrower and revise the PR right now in current shape its too broad imo.

@srikanth-bitdynamics:

The revised proposal is much better at explaining delegation to dpm and DevKit, but the practical user surface still overlaps heavily with them. If cantool build, cantool test, cantool dev, package inspection, package upload, and local environment management are all fronted by Cantool, then the “entry point” ends up owning the user relationship even if the lower layers do the work. That is still meaningful overlap with dpm, PR #18, and PR #105, even if the implementation delegates internally.

Fair point. I think the core issue is that even when overlap is implemented by delegation, it still reads as overlap if Cantool appears to own the same user surface as dpm or DevKit. I’ve revised the proposal to narrow that boundary directly.

A few clarifications first:

• The README/install issue and the earlier “zero dependencies” messaging problems have been fixed in the shipped tool earlier today; the current release is now v0.1.3.
• This proposal revision is about scope and positioning, not about asking the fund to underwrite wrapper-style convenience commands.

The revised proposal now frames Cantool as a focused application-layer tool, not a unified front door for the Canton ecosystem.

The funded milestones are now described as:

• M1: Scaffolding and community templates
  cantool init, a versioned template spec, validation, starter templates, and documented conventions for community-hosted templates. This is now explicitly framed as patterns, reference templates, and best-practices documentation — not a hosted registry or marketplace.

• M2: MCP server
  Ledger API-oriented MCP capabilities for AI assistants, resources, Streamable HTTP transport, integration testing, and documentation. Package-related scope is now described narrowly as participant-visible package metadata needed for application workflows, not package management or dependency tooling.

• M3: Plugin system
  Install/remove lifecycle, reference SDKs, lifecycle hooks, and documented conventions for community plugin authoring/distribution. Again, this is framed as patterns and conventions — not a hosted plugin registry.

• M4: Named environment management and adoption
  cantool env CRUD, auth integration, health/status, and participant endpoint configuration. I removed language that made this sound like deployment ownership, package upload ownership, or LocalNet orchestration.

I also revised the proposal text to make the boundaries explicit:

• dpm owns SDK management, Daml build/test/codegen, dependency resolution, and related package workflows
• DevKit owns LocalNet / infrastructure orchestration
• Cantool owns application-layer workflows: scaffolding, named environments, health checks, AI integration, and extensibility

Concretely, I removed or rewrote the parts that were making the proposal sound broader than intended:

• removed the delegation map section entirely
• replaced “community registry” / “plugin registry” language with reference templates, conventions, and best practices
• replaced “deployment targets” / package-upload style wording with participant endpoint configuration
• replaced “single/unified CLI” framing with a focused CLI framing
• clarified that where Cantool surfaces package information, it is only participant-visible metadata inside application workflows, not package management as a product surface

So the story is now much simpler:

dpm and DevKit should stay focused on their own layers. This grant asks only for the greenfield application-layer capabilities that are not currently owned elsewhere: scaffolding, MCP integration, plugin extensibility, and participant-connected environment management.

That narrower scope is what I’m asking the committee to evaluate.

The distinction between core Cantool capabilities and optional convenience wrappers is much clearer now, and the v0.1.3 release supports that narrowed story better than the earlier alpha did.

Actual proposal text and milestone/funding structure still appear broader than the scope described here. If the intended funded scope is now limited to scaffolding/templates, MCP integration, plugin extensibility, and participant-connected environment management, then the proposal should be rewritten to reflect that directly and repriced accordingly.

Also please re evaluate the funding ask as the scope is much narrower now

@srikanth-bitdynamics:

The distinction between core Cantool capabilities and optional convenience wrappers is much clearer now, and the v0.1.3 release supports that narrowed story better than the earlier alpha did.

Actual proposal text and milestone/funding structure still appear broader than the scope described here. If the intended funded scope is now limited to scaffolding/templates, MCP integration, plugin extensibility, and participant-connected environment management, then the proposal should be rewritten to reflect that directly and repriced accordingly.

Also please re evaluate the funding ask as the scope is much narrower now

Fair ask. I’ve revised the proposal so the text, milestones, and pricing now match the narrower scope directly.

The funded scope is now limited to:

• M1: scaffolding and community templates
• M2: MCP server
• M3: plugin system
• M4: named environment management and lightweight adoption validation

I also reduced the pricing and tightened the timeline:

• Base ask: 1,350,000 CC
• Base schedule: 9 months

Updated milestone amounts:

• M1: 375,000 CC
• M2: 425,000 CC
• M3: 325,000 CC
• M4: 225,000 CC

Consistent with some of the other approved proposals, I've also added an "early completion bonus" of 150,000 CC to further incentivize early delivery.

This should now reflect the narrower application-layer scope much more directly.

Hey @ericmann

• To the extent you can, name which companies who intend to use it. If you can get people from those companies to comment here that they're using it and whether they'd be willing to review the updates and confirm milestone completion, that would help

• Give some explanation of the amount of estimated effort in person hours that goes into each milestone. This isn’t a hard requirement but helps get proposals approved faster.

• Even in the narrowed version, Cantool still touches participant-connected operations, package metadata surfacing, environment/auth workflows, and the application entry point

• The budget is more reasonable than before, but still high for the narrowed scope. 1,350,000 CC base with a 150,000 CC early-completion bonus is better than the earlier broader asks, but for a now-narrowed scope of templates, MCP, plugins, and environment management, it still feels on the high side unless the committee particularly values MCP and plugin architecture as ecosystem multipliers. I would suggest to re evaluate based on current content and remove early completion bonus.

Thanks @srikanth-bitdynamics. Addressing each point, with updated proposal text pushed alongside this comment.

Intended users: Displace Technologies will use Cantool as its primary Canton development workflow — We're building this because we need it for ongoing Canton consulting and application work. Beyond Displace, the proposal's adoption validation gates are designed to prove usage during delivery rather than promise it upfront: each milestone requires external developer testing, structured feedback collection, and a published validation summary before payment is triggered. We'll actively recruit testers from the Canton developer community as each milestone approaches. For a tool whose funded features don't exist yet, signed letters of intent aren't realistic — but milestone-gated payment means the committee takes on zero risk if adoption doesn't materialize.

Person-hours per milestone:

The timeline is 9 months. It's shaped in single-engineer hours, but explicitly with the possibility of bringing in additional engineering support to accelerate delivery. Person-hours were already documented per-milestone in the proposal; I've added a summary table for visibility.

At current CC pricing (~$0.15), the base ask of 1,350,000 CC works out to approximately $202,500 over 9 months — roughly $22,500/month. Assuming a single engineer, that effective hourly rate would be ~$241/hr before taxes, consistent with market rates and CC price volatility risk. For context, this proposal would be the second smallest grant in the program by total CC and among the lowest in monthly burn rate.

Early completion bonus: I've kept the early completion bonus of 150,000 CC (11% of base), consistent with the incentive structure established in multiple approved proposals — including PR #53 (20% bonus) and PR #76 (10–20% bonus). Cantool's track record of ahead-of-schedule delivery (v0.1.0 and v0.1.3 both shipped within days of deciding to build) supports the viability of a 6-month completion target.

Participant-connected operations: Agreed — any developer tool that helps people build and deploy Canton applications will necessarily touch participant operations, package metadata, and environment configuration. That's what "application developer workflow" means. The distinction is that Cantool doesn't manage those systems (that's dpm and DevKit's domain) — it provides a developer-facing interface to them for scaffolding, AI-assisted development, and extensibility purposes.

Budget: This proposal has been revised three times since the initial submission, incorporating feedback from both your reviews and broader community input on scope and ecosystem fit. The funded milestones are now limited exclusively to greenfield capabilities that no other tool in the ecosystem provides, and the dpm convenience wrappers — originally shipped as an unpaid open-source contribution — were removed entirely to avoid even the appearance of scope overlap.

I'm confident this version is ready for committee review and represents strong value for the ecosystem relative to other funded proposals in the program. Happy to address any remaining feedback — let me know where things stand on your end.

@ericmann

1. Ideally Voting team is asking for atleast 2 external ecosystem projects wanting to use the product .
2. Funding still feels premium but I'll let voting team decide the rest.
3. A single natural-language prompt completes scaffold → connect → query without further human input” is a cool demo target, but it depends heavily on the assistant/model and surrounding MCP client behavior, not just on Cantool itself. I would not want milestone payment hinging on a generic AI-agent behavior statement like that.

I can pass this to voting for voting team to decide from here.

cc: @hythloda

Have you considered adding the functionality you defined below directly into DPM, such that developers have a uniform experience without duplication of functionality?

dpm itself is just a plugin system in order to deliver a uniform user experience coming from the invocation of different tools.

Have a look at the .dpm/cache folder (look for the component.yaml and the major.minor.patch.yaml file).

dpm already supports templates.

ratkovepreknwyx4r:canton ravep$ dpm new --list The following templates are available: daml-intro-choices daml-intro-compose daml-intro-constraints daml-intro-contracts daml-intro-daml-scripts daml-intro-data daml-intro-exceptions daml-intro-functional-101 daml-intro-parties daml-intro-test daml-patterns empty-skeleton finance-lifecycling finance-payoff-modeling finance-settlement finance-upgrades multi-package-example quickstart-finance quickstart-java script-example skeleton upgrades-example

What is lacking IMHO is:

• creation, documentation and maintenance of such templates for different languages and use cases
• curation and process of how these templates are discovered and added

In that sense, you offer here to work out more patterns and starting points, which I think is a great initiative. Can you elaborate on where these would be hosted and what the contribution guidelines would be?

There are plans to add a plugin system to dpm. dpm is written in Go. I see a lot of potential for collaboration.

Thank you for your proposal. I think that you are trying to contribute important and valuable work. Milestones 1,2 and 3 are on my "I would like to have that list" as well (I left a comment on Milestone 4).

However, I think that from a community perspective, it would be great if, rather than building yet another CLI, you would directly add the functionality to dpm. Would you be open to talk to the dpm maintainers and DAs SDK lead?

A small comment on this milestone here: I don't disagree with the potential convenience or the goals of this milestone. However, it does seem to me that managing deployments and credentials is something that every company handles differently, and anyway via their K8 deployments.

Especially from a security perspective, you should anyway have a pretty strict separation between developer infrastructure and ops infrastructure.

Therefore I don't know whether the solution you are proposing here is really generic and sufficiently applicable to manage deployments.

Thanks for the pointer — I read through docs-internal/src/components/components.rst and the component.yaml schema to make sure I understood what you're describing.

If I'm reading it right, the components mechanism is a launcher pattern for SDK-shipped binaries. That's a sensible way to package SDK pieces, and there's overlap with the "exec a binary and hand it a structured handoff" idea at the heart of Cantool's plugin layer. But I'd push back gently on framing it as a plugin system in the sense Cantool (or, say, Hardhat, Anchor, or Cargo subcommands) uses the term. The components model as documented doesn't cover install/remove for user-authored extensions, a discovery or distribution convention for third-party authors, a permission or sandbox model for untrusted code, or lifecycle hooks that let a plugin participate in a workflow rather than replace a command. Components are wired into SDK assembly; Cantool plugins are wired into a developer's local workflow.

Where the two models do overlap is the exec-a-binary-with-a-known-contract pattern. That's genuine shared ground, and if dpm's components grow toward a user-installable plugin surface, a JSON-RPC-over-stdio contract is a natural complement to the env-var-path-injection pattern components already use — plugins can call out to dpm components the same way dpm components can be composed today. Happy to align on shared conventions as Cantool's M3 work firms up.

This is an important clarification to nail down, because I think there's a layer confusion worth pulling apart.

dpm new creates Daml package templates: projects centered on Daml source that compile with dpm build, using the Daml template keyword for contract definitions. That's the right home for that workflow and Cantool explicitly does not duplicate it.

Cantool's init targets a different layer: full project scaffolds for Canton applications. Concretely, a Cantool-scaffolded project includes the application code (Go initially, with extension points for other languages), the directory layout, Docker Compose wiring for cn-quickstart, CI/CD configs, direnv and environment manifests, and the boilerplate needed to connect application code to a participant. The Daml package inside that project is still created and built with dpm — Cantool does not replace it.

On your question about where these templates live and how contribution works — good question, and one I want to answer concretely:

• Hosting: Templates are plain GitHub repositories. No hosted registry; cantool init --from <github-url> fetches and validates against the template spec. Discovery happens through a documented GitHub topic tag (e.g. cantool-template) and a listing format, so the Canton Foundation isn't on the hook for running registry infrastructure.
• Contribution guidelines: M1 delivers a versioned template specification (schema, required files, metadata), a template authoring guide, and a starter library (token, marketplace, multi-party workflow) living in the Cantool org as reference examples — not a gated set. Anyone publishing a conforming template can be listed.
• Curation and maintenance — which you rightly flag as the real gap — is baked into M1 as the authoring guide, spec validation, and starter library, and the plugin system in M3 gives community authors a mechanism to ship their own extensions to this over time.

I'd welcome your input on the authoring conventions during M1; you've clearly thought about the curation problem and I'd rather get the conventions right the first time.

Strong agreement on the collaboration potential.

One practical note: I've looked for public issues, RFCs, discuss.daml.com threads, or roadmap entries describing dpm's plugin-system plans and I can't find any. The public digital-asset/dpm docs describe dpm as a replacement for the Daml Assistant, and the components mechanism in docs-internal is an SDK-assembly launcher pattern rather than a third-party plugin surface. If there's public material I've missed, a link would help me align Cantool's plugin design where it makes sense to converge. If the plans are internal, I'd genuinely encourage posting them — the committee evaluating this proposal, and any plugin authors in the community, would benefit from the visibility, and it would let the two projects coordinate openly rather than in parallel.

Cantool's plugin system (JSON-RPC over stdio, language-agnostic, Apache 2.0) will be fully specified and documented as part of M3. I'm happy to publish the protocol spec, the reference SDK, and the lifecycle-hook model as upstream contributions if the designs line up, or to adjust Cantool's design to match dpm's where that serves the ecosystem better. Cross-pollination between two Go-based tools with shared conventions is exactly the kind of ecosystem win that justifies having separate tools in the first place.

You're raising the right concern in general, and I want to address it directly because I don't want to blur the line you're drawing.

Cantool's environment management is scoped to the developer-facing surface: connecting a developer's machine or CI runner to local sandboxes, shared dev/test participants, and remote staging environments for application development and integration testing. It is explicitly not a deployment or production ops tool. It does not provision Canton infrastructure, generate K8s manifests, manage production secrets, or rotate operator credentials. That work lives in Terraform, Helm, and whatever internal tooling each organization runs. It should stay there.

The credential management in scope for M4 is Ledger API authentication for developer workflows: the JWT/OAuth/Keycloak flow a developer uses to obtain a token that lets their application code talk to a participant. It's the same authentication a developer would perform against the JSON API directly; Cantool standardizes the flow and stores the resulting token with appropriate file permissions, nothing more.

On the dev/ops separation itself: the boundary is enforced at the participant and network layer — scoped credentials, network segmentation, identity provider rules — not by which CLI tool the developer uses to speak to the participant. A developer running cantool status against a staging participant has exactly the same access as that developer running grpcurl against the same endpoint with the same token. The tool is not the security boundary; the participant's authorization is.

Would it help if I tightened the M4 language in the proposal to make the scope explicit?

@daravep:

Thank you for your proposal. I think that you are trying to contribute important and valuable work. Milestones 1,2 and 3 are on my "I would like to have that list" as well (I left a comment on Milestone 4).

However, I think that from a community perspective, it would be great if, rather than building yet another CLI, you would directly add the functionality to dpm. Would you be open to talk to the dpm maintainers and DAs SDK lead?

I appreciate you separating the milestones out; that's helpful context for where the proposal lands for you.

I'm open to a conversation with the dpm and DA SDK teams, but the framing I'd most want to explore is interoperability rather than absorption. The reason I don't think this work belongs inside dpm is scope: dpm's migration from the Daml Assistant explicitly removed the application-developer commands — upload-dar, allocate-parties, list-parties, start — and directed users to raw gRPC, the JSON API, or the Canton Console instead. That's a reasonable scoping decision for dpm, but it left an application-developer gap. I've seen some teams fill that gap with bespoke, internal CLI tools. I've also seen it filled with shipped bundles of bash scripts in onboarding material from Canton integration partners. Cantool is an attempt to productize that layer in one place, shaped around Canton's party-centric and sub-transaction-privacy model.

Keeping the two tools separate with a clean interop story preserves dpm's focus on SDK and compilation, and gives the application-layer workflow its own home, without either tool having to grow unrelated surface area. I'm committed to the interop work on both sides: a Cantool plugin that calls out to dpm for SDK operations from within a Cantool workflow, and — if the dpm maintainers want it — a corresponding integration on the dpm side that calls out to Cantool for scaffolding and environment commands. The plugin architecture described in M3 is Go-native and Apache 2.0, so any of that is contributable upstream.

@daravep Thanks again for taking time on this!

Quick summary of clarifications across the review thread, since a few of the concerns build on shared assumptions worth separating out:

• Scope boundaries. dpm's charter is SDK management, Daml compilation, and the single-process sandbox — the toolchain layer for building Daml packages. Cantool's charter is the application-developer layer above that: project scaffolding (directory layout, Docker Compose for cn-quickstart, CI/CD, direnv, environment manifests), named participant-connected environments for application code, AI-assisted workflows via MCP, and a plugin system for community extensions. Each tool owns a distinct surface, and the scope split is what makes interoperability clean rather than duplicative.
• Templates. dpm new creates Daml package templates (Daml source that compiles with dpm build). Cantool's init creates full project scaffolds (application code, Docker wiring, CI/CD, env manifests) that contain a Daml package which can then be built with dpm. Different layer; no duplication.
• Interoperability commitment. Cantool → dpm interop already ships as an opt-in plugin in the current release, and I'm committed to maintaining and extending it as both tools evolve. If the dpm maintainers want a dpm → Cantool interop layer on their side, I'll contribute the code for it. The M3 plugin architecture — JSON-RPC over stdio, Go-native, Apache 2.0 — is also available for upstream contribution if it aligns with dpm's own plugin direction.
• M4 scope. Environment management in M4 is developer-facing: local sandboxes, shared dev/test participants, staging participants for integration testing. It is not a deployment or production ops tool, and the dev/ops boundary is enforced at the participant and network layer, not by the CLI.

Happy to answer further questions before the vote.

@ericmann dpm is already in use by the Canton development team, the Canton Network development team, dApp developers, etc. dpm does have a plug-in architecture that you can add these functions into. Other grant proposals have plans to plug into dpm. I strongly suggest that your proposal do the same since I see nothing that is precluded from being added to dpm and those additions would be warmly welcomed. For example, dpm is Go based as well so there is a great opportunity for synergy.

Of course, you are welcome to proceed but I do not see support forthcoming from DA for this as written.

Should someone have a proposal to enhance dpm with similar features, we would support that grant proposal.

This is not intended to be adversarial. I'm just laying out the practicalities that dpm already has momentum. I would be happy to work with you on such a proposal.

Thanks, @hrischuk-da. A few points in response:

• On the proposal's framing: this grant is submitted to the Canton Foundation under CIP-0082, for community-benefit tooling. DA's support or non-support is information the Tech & Ops Committee can weigh, but the evaluation criteria are the Foundation's, not DA's.
• On dpm's plugin architecture: as noted elsewhere in the thread, I've reviewed the public repo and documentation and haven't located a published specification for third-party plugin authoring against dpm. The components mechanism is a launcher pattern for SDK-shipped binaries, not an extension interface for third-party plugin authors. Of the other proposals referenced, PR #105 describes itself as "additive extensions to Digital Asset's dpm CLI" — contributions into the dpm codebase, not plugins against an extension interface. If a public plugin specification exists that I've missed, I'd welcome the link.
• On scope and ecosystem diversity: Cantool's scope is deliberately disjoint from dpm's. dpm owns SDK management, Daml compilation, and the single-process sandbox. Cantool owns application-layer project scaffolding, named participant-connected environments, AI-assisted workflows via MCP, and a plugin system for community extensions. Beyond the technical case for keeping each tool focused, there's a structural one: an independent CLI with a clearly separated scope, authored outside DA and maintained under Apache 2.0 by a separate organization, provides diversity to the Canton ecosystem. That diversity has value on its own — multiple independently-governed implementations, public specs, and distinct maintainer communities strengthen the ecosystem against single-vendor dependencies. If Cantool's and dpm's surfaces begin to converge in ways that warrant bridging, we can evaluate that in context. For now, clear scope separation and separate authoring organizations are features, not gaps to close.
• On interop: the Cantool → dpm interop plugin ships (disabled by default) in the current release, and I've committed to contributing a corresponding dpm → Cantool integration if the dpm maintainers want one. That commitment stands regardless of the vote outcome.

The proposal stands on its alignment with Foundation priorities, the 2026 developer survey findings, and the technical case as written.

It's somewhat unclear to me how a number of these features can work. Anything interacting with the ledger - essentially the whole MCP feature set - is dependent on participant, user, and party configuration and selection, as well as authentication considerations. This is one of the essential problems that a lot of tools and app developers need to wrangle with today. I think we need some more details into your thought process here, as I'm struggling to wrap my head around what this proposal wants to do in a cohesive way.

It also looks like the MCP is providing a disparate set of features from the CLI, which is makes it hard to understand. Does the CLI support all those party/ledger/contract/participant type operations as well, or is that only in the MCP? The proposal doesn't seem to include those features in the CLI itself.

Named environment management also raises questions about how those are configured, and what is actually in those named environments.

Please work with Ali Abrar on getting this ready for vote again

It also looks like the MCP is providing a disparate set of features from the CLI, which is makes it hard to understand. Does the CLI support all those party/ledger/contract/participant type operations as well, or is that only in the MCP? The proposal doesn't seem to include those features in the CLI itself.

Fair point, and the proposal under-specifies this. The CLI supports the same operations the MCP server exposes — cantool contracts list, cantool party allocate, cantool participant packages, etc. The MCP server is a structured tool surface over those same capabilities, designed so AI assistants can compose them programmatically with typed inputs and outputs.

The two surfaces should be at parity: anything the MCP exposes, the CLI exposes directly, and vice versa. The proposal emphasized the MCP server because that's the novel capability, but the CLI equivalents are part of the same milestone scope. I can tighten the language in the proposal to make that explicit.

It's somewhat unclear to me how a number of these features can work. Anything interacting with the ledger - essentially the whole MCP feature set - is dependent on participant, user, and party configuration and selection, as well as authentication considerations. This is one of the essential problems that a lot of tools and app developers need to wrangle with today. I think we need some more details into your thought process here, as I'm struggling to wrap my head around what this proposal wants to do in a cohesive way.

Good question, and worth pulling apart because I think the proposal language is doing too much compression here.

The MCP server runs in the context of a configured Cantool environment, which is the same context the CLI uses. An environment specifies the participant endpoint, the authentication credentials (JWT, OAuth, or Keycloak flow), the default party identity, and any synchronizer configuration. When an AI assistant invokes an MCP tool, the tool executes against the active environment's connection with the configured party scoping. Party selection for specific operations happens through tool inputs where multiple parties are available.

There's no separate auth model for MCP. It's the same Ledger API access the CLI has, exposed through a different surface. The MCP server isn't doing anything novel from the participant's perspective; it's translating tool invocations into Ledger API calls against the active environment's connection.

Named environment management also raises questions about how those are configured, and what is actually in those named environments.

Each environment is a profile stored under Cantool's config directory, containing the participant endpoint, a reference to credentials (either a token file or an OAuth config), the default party identity, and synchronizer configuration.

cantool env add <name> creates a profile, cantool env switch <name> makes it the active environment, and subsequent commands operate against it. Credential storage uses appropriate file permissions and is per-environment, so a developer can have separate dev/staging/production credentials without intermixing. Worth noting that Cantool itself isn't the security boundary here -- RBAC, scoped credentials, and access controls are enforced by the participant and the surrounding network configuration, the same way they would be for any other Ledger API client. Cantool just standardizes how a developer configures and switches between the connections they're authorized to use.

The configuration model is YAML-based and human-editable, with cantool env show <name> rendering the current state.

Happy to go deeper on any of this. The proposal's milestone descriptions cover the surface, but the underlying mechanics are worth getting right in committee discussion.

Thanks, @hythloda. Reached out to Ali earlier this week; will keep the thread moving as soon as we can connect.

Posted a revised version of the proposal reflecting committee feedback from the past few weeks. Key changes:

1. Descoped the original Milestone 4 (Environment Management and Adoption) in response to the security posture concerns raised in committee discussion. Environment management features remain on the Cantool roadmap as opt-in plugins shipped with the standalone tool, but are no longer part of the grant scope.
2. Added a new Milestone 4: OCI Component and dpm Integration. Cantool will publish as both a standalone binary and as an OCI-distributed component compatible with dpm's component manifest schema. This addresses the "single entry point" concern about ecosystem fragmentation by giving dpm users access to Cantool's capabilities through dpm's command namespace, while preserving Cantool's independent codebase, governance, and release cycle.
3. Compressed delivery to 6 months from the original 9-month plan.
4. Reduced total ask to reflect revised scope: 1,000,000 CC base (down from 1,350,000 CC), with a 100,000 CC early completion bonus if all milestones are delivered within 4 months. Maximum total of 1,100,000 CC versus the prior 1,500,000 CC.

The full revision is now in the PR. Happy to answer questions or work through specific milestone details with anyone on the committee.

@srikanth-bitdynamics this ready for vote?

Please work with Ali Abrar on getting this ready for vote again

To reiterate some of the feedback provided by email:

In general, everyone I've spoken with loves the idea of improving the canton development ecosystem, but we did not find significant support for the specific capabilities you listed. The "we" here is primarily developers at Obsidian: I'm not speaking for the community at large.

M1 scaffolding: we wanted to see more of a story around security, trust, and maintenance of templates.

M3 permissioned plugins: another security-sensitive area where we would have liked more detail on the guarantees provided and how they are verified.

I see that you have worked toward mitigating the tool fragmentation issue in M4. I see that others raised this issue as well and would like to hear their feedback on this, but it looks like a step in the right direction.

On the funding: I'll defer to the core contributors on amount/level of effort but, structurally, I would have like to see more adoption-linked milestones.

@ericmann a couple of questions

• How will we know if the extension points are sufficiently general to support other languages?
• Wouldn't the template specification need to be a CIP standard?

@ericmann it isn't clear what this is adding since everyone has an MCP connection. For example, the new doc site (docs.canton.network) has the set of options in the figure below.

I don't know if this is enabling something unique. Could you please identify this?

Documentation for dpm's component (aka plug-in architecture) is here. An example is being documented.

Will it have integration with the daml.yaml and multi-package.yaml files?

Can we more precisely define what is meant by template? Another way of asking this is, what is out of scope of this type of template:

• local party
• multi-hosted party
• decentralized party
• one, two, or many validators
• automation with local client processes as a party
• multi-synchronizer configuration
• wallet integration
• CIP 556 or 103 compatibility
• multi-validator vault pattern

Then, for what is in scope, what is actually provided? How hard is it to build a template?

Is this proposal limited to running against sandbox?

I think the acceptance criteria requires:

• independent organizations creating their own templates
• other independent organizations using those templates

That would validate value to the ecosystem.

Is the value here: agentic AI driven test generation and execution? I'm not sure that MCP by itself adds value.

What additional value does this bring from IDE AI agents?

I think this is very useful but I'm curious how this is done if dpm is used for building and running tests?

Two weeks ago, this proposal was moved forward for committee vote. In the time since, neither I nor Displace Technologies has received any communication from the committee or the proposal's assigned reviewer regarding outcome, next steps, or any potential further required revisions.

This proposal has been in flight for nearly three months. The funding ask was reduced by roughly half, the timeline compressed from twelve months to six, and the scope materially restructured in response to community and committee feedback. Over that period the proposal has had multiple assigned champions, each engaging on different timelines and with different stated concerns. The ecosystem has also continued to evolve during that period, with other participants shipping tooling that overlaps with the proposal's original scope while it remained in review. The opportunity cost of further iteration against a process that is not communicating outcomes has reached the point where it exceeds the value the grant can deliver.

I am formally withdrawing this proposal.

The v0.1.x branch of Cantool remains available under Apache 2.0 for any Canton developer or organization that finds it useful. Displace will continue to monitor the evolution of the network and may revisit involvement when the development fund's review process and economic structure stabilize.

Thank you to all who engaged constructively through this process.

@ericmann completely agree this took too long. We attempted to communicate well throughout the process but clearly we didn't do a great job from your POV. Sorry about that, it's still a very new fund and we're looking to get feedback and improve. I suggest we have a call with you and anyone from the T&O committee who wants to join to get a download on how the process looked from your end, so we can improve process and communications going forward.