Proposals/canton-foundation/canton-dev-fund/#82GitHub ↗

Declined#82 Pull requestBitdynamics

Proposal: Canton ClearSign

Opened 13-03-2026 by srikanth-bitdynamics, last activity 29d ago

Incoming6.2 days19-03-2026
Needs Champion0.1 days25-03-2026
Needs Revision0.1 days25-03-2026
Incoming7.8 days25-03-2026
In Review7 days02-04-2026
Ready for Vote6.1 days09-04-2026
Voting Live7.2 days15-04-2026
Needs Revision8.3 days22-04-2026
In Review40 days01-05-2026
Declinedsince 10-06-2026

Waiting on: Decided on the board but the PR is still open; idle 133 days
Organization: Bitdynamics
Discussion: 10 messages; 7 people

Development Fund Proposal Submission

Proposal file:
/proposals/canton-clearsign.md

Summary

This proposal requests funding for Canton ClearSign, an open-source wallet platform focused on explainable self-custody, external-party onboarding, and operator conformance for custom/operator-managed Canton environments. It is intentionally complementary to broader wallet-connectivity efforts and focuses instead on a concrete reference wallet, topology-aware onboarding flows, transaction explainability, diagnostics, and deployment-readiness tooling.

Checklist

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

Notes for Reviewers

This proposal is intentionally scoped to avoid overlap with broader wallet-discovery, generic provider-standard, and dApp-SDK efforts already under discussion.

ClearSign is not trying to define the universal wallet standard for Canton. It is an open-source reference wallet and integration surface focused on making self-custodial Canton usage real, inspectable, and usable in custom and operator-managed environments. The goal is to give new dApp teams a concrete wallet target they can integrate against today, while giving operators the onboarding, diagnostics, and conformance tooling needed to support real deployments.

The main differentiators are:

external-party onboarding with explicit topology review
explainable signing with local transaction-hash verification
JWT / rights / package / route diagnostics for custom nodes
operator conformance harness and deployment-readiness reporting

The provider/SDK/React/extension surfaces in this proposal are scoped as ClearSign’s own integration surfaces for the reference wallet and example dApp, not as a new universal ecosystem standard.

This project is intended as a practical open-source reference implementation, not just an abstraction layer. It is designed to help new dApp teams integrate against a real wallet, especially in custom-node and operator-managed deployments that remain under-served today. The codebase is modular and public so it can be extended and maintained by the wider community after release.

No dedicated third-party audit budget or recurring maintenance funding is requested in this proposal. If the shipped platform demonstrates meaningful adoption or reviewer-requested security scope beyond the funded milestones, Bitdynamics may return with a follow-on proposal for scoped security review and/or ongoing maintenance support.

Current Prototype

The project is not starting from a blank slate. We've got Wireframes ready to start development once approved and make lives of developers much easier.

Current prototype UI Wireframe : canton-wallet-demo

Milestones 4

Public Alpha for Wallet Core, SDK Alignment, and Routing Diagnostics
External-Party Onboarding, Explainable Signing, and Activity History
Hardened Wallet, Extension, and Ecosystem Interoperability Release
Operator Conformance, Security Audit, and Deployment Readiness

Discussion9 comments, 1 review, 0 inline comments

1 automated message from bots hidden. Show bot messages

Showing 1 to 10 of 10, oldest first.

LucasnFCSreviewedcommented08-04-2026 · 6mo agoGitHub ↗

This proposal addresses a real gap in the Canton ecosystem. Self-custodial wallet usage in Canton is still difficult in practice because onboarding and transaction execution depend on topology state, party mode, rights, package availability, and environment-specific routing. In that context, a reference wallet plus operator-oriented diagnostics is a reasonable and relevant scope.

The strongest part of the proposal is not the wallet UI itself, but the focus on external-party onboarding, explainable signing, and operator diagnostics. Those are areas where Canton setups often fail in practice. The emphasis on JWT, rights, package, topology, and route diagnostics is well aligned with the operational reality of custom Canton environments, where integration problems are often caused by surrounding configuration rather than the transaction flow alone.

I also think the proposal is correctly framed as reference tooling rather than a protocol change or universal wallet standard. That makes the scope easier to justify and lowers architectural risk. The operator conformance harness, deployment guidance, and explicit treatment of unsupported paths are likely to be more valuable in practice than the frontend surface on its own.

My main reservation is security and missing timeline in months. Wallet-related work is a sensitive surface by definition, and this proposal goes beyond simply wrapping Foundation-provided protocol functions. It introduces custom logic around local key custody, signer abstractions, topology onboarding/orchestration, route planning, transaction explanation, local hash verification, and extension approval flows. That matters because Canton’s external-party model already requires careful client-side verification of prepared transactions and their hashes before signing, so mistakes in this layer are security-relevant rather than cosmetic. For that reason, I would not treat the result as production-grade wallet infrastructure without an independent external security review if the implementation includes meaningful custom logic beyond the existing protocol surfaces.

So overall, I think this is a relevant and technically sensible proposal, but I would evaluate it primarily as a reference implementation and operator toolkit unless or until the security-sensitive custom logic is externally reviewed. The key question is whether it will materially reduce real onboarding and signing friction for Canton users and operators while maintaining an appropriate level of security rigor.

hythlodacontributorcommented15-04-2026 · 6mo agoGitHub ↗

To strengthen the proposal, it would also be helpful to include clear adoption signals from the ecosystem. Please have such users, for example, two to three Canton ecosystem teams who intend to use the tool would help demonstrate practical demand post on this PR they would use the functionality.

Please add this additional information directly to the PR.

Harsh-Zynkcommented15-04-2026 · 6mo agoGitHub ↗

We can see ourselves using this as a reference implementation for Canton wallet integration work.

The combination of wallet flows, extension support, and operator diagnostics feels much more practical to us than another generic connectivity layer on its own.

We’re building on Canton now, and this is the kind of tooling we would genuinely expect to use for integration and testing before we go live.

ghostcommented15-04-2026 · 6mo agoGitHub ↗

Alterscope would be interested in this.

If this moves ahead, we’d be happy to evaluate milestone outputs as they land and share feedback on the onboarding, signing, and operator-readiness pieces.

ghostcommented15-04-2026 · 6mo agoGitHub ↗

We support this proposal. It will help with our development for sure.

nogods404commented22-04-2026 · 6mo agoGitHub ↗

This is something we'd want to use.

The part that stands out to us is the combination of self-custodial wallet flows, clearer transaction signing, and better onboarding for real Canton environments. Having a reference wallet to test against would be genuinely helpful.

davidrichards-dacontributorcommented24-04-2026 · 6mo agoGitHub ↗

Here's my assessment of this reference wallet implementation:

Positives

Administrative Transparency: The proposal provides a commendable level of detail regarding clear signing for topology transactions and transfers. Providing this level of visibility for administrative and transfer operations is a significant benefit for user trust.
Automation: Including an "operator conformance harness with CLI, machine-readable JSON output, and optional HTML reporting" allows for automated use of the wallet
Reference Application: Including a reference application alongside the core UI provides a practical entry point for developers to see the implementation in a live context.

Improvements

Limited Protocol Support: The depth of network capability support appears shallow. CIP-0056 (Token Standard) is only mentioned once and its support is conditional ("where available"). Furthermore, there is a total absence of CIP-0103 (dApp API) support, which is critical for standardized communication between dApps and wallets in the ecosystem.
Ecosystem Integration: While the proposal targets node operators, it does not clarify how this implementation interacts with, overlaps, or replaces existing features within the current Splice Amulet wallet or the wider validator stack.
Security Accountability: The proposal does not commit to an upfront external security audit. Stating that an audit would only be conducted after "demonstrating meaningful adoption" creates a "chicken and egg" problem; for a reference implementation intended to handle network assets, security verification is typically a prerequisite for adoption.
Feature Completeness: Some core wallet features are missing from the scope, most notably a transaction history view.
Future feature support: For any reference wallet implementation to be useful to wallet providers and exchanges who have already integrated with the Canton Network, it would need to commit to support future network features. The only reference to a future feature is multi-synchronizer support but explicitly states that future-facing reference features are not covered, which may limit its long-term utility to the community.
SDK Alignment: The implementation relies on a custom/proprietary SDK rather than the Digital Asset (DA) Wallet SDK which is already in use by many exchanges and wallet providers. If the goal is to drive ecosystem-wide adoption, alignment with the most commonly used developer tools is essential.

srikanth-bitdynamicscontributorcommented24-04-2026 · 6mo agoGitHub ↗

@davidrichards-da

Thank you for the thorough review. Several of these points surfaced concrete improvements as we moved from proposal into implementation planning, and we want to address them directly in the revised proposal.

SDK Alignment

This is the most substantive point, and you are right to raise it. As we refined the ledger communication layer, we introduced a transport abstraction and started integrating the official @canton-network/wallet-sdk as the preferred ledger backend for production-oriented deployments, while retaining a direct JSON Ledger API path as a zero-dependency fallback where appropriate. Our value-add — the self-custodial key management stack (ED25519/WebAuthn/KMS/threshold signers), transaction explainability, hash verification, and operator conformance harness — sits above that transport layer. We will update the proposal to reflect this alignment explicitly rather than presenting the implementation as a separate proprietary stack.

CIP-103 dApp API

As we refined the provider layer, it became clear that the reference wallet should align to the CIP-103 dApp-facing JSON-RPC surface rather than rely only on a ClearSign-specific interface. We have already started that alignment in the provider layer and will update the proposal to make CIP-103 compatibility an explicit deliverable, including the browser-injected provider surface needed for interoperability with dApps built against the standard.

CIP-56 Support

The phrase “where available” in the proposal was poorly chosen and understates the intended behavior. CIP-56 asset discovery, holdings, and direct transfer flows are the default path in the wallet design, with Splice CC gateway transfers handled as a named network-specific alternative where applicable. We will revise the proposal language so that CIP-56 support is described as first-class rather than incidental.

Transaction History

This is a fair catch and was an omission in the proposal document. Transaction/activity history is already part of the implementation workstream, including lifecycle-aware views that distinguish incoming, outgoing, deposits, and settled activity. We will make this explicit in the revised scope and acceptance criteria, and we will also call out follow-on usability items such as export and richer filtering more clearly.

Ecosystem Integration / Splice Amulet

To clarify the intended positioning: ClearSign is not a replacement for the Splice Amulet validator wallet. It is a self-custodial layer for external parties and wallet users who are not themselves operating validator infrastructure, while still integrating with the existing participant, scan, validator, and hosted wallet surfaces where those exist. We will add an explicit section to the proposal describing those integration points and boundaries so the relationship to the wider validator stack is clear.

Security Audit

Initially when we proposed this idea we are not sure about few things like Audits and maintenance as that will increase costs more so we planned to add it as a follow on proposal so that this proposal doesn't look huge and also doesn't add random costs which are unknown at this point. We will revise the proposal to include an external security audit of the key-management and signing path as a funded milestone before final sign-off. For a reference implementation handling network assets, that sequencing is more appropriate than deferring audit work until after adoption.

Future Feature Support / Multi-Synchronizer

We also agree that the proposal should say more here. The multi-synchronizer note was written conservatively based on the rollout status at the time, but the proposal should be clearer about forward compatibility more broadly. We will add a forward-compatibility section covering capability-driven routing, evolving dApp/API alignment, and multi-synchronizer support as a first-class scenario as the network surface matures.

If it makes easy we can give access to implemented part so far , we haven't made it public to avoid uninformed usage by community.

We appreciate the rigor of this review. It highlighted several areas where the implementation direction had already moved further than the written proposal, and we will revise the proposal accordingly.

LucasnFCScommented06-05-2026 · 5mo agoGitHub ↗

Thanks for the revision. The technical changes address most of the points raised in the original review and in @davidrichards-da's follow-up. CIP-103 alignment, the @canton-network/wallet-sdk transport adoption, CIP-56 as the default asset path, transaction history as a first-class feature, the Splice Amulet relationship section, and bringing the audit inside the grant are all real improvements.

Some funding increase is reasonable given the higher security and auditing requirements.

For reference, several of the points below compare against the parallel Digital Asset proposal for Splice Portfolio dApp UI and Splice Wallet Browser Extension (#90), which covers similar ground.

Two-stage audit. #90 does an internal audit at M1 and an external third-party audit at M3, with a "Critical/High issues resolved" commitment and a published report. The same structure here would help.
Timeline. Still missing. Concrete delivery estimates per milestone, in months or target dates.
Accountability and volatility. #90 includes acceleration bonuses, late penalties, and proposer-borne volatility risk. The current ClearSign clause asks for re-evaluation at six months in the proposer's favour. Aligning these terms would put the two proposals on equal footing.
Adoption signals. The original proposal named Gateway, Lumens.fi, and Hashrupt. The revision dropped them. The PR comments are still conditional ("would use", "would be interested"). Reinstating named beneficiaries, or attaching a letter of intent with a specific integration timeline, would help.
Team composition. The proposal leans on validator ops experience. That fits infrastructure work but less so applied cryptography or wallet security. With audit now a milestone gate, naming personnel with wallet security or crypto experience, or committing to a subcontract, would close the gap.
License. State it explicitly. Apache 2.0 is the precedent in #90.
Deployable artefacts. #90 commits to a docker image and helm chart at M1. Similar artefacts would let reviewers exercise the wallet independently.
Portfolio overlap with #90. The wallet UI, provider/SDK/React surfaces, and extension overlap with #90. The operator toolkit (conformance harness, JWT/rights/package/route diagnostics, topology wizard, deployment guides) and the explainable-signing and local hash recomputation work do not. If #90 is funded, would ClearSign descope the overlapping pieces and focus on the operator toolkit and explainable-signing?

Architectural point: #90 follows CIP-103's separation of concerns where topology operations live in the Wallet Provider (Wallet Gateway), not the wallet UI. ClearSign's topology wizard appears to keep topology orchestration inside the wallet. Does the wizard run against a CIP-103-compliant Wallet Provider, or implement topology operations directly?

One process point. Your reply to @davidrichards-da noted the implementation had moved beyond the written proposal. The committee should be voting on what will actually ship, so the revised document needs to reflect current scope.

Once items 2 and 8 are resolved this is in a stronger position to move forward.

srikanth-bitdynamicscontributorcommented07-05-2026 · 5mo agoGitHub ↗

@LucasnFCS

Thanks for the thorough follow-up. Please find my comments below

Two-stage audit. Agreed. We are happy to mirror #90's structure exactly: internal audit at M1 (we'll invite the Digital Asset team or any external team to scope and review), external third-party audit at M3 with a published report and a "Critical/High issues resolved before sign-off" commitment.
Timeline. Targeting one month per milestone from grant award. With grant award at T0:

M1 — T0 + 1 month (internal audit, conformance harness GA, CIP-103 topology surface frozen) M2 — T0 + 2 months (explainable-signing UX + structural verification UI, preapproval revocation dashboard) M3 — T0 + 3 months (external audit, Critical/High remediation, Docker image + Helm chart published) M4 — T0 + 4 months (operator deployment guide, deployment-readiness reporting, multi-key external-party support)

Accountability and volatility. Agreed — adopting #90's structure verbatim: acceleration bonus (+10–20% for early delivery), late penalty (-10%/month for the first four months), and proposer-borne CC volatility risk. The original six-month re-evaluation clause is withdrawn.
Adoption signals. The earlier names were removed deliberately because the most recent voting-team guidance asked teams to surface adoption signals as PR comments and to tie milestones to usage metrics rather than upfront letters. They are still the partners interested to use nothing changed.
Team composition. Team comes from an background with validator operations experience and also shipped indexers, wallets, and DEX integrations across several ecosystems.We used to run L2's on ETH for prominent players. We hear the wallet-security-specific concern — for the M3 external audit we'll pick a firm with applied-cryptography/wallet-security depth and treat their Critical/High findings as gating, which addresses the expertise gap at the audit boundary rather than only at the team boundary.
License. We've been preparing the repo under MIT; happy to switch to Apache 2.0 to match #90's precedent. Will update the LICENSE before M1.
Deployable artefacts. Committed. Docker image + Helm chart at M1, plus a Compose stack that wraps the conformance harness against local-multi-sync so reviewers can exercise the wallet independently against a real Canton stack with one command. Not difficult — the wallet web app is a standard Next.js build, the extension is a static bundle, and the conformance harness is a CLI. We can publish a preview image ahead of M1 if it would help the committee evaluate.
Overlap with #90. Agreed: #90 is the broader, default-wallet-replacement effort, and we want to avoid duplicate audit spend on overlapping surfaces. Happy to coordinate directly with the #90 team — concretely, we'd descope the portfolio-style UI and any extension surfaces that #90's M1/M3 will cover, and consume those instead. ClearSign would then focus on the four pillars #90 doesn't address at any milestone:

CIP-103 topology extension (canton_topology_* namespace) routing onboarding through the wallet provider boundary Architecture clarification. The wizard runs through a CIP-103-compliant Wallet Provider. the wizard calls those provider methods, not LedgerApiClient directly. dApps and operator tooling drive onboarding through the same JSON-RPC boundary as transactions.

Proposal file proposals/canton-clearsign.md, 34 KB

Development Fund Proposal: Canton ClearSign -- External-Party Onboarding, Explainable Signing, and Operator Conformance

Author: Srikanth (Bitdynamics)
Implementing Entity: Bitdynamics
Status: Submitted
Created: 2026-03-13

Abstract

This proposal requests funding to harden, validate, and release an open-source Canton reference wallet and operator toolkit for self-custodial users and operator-managed participants. It focuses on the place where Canton's architecture is most visible to real users: party-owned signing keys, participant-hosted execution, topology-backed onboarding, and domain-aware transaction routing.

The proposal is intentionally complementary to the broader wallet-connectivity efforts already under discussion. It does not try to become a universal multi-wallet discovery standard or replace general dApp SDK work. Instead, it targets a more operationally urgent gap: there is still no strong open-source reference wallet for custom/operator-managed Canton environments that makes external-party onboarding, explainable signing, and operator-readiness first-class concerns.

The funded outputs are designed to be concrete, reusable, and easy to evaluate:

a release-grade self-custodial reference wallet for real Canton environments
an external-party onboarding wizard with explicit topology review
explainable signing with completed local transaction-hash recomputation and verification
first-class transaction history and activity views with lifecycle-aware status tracking
JWT, rights, package, and route diagnostics for custom nodes
an MV3 browser extension plus CIP-103-compatible wallet-local provider/SDK/React surfaces
official DA wallet transport alignment and interoperable dApp-facing surfaces
an operator conformance harness and deployment guides

If approved, the result will be more than a wallet UI. It will be a reference wallet and compatibility toolkit for safe Canton self-custody, trustworthy transaction authorization, and operator readiness on real infrastructure.

This proposal is also not starting from a blank slate. It builds on an existing TypeScript prototype and monorepo that already includes working wallet flows, key handling, provider/SDK/React package surfaces, an MV3 extension shell, a reference dApp, a conformance CLI, Canton API client layers, and network/domain state management. The funded work is therefore primarily about hardening, restructuring, live-environment validation, and closing the remaining safety-critical gaps rather than inventing the product from zero.

Specification

1. Objective

Current wallet-related proposals in the ecosystem primarily target dApp connectivity, wallet discovery, provider abstractions, and generalized SDK layers. Those are important and this proposal is intended to interoperate with that direction. However, they do not fully solve a separate and increasingly important problem faced by users and operators today:

a self-custodial user needs external-party onboarding that matches real Canton topology rules
a signer must be able to understand what a prepared transaction will actually do before authorizing it
an operator needs objective tooling to verify that JWT configuration, user rights, package vetting, topology propagation, and routeability are all correct
an app team targeting a specific participant deployment needs a real reference wallet to test against, not only an abstract integration library

This proposal addresses that gap.

The intended outcome is an open-source wallet platform that demonstrates how to do the following correctly:

generate and protect keys locally
onboard users through either local-party or external-party flows
guide external-party topology setup and approval
connect to custom Canton JSON API and Scan API endpoints
present balances, supported actions, and failure reasons per connected domain or synchronizer
expose a standards-aligned dApp-facing provider surface that interoperates with official Canton/DA SDK consumers
show transaction history and activity with lifecycle-aware views for pending, incoming, outgoing, deposit, and settled states
explain a prepared transaction in human-readable form, recompute the signable hash locally, and block signing when verification cannot be proved
diagnose rights, JWT, package, and topology failures without operator guesswork
allow applications to request connection through a real wallet extension approval flow

The primary success condition is not "another SDK exists." The success condition is that a user and operator can run the wallet against a real Canton environment, complete onboarding safely, inspect and authorize a transaction confidently, and understand what is or is not possible on the connected participant/domain set.

Who This Is For

The intended users of ClearSign are:

operators exposing custom participant, JSON API, and Scan API environments
teams that need a real reference wallet for external-party onboarding and transaction authorization against those environments
application teams that want an extension-backed wallet and reference dApp to test against in operator-managed Canton deployments
wallet providers, exchanges, and integrators that want a reference implementation aligned with the official DA wallet transport and Canton dApp-facing standards

This proposal is strongest in settings where generic wallet connectivity is not enough and the operational questions are specifically Canton-shaped: topology-backed onboarding, rights and package diagnostics, synchronizer-aware route validation, and explainable prepared submissions.

What V1 Does Not Claim

This proposal does not claim:

a universal Canton wallet discovery or connection standard
uniform feature parity across all Canton networks or hosted wallet APIs
unconstrained production multi-synchronizer wallet support
a generic provider or React standard for every Canton wallet

Instead, V1 is explicitly a ClearSign-specific reference wallet and operator toolkit for custom environments, with controlled multi-synchronizer discovery and route validation where the connected environment supports it.

Relationship to Existing Wallet Surfaces

ClearSign is not intended to replace the existing Splice Amulet validator wallet or broader validator stack.

Instead, it is positioned as a complementary self-custodial layer for external parties and other users who are not themselves operating validator infrastructure. Where a deployment already exposes Scan, hosted app-wallet, validator-wallet, or Splice gateway surfaces, ClearSign will integrate with those capabilities rather than attempting to duplicate or silently replace them.

2. Implementation Mechanics

The implementation starts from an existing TypeScript monorepo prototype with a Next.js web application, browser-side ED25519 key generation, encrypted local key storage, import/export flows, participant-backed party allocation, provider/SDK/React package surfaces, an MV3 extension shell, a reference dApp, a conformance CLI, network/domain stores, and Canton JSON API / Scan API client layers.

The funded work will harden that prototype into a reusable public reference platform with the following package layout:

packages/types
packages/core
packages/provider
packages/sdk
packages/react
packages/conformance
packages/plugins/splice
apps/web
apps/extension
apps/example-dapp

Inside packages/core, the primary modules will be:

signers/
routing/
topology/
explain/
diagnostics/
preflight/

The ledger communication layer will be structured around an internal transport abstraction so the reference wallet can use the official @canton-network/wallet-sdk as the preferred ledger backend while retaining a direct JSON Ledger API fallback for zero-dependency environments such as sandboxes, demos, and selected conformance checks. The dApp-facing provider layer will align to the CIP-103 JSON-RPC surface and remain consumable from the extension, example dApp, and ecosystem tooling built against the official SDK stack.

The funded scope is organized around eight technical workstreams.

A. Dual-Mode Onboarding

Support both local-party and external-party onboarding modes.
Treat external-party onboarding as the signature self-custodial path of this proposal.
Support operator-managed local-party onboarding for deployments where a participant-hosted party model is the preferred operational choice.
Support provisional identities only in explicitly labeled local-development mode.
Add production-mode restrictions so provisional or unregistered parties cannot transact.

B. Signer Abstraction and Secure Local Custody

Introduce a SignerAdapter abstraction instead of coupling flows directly to one browser key manager.
Ship LocalKeySigner and MnemonicSigner in the funded scope.
Define placeholder interfaces for WebAuthnSigner and KmsSigner so future signers do not require re-architecture.
Keep private keys client-side only, with encrypted persistent state and short-lived in-memory unlock sessions.

C. Route Planning, Diagnostics, and Preflight

Replace simple domain resolution with a real RoutePlanner.
Support explicit synchronizer/domain selection and route validation.
Return precise failure reasons such as NO_COMMON_SYNCHRONIZER and NO_SYNCHRONIZER_FOR_SUBMISSION.
Add AuthDiagnostics for missing/expired JWTs, wrong audience/scope, and insufficient actAs / readAs rights.
Add PackagePreflight to detect missing package vetting, incompatible package/template expectations, and optional DAR validation.
Treat CIP-56 holdings and transfers as the default asset path, with capability-aware network-specific alternatives where a connected environment requires them.

D. External-Party Topology Wizard

Provide a topology onboarding wizard that makes the external-party trust model explicit.
Guide the user through key generation/import, party mode selection, validator/synchronizer choice, topology bundle creation, local review, signing, submission, and propagation checks.
Complete the participant-aware submission path so selected confirming participants, observing participants, and thresholds are reflected in the generated topology rather than being only a UI review surface.
Make required topology relationships visible rather than implicit, including PartyToParticipant, ParticipantToParty, and party key mappings.

E. Explainable Signing

Decode prepared transactions into a human-readable explanation.
Show creates, exercises, archives, pinned contract IDs, synchronizer/domain, expiry, and command identifiers.
Complete a true local transaction-hash recomputation path and compare it to the participant-provided prepared hash before enabling signing.
Persist the explanation alongside the signed submission for auditability.

F. Delivery Surfaces and Operator Readiness

Expose ClearSign's own wallet-local provider, SDK, React layer, and extension as the integration surfaces for this platform, while aligning those surfaces with CIP-103 where practical.
Continue dogfooding those surfaces by migrating and stabilizing the web wallet against them internally.
Harden the MV3 extension with per-origin approval and encrypted local/session state.
Ship an operator conformance harness with CLI, machine-readable JSON output, and optional HTML reporting, then validate it against real deployments rather than only synthetic or demo scenarios.
Publish a local sandbox guide, a custom-node/operator guide, and a reference dApp.

G. Standards Alignment, Activity History, and Ecosystem Integration

Introduce a LedgerApiPort transport boundary so the released core can run against the official @canton-network/wallet-sdk while preserving a documented direct-API fallback.
Align the dApp-facing provider surface to CIP-103 and ensure the extension-backed wallet remains interoperable with dApps built against the official @canton-network/dapp-sdk / wallet SDK expectations.
Make transaction history a first-class wallet feature, including paginated activity, lifecycle-aware buckets, pending proposal tracking, and transaction detail / receipt views.
Treat CIP-56 holdings and transfers as the default path, with capability-aware alternatives such as Splice CC gateway flows where the connected network requires them.
Document and support the relationship between ClearSign and existing Scan, hosted app-wallet, validator-wallet, and Splice Amulet / CC gateway surfaces so the reference implementation is clearly complementary rather than replacement-oriented.

H. Security Assurance and Forward Compatibility

Commission an independent external security audit of the key-management and signing path before final release sign-off.
Publish a remediation summary for material findings and track any deferred low-severity issues transparently.
Keep explicit extension points for multi-synchronizer routing, hosted-wallet capability discovery, proposal/preapproval flows, and evolving Canton / DA SDK interfaces.
Include a funded 12-month maintenance and support window covering security updates, dependency updates, compatibility fixes, release management, and documentation corrections after audited release.

Important scope boundary:

the funded provider, SDK, and React surfaces are ClearSign-specific reference integration layers for this wallet platform
where practical they will align to CIP-103 and official DA/Canton SDK expectations, but they are not proposed as universal Canton wallet standards or ecosystem-wide governance interfaces in this grant

Phase 2 functionality such as reward-claim assistance, multi-CPN read quorum, threshold-signing UX, and additional signer types remains outside the requested first-release scope except for architectural placeholders and plugin boundaries. However, the funded architecture will explicitly preserve forward-compatibility for multi-synchronizer routing, hosted-wallet capability discovery, proposal/preapproval flows, and standards-aligned SDK/provider evolution so the reference implementation remains useful as the Canton Network surface matures.

Because official Canton documentation currently notes that external-party submissions are limited to a single root node and a single submitting party, and that multi-synchronizer participant setups remain a preview feature rather than general production guidance, Phase 1 of this proposal will treat multi-synchronizer support as a controlled production rollout with explicit route validation rather than unconstrained "works everywhere" claims.

3. Delivery Readiness

This work is not starting from zero. The current prototype already includes:

a working TypeScript monorepo and web wallet shell
browser-side ED25519 key generation and encrypted local storage
import/export flows for wallet material
shared provider, sdk, and react package surfaces
an MV3 browser extension shell with approval/session plumbing
a reference dApp that already consumes the shared wallet surfaces
a conformance CLI with JSON and HTML reporting paths
a transport abstraction with an initial official SDK-backed ledger adapter path
Canton JSON API and Scan API client layers
external-party topology generation/allocation flows and validator setup approval wiring
network and domain state management
send/receive/activity flows, lifecycle-aware wallet UX, and network-specific integration hooks

That existing baseline reduces zero-to-one risk significantly. The funded work is primarily about hardening, restructuring, and proving the platform across realistic Canton deployment patterns rather than inventing the product from scratch.

Current Proof Today

The current repository already proves several important pieces of the proposal:

a working wallet shell with local key custody, import/export, and network/domain state management
shared provider, sdk, react, and conformance package surfaces already wired into the monorepo
a reference dApp consuming the shared wallet surfaces
an initial official SDK-backed ledger transport adapter coexisting with the direct API path
a live browser proof for real external-party onboarding against the checked-in local multi-synchronizer stack
activity/history flows and hosted wallet / Splice integration work that already go beyond the originally written proposal text
live conformance runners for JSON API reachability, JWT acceptance, rights checks, synchronizer reachability, onboarding viability, and related compatibility checks

The implementing team is therefore positioned to deliver:

a coherent package architecture rather than a one-off app
a reference wallet that dogfoods its own provider/SDK surfaces
a practical operator toolchain rather than UI-only deliverables
a hardening-oriented release plan grounded in already-running code rather than speculative greenfield milestones

4. Risks and Mitigations

This proposal takes on technically meaningful work, so the delivery approach explicitly accounts for the main risks.

External-party constraints: external-party submissions currently have important platform limits. The wallet will encode those limits directly in UX, route validation, and documentation rather than hiding them.
Multi-domain production posture: because multi-synchronizer participant setups remain preview-oriented in current documentation, the project positions Phase 1 as a controlled production rollout with explicit route planning and unsupported-path rejection.
Operator auth diversity: real deployments vary widely in JWT issuance, audience configuration, and rights assignment. The funded diagnostics and conformance workstreams are intended to reduce integration ambiguity here.
Chrome MV3 lifecycle complexity: the extension will be designed around ephemeral service-worker behavior from the beginning, with encrypted persistent state, session-backed unlock state, and approval-focused initial scope.
Scope breadth: the sequence of milestones intentionally reduces risk by building and dogfooding the shared core before broadening to the extension and conformance layers.
Standards-alignment drift: the official SDK and CIP-103-facing surfaces may continue to evolve. The transport abstraction, backward-compatible aliases, and standards-alignment workstream are intended to keep ClearSign interoperable without forcing a rewrite.
Security assurance expectations: because this is a reference wallet handling network assets, audit expectations are appropriately higher than for a prototype. The revised proposal includes an external audit before final sign-off rather than treating audit as a post-adoption extra.

5. Architectural Alignment

This work aligns with Canton architecture and ecosystem goals in a straightforward way.

It consumes existing Canton interfaces and official SDK layers instead of modifying protocol internals.
It improves the safety and usability of participant onboarding and wallet operation without changing ledger semantics.
It supports controlled multi-synchronizer discovery and route validation where the connected environment exposes the necessary capabilities, rather than hiding domain state behind opaque UX.
It integrates with existing Scan, validator-wallet, hosted app-wallet, and Splice gateway surfaces where they already exist, rather than attempting to replace them.
It is a shared public-good reference implementation that can be reused by operators, app teams, and wallet builders.

Relevant architectural alignment points:

CIP-56 alignment: CIP-56 holdings and transfers are treated as the default asset path, with capability-aware network-specific alternatives used only where required.
CIP-103 alignment: the extension/provider layer will align to the Canton dApp-facing JSON-RPC surface so dApps targeting the standard can interoperate with the wallet.
Official SDK alignment: the core transport layer will support the official @canton-network/wallet-sdk as the preferred ledger backend while retaining a documented fallback where appropriate.
External-party alignment: the project treats external parties as the signature self-custodial model and designs around their real onboarding and signing requirements.
Local-party alignment: participant-backed party allocation remains supported for operator-managed deployments where a participant-hosted party model is operationally preferred.
Custom-node compatibility: the wallet is designed to work with operator-managed JSON API / Scan API endpoints rather than assuming a single hosted environment.
Ecosystem integration: ClearSign is positioned as a complementary self-custodial layer that can work with existing validator/app-wallet/Splice surfaces instead of replacing them.
Operator-readiness: package vetting, rights diagnostics, and conformance testing are aligned with how Canton environments are actually operated.
Future compatibility: the architecture keeps explicit extension points for multi-synchronizer routing, hosted-wallet capabilities, and evolving network features instead of treating future support as an afterthought.

Relationship to Existing Proposal Areas

This proposal is intentionally designed to complement the wallet-connectivity proposals already under discussion.

It does not primarily seek to deliver:

a universal multi-wallet discovery layer
a new ecosystem-wide wallet connection standard
a generic provider standard for all Canton wallets
a generic React wrapper for all wallets
a broad end-to-end dApp starter kit beyond the wallet/provider surface itself
a backend/server wallet SDK

Instead, it delivers a concrete and more specialized platform that broader connectivity efforts can interoperate with, while aligning to shared standards where that improves adoption:

a self-custodial wallet for real operator-managed environments
an external-party onboarding and explainable-signing reference flow
an operator diagnostics and conformance layer
a plugin-ready base for network-specific workflows without polluting the generic core

6. Backward Compatibility

No backward compatibility impact.

The proposal introduces an external wallet implementation and supporting docs. It does not require protocol changes, participant changes, or contract migrations.

Milestones and Deliverables

Milestone 1: Public Alpha for Wallet Core, SDK Alignment, and Routing Diagnostics

The released alpha can run the wallet on the stabilized core, expose a documented transport abstraction with the official SDK-backed path, and deterministically surface route, auth, and package failures.

Milestone 2: External-Party Onboarding, Explainable Signing, and Activity History

At least one evaluator completes the onboarding and explainable-signing flow, and the released wallet exposes first-class activity/history views with lifecycle-aware transaction states.

Milestone 3: Hardened Wallet, Extension, and Ecosystem Interoperability Release

The shared provider, SDK, and React layers, example dApp, and extension-backed flow are hardened based on evaluation feedback, aligned to CIP-103 where practical, and documented with clear ecosystem-integration boundaries.

Milestone 4: Operator Conformance, Security Audit, and Deployment Readiness

An operator can run the conformance harness against a real or demo deployment and get a reproducible compatibility report plus deployment guidance, and the project reaches audited release readiness before final sign-off.

Potential Ecosystem Beneficiaries

This proposal is intended as public-good infrastructure for the wider Canton ecosystem, and I have identified a few ecosystem teams that are well aligned with the feature set and have expressed interest in this kind of capability .

These features address recurring onboarding, signing, and operator-conformance pain that teams in this category face when building or operating Canton-based systems, especially where external parties need safe, understandable wallet interactions.

More broadly, this project is useful for all teams building Canton wallet experiences, self-custodial user flows, external-party onboarding journeys, and operator-managed signing workflows.

Acceptance Criteria

The Tech & Ops Committee will evaluate completion based on:

all milestone deliverables shipped under an open-source license
demonstrated local-party and external-party onboarding flows in the released wallet
documented prevention of production transactions from provisional or unregistered identities
functioning transaction explainability and true local hash recomputation/verification
functioning transaction history / activity views with lifecycle-aware state tracking
functioning route diagnostics, auth diagnostics, and package preflight reporting
functioning extension approval flow for connect/sign/submit for the reference dApp
a documented CIP-103-compatible dApp-facing provider surface exercised by the reference dApp
an official @canton-network/wallet-sdk transport path available in the released core, with documented fallback behavior where applicable
functioning conformance harness output against the demo environment
published setup documentation for both local sandbox and custom-node/operator environments
completed independent security audit of the key-management and signing path before final sign-off

Project-specific acceptance conditions:

the project must remain explicitly out of scope for universal multi-wallet standardization
the local demo must be reproducible from repository documentation without private infrastructure
the reference dApp must exercise at least one success path and one clearly rejected unsupported-capability path
external-party support must explicitly respect documented Canton limitations in the released UX and documentation
selected confirming/observing participants and threshold choices must be reflected in the actual onboarding submission path where the connected environment supports them
the funded provider, SDK, and React layers must remain ClearSign-specific reference surfaces rather than being presented as generic ecosystem standards
the released documentation must clearly explain how ClearSign integrates with Scan, validator/app-wallet, and Splice Amulet / CC gateway surfaces
the audited release must begin a committed 12-month maintenance and support window

Funding

Base Implementation Funding Request: 900,000 CC

Payment Breakdown by Milestone

Milestone 1 Public Alpha for Wallet Core, SDK Alignment, and Routing Diagnostics: 250,000 CC upon committee acceptance
Milestone 2 External-Party Onboarding, Explainable Signing, and Activity History: 300,000 CC upon committee acceptance
Milestone 3 Hardened Wallet, Extension, and Ecosystem Interoperability Release: 200,000 CC upon committee acceptance
Milestone 4 Operator Conformance, Security Audit, and Deployment Readiness: 150,000 CC upon final audited release and committee acceptance

Additional Budget Items

External security audit: approximately USD 30,000. The final quote may land below or above this estimate depending on the firms engaged and the final agreed scope. I will keep the Committee informed before engagement and if the estimate changes materially.
Post-release maintenance and support for 12 months: 484,000 CC. This covers security updates, dependency updates, Canton / CIP-103 / DA SDK compatibility fixes, release management, issue triage, and documentation corrections during the first year after audited release.

Funding Rationale

Milestone 1 funds stabilization of the core package boundaries and the highest-risk architectural hardening work: signer abstraction, routing, auth diagnostics, package preflight, and the generic wallet core that all later flows depend on.
Milestone 2 funds the main user-safety work: external-party onboarding, participant-aware topology submission, transaction explainability, and completed local hash verification.
Milestone 3 funds platform dogfooding and reference integration proof: hardened provider surfaces, the extension, standards-aligned dApp interoperability, and the example dApp used to validate the wallet against realistic application flows.
Milestone 4 funds the operator-facing validation layer: reproducible conformance checks, live compatibility testing where available, deployment guides, and the work required to reach audited release readiness.
The external audit line item funds independent assurance for the key-management and signing path before final sign-off.
The maintenance/support line item funds the first 12 months of keeping the reference implementation secure, compatible, and usable after release.

Volatility Stipulation

The base implementation grant is denominated in fixed Canton Coin and will require a re-evaluation at the 6-month mark to account for significant USD/CC price volatility.

The audit and maintenance/support line items are stated in USD because they depend on external vendor quotations and post-release operating costs more naturally expressed in fiat terms. Their final CC-equivalent can be normalized with the Committee during contracting or milestone planning, and I will keep the Committee informed if those estimates move materially.

Co-Marketing

Upon release, the implementing entity will collaborate with the Foundation on:

announcement coordination
a technical blog describing explainable self-custody and external-party onboarding for Canton custom nodes
developer and operator promotion for the reference wallet, extension, and demo environment

Specific commitments:

publish a walkthrough showing local-party, external-party, and custom-node/operator flows
host at least one public demo or workshop focused on external-party onboarding, explainable signing, and operator conformance
publish the reference dApp and demo scripts used for milestone acceptance

Motivation

This proposal is valuable because it addresses the most operationally sensitive part of the Canton wallet stack: the point where a user-controlled signing key, a participant-controlled execution environment, and a topology-governed trust model all meet.

Much of the current ecosystem discussion is rightly focused on connectivity standards and SDKs. But a user still needs to answer harder questions:

how do I onboard an external party correctly?
what exactly am I signing?
why is this validator rejecting my request?
is this node really ready for production self-custodial usage?

Those are not generic wallet questions. They are specifically Canton questions.

An open-source platform for explainable self-custody and operator conformance delivers shared value in several ways:

it reduces the amount of bespoke onboarding, signing, and diagnostics logic each operator must build
it gives the ecosystem a reusable example of safe external-party flows
it improves trust by making transaction effects visible before signing
it gives operators an objective compatibility and readiness tool rather than ad hoc debugging
it creates a clean place for future network-specific plugins without forcing those workflows into the generic core

Because the work is open-source and reference-oriented, the benefit is shared rather than private, while still solving a problem that real users and operators face immediately.

It also gives the ecosystem something that is currently missing in a single public package: not just a wallet surface, but a reference flow for explainable self-custody and a practical way for operators to verify compatibility before users ever see a confusing failure.

Rationale

This is the right approach because it stays tightly scoped to a real gap while still feeling ambitious and distinctive.

Alternative directions were considered:

proposing a universal wallet connector SDK
proposing a generic provider standard
proposing a broad React integration toolkit
proposing a backend/server wallet SDK

Those directions are either already being pursued by other proposals or are better handled by broader standards-focused efforts.

By contrast, this proposal combines three things that fit together naturally and are currently under-served:

a wallet
an explainable external-signing reference flow
an operator conformance and diagnostics toolkit

That combination makes the proposal more useful than a wallet UI alone, while remaining more disciplined than a whole-ecosystem standards effort.

It is also technically well matched to the current state of Canton:

external parties are the strongest self-custodial model, so the proposal leans into them
external-party limits are real, so the proposal encodes them explicitly instead of hiding them behind vague promises
multi-domain support is useful, but must be routed and validated carefully under current platform constraints
operator trust depends as much on diagnostics and conformance as on UI polish

The project follows a sound delivery sequence:

freeze interfaces and core constraints first
make onboarding and signing safe second
dogfood the provider surfaces in the wallet itself third
turn the result into an operator-ready reference platform fourth

That ordering reduces risk, makes milestones easy to verify, and gives the proposal a clearer identity than existing connectivity-focused submissions.

Team Background

BitDynamics

BitDynamics brings deep experience in building and operating blockchain infrastructure. The team has worked across Ethereum client infrastructure, validator operations, and production-grade hosting systems supporting validator infrastructure securing more than 2 billion AUD in assets. This background is directly relevant to building reliable, auditable, and security-conscious public infrastructure for a grants program. Team is also building actively on Canton.

Why Bitdynamics Can Deliver This

Bitdynamics is already building the underlying prototype in an active TypeScript monorepo rather than proposing from a blank slate. That matters for feasibility.

The current implementation already demonstrates:

client-side key generation and encryption
wallet import/export flows
participant-backed party allocation attempts
domain/network modeling
Canton API integration layers
a functioning wallet UI shell that can be migrated to the new provider stack

This means the requested funding is aimed at hardening, restructuring, and proving the platform in realistic Canton scenarios, not at speculative invention. The proposal is ambitious, but it is grounded in code that already exists and can be demonstrated.

Journey on the board 10 moves, stepped back or reopened 2

Now: Declined, 133 days since 10-06-2026
Waiting: decided on the board but the PR is still open. The board shows Declined but the pull request is still open.
First human response: 26 days after opening, by LucasnFCS (committee side)

Incoming19-03-2026 to 25-03-20266.2 daysmoved by hythloda
Needs Champion25-03-2026 to 25-03-20260.1 daysmoved by hythloda
Needs Revision25-03-2026 to 25-03-20260.1 daysmoved by hythloda
Incoming25-03-2026 to 02-04-20267.8 daysmoved by hythloda
In Review (Champion Assigned)02-04-2026 to 09-04-20267 daysmoved by hythloda
Ready for Vote09-04-2026 to 15-04-20266.1 daysmoved by hythloda
Voting Live15-04-2026 to 22-04-20267.2 daysmoved by hythloda
Needs Revision22-04-2026 to 01-05-20268.3 daysmoved by hythloda
In Review (Champion Assigned)01-05-2026 to 10-06-202640 daysmoved by srikanth-bitdynamics
Declined10-06-2026 to now133 daysmoved by srikanth-bitdynamics

Rebuilt from the recorded board moves (complete history). get_dev_fund_lifecycle(number) gives the same in the MCP.

Timeline 25 events

13-03-2026review requested from team:admins by srikanth-bitdynamics
13-03-2026review requested from tkatrichenko by srikanth-bitdynamics
13-03-2026review requested from hythloda by srikanth-bitdynamics
13-03-2026review requested from stas-sbi by srikanth-bitdynamics
13-03-2026review requested from waynecollier-da by srikanth-bitdynamics
13-03-2026review requested from isegall-da by srikanth-bitdynamics
19-03-2026moved to another column of the project board by hythloda
19-03-2026added to the project board by hythloda
19-03-2026branch force-pushed by srikanth-bitdynamics
25-03-2026label added: wallet-apps by hythloda
25-03-2026moved to another column of the project board by hythloda
25-03-2026moved to another column of the project board by hythloda
25-03-2026moved to another column of the project board by hythloda
02-04-2026assigned to LucasnFCS by LucasnFCS
02-04-2026review requested from LucasnFCS by LucasnFCS
02-04-2026moved to another column of the project board by hythloda
09-04-2026moved to another column of the project board by hythloda
15-04-2026moved to another column of the project board by hythloda
22-04-2026moved to another column of the project board by hythloda
01-05-2026moved to another column of the project board by srikanth-bitdynamics
05-05-2026assigned to Denend by Denend
05-05-2026unassigned LucasnFCS by LucasnFCS
05-05-2026assigned to LucasnFCS by LucasnFCS
05-05-2026unassigned Denend by Denend
10-06-2026moved to another column of the project board by srikanth-bitdynamics

← Back to Proposals Open on GitHub ↗