Skip to content
CCPEDIAby Unity Nodes
Mailing Lists/Running a Validator with Wallet app and custody considerationSource on lists.sync.global ↗

Running a Validator with Wallet app and custody consideration

globalSyncForum4 messagesstarted 11-04-2025
  1. #1Francois Branciard11-04-2025source ↗
    Hey,
    I have a few technical questions regarding Wallets and transfers (specifically, transfer-offers in the Wallet App of Validators):
    From my understanding (from architecture schema), Validators host users' wallets (in a database or KMS linked to participant node).
    • Is this correct?
    • If Validators do not want to host users' wallets, they can expose an External Custody API, allowing users to be hosted on an external participant node responsible for custody?
    • In all cases, Canton wallets are hosted on a participant node?
    • Is there support for unhosted wallets (e.g., Ledger cold wallets) or MPC wallets (e.g., Fireblocks) at some point?
  2. #2Eduardo @T-RIZE14-04-2025source ↗
    I would love to learn the answer to these questions as well!
  3. #3Wayne Collier17-04-2025source ↗

    When working with wallets on the Canton network, it’s helpful to think about users, real-world entities, addresses, nodes and wallets in the following way:

    • Users are identities created via an OAuth provider, which can sign into apps. 

    • Parties are a means for real-world entities to act on chain, using a PartyID and the PartyID’s associated public-private keypair. The PartyID is the equivalent of a Canton blockchain address. This address is formed from a fingerprint (hash) of the Party’s public key, plus a configurable prefix. 

      • A given PartyID may be associated with one or more users who are able to act as that Party in on chain workflows. 

      • A given real-world entity (a person or organization) may interact with the Canton blockchain directly as a Party; you don’t have to define a user. 

    • Nodes host Parties, and execute just those transactions that involve their hosted Parties. Transactions update the state that's accessible the parties on a given node.

    • Wallets are tools for signing transactions. Transactions are generated from commands submitted by a given application on behalf of a given PartyID (address). The core function of a wallet is to let a given party (representing a real-world entity) sign a transaction using a given set of keys, and then submit the transaction to a chain. Canton-compatible wallets may provide additional services, but they all build on this core function. 

     

    For more general background about 

     

    Canton allows wallets to be implemented in several different ways:

    1. A Canton Validator node can act as a wallet. The node can perform all the work that might be associated with a wallet:

    • Store the public and private keys for a partyID, 

    • Prepare a transaction for that partyID from commands submitted to the Participant node by an application, 

    • Sign the transaction on behalf of that partyID

    • Submit the transaction to the blockchain. 

      This is the default mode described in the Global Synchronizer docs, but going forward it will be used less often and may phase out over time.

     

    2. A Canton-compatible wallet application can take the other extreme and only sign the transaction, allowing the transaction to be prepared by a Participant node. This approach uses the “External Signing” APIs to interact with nodes in Canton. In this case, the added value of the wallet application might include:

    • Displaying to the user what the transaction will do: the inputs and the effects that will result from signing the transaction

    • Collecting authorization to sign the transaction, using a Policy Engine or similar software; 

    • Collecting keys from a KMS or other secure storage, and applying them to the transaction

     

    The wallet could return the signed transaction to another application for review by users before it gets submitted to the blockchain. 

     

    In this case, the Party will still be hosted on a Validator/Participant node, but only in Confirming mode. Confirming mode allows nodes to be updated by a transaction from the blockchain, and it allows Parties to read from the node. When a node hosts a party in Confirming mode, new transactions must be submitted via a wallet; they cannot be submitted via the node itself.  

     

    3. Beyond these two modes, a Canton-compatible wallet could perform any combination of 

    • preparing the transaction via calls to a Validator node; 

    • presenting the details of transaction to the user, 

    • collecting authorization via a policy engine, 

    • generating, storing and retrieving keys (via a KMS or other secure storage), 

    • submitting the transaction. 

     

    Beyond these core functions related to keys and signing, a Canton-compatible Wallet could provide a user interface that presents the set of assets (or full applications) for which the Wallet can sign transactions.  A wallet might also include application logic that lets the user organize their assets into cold and “active” sets, or other types of segregations, but this organization might also be performed by more specialized Canton applications.


    Currently, Dfns (https://www.dfns.co/)  and Copper (https://copper.co/en) provide Canton-compatible wallets that perform some or all of the functions described in 3.   

    Digital Asset and other Canton Network partners are also actively working on a variety of other types of wallets, including wallet browser plugins, and wallets that allow fully offline key storage. 

    Wayne Collier

    Director of Product Management, Digital Asset

  4. #4Shaul08-05-2025source ↗
    Hi Francois, to answer your four questions explicitly:
    1. Yes, you are correct.
    2. Yes, with a slight correction. If we think of a wallet as both the backend that stores state and the key, by exposing an External Custody API you’re enabling a user to self-host the key that authorizes transactions, but the Validator is still hosting that Party’s data. Consider this similar to a Ledger hardware device (key vault) and Ledger Live (backend and UI). In this example you still need a Validator node as the wallet backend.
    3. The wallet data/backend is always hosted on a Validator; the key can be held separately using the External Custody feature.
    4. There will be support for the most common wallets, such as Ledger and Fireblocks.