> ## Documentation Index > Fetch the complete documentation index at: https://cantonfoundation-fix-1392-tokenomics-cip-104.mintlify.site/llms.txt > Use this file to discover all available pages before exploring further. # Splice Wallet Reference > Reference documentation for the built-in Splice wallet, covering Canton Coin operations, automation, transfer workflows, APIs, and UTXO management 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](https://github.com/canton-foundation/cips/blob/main/cip-0078/cip-0078.md), 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](https://raw.githubusercontent.com/canton-network/splice/refs/heads/main/apps/wallet/src/main/openapi/wallet-external.yaml) and [wallet-internal.yaml](https://raw.githubusercontent.com/canton-network/splice/refs/heads/main/apps/wallet/src/main/openapi/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](https://raw.githubusercontent.com/canton-network/splice/refs/heads/main/apps/validator/src/main/openapi/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](/sdks-tools/sdks/wallet-sdk/quickstart).