Add bootnode-canton-dappbooster-dev-stack proposal#390
Conversation
pablofullana
requested review from
hythloda,
isegall-da,
stas-sbi,
tkatrichenko and
waynecollier-da
|
SIG labels auto-detected and applied: If this is incorrect, you can ask the reviewers to update the labels. |
|
@pablofullana, thank you for your interest in the Canton Development Fund! Your proposal does not include a Champion/Endorser field. Per CIP-0100, all external proposals require a Tech & Ops Committee champion. Next steps:
If you need help finding a champion, reach out to SIGs or any Tech & Ops Committee member. This PR is being closed automatically. You are welcome to reopen it once a champion is confirmed. |
github-project-automation
Bot
moved this from Incoming
to Declined
in Dev Fund Incoming
hythloda
moved this from In Review (Champion Assigned)
to Ready for Vote
in Dev Fund Incoming
daravep
left a comment
daravep
left a comment
There was a problem hiding this comment.
Thank you very much for your proposal. There is significant overlap with the Self-Signed OIDC work that is currently being completed by DA, which provides the native ability to authenticate to the user validator as well as to the provider app using self-signed JWTs.
At the same time, Send has already published, their browser variant of a CIP-103 wallet.
Would you be open to connect with the developers of CIP-103, Wallet Gateway and JWT auth to discuss how to structure your proposal in a way that incorporates these changes?
|
|
||
| Canton's Q2 "App Building and Developer Experience" priority area lists reduced developer friction, interoperability across wallets and dApps, wallet gateway and dApp standards, documentation and examples, and lower total cost of ownership. dAppBooster for Canton **v0.1, shipping today**, already collapses local environment setup into a one-command install and demonstrates CIP-0103 end-to-end. | ||
|
|
||
| **This proposal funds the evolution of v0.1 around a single thesis:** in Canton's external party model, a user's identities and signing keys belong to the user, not to any one validator or any one dApp. The reference workflow this stack must demonstrate is therefore **a single self-custodial wallet that holds keys for the user's external parties and interacts with multiple dApps across multiple validators.** The v0.1 establishes the local loop; this proposal delivers the components needed to make that cross-validator, cross-dApp workflow production-shaped: wallet-based identity at the validator boundary (SIWC), per-account scoped sessions via the upstream wallet-gateway, a composable scaffold that can stand up production-like contexts, and a developer-grade wallet that holds up across real apps and real validators. |
There was a problem hiding this comment.
What do you mean with "interacts with multiple dApps across multiple validators"? Where is my party hosted, where do I submit my commands to? How do I authenticate to the dApp and how to my validator? How do I authorize my commands? This is all captured in CIP-103. But you are saying here that you are building something new but you also refer to CIP-103. Can you elaborate?
There was a problem hiding this comment.
We mean, where the party is hosted, where commands are submitted, how the wallet authenticates to the dApp, and how authorization happens. These are all CIP-103, and Carpincho follows the spec. We are not aiming to reinvent any of that; it's not in scope here.
Carpincho (intended for external parties) is discovered by dApps over window.canton.carpincho, signs prepared transactions locally, and submits via wallet-service → participant.
What CIP-103 doesn't yet cover, and what we meant by "multiple validators", is being able to use the same identity across many validators.
Our proposal was to implement a SIWC IdP and extend the wallet-gateway with an external signing provider. SIOPv2 makes that go away: the wallet mints the JWT itself, the validator verifies the signature, no IDP in the loop. That's what we'll integrate once it lands in the wallet-gateway.
|
|
||
| **canton-barebones** is the minimal Canton infrastructure layer: a Canton participant, a local synchronizer, Postgres, the JSON Ledger API, local dev token generation, DAR deployment scripts, and health checks. It intentionally excludes Keycloak/OIDC, PQS, the Splice layer, the business backend, and the frontend app, so the base stays small and predictable. A developer starts from a working Canton runtime and adds only the pieces they need. | ||
|
|
||
| **Carpincho** is a self-custodial browser wallet that implements the Synchronous variant of the CIP-0103 dApp API. Keys are created and stored locally in the browser, and a single Carpincho instance can hold keys for any number of the user's external parties. Carpincho signs prepared Canton hashes locally only after the user approves in the wallet. Private keys never leave Carpincho. |
There was a problem hiding this comment.
Can you elaborate what you mean with synchronous variant of CIP-0103? Is it the CIP-103 API or is it something different?
Also, please note that Send seems to have already built the CIP-103 browser wallet using passkeys: https://info.send.it/docs/send-safe/send-connect
There was a problem hiding this comment.
re: "synchronous variant". That's our coinage, not CIP-103 spec language, and we can do better. We mean the CIP-103 dApp API served over the sync transport, the browser provider injected at window.canton.carpincho. The "async variant" we use for wallet-service is the same CIP-103 API, served over HTTP. Same protocol, different transports. We'll fix the proposal wording.
re: Send Connect. Indeed, they've shipped a real CIP-103 browser wallet, and the WebAuthn PRF passkey UX is genuinely good for the consumer use case.
Carpincho is CIP-0103 compatible, but it is designed as a development wallet. To provide richer tooling than a standard wallet, Carpincho relies on an extended version of the wallet-gateway, which we call wallet-service.
The differences that matter for that use case:
- Protocol-native Ed25519 keys, not derived via WebAuthn PRF. Easier to inject test keys, easier to reason about in CI, no passkey enrollment step.
- Headless / Playwright mode for CI testability. Passkey-based wallets are structurally hard to drive in headless CI. Virtual authenticators help, but PRF in particular has thin test tooling.
- Open development: both the wallet binary and the SDK live in the same canonical public repo, with all commits public. That makes the codebase forkable for teams building on top, not just installable.
- Stack integration: Carpincho ships as one of the components inside dAppBooster, alongside the dev environment and example dApp. Send Connect is a standalone consumer product.
A dApp built with dAppBooster targets any CIP-103 wallet at ship, Send Connect included. Different artifacts for different audiences, no overlap to resolve.
At the time of writing this comment, current POC/alpha version of Carpincho already ships with:
- CIP-56 and Amulet asset listing
- Balances and UTXO inspection
- Token send and transfer acceptance flows
- Amulet preapproval management
- dApp transaction preparation
- Execution of prepared transactions
- prepareExecuteAndWait
- Controlled ledgerApi proxying
- DAR deployments
- Contracts creation
- Choices exercise
- Party activity listing
- Active contract listing for parties
Screenshots of these features here: Carpincho features for developers
And many others in the projected roadmap.
|
|
||
| **Carpincho** is a self-custodial browser wallet that implements the Synchronous variant of the CIP-0103 dApp API. Keys are created and stored locally in the browser, and a single Carpincho instance can hold keys for any number of the user's external parties. Carpincho signs prepared Canton hashes locally only after the user approves in the wallet. Private keys never leave Carpincho. | ||
|
|
||
| **wallet-service** is the bridge between Carpincho and Canton, implementing the Asynchronous variant of CIP-0103. It exposes the operations Carpincho needs while wallet-gateway migration is not yet done: external party creation, transaction preparation, user-approval handoff, local signing, and execution of signed, prepared transactions. It does not store private keys and contains no example-specific business logic. |
There was a problem hiding this comment.
What do you mean with "while wallet-gateway migration is not yet done"?
There was a problem hiding this comment.
wallet-service is our temporary solution while wallet-gateway is under development. It gives Carpincho the async CIP-103 operations it needs today (external party creation, transaction prep, …), because upstream wallet-gateway can't yet serve browser-resident wallets.
wallet-service keeps the base wallet-gateway capabilities, but adds internal RPC methods that Carpincho uses to interact with Canton. It also makes it possible for Carpincho to feature all the developer tools, features, and capabilities it ships with.
|
|
||
|  | ||
|
|
||
| **canton-barebones** is the minimal Canton infrastructure layer: a Canton participant, a local synchronizer, Postgres, the JSON Ledger API, local dev token generation, DAR deployment scripts, and health checks. It intentionally excludes Keycloak/OIDC, PQS, the Splice layer, the business backend, and the frontend app, so the base stays small and predictable. A developer starts from a working Canton runtime and adds only the pieces they need. |
There was a problem hiding this comment.
Note that https://openid.net/specs/openid-connect-self-issued-v2-1_0.html is coming to canton to allow removing the reliance on IDPs.
There was a problem hiding this comment.
Note that this is also covered in this grant here: https://github.com/Stephan-da/canton-dev-fund/blob/64c32415b0c5a01b2ef9d1f742cfb281793e5b99/proposals/wallet-gateway-reference-implementation.md#milestone-4-decentralized-identity-oidc
There was a problem hiding this comment.
The goal has always been to let developers run a complete Canton development stack with a single command, npx dappbooster --canton and get a full local Canton stack running without having to manually (Splice frontend, JS backend, wallet, Splice, wallet-gateway, and wallet-service). Where developers could customize the validators it starts, which optional services to enable, like PQS.
We understand there may be other ways to provide this one-command Canton stack, for example creating DPM templates. During the recent NYC 2026 ETHGlobal hackathon we realized those templates exist. This is the way we propose, but we are open to collaborate with other alternatives if you consider them more appropriate.
|
|
||
| The milestones describe the work in detail. At a high level: | ||
|
|
||
| 1. **Sign-with-Canton (SIWC)** replaces username/password-style auth at the validator boundary with JWTs issued against the party's own protocol signing keys, so the same wallet that signs Daml transactions also proves identity to every validator it talks to. This is what makes the workflow practical at the network level: the same wallet, the same keys, and the user's parties across many validators. |
There was a problem hiding this comment.
Did you implement a new auth method in Canton or where are you validating the JWTs? In the wallet service? We are right now adding this actually as part of the CIP-103 work to Canton, using the self-signed OIDC standard.
There was a problem hiding this comment.
At the moment of submitting this RFP, we were not aware of the existence of self-signed OIDC standard. So this SIWC item is no longer relevant.
@daravep , thanks for the review. The overlap concerns are well-placed and we want to bake them in rather than work around them. Yes to the offer to connect. A call with the CIP-103, Wallet Gateway, and JWT auth folks at DA is the right venue before we revise the proposal body. If you can point us at the right contacts or set it up, we'll coordinate timing as soon as possible (pablo@bootnode.dev). We'll work through the inline feedback and reply on each thread shortly. |
|
@daravep , below is a chart and a condensed list of our proposal's components to make the scope easier to follow at a glance, happy to refine if anything reads unclear. 
Hoping this gives a clearer picture going into the sync with the CIP-103, Wallet Gateway, and JWT auth team at DA. |
3 participants
Development Fund Proposal Submission
Proposal file:
/proposals/bootnode-canton-dappbooster-dev-stack.md
Summary
dAppBooster for Canton v0.1 is an open-source local development stack (live today at github.com/BootNodeDev/cn-dappbooster) that takes a Canton dApp developer from Daml contracts to a working dApp UI on a laptop, including a self-custodial CIP-0103 browser wallet (Carpincho), and one-command local Canton infrastructure. This proposal funds the evolution of v0.1 toward its core thesis: Canton users installs one self-custodial wallet, creates their external parties within it, and uses those same parties to connect to any dApp on any validator. The keys never leave the wallet, the same identities work everywhere, and no dApp or validator can lock the user in.
Checklist
/proposals/Notes for Reviewers