Custody Wallet

Overview

The wallet may be assigned to one client, shared across an omnibus account, or used for a function such as deposits, withdrawals, reserves, staking, or fee funding. It can be hot, cold, multisignature, threshold-controlled, or managed through a smart contract.

A custody–account balance does not always map one-to-one to a custody wallet. Internal ledgers may allocate portions of a shared on-chain balance to many clients, while one client may use several wallets. Accurate mapping is required for ownership, reporting, transaction attribution, and solvency reconciliation.

Operations should document the wallet’s owner, purpose, assets, networks, signer set, storage tier, limits, and connected accounts. Address and key rotation must preserve history. A custody wallet is a technical container within the service, not by itself proof of legal segregation or beneficial ownership.

Custody Wallet should be distinguished from investment ownership and from a software interface. For example, a provider may display an asset balance while holding pooled assets through another custodian; operations must verify contractual rights, segregation, withdrawal capability, and external evidence rather than rely on the screen alone.

Custody Wallet works through controlled onboarding, asset receipt, internal attribution, storage-tier assignment, authorization, signing or provider instruction, monitoring, withdrawal, reconciliation, reporting, and return or migration. For Custody Wallet, each handoff needs stable identifiers and an authoritative record of who approved and executed it.

Records for Custody Wallet should reconcile on-chain or provider balances with customer entitlements and the internal ledger by asset, network, account, and cutoff. For Custody Wallet, pending deposits, locked assets, staking, fees, conversions, forks, unsupported transfers, and manual adjustments require separate treatment and review.