Shared Custody

Overview

The arrangement can use multisignature, threshold signing, split keys, contractual approval, or custody layers involving a client and provider. It may balance professional operations with client participation or distribute organizational control across independent teams.

Shared custody is not automatically non-custodial. A provider may hold an override, recovery, policy, or upgrade path. Participants can also be exposed to collusion, unavailability, incompatible procedures, or disputes. Legal ownership may differ from technical signing authority.

Agreements and architecture should identify each party, quorum, permitted actions, key storage, policy changes, recovery, replacement, and exit. Signers should verify transaction intent independently. The design must tolerate expected loss without enabling easy collusion. Tests should cover participant failure, provider outage, conflict, and migration to a new arrangement.

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

Shared Custody 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.

The operating model for Shared Custody should map legal ownership, beneficial entitlement, technical control, account structure, asset segregation, supported networks, signing policy, provider roles, contractual duties, and insolvency treatment. For Shared Custody, these dimensions can belong to different parties and must not be inferred from a wallet label.