Shared Wallet

Overview

A shared wallet can use multisignature keys, smart-contract owners, provider roles, or a shared login. Proper designs preserve individual identity and enforce permissions, while shared credentials give every holder uncontrolled and unauditable access.

Shared use does not determine asset ownership. Company funds, joint personal assets, customer balances, or project treasuries require different legal and accounting treatment. One administrator or recovery mechanism may still control the entire wallet despite multiple visible users.

Participants should document owner, purpose, roles, approval threshold, spending limits, key custody, recovery, and exit. Each action should identify the responsible user or signer. Access reviews and offboarding are essential. The wallet should tolerate reasonable participant absence without permitting one compromised account to redirect all assets.

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

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

Records for Shared 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 Shared Wallet, corrections must remain linked rather than overwrite the original event.