Sub-Wallet

Overview

Sub-wallets can separate balances, addresses, policies, reporting, or workflows without requiring a fully independent platform relationship. They may derive from a parent seed, share custody infrastructure, or exist only as internal ledger partitions.

The apparent separation may not limit technical authority. A parent administrator, master key, provider, or recovery path may control every sub-wallet. Internal transfers can occur without on-chain movement, and legal ownership may remain with the same parent account.

Systems should define ownership, custody, derivation, permissions, asset and network scope, limits, and transfer behavior for each sub-wallet. Identifiers must remain stable for reconciliation. Parent-level access requires strong controls. Recovery should preserve child mappings and indexes. Reports should distinguish independent on-chain balances from internal allocations.

Material risks for Sub-Wallet include credential compromise, malicious destinations, unsupported assets, wrong-network transfers, stale balances, compromised software, provider outage, privacy leakage, and inaccessible recovery material. For Sub-Wallet, controls should reflect value, automation, reversibility, and whether the organization or a third party controls signing.

Production ownership for Sub-Wallet should identify the user or legal entity, supported assets and networks, address model, custody boundary, signing authority, recovery method, and systems permitted to request or observe transactions. For Sub-Wallet, these fields determine who can act and which evidence is authoritative.

Records for Sub-Wallet should preserve account and address identifiers, asset and network identity, policy version, requester, approvers, signed payload or transaction reference, fees, timestamps, status history, confirmations, exceptions, and final balance and accounting effects. For Sub-Wallet, corrections must remain linked rather than overwrite the original event.

Sub-Wallet should be distinguished from the asset balance and from the application that displays it. For example, a customer-facing success message does not prove that the intended transaction executed on the correct network; operations should verify execution and reconcile the result before irreversible fulfillment.