What an EVM developer gets from a CLI toolkit, a browser wallet, and a frontend starter, now for Canton: a self-custodial browser wallet, a local participant and synchronizer, and a wallet-service bridge that executes real approval flows on your laptop. No OIDC, no production backend, no external access approvals.
→ npx dappbooster --canton dAppBooster includes an end-to-end example. Run it, fork it, or read it as a starting point. The example exercises every step of the loop: write a Daml template, deploy the DAR, pair the browser wallet, and sign a real Canton transaction.
local participant + synchronizer
self-custodial browser wallet
CIP-0103 bridge
ready-to-start React frontend
end-to-end Canton dApp
With the current stack, a developer can:
The goal is fast iteration: write Daml, deploy it locally, connect a dApp, and verify that a real wallet approval flow executes Canton transactions.
Each piece of the stack runs locally and ships with the source you need to fork it for your own dApp.
Minimal Canton infrastructure layer.
Includes
Intentionally excludes Keycloak/OIDC, PQS, SV infrastructure, business backend, official wallet, Splice, frontend app.
The base stays small and predictable. A developer can start from a working Canton runtime and add only the pieces they need.
View on GitHubSelf-custodial browser wallet · CIP-0103 (Sync dApp API)
Carpincho implements the CIP-0103 dApp API. The wallet creates an Ed25519 key in the browser, stores the private key locally, and exposes wallet-provider behavior to dApps (connect, listAccounts, signMessage, prepareExecute, ledgerApi). When a transaction is prepared, the user approves it in the wallet, and Carpincho signs the prepared Canton hash locally.
The private key never leaves Carpincho.
View on GitHubA temporary bridge between Carpincho and Canton · CIP-0103 (Async dApp API)
wallet-service exposes the CIP-0103 operations Carpincho needs while we are still before the wallet-gateway migration: external party creation, transaction preparation, user-approval handoff, local signing, and execution of signed prepared transactions.
Does not store private keys. Does not contain example-specific business logic.
View on GitHubReady-to-start React frontend for Canton dApps.
react-starter uses the Canton dApp SDK to connect to a wallet provider, build generic Daml commands, list accounts, read ledger state, and approve transactions. It includes the example pre-wired, but works with any Daml application, not just the example.
Does not store private keys. Does not depend on example-specific wallet plumbing.
View on GitHubAn end-to-end Canton dApp.
The example exercises every step of the loop: a Daml template, a DAR deploy, a paired browser wallet, and a signed Canton transaction. Fork it as the starting point for your own dApp.
View on GitHub
The official Canton Network Application Quickstart is a complete enterprise-style demo built by Digital Asset. It is scaffolding for shipping a real Global Synchronizer application, and includes preconfigured users, known parties, OIDC login via Keycloak, a Spring Boot backend service, PQS instances, JSON Ledger and Validator admin APIs, App Name Service and Scan UIs, an end-to-end install / license / renew workflow, an observability stack (Grafana, Prometheus, Loki, Tempo), and a multi-actor local network (built on Splice LocalNet) closer to production.
That is useful when the goal is to understand the full production-oriented stack.
dAppBooster solves a different problem: a fast Canton dApp development loop.
Parties are still central. We are not removing the Daml party model. We are simplifying the user layer during local development, so an individual developer can write Daml, deploy a DAR, and execute a real wallet approval flow without standing up Keycloak, a Spring Boot backend, or PQS.
dAppBooster Canton v1 has one deliberate scope cut to keep the dev loop fast: wallet-service uses a single technical Canton user to talk to the Ledger API. That is acceptable for local development. It is not the right production model.
The issue is permission scoping. The technical user can accumulate rights over parties created during testing.
External signatures protect every write. wallet-service cannot construct a valid transaction signature without Carpincho, and Carpincho only signs after the user approves in the wallet.
A broad backend token can read more than a user-scoped wallet session should.
dAppBooster Canton is open source under the MIT License. Repository: github.com/BootNodeDev/cn-dappbooster.
Built on dAppBooster for EVM.
dAppBooster for Canton did not appear out of nowhere. The EVM-side dAppBooster has been shipping and improving with web3 builders for years. The Canton version is built by the same team and applies the same architecture, best practices, and developer-experience lessons, adapted for the Canton ecosystem.
Common questions about what dAppBooster Canton is, how it fits next to the official Canton tooling, and what the local dev loop looks like in practice.
