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!