Architecting an Interoperable Hardware Wallet (Trezor) via CIP-103: Topology, Validator Multi-Tenancy, and Custom dApp DAR Handling

Hi Canton Network Team & Ecosystem Builders,

We are exploring adding Trezor hardware support to the Canton Network.

In ecosystems like EVM, Solana, or any other chain, hardware integration does not require building an entire wallet application or operating custom node infrastructure from scratch. The hardware device simply integrates with existing universal non-custodial wallets (e.g., MetaMask, Rabby, Phantom) or connects via standardized dApp connector libraries.

On Canton, we want to provide an interoperable signing service / hardware bridge that lets users self-custody assets on Trezor, maintain consistent balances, and interact with any dApp across the network. However, looking at the current landscape, we don’t see any native wallet functioning as an open, cross validator, non-custodial bridge in this way. Most existing tools appear to be web interfaces tied to specific validators, app specific implementations, or passkey based web applications.

We want to avoid reinventing the wheel by building our own full fledged wallet application and maintaining dedicated validator clusters if the network already provides or plans a standard path for external signers. We would appreciate architectural guidance on three core questions:

1. Is there an existing open wallet or connector service we can plug into?

Instead of building a bespoke wallet UI from scratch:

• Is there an active open-source CIP-0103 browser extension or standardized wallet service (e.g., within the Splice Wallet Framework / @canton-network/wallet-sdk) where contributing a Trezor signing driver is the recommended path?

• Or is the ecosystem expecting every hardware / custody provider to deploy their own standalone browser extension and dApp connector layer?

2. The Validator Dilemma: Must we operate a dedicated validator for hardware users?

In Canton’s architecture, ledger interaction and the InteractiveSubmissionService require access to a Participant Node (Validator):

• If we do not run a dedicated validator node, can an external party derived from a Trezor device interact directly with third-party dApp validators using Explicit Disclosure (disclosedContracts)?

• If we are required to run a validator to host the user’s External Party ID and Active Contract Set (ACS), how is the user supposed to interact with external dApps that run custom Daml smart contracts (DARs) that our validator does not have pre-installed?

• What is the intended topology for retail non-custodial users so they don’t hit “validator isolation,” where their wallet only works on apps supported by the specific node hosting them?

3. Cross-dApp Balance Continuity & CIP-0056 UTXO Management

For a hardware wallet user, balance retention across all apps is critical:

• Under CIP-0056 / CIP-0112, token holdings are UTXO-like active contracts that require bilateral acceptance (TransferInstruction) and consolidation (MergeDelegation).

• If the user’s signing keys remain offline on a Trezor device, what is the standard pattern for handling incoming transfers and background UTXO merges across different dApps without prompting the physical device for every non-spending state transition?

We want to bring Trezor security to Canton users in the cleanest, most ecosystem aligned way possible. Any insights on existing initiatives, reference implementations, or recommended architectural patterns would be greatly appreciated!

Hey @e1emre
Apologies for delay:

Is there an open wallet/connector you can plug into?

Yes. The open-source Splice Wallet Gateway ( GitHub - canton-network/wallet: dApp SDK / Wallet SDK / Wallet Gateway · GitHub ) is the standard stack, and it has a dApp SDK that implements CIP-0103, a JSON-RPC interface between dApps and wallets. It also exposes an EIP-1193-style window.canton provider and includes a discovery component, so dApps get a RainbowKit-like “pick your wallet” flow.

So the recommended path is to support the dapp standard to have a Trezor signing driver to the Wallet Gateway, rather than shipping your own extension and connector layer. Once the driver exists, any CIP-0103 dApp works with Trezor-held keys without further integration work.

Do you have to run a dedicated validator?

Your party needs a hosting participant.

An external party is still hosted on at least one participant with Confirmation or Observation permission. That participant prepares the transaction, validates it, and holds the party’s ACS. InteractiveSubmissionService runs against a participant’s Ledger API.

On explicit disclosure: disclosedContracts solves contract visibility. It lets you use contracts you aren’t a stakeholder on, such as a token admin’s factory or rules, or a dApp’s service contract. Every participant involved in a transaction must have the relevant packages vetted. Otherwise you get PACKAGE_SELECTION_FAILED. So a party can’t transact against a third-party DAR through a validator that hasn’t vetted that DAR, disclosure or not.

A validator operator choosing which code to vet is a trust decision, not a missing feature. Today the answer is a combination of multi-hosting and a well-maintained DAR set on the home node.

Balance continuity and UTXO management with offline keys

For Incoming Canton Coin, set up a TransferPreapproval. One signature, and after that incoming CC transfers settle in a single step without an accept. The provider party renews it, and if the provider is featured, it earns app rewards on those transfers. For UTXO merges, at onboarding have the user sign a MergeDelegationProposal from splice-util-token-standard-wallet. The provider accepts it, then runs a background job using BatchMergeUtility to merge holdings across users and instruments in batches. No device prompts after setup.