diff --git a/proposals/bootnode-canton-dappbooster-dev-stack.md b/proposals/bootnode-canton-dappbooster-dev-stack.md new file mode 100644 index 000000000..82f45321b --- /dev/null +++ b/proposals/bootnode-canton-dappbooster-dev-stack.md @@ -0,0 +1,257 @@ +## Development Fund Proposal + +**Author:** BootNode +**Status:** Draft +**Created:** 2026-05-28 +**Label:** dapp-integration + +--- + +## Abstract + +dAppBooster for Canton v0.1 is an open-source local development stack, shipping today at [cn-dappbooster](http://github.com/BootNodeDev/cn-dappbooster), that takes a Canton developer from Daml contracts to a running dApp on a laptop. It bundles one-command local Canton infrastructure (canton-barebones); a React frontend starter with reusable UI components; and a working end-to-end example that works with any CIP-0103 wallet. + +**This proposal funds evolving v0.1 into a stack that takes a developer from zero to a complete, running CIP-0103 dApp (infrastructure, and a framework-spanning frontend) with a single command, so teams ship in days, not weeks.** It builds on top of Canton's wallet & dApp SDKs, not alongside it: it consumes the upstream SDK, stays wallet-agnostic so any CIP-0103 wallet (including the [Foundation's reference wallet](https://github.com/canton-network/wallet/tree/main/wallet-gateway/extension)) drops straight in, and adds the environment, components, and framework bindings that make those primitives usable. This maps directly to the Foundation's "App Building and Developer Experience" priority; lowering the barrier to building on Canton, and driving CIP-0103 adoption. + +## Specification + +### 1. Objective + +This proposal maps directly to Canton's **"App Building and Developer Experience"** priority. dAppBooster for Canton **v0.1, shipping today**, already turns local setup into a one-command install. Its evolution is funded around one thesis: **building a Canton dApp should take days, not weeks**. + +**The reference workflow becomes:** one command takes a developer from zero to a complete, running CIP-0103 dApp. Four deliverables make that production-shaped. First, canton-barebones (a composable local environment that runs from its own CLI). Second, dAppBooster (a framework-spanning layer of reusable components). Third, canton-token-forge (a CIP-56 standard-compliant token registry that lets a local environment issue tokens). Fourth, a single unifying CLI, working example, and docs that tie the loop together. + +### 2. Implementation Mechanics + +**The starting point is v0.1, already published.** v0.1 ships as open-source components, one of which is an end-to-end example dApp. + +**canton-barebones** is the minimal Canton infrastructure layer: Splice, local dev token generation, DAR deployment scripts, and health checks. It intentionally excludes Keycloak/OIDC, so the base stays small and predictable. A developer starts from a working Canton runtime and adds only the pieces they need. + +**dAppBooster** is a framework-agnostic core: connection logic built on Canton's dApp SDK, with React wagmi-style hooks shipped today and a library of reusable UI components (token select/input, connect button, party input, explorer link, hash handling, TX lifecycle). + +**canton-token-forge** is a CIP-56-compliant token registry for local environments: it issues tokens that behave exactly like real standard assets, mirroring Amulet's structure (factory contract, locking, two-step transfers, DvP). Issuance is free and admin-controlled, with an optional faucet per token, and it plugs into canton-barebones as a composable module. + +**At a high level, the milestones are:** + +1. canton-barebones stack; +2. dAppBooster ships the agnostic core, React binding, and component set, with a Vue binding assessed; +3. canton-token-forge, a CIP-56 standard-compliant token registry for tokens issuing; +4. a unified CLI, working example, and documentation tie the loop together. + +### 3. Architectural Alignment + +dAppBooster works with **CIP-0103: dApp Standard**. A dApp built with it delegates the signing and execution of its transactions to the user's wallet through the standard flow, so any compliant wallet works with any dApp built on dAppBooster, with no wallet-specific code. Everything beyond that interface (the wallet's internals, its signing backend, and identity) is out of dAppBooster's scope. This maps to the Q2 priority: reduced friction, interoperability, standards adherence, documentation and examples, and lower total cost of ownership. + +### 4. Backward Compatibility + +No backward compatibility impact. + +## Milestones and Deliverables + +### Milestone 0: dAppBooster for Canton v0.1 (already built) + +- **Focus:** Recognition of the developer-experience foundation already shipped, published, and live before submission. The starting line for M1–M4. +- **Description:** v0.1 collapses the local Canton dApp setup into a one-command install and demonstrates CIP-0103 end-to-end. Open-source components (one of which is an end-to-end example dApp) were built and operated by BootNode, out of its operations budget. +- **Deliverables / Value Metrics:** + - canton-barebones: working local Canton runtime with one-command bring-up. + - Carpincho: CIP-0103 Sync browser wallet with encrypted local vault and Ed25519 signer. + - wallet-service: CIP-0103 Async server (external party creation, transaction prepare/sign/execute). + - react-starter: React frontend integrated with the upstream Canton dApp SDK and Carpincho. + - An end-to-end example dApp exercising the full Daml-contracts -> working-dApp-UI loop. + - Repository: [github.com/BootNodeDev/cn-dappbooster](https://github.com/BootNodeDev/cn-dappbooster), MIT licensed. + - Public landing page: [dappbooster.cc](https://dappbooster.cc). + - Used to build the Dark Pool project, winner of the EthGlobal NYC 2026 Canton Foundation track. +- **Estimated Effort:** 0 weeks (already built and live at submission). + +### Milestone 1: canton-barebones composable CLI + +- **Focus:** Evolve canton-barebones from a single opinionated runtime into a composable CLI for production-like local Canton environments. +- **Description:** Replace the fixed runtime with a minimal CLI that assembles a Canton environment from composable modules: the Splice bundle, PQS (optional). It builds no auth of its own. Where custom topology is needed, it can consume Denex Localnet for the underlying node orchestration rather than reimplementing it. +- **Deliverables / Value Metrics:** + - CLI released in a public GitHub repo + - Documentation: CLI commands, module composition, workspace bring-up. + - Agentic readiness (documentation, tools). + - Validated by at least 3 external developers +- **Estimated Effort: 3 weeks** + +### Milestone 2: dAppBooster core + UI components + +- **Focus:** A framework-agnostic core with a reference React binding and a reusable UI component library. +- **Description:** Extract dAppBooster's connection logic and hooks into a framework-agnostic core built on Canton's dApp SDK, exposed today through a shipped React binding plus a set of reusable UI components. Hooks stay wagmi-canonical so the implementation can later delegate to the Foundation's React Wrapper without breaking consumers. A Vue binding is assessed to prove the core is genuinely portable (an assessment, not a committed binding). +- **Deliverables / Value Metrics:** + - **Framework-agnostic** core (connection logic + viem-style functions on Canton's dApp SDK), public repo. + - React binding, following the wagmi-canonical. + - Reusable component set: token select/input, connect button, party input, explorer link, hash handling, among others. + - Documentation. + - **Assessment of:** a Vue binding. +- **Estimated Effort: 5 weeks** + +### Milestone 3: canton-token-forge + +- **Focus:** Let a local Canton environment issue realistic stand-in tokens for assets a developer can't mint locally, so dApps can be built and tested against tokens that behave like the real thing. +- **Description:** canton-token-forge is a CIP-56 (CN Token Standard) compliant token registry that runs on a self-hosted Canton. To any wallet or app, its tokens look and behave exactly like real standard tokens, and it mirrors Amulet's structure (factory contract, locking, two-step transfers, allocation / DvP, and a Registry HTTP API), but with none of the economics (no fees, decay, mining rounds, rewards, or DSO governance). Issuance is free and admin-controlled, with an optional faucet per token. It plugs into the canton-barebones CLI as a module, so a workspace can spin up realistic tokens alongside the rest of the stack. We are also open to supporting version 2 of the CN Token Standard as it stabilizes, so the registry can track the standard as it evolves rather than being pinned to v1. +- **Deliverables / Value Metrics:** + - Delivered as a standalone, self-contained project in its own dedicated public GitHub repo, consumable both on its own and as a canton-barebones module. + - Daml package + Registry HTTP service, released in a public GitHub repo. + - CIP-56 conformance, proven against the upstream splice-token-standard test kit (not just our own tests). + - Multi-token registry: one operator serving multiple tokens and admins, with mint/burn, optional faucet, Amulet-style locking, two-step transfers, and DvP/allocation settlement. + - Documentation: token setup, the Registry API, and how to add it to a canton-barebones workspace. + - Agentic readiness (documentation, tools). +- **Estimated Effort: 2 weeks** + +### Milestone 4: dAppBooster CLI + working example + docs + +- **Focus:** Unify the toolset under one CLI and ship a worked end-to-end example that proves the thesis. +- **Description:** A single CLI guides developers through scaffolding and running the full stack. A worked example takes a developer from zero to a running CIP-0103 dApp, connecting to any CIP-0103 wallet to sign. Documentation is agentic-ready. +- **Deliverables / Value Metrics:** + - Unified CLI: one command to scaffold and run the stack. + - Worked end-to-end example: zero → running CIP-0103 dApp, connecting to any CIP-0103 wallet to sign. + - Updated dAppBooster Canton landing page and agentic-ready documentation. + - Within 4 weeks of release, at least 5 external developers complete the zero-to-running-dApp path, tracked via GitHub and community channels (verified at the Milestone 5 month-3 review). +- **Estimated Effort: 2 weeks** + +### Milestone 5: Six-Month Post-Delivery Ownership + +- **Focus:** Active maintenance of the full stack during the initial adoption period. +- **Description:** for six months after Milestone 4 acceptance, BootNode operates as the stack's active maintainer tracking upstream releases, fixing bugs, keeping documentation updated, and including Foundation and early-adopter feedback into its releases. +- **Deliverables / Value Metrics:** + - New Splice, Canton, and dApp SDK releases incorporated and verified within four weeks of upstream release, each with a published compatibility note. + - GitHub issues triaged within one week. Critical fixes shipped as patch releases. + - Handoff report: operational experience, adoption observed (external teams using the stack, forks, third-party issues), open items, and recommended follow-on scope. +- **Timeline:** 6 months following Milestone 4 delivery. + +## Acceptance Criteria + +The Tech & Ops Committee will evaluate completion based on: + +- Deliverables completed as specified for each milestone. +- Demonstrated functionality or operational readiness. +- Documentation and knowledge transfer provided. +- Alignment with the stated adoption metrics (see Adoption targets in Motivation). + +**Already shipped as v0.1 (live at proposal submission):** + +- canton-barebones: one-command local Canton runtime. +- react-starter: React frontend on Canton's dApp SDK, with reusable components. +- End-to-end example dApp exercising the full loop. +- Repository: [github.com/BootNodeDev/cn-dappbooster](https://github.com/BootNodeDev/cn-dappbooster), MIT licensed + - Open to upstreaming into [canton-network/wallet](https://github.com/canton-network/wallet), in coordination with the Foundation. +- Public landing page: [dappbooster.cc](https://dappbooster.cc) + +**Per-milestone acceptance signals (funded work):** see the Payment Trigger column in the Funding section. + +## Funding + +**Total Funding Request:** 1,780,000 CC + +### Payment Breakdown by Milestone + +| Milestone | Effort | Payment on Acceptance | Payment Trigger | +| :---- | :---- | :---- | :---- | +| M0: dAppBooster for Canton v0.1 (already built) | 0 weeks | 0 CC | Already delivered; no payment requested | +| M1: canton-barebones CLI | 3 weeks | 320,000 CC | Committee acceptance + composable CLI released in a public GitHub repo with documented module composition and workspace bring-up | +| M2: dAppBooster core + UI components | 5 weeks | 530,000 CC | Committee acceptance + framework-agnostic core, React binding, and reusable component set; Vue-binding assessment | +| M3: canton-token-forge | 2 weeks | 210,000 CC | Committee acceptance + Daml package and Registry HTTP service, released in a public GitHub repo | +| M4: dAppBooster CLI + working example + docs | 2 weeks | 210,000 CC | Committee acceptance + unified CLI + worked end-to-end example released in a public GitHub repo, with updated docs | +| M5: Six-Month Post-Delivery Ownership | 6 months | 510,000 CC | – 50% at month 3: committee review of SLA compliance to date (compatibility notes, triage times, patches shipped) and progress against the adoption targets stated in Motivation.
– 50% at month 6: committee acceptance of the handoff report. | +| **Total** | **12 weeks + 6 months maintenance** | **1,780,000 CC** | | + +Per-milestone payments are released on Tech & Ops Committee acceptance against the deliverables and acceptance signals stated for that milestone. + +### Volatility Stipulation + +The core delivery phase (Milestones 1 to 4) runs 12 weeks. Milestone 5 extends the engagement to approximately 9 months from grant approval. The grant is denominated in fixed Canton Coin and BootNode assumes price volatility risk. Since the Milestone 5 payment falls more than 6 months after approval, the remaining un-minted milestones will be re-evaluated at the 6-month mark to account for material CC/USD volatility, per CIP-0100. Scope changes requested by the Committee that extend timelines beyond the plan will likewise trigger renegotiation of the remaining un-minted milestones. + +### Timeline Accountability + +- **Acceleration Bonus:** If Milestones 1 through 4 are met and accepted 2 weeks or more ahead of the estimated 12-week schedule, a +5% bonus on the combined Milestone 1 to 4 payout (63,500 CC) will be awarded. Early delivery extends the effective adoption window covered by Milestone 5 at no additional cost. +- **SLA Penalty:** A 10% reduction of the respective milestone payment will be applied for each full month of delay beyond the estimated delivery date. If any milestone is more than 3 full months delayed due to reasons within BootNode's control, the terms of the agreement will be revisited by BootNode and the Tech & Ops Committee. +- **Audit funding:** Not requested in this proposal. The deliverables in M1 to M4 are developer infrastructure rather than financial primitives; security review will be handled inside the engineering scope (threat model documentation, dependency review, CI security gates). + +## Why BootNode? + +BootNode is a high-trust engineering collective partnering with founding teams, foundations, and protocols to build, launch, and scale Web3 products. Our team of engineers has been building Web3 products together **since 2017**, with 30+ dApps shipped across the Ethereum ecosystem. + +Major projects we have contributed to include **MakerDAO, Aave, Derive, Hyperlane, Eigenlayer, Gelato Network, Nexus Mutual, and Uniswap**. We were a **core contributor to Safe** (Gnosis Safe) in earlier years, shipping work on the Safe React App, the Safe Apps SDK, and the Safe Apps ecosystem. We have shipped on **POA Network** (EVM bridges, Proof-of-Authority validator-set governance App, Token Wizard) and continued through its pivot into **xDAI Chain**, which became **Gnosis Chain** (Unified Bridge + Explorer, Gnosis Pay, Cow Protocol, and others). Recent engagements include **Infinex, Wormhole, and the Open Intents Framework** (funded by the Ethereum Foundation). More project case studies are at [bootnode.dev/case-studies](https://www.bootnode.dev/case-studies). + +The contribution model is consistent across these engagements: an interdisciplinary POD team that takes full ownership of the work from ideation through adoption, partnering with the organization rather than acting as an external vendor. + +### Aligned incentives + +BootNode routinely accepts project tokens as a portion of compensation, and at times, the full payment is in tokens. The intent is long-term alignment: BootNode succeeds when the project succeeds, and our work directly contributes to the token's utility rather than being treated as a one-shot deliverable. + +### Capability areas + +| Area | Examples from BootNode's portfolio | +| :---- | :---- | +| Smart contracts and protocol design | MakerDAO, Aave, Synthetix, Eigenlayer, Nexus Mutual, Hyperlane, Revert / Uniswap (Uniswap v4 StableSwap hook) | +| dApp / frontend / UI | NTT Launchpad (Wormhole) and Portal, xERC20 Launchpad (Everclear), Derive Finance, Covenant Finance | +| **DevEx and dev tooling** | **dAppBooster for EVM** (the direct EVM analog of this proposal), DMe notification framework, Uniswap Frontend SDK, reference implementations across multiple ecosystems | +| Cross-chain and bridges | Hyperlane, Wormhole, Connext / Everclear, Khalani, Gnosis Bridge + Explorer | +| Wallets and account abstraction | **Safe** (prior core contributor), NFTfi Rights Management Wallet, **zkSync** Azure SSO multisig wallet, Aztec privacy wallet PoC, BootNode Agentic Wallet (ERC-7702 + passkeys + MCP) | +| Infrastructure | Gnosis Chain validators, The Graph Indexers, relayers (Hyperlane OIF, Warp Rebalancer) | +| Privacy | Zama Confidential Payroll dApp (FHE), Optimism anonymous-voting, Aztec privacy wallet PoC | + +BootNode runs infrastructure when it adds value to the ecosystems we work with, rather than as a separate commercial line. + +### Direct analog: dAppBooster for EVM + +The dAppBooster for Canton stack is built by the same team, with the same architectural conventions, that produced [dAppBooster for EVM](https://dappbooster.dev): an open-source development stack for the Ethereum ecosystem, distilled from BootNode's experience shipping 30+ dApps and supported by **Optimism** and the **Ethereum Foundation**. The project is actively maintained at [github.com/bootnodedev/dappbooster](https://github.com/bootnodedev/dappbooster). The Canton version applies the same architecture, conventions, and developer-experience lessons learned, adapted for the Canton ledger and CIP-0103. + +### Support from other teams + +> *"dAppBooster pairs perfectly with Daml Autopilot: write and validate your Daml with Autopilot, then ship a running full-stack dApp fast with dAppBooster. It makes building on Canton much easier."* +> — Colin Schwarz, Program Lead, ChainSafe + +## Maintenance + +- All code produced under this grant is published open source (MIT) +- Contributions are welcomed via GitHub Issues and PRs. +- Maintenance during the first six months post-delivery is covered by Milestone 5. Beyond that period, continued maintenance can be structured as a separate recurring maintenance grant, following the pattern of existing Foundation maintenance grants. + +## Co-Marketing + +Upon each milestone release, BootNode will coordinate with the Canton Foundation on: + +- A joint announcement at each milestone release. +- A technical blog post documenting the new components and their integration patterns. +- A walkthrough video showing a dApp built end-to-end against the milestone's deliverables. +- A presentation at an upcoming Canton or developer ecosystem event (specific event to be agreed with the Foundation). +- An updated entry in the Canton developer documentation linking to the stack and the example. + +## Motivation + +Building a Canton dApp today means wiring up a participant, synchronizer, JSON Ledger API, persistence, auth, and a wallet, then implementing CIP-0103 discovery, connection, and signing in application code. Weeks of setup before any business logic runs. That friction is the biggest tax on Canton's "App Building and Developer Experience" priority: reduced friction, interoperability, standards adherence, documentation and examples, and lower total cost of ownership. + +dAppBooster collapses that setup into one command. canton-barebones removes the local-environment work; the framework-agnostic core and React binding remove the CIP-0103 wiring; and the worked example gives teams a running, wallet-agnostic dApp to fork. Nothing here reimplements Canton's SDK, wallet, or standards work. It consumes them, so a team's first day goes to their product, not their plumbing. + +**Adoption targets.** Every new Canton dApp building under CIP-0103 is a potential consumer of the stack, particularly developers arriving from an Ethereum or Solana background, for whom the wagmi-style surface is immediately familiar. The stack has already produced one adoption proof: Dark Pool, winner of the EthGlobal NYC 2026 Canton Foundation track, was built on v0.1. The quantified targets this proposal commits to, measured during the Milestone 5 period, are: + +- 10 external teams (not BootNode) have scaffolded a dApp with the unified CLI, verified via template forks, GitHub issues, or direct confirmation. +- 3 external dApps in active development on the stack. +- 2+ independent CIP-0103 wallets, including the Foundation's reference wallet, verified against the worked example. +- 100+ monthly npm downloads of the core and React packages by month 6. + +**Built on years of dAppBooster for EVM.** dAppBooster for Canton is not new from thin air. The EVM-side [dAppBooster](https://dappbooster.dev) has been shipping and improving with web3 builders for years (see [github.com/BootNodeDev/dAppBooster](https://github.com/BootNodeDev/dAppBooster) for the project history). The Canton version is built by the same BootNode team and applies the same architecture, best practices, and developer-experience lessons learned, adapted for the Canton ledger and CIP-0103. + +## Rationale + +Why a dedicated developer-first dApp stack? The Canton ecosystem already has wallet and SDK proposals in flight. This section names them and draws the lines of differentiation, so the Committee can see this proposal extends and consumes existing work rather than duplicating it. Besides, rather than keeping the result as a standalone stack, BootNode is open to contributing suitable components upstream into the relevant Canton repositories (including [canton-network/wallet](https://github.com/canton-network/wallet)), where the Foundation and repo maintainers see a fit and with scope agreed together. + +[**PR #90: Open Source Reference Wallet (Digital Asset, Approved)**](https://github.com/canton-foundation/canton-dev-fund/issues/90)**.** PR #90 ships the Splice Portfolio dApp UI and the Splice Wallet browser extension. dAppBooster does not ship a wallet. It is wallet-agnostic, targeting the CIP-0103 dApp API so any compliant wallet serves any dApp built with it. The reference wallet drops straight into dAppBooster's loop as a default signer; there is no overlap to reconcile. + +[**PR #69: Canton Network dApp SDK and Tooling (Digital Asset, Approved)**](https://github.com/canton-foundation/canton-dev-fund/pull/69)**.** PR #69 ships the production dApp SDK, a Wallet Compliance Test Suite, a React Wrapper Library, and a dApp Starter Template by end of Q4 2026. dAppBooster is downstream of it: its hooks build on @canton-network/dapp-sdk rather than reimplementing it, and stay wagmi-canonical so they can later delegate to PR #69's React Wrapper without breaking consumers. dAppBooster's CLI complements (not replaces) PR #69's Starter Template. + +Audiences differ: PR #69 targets top production dApps retrofitting CIP-0103; dAppBooster targets developers who need a working answer today. + +[**PR #318: Denex Localnet (Denex, Approved)**](https://github.com/canton-foundation/canton-dev-fund/issues/318)**.** PR #318 ships a declarative Canton topology engine: a Testcontainers-style SDK, a single YAML config format, a CLI for managing localnets via the Docker API, and runtime state inspection. + +**canton-barebones** sits at a different abstraction level. Where Denex Localnet describes which Canton nodes exist and how they connect, canton-barebones assembles a running environment (Splice bundle, optional PQS and upstream wallet-gateway) that a dApp runs against out of the box. + +Topology configuration is not the deliverable; the workflow is. + +The two complement each other: a developer modeling a custom Canton topology reaches for Denex Localnet, while a developer who just wants a working environment to build against reaches for canton-barebones. Where custom topology is needed, canton-barebones can consume Denex Localnet for the underlying node orchestration, treating it as an Approved upstream rather than reimplementing the topology layer. + +[**PR #109: Wallet Gateway Reference Implementation (Approved) & self-issued OIDC.**](https://github.com/canton-foundation/canton-dev-fund/issues/109) Both are consumed, not rebuilt. canton-barebones optionally composes the upstream wallet-gateway; authentication in production-like contexts relies on the validator's OIDC / self-issued OIDC. dAppBooster adds no wallet-gateway fork and no identity provider of its own. + +**Why not just extend an existing component?** Each piece: Canton participant, Daml SDK, CIP-0103 spec, dApp SDK, wallet-gateway reference, is available, but no project assembles them into a single one-command path from zero to a running dApp (infrastructure, backend, and frontend). That integration layer is the gap this proposal closes.