Segregated Wallet

Overview

Segregated wallets improve transaction attribution, risk isolation, policy assignment, and reconciliation. A custodian may provide separate blockchain addresses, key domains, or ledger accounts, while an organization may separate customer, entity, reserve, and operating funds.

Separation at the interface may not equal independent key control or legal ownership. Several wallets can share a master key, signer, administrator, provider account, or recovery path. Shared dependencies can create correlated compromise even when balances appear separate.

The design should document owner, purpose, custody, keys, signers, policy, assets, networks, funding, and permitted destinations. Access and accounting must preserve boundaries. Organizations should evaluate shared infrastructure and recovery authority. Transfers between segregated wallets need the same approval and reconciliation as other ownership or purpose changes.

The Segregated Wallet workflow operates through several distinct states: request creation, user or policy approval, signature generation, network submission, execution, confirmation, balance recognition, and accounting. For Segregated Wallet, a wallet interface or provider response can report progress, but it cannot replace verified transaction and ledger evidence.

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

Segregated 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.