Skip to main content
The Splice Wallet is the built-in wallet component of every validator node on the Canton Network. It provides Canton Coin (CC) management for parties hosted on that validator, including a web UI, background automation, and programmatic APIs.

​
Wallet UI

The wallet UI ships with every validator node and gives users a browser-based interface for CC operations. After logging in and onboarding (which allocates a fresh party), users can:
  • View their CC balance and individual Holding contracts (UTXOs)
  • Send CC to other parties via transfer offers or one-step preapproved transfers
  • Accept, reject, or withdraw incoming transfer offers
  • Review transaction history
  • Buy traffic for any validator on the network
  • Manage minting delegations (accept, reject, or withdraw proposals from external parties)
The validator operator’s party is automatically created during validator initialization and associated with the configured validatorWalletUser. Other users onboard through the UI or via the /v0/admin/users API endpoint.

​
Wallet Automation

The validator app runs several background automations on behalf of wallet users. These handle recurring CC operations without manual intervention. Reward collection. The wallet automation periodically collects and mints reward coupons (validator rewards, app rewards, liveness activity records) for each onboarded party. This converts earned coupons into CC holdings. Traffic top-ups. When configured, the validator automatically purchases traffic credits using CC from the operator’s wallet whenever the extra traffic balance drops below a threshold. Operators set a targetThroughput and minTopupInterval, and the automation buys enough traffic to sustain that throughput. On DevNet, the validator taps enough coin automatically if the wallet lacks funds. Sweeps. Operators can configure automatic sweeping, where CC is transferred from one party to another when the sender’s balance exceeds a maxBalanceUSD threshold. The automation creates transfer offers that move funds down to a configured minBalanceUSD. Sweep configuration maps sender party IDs to receiver party IDs and balance thresholds. Sweeps can use transfer preapprovals for one-step delivery. Auto-accept. Operators can configure automatic acceptance of incoming transfer offers from specific sender parties. This is configured per sender-receiver party ID pair in the validator’s Helm chart or Docker Compose configuration.

​
Transfer Workflows

A manual CC transfer using the UI of the Splice wallet (the wallet UI built into every validator) is an example of an AmuletRules_Transfer. There are three types of manual transfers possible with the Splice Wallet UI:
  • Amulet legacy transfer offer where the receiver has to accept the transfer offer and then automation on the sender’s side completes the transfer. The sender is assigned to the ValidatorRewardCoupon user field. These transfers are never featured.
  • A two-step, token standard based Transfer offer first locks the desired CC amount; on acceptance, it is unlocked and the transfer is completed. This does not rely on automation and works well for external parties. Both steps appear as separate entries in the wallet’s transaction history:
    1. The first step locks the CC into a TransferInstruction contract as part of creating the transfer offer.
    2. When the receiver accepts the transfer, the CC is unlocked and the CC amount is transferred to the receiver. (Alternatively, the transfer may be rejected or allowed to expire.)
    The sender can also withdraw the offer before acceptance, reclaiming the locked funds. Since CIP-0078, no fees are charged on these transfers.
  • One-step transfer to a receiver that has preapproved incoming CC transfers set up via a TransferPreapproval contract. The validator operator of the receiver is the provider party on the TransferPreapproval and handles its periodic renewal. The TransferPreapproval contract is only visible to: the receiver, the receiver’s validator operator party, and SuperValidators.
The transfer is featured if the provider party is a featured application provider. The reason for this being a featured transfer, is that this provider party enabled the receipt of the CC for the external party by creating the TransferPreapproval and taking care of its regular renewal. The legacy or token standard based one-step transfers work the same. As for the other two transfers, no fees are charged. If the transfer is featured, then an AppRewardCoupon is created for the provider with the amount set to AmuletConfig.transferConfig.extraFeaturedAppRewardAmount / conversionRate where the USD / CC conversionRate is read from the OpenMiningRound contract referenced in the transfer.

​
Wallet API Endpoints

The validator app exposes wallet APIs under the /v0/wallet/* path. These fall into two categories. External API (wallet-external.yaml) — intended for programmatic wallet interaction with backwards compatibility guarantees. Requires a JWT where the subject claim identifies the wallet user. Endpoints include:
  • POST /v0/wallet/transfer-offers — create a transfer offer
  • POST /v0/wallet/transfer-offers/{tracking_id}/status — check transfer offer status
  • GET /v0/wallet/transfer-offers — list transfer offers
  • POST /v0/wallet/buy-traffic-requests — request a traffic purchase
  • POST /v0/wallet/buy-traffic-requests/{tracking_id}/status — check traffic purchase status
Internal API (wallet-internal.yaml) — used by the wallet UI frontend. No backwards compatibility guarantees. Endpoints include:
  • GET /v0/wallet/balance — query wallet balance
  • GET /v0/wallet/amulets — list UTXOs
  • POST /v0/wallet/transactions — transaction history
  • POST /v0/wallet/transfer-offers/accept — accept a transfer offer
  • POST /v0/wallet/transfer-offers/reject — reject a transfer offer
  • POST /v0/wallet/transfer-offers/withdraw — withdraw a transfer offer
  • GET /v0/wallet/user-status — user onboarding and wallet status
For the full OpenAPI specifications, see the wallet-external.yaml and wallet-internal.yaml files.

​
UTXO Management

Canton Coin uses a UTXO model inherited from the underlying Amulet contract structure in Splice. Each active Holding contract on the ledger represents a single UTXO with a specific CC amount. Unlike account-balance models, a party’s total balance is the sum of all their individual Holding UTXOs. UTXO management matters for wallet providers because active Holding contracts consume storage and compute on the hosting validators, and each UTXO input to a transfer incurs extra traffic cost. Canton Coin enforces a limit of 100 input contracts per transfer and expires dust UTXOs whose initial amount is smaller than the accrued holding fee. Wallet providers should aim for roughly 10 or fewer UTXOs per user on average. MergeDelegation contracts allow a wallet provider to merge small Holding UTXOs on behalf of users. The workflow:
  1. The user signs the creation of a MergeDelegationProposal during onboarding.
  2. The wallet provider accepts the proposal, creating an active MergeDelegation.
  3. A background process identifies users with more than 10 UTXOs, constructs merge operations via the registry API, and executes them in batches of ~100 using the BatchMergeUtility_MergeHoldings choice.
MergeDelegation contracts also allow wallet providers to combine airdrop campaigns with the auto-merging of holdings in a single batched call. Featured wallet providers earn featured app rewards for performing merges.

​
External Party Wallet Support

The validator provides APIs for managing CC for external parties — parties whose transaction signing keys are held outside the participant node. The external signing workflow uses Canton’s interactive submission feature, where transactions are prepared on the participant, signed externally, and then submitted back. The high-level flow for an external party:
  1. Set up the external party’s topology using /v0/admin/external-party/topology/*
  2. Create a TransferPreapproval via /v0/admin/external-party/setup-proposal to enable sending and receiving CC
  3. Send CC using /v0/admin/external-party/transfer-preapproval/*
  4. Query balances with GET /v0/admin/external-party/balance
For each transfer, the caller must prepare the transaction (obtaining a hash), sign the hash with the external party’s private key, and submit the signed transaction back to the participant. See the validator-internal.yaml OpenAPI spec for the full endpoint list. For building custom wallet integrations using the TypeScript Wallet SDK, see the Wallet SDK documentation.