Proposal: Canton devkit (dpm component) - a unified toolkit for Canton app development (LocalNet, dar helpers, etc)#18
Conversation
zheli
requested review from
hythloda,
isegall-da,
stas-sbi,
tkatrichenko and
waynecollier-da
zheli
changed the title
zheli
changed the title
zheli
force-pushed
the
canton-devkit
branch
2 times, most recently
from
243b4c9 to
2613465
Compare
srikanth-bitdynamics
moved this from Needs Champion
to In Review (Champion Assigned)
in Dev Fund Incoming
| All features covered by CLI commands but with a user-friendly interface. | ||
|
|
||
| ###### AI Coding Agent Integration | ||
| AI skill and command to work with the LocalNet using canton-devkit that supports Claude, Codex. |
There was a problem hiding this comment.
I think this part should not be part of DevKit. Each person typically has their own editor with their own setup. DevKit should concern about building primitive (the infra, the local setup) and not be the how one write code.
There was a problem hiding this comment.
I am thinking of something like this https://github.com/ClickHouse/agent-skills/blob/main/skills/clickhousectl-cloud-deploy/SKILL.md actually.
So you could just write "compile and test the new daml code and deployt to localnet 1" in your ai coding agent and it will call the correct command to upload to the corresponding localnet deployment.
| The existing LocalNet setup requires manually downloading Splice bundles, exporting environment variables, composing multi-flag Docker commands, and understanding Docker Compose profiles. DevKit collapses this into: | ||
|
|
||
| ###### CLI Commands | ||
| * `canton-devkit localnet up` / `down` / `restart` / `clean` / `status` / `logs` — a single installable CLI that downloads the latest Splice LocalNet bundle, generates configs, keys, and identities, starts the Docker stack, runs health checks, and prints ready-to-use endpoints (Ledger API, Admin API, JSON API, wallet UIs) and token credentials. |
There was a problem hiding this comment.
I have a few question about this canton-devkit
- How does
canton-devkitbinary get distribute? is it pre-build binary across platform (Window/Linux/Mac arm64/amd64) . - Does user need to setup any programming language for this to run (nodejs/python) or this is executeable binary
- How does docker setup is handle
There was a problem hiding this comment.
Thanks for the questions!
I have a few question about this
canton-devkit* How does `canton-devkit` binary get distribute? is it pre-build binary across platform (Window/Linux/Mac arm64/amd64) .
I am more leaning towards Golang or rust where I can have static linked library and a single binary for each platform.
* Does user need to setup any programming language for this to run (nodejs/python) or this is executeable binary
Yeah. I am trying to avoid that so I think a single binary cli file should be the cleanest. Althought i might need to store some settings locally in user's home folder.
* How does docker setup is handle
Do you mean how user should install their docker in their environment? That's a good question, I haven't thought about it. It will probably require user to install docker runtime themselves. (Docker desktop on macos, docker on linux)
|
@v9n updated proposal based on your feedback |
hythloda
moved this from In Review (Champion Assigned)
to Ready for Vote
in Dev Fund Incoming
leonidr-c7
left a comment
leonidr-c7
left a comment
There was a problem hiding this comment.
I think this is an exciting project:
- Will there be any open-source artifacts as a result of the project? Perhaps some of the CLI elements will call library code that could be externally?
- Furthermore, what will be the long term governance of this tool?
- I wish that the funding had more weight towards Milestone 4; focusing on external adoption of the tool, so that this proposal demonstrates developing for the broader ecosystem.
|
|
||
| The solution is delivered as a **standalone CLI application** (`canton-devkit`) with web UI. It will be implemented in **Go** and distributed as standalone native binaries for macOS and Linux on arm64 and amd64. End users will not need Go, Node.js, Python, Rust, or a source checkout to run it. DevKit uses Docker containers and runs LocalNet using Splice nodes, but packages the developer experience into a single binary that requires no git clone, no Makefile knowledge, and no manual environment variable setup. It will also include other optional helper services that developers can enable or disable as needed. | ||
|
|
||
| Windows native support is out of scope for the initial grant. Windows users may be documented later through WSL2 if there is demand, but it is not part of the committed deliverables. |
There was a problem hiding this comment.
A big market to ignore from the start https://survey.stackoverflow.co/2025/technology#1-computer-operating-systems
There was a problem hiding this comment.
Good point — Windows is definitely a meaningful segment.
The main constraint for us right now is practical: we don’t currently have any Windows environments, which makes it hard to properly test, validate, and reliably estimate the effort required for native support. Rather than overcommitting early, we’re prioritizing macOS and Linux where we can deliver with high confidence.
This is not a long-term exclusion. If we see demand or traction from the tool or Windows users, we’ll revisit it — likely starting with a WSL2-based path before considering native support.
Appreciate you raising it.
There was a problem hiding this comment.
We do not need amd64 for macOS. However Windows support is mandatory IMO. Commitment to a Windows implementation should be included in one of the planned grant phases (even if it is a late one). If it were not the case, it would create a gap that may never be closed as contributors come and go.
| * **Milestone 1:** **3 voting member companies** have installed a binary release and successfully run `localnet up/status/down` on macOS or Linux, with at least one tester validating named-instance isolation using explicit non-conflicting ports. | ||
| * **Milestone 2:** **5 voting member companies or representative Canton deployments** have used the Web UI, DAR workflow, contract explorer, transaction explorer, or observability workflow against their own DAR/application and provided feedback artifacts. | ||
| * **Milestone 3:** At least **5 external projects/teams** demonstrate a LocalNet CIP-56 workflow such as `create -> mint -> transfer` or `mint -> transfer -> burn` and provide feedback or demo artifacts. | ||
| * **Milestone 4:** Sustained external adoption is demonstrated through at least **2 public workshops** and **1 case study/blog post**, plus compatibility updates across newer Splice releases and public issue or release-note evidence that feedback was incorporated. |
There was a problem hiding this comment.
Sustained external adaption would be better measured via a clear metric that is perhaps not too game-able; github-stars or unique downloads?
There was a problem hiding this comment.
@leonidr-c7 I think below would be fine?
Unique binary downloads (per release, deduplicated by installer fingerprint where possible) — primary metric
GitHub stars and unique cloners — secondary, directional signal
External projects publicly demonstrating CIP-56 workflows built on DevKit — kept from Milestone 3 since it's the strongest signal of real adoption
There was a problem hiding this comment.
Sustained external adaption would be better measured via a clear metric that is perhaps not too game-able; github-stars or unique downloads?
Good points 👍 GitHub stars are useful for visibility, but they don’t necessarily indicate real usage.
I’ll track adoption using a combined set of indicators: stars, download counts, and privacy-preserving telemetry (with user opt-out).
However, given telemetry opt-out, I won’t rely on one metric alone; instead I’ll use a composite view and focus on sustained trends over time. Would that be better?
There was a problem hiding this comment.
All of those are great, and I like your approach of melding the metrics. As long as there is transparency about what you are measuring, how and the goal then I am in support.
There was a problem hiding this comment.
Thanks a lot! I have updated the proposal based on your feedback.
|
Hi — BitSafe here. We're an active Canton LocalNet operator currently implementing CIP-56, so a unified DevKit that streamlines local development and testing lands directly in our workflow. We've been navigating the current tooling friction firsthand, which is why this proposal caught our attention. A few exploratory questions:
Happy to share more about our LocalNet setup and testing patterns if it would help inform the DevKit design — feel free to loop us in. |
|
@leonidr-c7 thanks for the comments!
The project will be fully open-sourced. The primary artifact is a CLI binary (canton-devkit) that can be invoked directly from the command line, and it also can launch a web server to serve the web UI locally. Binaries will be distributed for macOS and Linux (arm64/amd64), with Windows support planned for the future.
Initially, governance will be guided by the Canton Dev Fund committee as the primary funder of the project. Long-term governance beyond that is still to be determined. Good question.
Thanks for the feedback. This is a valid point, and I'd like to wait for the committee's input before considering any structural changes to the milestones. |
|
Thanks for the comments @Akibalogh !
That's a valid concern. We're planning to optimize the monitoring stack to minimize resource usage, and the monitoring components (Prometheus, Grafana, Tempo) will have on/off switches so developers can enable only what they need. We're also considering removing Loki from the default setup. Since the monitoring stack can be shared across multiple LocalNet instances, the overhead per instance should be manageable.
Our default support model is best-effort, with a clearly defined support window/cutoff timeline for each breaking Splice release. We will own compatibility patches within that window and communicate expected timelines early so teams can plan upgrades. If there is broader demand for stricter guarantees, we are open to introducing an SLA-based support tier with defined turnaround commitments.
By "CIP-56 V2" do you mean CIP-0112? That's a good point. We plan to deliver a V2-first wizard in the early milestones to align with the expected direction of the standard and provide immediate value for new projects.
Thanks for raising this. Our view is that the two efforts are related but operate at different layers. To avoid duplication, we will proactively coordinate with the Denex team on the LocalNet surface area. The goal is to ensure the ecosystem does not end up funding two overlapping lifecycle CLIs, and to converge where practical (or clearly separate responsibilities where not).
The 12-month window is intended to validate adoption and community interest. Depending on uptake, the path forward is either a follow-on maintenance grant or a handover to DA — whichever the Committee judges best. We'll surface adoption metrics through the milestones so the decision has data behind it. |
|
|
||
| ###### LocalNet Configuration Model | ||
|
|
||
| DevKit will make the important LocalNet inputs explicit: instance name, Splice version, port settings, enabled optional services, observability settings, startup DAR uploads, and LocalNet-only token test setup. The initial scope does not require a full topology language; the priority is a predictable, documented configuration surface for common local development, workshop, and CI workflows. |
There was a problem hiding this comment.
When you say "The initial scope does not require a full topology language" what do you mean?
By default which topology would be picked by the canton-devkit, will it be identical to cn-quickstart?
Could canton-devkit provide an alternate minimal topology along with the default one, which could allow saving system resources.
There was a problem hiding this comment.
When you say "The initial scope does not require a full topology language" what do you mean?
By default which topology would be picked by the canton-devkit, will it be identical to cn-quickstart? Could canton-devkit provide an alternate minimal topology along with the default one, which could allow saving system resources.
Honestly, I'm not sure why I phrased it that way 😂 — I think I was thinking about a more programmable config feature down the road. By default, canton-devkit uses the splice repo topology (2 validator/participant + 1 super validator).
Good idea on a minimal topology though — I'll add that as an option in the proposal 👍
| * `canton-devkit dar diff <package-a> <package-b>` — human-readable diff of templates/choices/fields between two package versions, with SCU-compatibility signals (name/version/LF-version/field deltas). | ||
| * `canton-devkit dar remove <package-id>` — unvet / remove where supported by the participant admin API. | ||
| * `canton-devkit dar build [--project <path>]` — optional thin shortcut that invokes `dpm` (or `daml build`) and uploads the result; skipped with a clear message if `dpm` is not installed. | ||
| * `canton-devkit dar watch <project>` — watch mode: rebuild via `dpm` and re-upload to selected participants on source change for a hot-deploy loop. |
There was a problem hiding this comment.
This is interesting; could this tool take care of package-version/name such that upload just works. Or user will have to restart network from scratch to avoid package upgrade issues
There was a problem hiding this comment.
This is interesting; could this tool take care of package-version/name such that upload just works. Or user will have to restart network from scratch to avoid package upgrade issues
Great point. I want devkit to handle as much as possible for devs, but I'm now less sure that auto re-deploy on every save is a good idea... I'm leaning toward watch only rebuilding on version bumps/name changes for re-upload. WDYT?
There was a problem hiding this comment.
My suggestion is to remove this unless users want it. In full-auto redeploy mode I would expect some sort of patching of the name with random string to not hit the upgrade issues, and the user's app would simply use the latest uploaded package.
| - (Experimental) Cost projection view estimating how observed transaction patterns translate to traffic costs on Mainnet. | ||
| - **Adoption Metrics:** at least 3 companies have started using it in their daily Canton development workflow. | ||
|
|
||
| ### Milestone 3: Token Faucets & CIP-56 Token Tooling |
There was a problem hiding this comment.
I think this will be really useful, but is it possible to have this as Milestone 2, and move web UI work to Milestone 3?
There was a problem hiding this comment.
I think this will be really useful, but is it possible to have this as Milestone 2, and move web UI work to Milestone 3?
Good point — I'm open to swapping them. Token Faucets & CIP-56/CIP0112 tooling probably delivers more immediate dev value than the web UI. I'll wait a day or two for any other reviewer input, then update the proposal.
| ##### DAR Management | ||
|
|
||
| Today developers upload DARs to each LocalNet participant manually (via `daml ledger upload-dar`, the JSON API, or the Canton Console), and there is no built-in way to inspect, diff, or hot-redeploy packages across a multi-participant LocalNet. DevKit closes that gap without replicating `dpm` / `daml build` — it accepts pre-built DAR files and, when `dpm` is available on `PATH`, offers an optional build+upload shortcut that delegates compilation to `dpm`. | ||
|
|
There was a problem hiding this comment.
Note that DPM (which is replacing daml) has been built for much better extensibility, but in a first iteration, it just covered the bare operations that had to be carried over from the daml CLI.
In that light, I would ask you to consider instead of rolling out another CLI to integrate your commands directly into DPM. I'd be happy to connect you with the maintainers of DPM in that regard.
There was a problem hiding this comment.
Sure @daravep we will be happy to disuss and have Dpm as the only CLI
There was a problem hiding this comment.
Note that DPM (which is replacing daml) has been built for much better extensibility, but in a first iteration, it just covered the bare operations that had to be carried over from the daml CLI.
In that light, I would ask you to consider instead of rolling out another CLI to integrate your commands directly into DPM. I'd be happy to connect you with the maintainers of DPM in that regard.
Hi @daravep thanks for the comments. What do you think if we release the tools both as a standalone binary and as a native dpm component? I believe adding it to dpm as a component should be a low effort change technically for most of the proposed features. And we can release it like that already in milestone 1. We will be happy to discuss with dpm team on the details. What is the best channel to reach out?
There was a problem hiding this comment.
@daravep updated the proposal and choose dpm as the primary distribution method.
|
|
||
| ###### Web UI Features | ||
| * Drag-and-drop DAR upload with per-participant vetting toggles. | ||
| * Package explorer tree: modules → templates → choices → fields (with types), interfaces, dependencies, and hashes. |
There was a problem hiding this comment.
Note that we wanted to beef up the package metadata endpoints in order to support this much better on the Ledger API.
| * `canton-devkit dar watch <project>` — watch mode: rebuild via `dpm` and re-upload to selected participants on source change for a hot-deploy loop. | ||
|
|
||
| ###### Web UI Features | ||
| * Drag-and-drop DAR upload with per-participant vetting toggles. |
There was a problem hiding this comment.
A word of caution: modifying the whole package management and vetting logic is on our roadmap to rebalance the trust assumption around party <-> particpant. Do not assume that the current vetting logic is going to remain exactly the same as it is now. It must become better.
There was a problem hiding this comment.
A word of caution: modifying the whole package management and vetting logic is on our roadmap to rebalance the trust assumption around party <-> particpant. Do not assume that the current vetting logic is going to remain exactly the same as it is now. It must become better.
Thanks for the heads-up — understood. The proposal is mainly focused on improving the LocalNet developer workflow around the current APIs, not assuming the existing vetting model is the long-term design.
We’ll reach out to the package management / DPM team to better understand the roadmap and make sure the tooling is designed in a way that can evolve together with the upcoming trust model changes.
| * `canton-devkit tx show <tx-id|offset>` — render the transaction as a tree of creates and (nested) exercises, with contract IDs and choice arguments. | ||
| * `canton-devkit tx replay <tx-id>` — reconstruct the per-party visibility projection ("what this party sees") for debugging privacy and authorization issues. | ||
|
|
||
| ###### Web UI Features |
There was a problem hiding this comment.
Note that this functionality was previously delivered by Navigator. I do think that this is indeed a missing gap.
| * **Saved queries / bookmarks** shareable via URL, and an ad-hoc **event subscription panel** that updates in real time. | ||
|
|
||
| ###### Implementation Notes | ||
| * Backend uses Ledger API v2: `StateService.GetActiveContracts`, `UpdateService.GetUpdates`, and `EventQueryService`, with `PackageService` + DAR metadata (from the DAR Management feature) to decode payloads into typed form. |
There was a problem hiding this comment.
As said, we wanted to improve the package metadata endpoint to support exactly such workflows. The team is happy to collaborate with you on this.
There was a problem hiding this comment.
100% Please let us know who to connect with, we will work with them @daravep
…ation paths. Update documentation to reflect support for macOS, Linux, and Windows from the start, and improve details on Docker preflight checks and standalone binary release artifacts. Ensure consistency in installation guides across all platforms.
…toolkit Introduce two new images: 'devkit-mock-overview.png' illustrating the LocalNet dashboard and 'devkit-mock-token-faucet.png' showcasing the token toolkit interface. Update documentation to reference these mockups, enhancing clarity on proposed UI features and functionalities.
…pdate documentation to streamline command descriptions for contract tracking, ensuring consistency in naming conventions and improving overall readability.
zheli
changed the title
|
Champion identified: List OR need The committee will verify this champion during review. |
zheli
changed the title
|
Champion identified: List OR need The committee will verify this champion during review. |
3 similar comments
|
Champion identified: List OR need The committee will verify this champion during review. |
|
Champion identified: List OR need The committee will verify this champion during review. |
|
Champion identified: List OR need The committee will verify this champion during review. |
|
HI @zheli ! Michael from Denex here. There are some compelling ideas here.
At the request of the committee, we split the localnet part of that referenced proposal into a separate proposal: Proposal: Denex Localnet #318 I think some collaboration could be valuable here. One of the major pain points that we see and are addressing with our system is the difficulty in managing configuration using the current splice-localnet layer. Specifying participants, users, parties, network bindings, and authentication layer considerations on Maybe there's a case here for using our I do think it's a miss to say that topology, user and node-level configuration is out of scope for tools like this. That leaves a set of problems for developers to still solve. |
…phrasing regarding the `build-upload` shortcut. This update enhances readability while maintaining the focus on the functionality of uploading DARs to LocalNet participants.
Thanks, Michael — appreciate the input. The proposal is already finalized/approved, so it’s hard to make substantial amendments right now without impacting scope/timeline. Let’s revisit the config/topology pieces after we deliver our first milestone and reassess alignment then. We’re also open to coordinating with your team (and others) to avoid duplication and explore convergence—let’s revisit after milestone 1. |
Milestone 1: LocalNet Management — CLI
|
Milestone 2: Web UI, Observability, Monitoring, DAR & Contract Tooling, Optional AI Agent Skill Documents
|
Milestone 3: Token Faucets & Token Standard Tooling (CIP-0112)
|
Milestone 4: Adoption Validation and Ecosystem Outreach
|
|
(Optional)Milestone 5 ### Optional Maintenance & Compatibility Extension An additional 600,000 CC is proposed as a separate optional extension covering 12 months of post-grant maintenance and Splice upgrade support after completion of the base proposal. If approved, this optional extension would cover:
This optional extension is not included in the 1,900,000 CC base proposal total above. If approved in addition to the base proposal, the combined total would be 2,500,000 CC. Funding is requested in Canton Coin, consistent with the Development Fund's CC‑denominated, milestone‑based grants model under CIP‑100.
|
|
Inspired by the 2026 DevEx survey, I’ve drafted a proposal for Canton Launchpad, a visual local control plane featuring a real-time topology canvas and a PostgreSQL snapshot engine that slashes ledger recovery times from 10 minutes to under 3. It solves the ecosystem's most urgent onboarding hurdles by turning opaque gRPC handshakes and JVM exceptions into clear, plain-English diagnostics. I'm currently looking for a champion to back the proposal, so if this aligns with your work, I'd love your feedback on our live PoC! |
13 participants
Development Fund Proposal Submission
Proposal file:
/proposals/devkit.md
Summary
Canton DevKit is a unified, open-source local developer environment tool for the Canton Network that leverages the existing LocalNet stack. It delivers one-command LocalNet lifecycle management, integrated observability dashboards, and CIP-0112 token faucets and tooling — lowering onboarding time for new developers, workshop participants, and hackathon teams. The project is structured across 4 milestones over 12 months and requests 1,900,000 CC in milestone-based funding, with an optional 600,000 CC Maintenance & Compatibility Extension covering 12 months of post-grant support (2,500,000 CC combined if both are approved).
Checklist
/proposals/