Add bootnode-canton-dappbooster-dev-stack proposal

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?

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

What do you mean with "while wallet-gateway migration is not yet done"?

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.

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.

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?

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

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?

@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 (p***@bootnode.dev).

We'll work through the inline feedback and reply on each thread shortly.

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.

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.

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.

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.

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 , 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.

• [New] dAppBooster CLI: a single command npx dappbooster --canton with everything you need to build Apps on Canton.

• [Existing] Splice: provisions a local instance of the standard Splice stack developed by Canton.

• [New] Wallet-Gateway for Developers: (formerly named wallet-service) extends the existing CIP-103 wallet-gateway with developer-focused capabilities. It exposes an RPC interface with methods such as prepareTransaction, executePrepared, cip56.listPendingTransfers, cip56.listHoldings, and many others.

• [New] dApp Backend: based on the Quickstart backend example, it's a TypeScript backend that acts as a bridge between the frontend and the Canton infrastructure, enabling contract queries, PQS access, and other backend services.

• [New] dApp Frontend: a TypeScript + Vite scaffold that provides the building blocks common to most Canton dApps, including wallet connectivity, connected-party visualization, and other essential integrations.

• [New] dApp Components: a collection of reusable React components for Canton dApps, including: token inputs, token selectors, party inputs, bigint inputs, and other commonly needed UI elements.

• [Temporary] Connect Kit: a lightweight connector that enables frontend applications to discover Carpincho through window.canton.carpincho. This component can eventually be replaced by PartyLayer if it adds support for automatic wallet discovery through the window.canton namespace.

• [New] Carpincho: a browser wallet extension designed for Canton developers.

  • End-user features: create external parties, manage token holdings, transfer tokens, approve transfers (CIP-56 and Amulet support), and view transaction activity.
  • Developer-oriented features: when connected to Wallet Gateway for Developers, Carpincho unlocks advanced development workflows such as DAR deployment, contract creation, choice execution, active contract inspection, and additional capabilities planned on the roadmap.
  • demo video: carpincho wallet demo

• (New) CIP-56 faucet: a local faucet that allows any connected party to manage sample CIP-56 utility tokens.

Hoping this gives a clearer picture going into the sync with the CIP-103, Wallet Gateway, and JWT auth team at DA.

As mentioned above and during the meeting, this is redundant with the introduction of the "native" self-issued OIDC work done as part of the milestone 4 in the referenced Wallet Gateway proposal.

During our meeting we have discussed that the wallet-service (component mentioned above) is a stop-gap solution. Instead, the work should go towards making the wallet-sdk (or underlying core modules for that matter) fully working in the browser context.

We further discussed that in terms of an extension to the wallet gateway, it would make sense to build a test-layer to the upcoming browser extension deployment (see https://github.com/canton-foundation/canton-dev-fund/blob/main/proposals/2026-03-DA-proposal-open-source-reference-wallet.md#milestone-3-splice-wallet-browser-extension). Development will start here soon: https://github.com/canton-network/wallet/tree/main/wallet-gateway/remote

I see it as a benefit to the community to have such dev starter kits!

As mentioned above and during the call, the browser extension itself is redundant with https://github.com/canton-foundation/canton-dev-fund/blob/main/proposals/2026-03-DA-proposal-open-source-reference-wallet.md#milestone-3-splice-wallet-browser-extension.

We see benefit in the dAppBooster, particularly the react-starter and would also encourage starter-kits for different frameworks to driver a broader adoption.

Thank you very much for the proposal and the contribution already done. It was also great to talk in person. This review (see comments below) summarises the feedback provided during the call.

In general, while there are a few items that are redundant due to other proposals or existing implementations, we see great value in the development-kit side of the proposal. A local development starter (barebones) and the react (ideally also other frameworks) boilerplates would drive dApp development and therefore adoption of the CIP-103.

We also stated that we are happy to receive contributions agains the canton-network/wallet repository, particularly when it comes to providing automated testing facilities to dApp Servers.

To summarize this according to the milestones of this proposal:

• X Milestone 1: Sign-with-Canton (SIWC) identity provider: redundant due to other proposal.
• X Milestone 2: Extending wallet-gateway: obsolete component; instead focus on improving wallet-sdk and core modules.
• Y Milestone 3: canton-barebones: I see value in this.
• X Milestone 4: Carpincho: redundant due to other proposals and existing browser extensions.
• Y Milestone 5: dAppBooster: I see value in the react-starter and ideally support for other frameworks

Thanks @mjuchli-da and @daravep for the earlier review. We've substantially reworked this proposal to reflect the feedback and just pushed the updated version.

What changed:

• Refocused on the developer-experience layer: canton-barebones + dAppBooster. Dropped SIWC, the wallet-gateway extension, and Carpincho-as-a-wallet (redundant with existing/planned ecosystem work).
• Wallet-agnostic throughout: builds on top of the dApp SDK and any CIP-0103 wallet (including the Foundation's reference wallet), not alongside them.
• Added canton-token-forge: a CIP-56-compliant local token registry so devs can build and test against realistic stand-in assets; open to tracking Token Standard v2 as it stabilizes.
• Added a six-month post-delivery ownership milestone: active maintenance and upstream tracking through the initial adoption window.
• Quantified adoption targets and clear per-milestone acceptance triggers.
• Open to upstreaming suitable components into canton-network/wallet, in coordination with the Foundation.

The full updated proposal is in the diff above. Would love your thoughts, and happy to jump on a call if useful.

Thanks for making these changes.

The DA team has reviewed the proposal, and its scope sounds appealing to our team in principle.

Given the size of the grant (both funds and time), the fact that BootNode is new to this ecosystem, and that the already-delivered v0.1 doesn't have external traction yet, I would feel more comfortable if we could either (1) scope this down to a bare-minimum MVP (e.g. M1 only followed by an adoption milestone) and demonstrate adoption on that before funding further scope, or (2) see significant evidence of traction for developer tooling BootNode has built and distributed itself in other ecosystems.

The closest analog to this proposal from BootNode seems to be dAppBooster for EVM, which after ~2 years shows 17 stars, 4 forks, ~100 npm downloads/month, and doesn't appear to have external contributors. I'm aware Open Intents Framework is widely used, but that's a larger product where I don't believe adoption was led by BootNode (please correct me if I'm wrong).

To be clear, I'd love to have BootNode as an ecosystem builder and don't want to deter you. All of this is my personal opinion and I'm not speaking on behalf of the other voting members, who may think differently. But we've learned the hard way that each approved grant incurs a high cost in review cycles throughout its lifecycle, so I feel the need to protect our collective teams and resources and to scrutinize the track record of new teams in the ecosystem a bit more before voting. Where we can't establish a track record of independently driving adoption, I'd prefer to keep initial grants bite-sized to keep financial and time-commitment risk low.

Hi @shaul-da, thank you for the direct feedback and for stating exactly what would make you comfortable. We are taking your option (1): scope this down to a bare-minimum MVP. The proposal has been updated alongside this comment.

Summary of what changed and why.

On track record. Fair point, and we won't argue it. dAppBooster for EVM has not achieved meaningful external adoption. On Open Intents Framework, adoption was not led by BootNode; our contribution there was engineering plus enablement work (workshops, hackathon presentations and office hours, blog posts, tutorials), not distribution ownership. One clarification: Dark Pool, the EthGlobal NYC Canton track winner, was built by BootNode on dAppBooster v0.1. We cite it as proof that the stack could take a team from zero to a running dApp under hackathon time pressure, explicitly not as external adoption.

The restructure:

1. Bare-minimum MVP. The proposal is now a single delivery milestone that hardens v0.1 into a reusable starter others build on, productionizing it, not rebuilding it: canton-barebones evolved into a composable CLI (Splice bundle, wallet-gateway, PQS optional, no auth of its own), a minimal dAppBooster (wagmi-canonical hooks with CIP-0103 connection logic plus core React components), one working example dApp connecting to any (CIP-0103) wallet, and agentic-ready documentation.

2. Everything else is out of this grant. canton-token-forge, extended components and framework bindings, and post-delivery maintenance are removed. Each returns, if at all, as a separate future proposal justified against the adoption evidence this MVP produces.

3. Two payment events, 50/50. Total request drops from 1,780,000 CC to 750,000 CC. 375,000 CC is paid on committee acceptance of the full MVP. The other 375,000 CC sits behind a single adoption review at the close of a 12-week window: tiered targets calibrated to what an MVP can honestly earn in that time (details in proposal)

4. On time. The previous version read as a 12 weeks + 6 months maintenance engagement; that was a communication mistake on our side. Milestone weeks were effort, not calendar, across parallel workstreams staffed by an existing team. The calendar commitment is now explicit: 5 weeks of delivery effort, then the 12-week adoption window, closing the full engagement in roughly 4.5 months.

5. On the committee's time. We understood the point. The original structure asked the committee for six milestone validations; this version asks for two: one acceptance of the MVP, and one adoption review at a fixed date, designed to be mechanical, checked against the verification methods pinned in the proposal rather than requiring judgment calls.

During the adoption window, we'll run a committed adoption program (public workshops, a getting-started tutorial, office hours on a public schedule, talk at hackathons if we attend), the same work we did for OIF, this time for a stack we own.

If the committee would prefer this cut further, we're open to discussing it. Our view is that this is the smallest unit that both proves the days-not-weeks thesis and gives the adoption milestone something real to measure.

Please work with @mziolekda to see how to integrate this natively into dpm so we don't end up with yet another CLI.

I think that these adoption criterias should be "production applications", not PoCs or Hackatons. It's much simpler to validate and also ultimately, the value lies with prod apps, not PoCs.

In the end, it's very hard to judge such projects based on the delivered artifacts. The importance and measureable factor remains adoption.

@mziolekda we are already planning this on our end, and tried to reach you out as well.

Supportive of this. I like the smaller scope and the focus on a simple dev stack + reusable app components. I think a clean end-to-end example that a developer can pick up and run with a real wallet would be a great first milestone. If that works well, it also gives a much clearer adoption path.

Thanks @daravep , we've thought this through and agree: production applications are simpler to validate and are where the value lies. We've updated the proposal as follows:

• Adoption criteria become production applications. The PoC and hackathon tiers are removed. The adoption milestone pays against attested external production deployments that use the stack.

• Extended window, no fixed review. Production adoption takes longer than 12 weeks (third-party audits, legal, deployment), so the adoption milestone becomes claimable whenever the evidence lands, within 6 months of MVP acceptance. No scheduled committee review; validation happens only when there is something concrete to verify.

• Payment rebalanced from 50/50 to 60/40. 60% at MVP acceptance (covering the delivery work), 40% against production adoption as above. Total request unchanged.

We keep the enablement program (workshops, tutorials, office hours) through the window regardless, since production apps start as prototypes. This will be folded into the next revision together with the dpm integration change.

Proposal looks good to me now, majority is on adoption, Supporting the proposal.

Approved in Tech-Ops voting on August 26th

Milestone 1: dAppBooster MVP

• Focus: The smallest adoptable slice of the stack: take a developer from zero to a running CIP-0103 dApp on a local Canton environment.
• Description: Combines two pieces into one MVP:
  • (1) canton-barebones. Evolves from a fixed runtime into a composable tool that assembles a local Canton environment from modules (the Splice bundle, wallet-gateway, PQS optional), building no auth of its own. Distributed as a dpm component, released in a public GitHub repo. No new standalone CLI.
  • (2) A minimal version of dAppBooster:
    • Family of hooks, wagmi-canonical with connection logic CIP-0103 compatible
    • Family of React components: connect button, party input, explorer link, hash handling, token component.
    • This hardens the v0.1 proof-of-concept into a reusable starter others build on; productionizing it, not rebuilding it.

Milestone 2: Adoption

• Focus: Demonstrate production adoption of the MVP. This is the explicit gate: the fuller vision is not requested in this proposal and returns only as follow-on proposals if the adoption evidence here supports it.

• Description: Production applications are the adoption metric. Because production timelines (third-party audits, legal review, Mainnet onboarding) run longer than a fixed short review window, this milestone is claim-based: adoption payments are claimable whenever the evidence lands, within 6 months of Milestone 1 acceptance. There is no scheduled committee review; the committee validates evidence only when a claim is submitted. Usage by BootNode or affiliated parties does not count.

• Enablement program: 2 public workshops or hackathon sessions, a getting-started tutorial per release, and office hours through the window on a public schedule during the first 12 weeks after MVP release. Production applications start as prototypes; this program feeds that pipeline.

• Adoption criteria: an external team runs a production application on Canton Network built on the stack, verified by a written attestation from that team plus publicly verifiable evidence if possible (public announcement, application identifiers, or repository).

• Ecosystem support: Mirroring the adoption support model of the approved OpenZeppelin ecosystem grant (PR #262), the Canton Foundation and Digital Asset will actively introduce dAppBooster to teams building in the Canton ecosystem and facilitate integration opportunities throughout the claim window.