Proposal: Cantool — Open-Source Canton Developer CLI#77
Conversation
Open-source CLI for Canton application development lifecycle: scaffolding, package management, integration testing, deployment automation, and MCP server.
ericmann
requested review from
hythloda,
isegall-da,
stas-sbi,
tkatrichenko and
waynecollier-da
Strengthen the proposal based on recently approved grants by adding milestone validation gates, sub-stage structure, ecosystem feedback loops, and clearer staged-funding language. Signed-off-by: Eric Mann <emann@displace.tech>
Strengthen the proposal based on approved grant patterns by adding milestone validation gates, external developer feedback loops, upstream issue reporting, and clearer payment-gated acceptance criteria. Signed-off-by: Eric Mann <eric@displace.tech>
Status Update: Cantool v0.1.0 Alpha PublishedTo demonstrate the proposed architecture and execution direction, an early alpha of Cantool is now available:
What the alpha coversCantool 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 provesThe alpha validates three architectural decisions that are central to the proposal:
What the alpha does not yet coverv0.1.0 is a proof of architecture, not a production release. Significant work remains:
Proposal update incomingI will be pushing a revised proposal to this branch that:
Still seeking a Tech & Ops Committee champion. Available to discuss the technical approach and roadmap at any time. |
Reflects the self-funded v0.1.0 alpha release, compresses timeline from 12 to 9 months, restructures to 3 funded milestones, reduces funding ask by ~20%, and adds architectural decisions section. Signed-off-by: Eric Mann <eric@displace.tech>
ericmann
force-pushed
the
proposal/cantool-developer-cli
branch
from
03732c4 to
142e54b
Compare
srikanth-bitdynamics
moved this from Needs Champion
to In Review (Champion Assigned)
in Dev Fund Incoming
|
@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 |
- Restructure "Relationship to Existing Tooling" with ecosystem stack diagram (SVG), delegation map, and per-tool comparison table including PR canton-foundation#105 (dpm DevKit) - Restore cantool package as the DAR lifecycle surface (inspect, upload, deploy); cantool build remains an ergonomic alias for package build - Clarify that compilation, SDK resolution, and dependency lockfiles stay in dpm — Cantool wraps but does not reimplement - Fix stale cantool up/down references to cantool dev - Update Rationale to address PR canton-foundation#105 positioning Signed-off-by: Eric Mann emann@displace.tech
|
@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. 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, 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:
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. |
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 A few clarifications first:
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:
I also revised the proposal text to make the boundaries explicit:
Concretely, I removed or rewrote the parts that were making the proposal sound broader than intended:
So the story is now much simpler:
That narrower scope is what I’m asking the committee to evaluate. |
Remove all dpm/DevKit wrapper commands from funded scope. Restructure from 3 milestones over 9 months to 4 greenfield milestones over 12 months: scaffolding/templates (400K CC), MCP server (450K CC), plugin system (375K CC), environment management (275K CC). Total unchanged at 1.5M CC. Signed-off-by: Eric Mann emann@displace.tech
- Replace "community template registry" and "plugin registry" with patterns, conventions, and best-practices documentation throughout - Remove delegation language; reframe Cantool as complementary to dpm and DevKit with no overlapping scope - Remove Delegation Map table and redundant "three architectural choices" paragraph - Expand "Why not extend existing tools?" with dpm command-removal context and "separate tools, shared ecosystem" framing - Redesign ecosystem SVG from layered stack to Venn diagram showing distinct tool boundaries with explicit "no overlap" labels Signed-off-by: Eric Mann emann@displace.tech
Refine the Cantool proposal to emphasize a focused application-layer scope instead of a unified front door for the ecosystem. Reframe MCP package handling as participant-visible metadata, replace deployment ownership with participant endpoint configuration, and clarify that Cantool does not own SDK management, dependency resolution, or LocalNet orchestration. Signed-off-by: Eric Mann emann@displace.tech
ericmann
force-pushed
the
proposal/cantool-developer-cli
branch
from
b87b1e2 to
88476f5
Compare
|
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 |
daravep
left a comment
daravep
left a comment
There was a problem hiding this comment.
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?
|
|
||
| #### Funded Greenfield Capabilities | ||
|
|
||
| **Project Scaffolding and Community Templates (`cantool init`)** — Generates a buildable Canton project structure with opinionated defaults: DAML source directories, application code scaffold (Go initially, with extension points for additional language templates), Docker Compose configuration for cn-quickstart, CI/CD templates, and environment-specific configuration via direnv. The funded scope deepens this into a full template system: versioned template spec, `cantool init --from <github-url>` for fetching community-hosted templates, template validation, a starter library of templates covering common Canton app patterns (token, marketplace, multi-party workflow), and a documented convention for authoring and sharing community templates. The deliverable is patterns, reference templates, and best-practices documentation — not a hosted registry or marketplace. |
There was a problem hiding this comment.
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 was a problem hiding this comment.
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.
There was a problem hiding this comment.
@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?
|
|
||
| **MCP Server (`cantool mcp`)** — Exposes Canton development capabilities through the Model Context Protocol, enabling AI coding assistants to scaffold projects, query contract state, manage parties, and inspect participant-visible package metadata needed for application workflows. The v0.1.0 proof of concept provides stdio transport; funded work delivers full Ledger API tool coverage (contract queries, party management, participant-visible package metadata), resource definitions for contracts/parties/packages, Streamable HTTP transport for remote and browser-based integration, multi-tool integration testing, and documentation for AI assistant integration. | ||
|
|
||
| **Plugin System (`cantool plugin`)** — Cantool's plugin system uses JSON-RPC over stdio — a language-agnostic protocol that allows plugins written in any language to extend the CLI. The v0.1.0 proof of concept provides plugin discovery; funded work delivers full lifecycle management (`cantool plugin list/install/remove`), a reference plugin SDK (Go + one additional language), documented conventions for plugin authoring and distribution, lifecycle hooks (pre-build, post-deploy, etc.), and a reference plugin demonstrating the full interface. As with templates, the deliverable is patterns and documentation for community plugin authors — not a hosted plugin registry. |
There was a problem hiding this comment.
There are plans to add a plugin system to dpm. dpm is written in Go. I see a lot of potential for collaboration.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
Documentation for dpm's component (aka plug-in architecture) is here. An example is being documented.
| - The reference plugin is published and installable via `cantool plugin install`. | ||
| - At least 3 external developers complete the plugin authoring workflow, and their structured feedback is summarized with resulting revisions. | ||
|
|
||
| ### Milestone 4: Environment Management and Adoption |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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?
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 — 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:
Happy to answer further questions before the vote. |
|
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 |
Fair point, and the proposal under-specifies this. The CLI supports the same operations the MCP server exposes — 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. |
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. |
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.
The configuration model is YAML-based and human-editable, with 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. |
- Descope original Milestone 4 (Environment Management and Adoption) - Add new Milestone 4: OCI component packaging for dpm integration - Compress delivery timeline from 9 months to 6 months - Reduce base ask from 1,350,000 CC to 1,000,000 CC - Adjust early completion bonus structure (100,000 CC for delivery within 16 weeks) - Remove hour-based effort estimates in favor of per-deliverable budget framing - Update comparison tables and architectural decisions to reflect dual-distribution model Signed-of-by: Eric Mann emann@displace.tech
|
Posted a revised version of the proposal reflecting committee feedback from the past few weeks. Key changes:
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? |
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. |
|
|
||
| **Project Scaffolding and Community Templates (`cantool init`)** — Generates a buildable Canton project structure with opinionated defaults: DAML source directories, application code scaffold (Go initially, with extension points for additional language templates), Docker Compose configuration for cn-quickstart, CI/CD templates, and environment-specific configuration via direnv. The funded scope deepens this into a full template system: versioned template spec, `cantool init --from <github-url>` for fetching community-hosted templates, template validation, a starter library of templates covering common Canton app patterns (token, marketplace, multi-party workflow), and a documented convention for authoring and sharing community templates. The deliverable is patterns, reference templates, and best-practices documentation — not a hosted registry or marketplace. | ||
|
|
||
| **MCP Server (`cantool mcp`)** — Exposes Canton development capabilities through the Model Context Protocol, enabling AI coding assistants to scaffold projects, query contract state, manage parties, and inspect participant-visible package metadata needed for application workflows. The v0.1.0 proof of concept provides stdio transport; funded work delivers full Ledger API tool coverage (contract queries, party management, participant-visible package metadata), resource definitions for contracts/parties/packages, Streamable HTTP transport for remote and browser-based integration, multi-tool integration testing, and documentation for AI assistant integration. |
There was a problem hiding this comment.
@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?
| #### Technology Stack | ||
|
|
||
| - **Language**: Go (single binary, strong gRPC support for Ledger API, Cobra CLI framework) | ||
| - **Canton Integration**: Ledger API (gRPC), PQS (PostgreSQL) |
There was a problem hiding this comment.
Will it have integration with the daml.yaml and multi-package.yaml files?
| | Stage | Timeframe | Description | | ||
| |---|---|---| | ||
| | **1A. Template Engine and Versioned Spec** | Weeks 1–3 | Refactor embedded templates into a versioned template specification. Implement template validation (schema checks, required files, metadata). Support parameterized templates with user prompts (project name, party names, target SDK version). | | ||
| | **1B. Community Template Conventions and Starter Library** | Weeks 4–7 | `cantool init --from <github-url>` fetches, validates, and scaffolds from community-hosted template repositories. Template discovery conventions (README badges, topic tags). Template authoring guide and contributor documentation. Starter template library: token contract, marketplace, multi-party workflow. | |
There was a problem hiding this comment.
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?
| - Starter template library: token contract scaffold, marketplace scaffold, multi-party workflow scaffold — each producing a buildable project with DAML source, application code, Docker Compose config, and CI/CD templates. | ||
| - Template authoring guide: how to create, validate, and publish community templates. | ||
| - Template discovery conventions: GitHub topic tags, README badges, and listing format for community templates. | ||
| - Integration test suite for the template engine running against real Canton sandbox environments. |
There was a problem hiding this comment.
Is this proposal limited to running against sandbox?
| - `cantool init --from <github-url>` successfully fetches and scaffolds from a community template repository, with validation errors reported for non-conforming templates. | ||
| - Template spec is versioned and documented; a third-party developer can author a conforming template using only the published guide. | ||
| - Integration test suite passes against a real Canton sandbox — no mocked Canton services in the critical path. | ||
| - At least 3 external developers complete the scaffolding workflow (including community template usage) without author intervention, and their structured feedback is summarized with resulting revisions. |
There was a problem hiding this comment.
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.
| | Stage | Timeframe | Description | | ||
| |---|---|---| | ||
| | **2A. Full Ledger API Tool Coverage** | Weeks 9-12 | MCP tools for contract queries (active contracts, contract history, template filtering), party management (allocate, list, describe), and participant-visible package metadata needed for application workflows (list packages exposed by a connected participant, extract template IDs, DAR metadata where available). Structured tool schemas with typed inputs/outputs. | | ||
| | **2B. Resources, Transport, and Integration Testing** | Weeks 12-15 | MCP resource definitions for contracts, parties, and packages. Streamable HTTP transport for remote and browser-based AI assistant integration. Multi-tool integration test suite verifying tool composition (e.g., scaffold → inspect → query workflow via MCP). PQS integration for efficient contract state queries. | |
There was a problem hiding this comment.
Is the value here: agentic AI driven test generation and execution?
I'm not sure that MCP by itself adds value.
| |---|---|---| | ||
| | **2A. Full Ledger API Tool Coverage** | Weeks 9-12 | MCP tools for contract queries (active contracts, contract history, template filtering), party management (allocate, list, describe), and participant-visible package metadata needed for application workflows (list packages exposed by a connected participant, extract template IDs, DAR metadata where available). Structured tool schemas with typed inputs/outputs. | | ||
| | **2B. Resources, Transport, and Integration Testing** | Weeks 12-15 | MCP resource definitions for contracts, parties, and packages. Streamable HTTP transport for remote and browser-based AI assistant integration. Multi-tool integration test suite verifying tool composition (e.g., scaffold → inspect → query workflow via MCP). PQS integration for efficient contract state queries. | | ||
| | **2C. Documentation and Validation** | Weeks 15-16 | Integration guide for AI coding assistants (Claude, Cursor, Codex) using Cantool's MCP server. Agent-driven end-to-end test: single natural-language prompt completes scaffold → connect → query workflow. External developer validation. Milestone 2 validation summary. | |
There was a problem hiding this comment.
What additional value does this bring from IDE AI agents?
| - Plugin manifest specification: declared capabilities, lifecycle hook subscriptions, dependency requirements, and compatibility constraints. | ||
| - Plugin sandboxing and permission model: plugins declare required permissions; Cantool enforces boundaries. | ||
| - Reference plugin SDK in Go: scaffolding, JSON-RPC handler generation, hook registration, and testing utilities. | ||
| - Lifecycle hooks: pre-build, post-build, pre-deploy, post-deploy, pre-test, post-test — plugins can subscribe to any combination. |
There was a problem hiding this comment.
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. |
github-project-automation
Bot
moved this from Voting Live
to Declined
in Dev Fund Incoming
|
@ericmann completely agree this took too long. |
8 participants
Development Fund Proposal Submission
Proposal file:
/proposals/cantool.md
Summary
Cantool is an open-source CLI tool covering the complete Canton application
development lifecycle: project scaffolding, DAML package management, integration
testing, deployment automation, and an MCP server for AI-assisted development.
Requested funding: 1,875,000 CC (~$300,000 USD) over 12 months across 4
milestones. Scope is complementary to PR #18 (DevKit) and PR #10 (Daml Code
Assistant) — see "Relationship to Existing Tooling" in the proposal.
This proposal was updated on March 23 to align more closely with the review and
delivery structure visible in the first approved grants, including milestone
validation gates, sub-milestone structure, adoption-based acceptance criteria,
ecosystem feedback reporting, and an explicit staged-funding option.
Checklist
/proposals/Notes for Reviewers
Updated March 23 with milestone validation gates, sub-milestone structure,
adoption-based acceptance criteria, upstream issue reporting, and a staged
funding option, informed by the review framework visible in the first two grant
awards.
This proposal targets the application-level development lifecycle that sits
between DAML authoring tools and LocalNet infrastructure management. The
"Relationship to Existing Tooling" section details how Cantool complements
PR #18 (DevKit) and PR #10 (Daml Code Assistant). Cantool delegates to
DevKit for local environment lifecycle when available.
The proposal now includes external developer validation at each milestone,
Developer Experience Reports covering upstream bugs/docs gaps discovered during
implementation, and payment-gated milestone summaries for Tech & Ops review.
The author has production Canton experience including Ledger API, PQS,
cn-quickstart, Canton Enterprise deployments, DAML contract integration,
authentication flows, and internal CLI tooling that directly informs the
proposed architecture.