Proposal: Denex Localnet

[mgaare]

Development Fund Proposal Submission

Proposal file:
./proposals/denex-localnet.md

---

Summary

denex-localnet is a Testcontainers-style SDK and CLI for running Canton Network LocalNets, collapsing what would currently require dozens of scattered config files into a single declarative YAML file. It orchestrates the full Canton stack — Super Validator, regular validators, Splice, Keycloak auth, and all associated web UIs — directly via the Docker API (no Docker Compose), with sensible defaults for ports, party hints, realm naming, and OAuth2 wiring.

It lowers the barrier to local development and integration testing: developers can spin up a fully-wired multi-validator network programmatically (via the cross-runtime SDK on Deno/Node/Bun) or interactively (via the Deno CLI), then query state, allocate parties, and provision users through clean high-level APIs. This enables programmatic and flexible integration for app developers, and makes Canton LocalNets viable as ephemeral fixtures in CI pipelines and SDK-driven test suites — a workflow that's currently very challenging with existing tooling.

---

Checklist

• Proposal file added under /proposals/
• Milestones and funding amounts defined
• Acceptance criteria included
• Alignment with Canton priorities described

---

Notes for Reviewers

(Add anything the Tech & Ops Committee should pay attention to.)

[da-tanabe]

From an implementation standpoint, have you seen the declarative API for users/parties? (https://docs.digitalasset.com/operate/3.4/howtos/configure/general/declarative_conf.html)

It would be nice if, as part of this, changes were implemented in lower levels of the stack so that components understand declarative APIs more natively.

[mgaare]

I hadn't seen that before. It looks interesting.

denex-localnet also provisions the users in keycloak from this config, and it's network-wide rather than localized to a single participant, so a 1-1 correspondence with the dynamic participant config feature probably isn't possible. It's worth thinking about using it in the implementation, though.

[vadasnorbert]

Based on our experience with Canton dev environments, a “Hardhat-like” tool could be very useful for Canton, and could significantly improve the developer experience for both new and experienced Canton builders.

The proposal also directly addresses one of the clearest pieces of feedback from the DevEx survey, i.e. the need for better local development frameworks and simpler environment setup. In addition, features described in the proposal, such as the single-file declarative configuration, programmatic API for lifecycle, or the runtime state inspection/discovery could potentially offer capabilities beyond those of existing frameworks. Personally, I am supportive of this proposal.