Self-custody

In brief

Custody, in this setting, is the practical ability to authorize a transfer. On typical public blockchains that means control of the private keys, smart-contract rules or other signing authority the network will accept. A custodial platform holds that authority on the user’s behalf and credits an internal balance. A self-custodial setup leaves signing authority with the user, or with a policy the user defined. Benefits include independence from a single service’s solvency and withdrawal rules. Responsibilities include backup, device security and the fact that networks do not reset lost keys. Software wallets, hardware wallets, multisignature arrangements, social recovery and programmable accounts are tools, not synonyms for self-custody. As account rules grow more flexible, control often becomes a spectrum rather than a single switch.

What custody means

You do not hold coins as physical objects. ethereum.org’s account documentation puts the point plainly: you never really hold cryptocurrency; you hold private keys, and the funds remain on the ledger. What people call “having” an asset is the ability to produce the authorization the protocol requires.

That authorization is usually a digital signature from a private key. It can also be a combination of signatures, a contract’s internal logic, a validator’s withdrawal credential, or a delegated permission. Custody is whichever party can satisfy those rules.

Legal and operational language sometimes uses “custody” more narrowly for businesses that hold client assets. This article uses the operational sense: who can cause a valid transfer.

Custodial and self-custodial systems

In a custodial system, a third party — typically an exchange, broker or specialist custodian — controls the keys or the account that the network recognizes. Your balance in the app is a claim on that party. Withdrawals depend on its security, solvency, operating hours and policy. bitcoin.org describes this as counterparty risk: the custodian stands between you and the funds.

In a self-custodial system, the user (or a group the user chose) holds the signing material or controls the authorization policy. The resulting authorization can be submitted on-chain without a custodian's approval, even if wallet infrastructure or a relayer helps transmit it. A company help desk typically cannot freeze a simple native account the way a bank can freeze a deposit, and it also cannot restore access if the secret is lost. That is not the same as saying a key can always spend whatever it points at. Smart-contract rules, token freeze authorities, protocol rules, multisig policies and programmable accounts can all restrict what a given key is allowed to move.

These are poles, not a complete map. A user can keep some assets on an exchange and some in a personal wallet. A company can let users export keys. A smart account can give a recovery guardian limited power. The interesting questions are always: who can sign, under what conditions, and who can change those conditions.

Account custody and asset administration are separate questions. For example, a Solana token mint can retain a freeze authority that can freeze individual token accounts, while token contracts on other networks may implement pause, denylist, mint or upgrade powers. Those powers do not give the administrator the user's private key, but they can still limit transferability or change an asset's rules. “I self-custody the account” therefore does not imply “no one else has administrative power over every token in it.”

What the user actually controls

Self-custody of a simple account usually means control of:

• the private key or the seed that derives it;
• any optional passphrase used when deriving the seed;
• the wallet software or device that will turn a spend request into a signature.

It does not mean control of the ledger, the issuance rules, or other people’s confirmations. It does not mean the wallet brand “contains” the coins. ethereum.org describes a wallet as a window onto an account and notes that users can change wallet providers.

On Bitcoin, control is over specific unspent outputs whose script conditions the user can satisfy. On Ethereum, a traditional externally owned account is controlled by a key pair, while a contract account is controlled by its code; later account features can add delegated code without turning that into a universal rule. On Solana, a signer-controlled address can authorize with an Ed25519 keypair, while a program-derived address has no private key and is authorized through its deriving program. Saying “I hold the coins” is shorthand for “I can satisfy the authorization rules for a spend.”

Signing and authorization authority

A network accepts a transaction because it verifies a signature or a program's rules, not because a company updated a database. The ability to satisfy those authorization rules is therefore the core of custody.

• One key, one spender: a single signature moves the funds.
• Several keys: a multisignature script or contract requires m of n approvals.
• Code: a smart account may allow a key to spend only below a limit, only to certain addresses, or only after a delay.
• Delegation: some designs give a session key, token spender or delegate bounded authority without handing over the master key.

Compromising a key matters only to the extent that key is sufficient. Compromising one key in a 2-of-3 setup is not the same event as compromising the only key of an ordinary account.

Benefits and responsibilities

A fully self-custodial setup can remove one class of failure: a custodian becoming insolvent, seized, hacked in a way that affects pooled keys, or unwilling to process a withdrawal. bitcoin.org's “you are your own bank” section is a description of that trade, not a slogan to end on. Removing that counterparty replaces its controls with the user's own backup, policy and device responsibilities.

The responsibilities are concrete:

• Generate entropy with a trustworthy wallet.
• Back up the seed phrase or other recovery secret offline.
• Keep that backup out of photos, cloud folders, chat apps and support forms.
• Understand what the wallet will actually sign.
• Plan for device loss, death or incapacity if others should be able to recover.

bitcoin.org and ethereum.org both state that lost recovery material on a self-custodied wallet is not reversible by developers or support teams. Transactions, once accepted, are not undone by a help desk.

Self-custody also does not remove market, legal or operational risk. It does not make assets anonymous by default. It does not make a mistaken address recoverable.

Recovery risks

The usual failure is not cryptography breaking. It is a lost backup, a house fire, a discarded device, or a phrase typed into a fake site.

A seed phrase that solely controls a single-signature account is a complete copy of that custody. Anyone who photographs it has what they need. Social-engineering scripts that impersonate support exist because the phrase is sufficient.

More structured setups change the failure modes rather than eliminating them. A passphrase wallet is unrecoverable if the passphrase is forgotten, even if the 24 words survive. A 2-of-3 multisig is safer against one stolen key and more fragile if two backups are stored in the same place. A social-recovery wallet is only as sound as the guardian set and the delay rules.

Software wallets

Software wallets are applications on a phone, desktop or browser that store or derive keys and construct transactions. They are a common way to hold keys directly. bitcoin.org notes that desktop environments can offer full control, and also that they are exposed to malware. Mobile wallets are convenient and can be lost with the phone.

A software wallet can be self-custodial if the user holds the seed and the vendor cannot move funds. The same interface pattern can be custodial if the app is only a view onto an exchange balance. Read what happens if the company disappears: can you restore the phrase in a different app?

Browser extensions and web wallets add phishing risk. ethereum.org recommends bookmarking a web wallet and treating seed entry on a surprise page as hostile.

Hardware wallets

A hardware wallet is a dedicated device that holds key material and produces signatures, typically after the user confirms the destination and amount on the device screen. bitcoin.org describes hardware wallets as among the more isolated ways to store funds, and notes that loss of the device without a backup can make funds unrecoverable.

The device is an isolation tool. It does not, by itself, create self-custody. Points that follow from how these products actually work:

• The seed phrase written at setup is still the recovery secret. Someone who has the phrase does not need the device.
• Firmware, supply chain and the companion desktop app are part of the trust surface.
• A hardware wallet used to approve withdrawals from an exchange account is not the same as holding the exchange’s keys.

Self-custody can be done entirely in software. A hardware wallet can also be one key among several in a multisig. Owning the gadget is neither necessary nor sufficient.

Multisignature arrangements

Multisig means a spend needs more than one key. Bitcoin can require several signatures in Script. Ethereum users often implement the same idea with a smart-contract account rather than a native script type. bitcoin.org lists multisig as a wallet feature that divides responsibility among parties.

Typical uses include a personal 2-of-3 across devices and locations, or an organizational m-of-n so that no single employee can move the treasury. Safe describes this family of designs as smart accounts: contract-based custody with more flexible rules than a single externally owned account.

Multisig is still self-custodial when the users hold the keys and no vendor can unilaterally satisfy the threshold. It becomes shared or partly custodial when a vendor holds a required cosigner and can block or enable spends.

Social recovery and smart-account recovery

Social recovery is a contract pattern, not a Bitcoin consensus rule. Vitalik Buterin’s 2021 essay describes a wallet with one everyday signing key and a set of guardians. A majority of guardians can change the signing key after a delay. Normal payments still look like a single confirmation. Guardians can be other devices, people or institutions.

This is a designed trade. It reduces the “one lost phrase ends everything” failure of a lone key. It introduces guardian collusion, guardian unavailability and the need to keep the guardian set current. It is not the same as giving a company full custody, and it is not the same as a BIP-39 phrase stored in a bank envelope.

Smart-account recovery more generally includes spending limits, time delays, swapping a compromised key, and requiring extra approval above a threshold. ethereum.org's account-abstraction overview lists recovery after lost or exposed keys as a reason these designs exist. Implementations differ. Argent and Loopring are early examples Buterin discusses, while Safe documents owner-threshold controls for organizational smart accounts. None of these is “how Ethereum accounts work” by default. Ordinary EOAs still have no built-in recovery.

Programmable accounts and delegated permissions

Account abstraction and related Ethereum designs are one family of examples, not a universal model. EIP-4337 user operations and EIP-7702, included in Ethereum's 2025 Pectra upgrade, make it easier for contract logic—or an ordinary key-controlled account whose authorization points at deployed code—to authorize transactions. Ethereum's Pectra documentation notes that wallets can then offer features such as spending controls, batching and recovery, while the account's private key retains the ability to revoke or replace an EIP-7702 delegation.

Delegation already exists in other forms. ERC-20 approve grants a spender an allowance to move tokens without giving it the account's transaction-signing key. Solana token accounts can record a delegate and a delegated amount. Session keys in some smart wallets can allow a game or app to transact inside limits without exposing the master key.

Each of these moves a slice of authorization, though not always transaction-signing authority. That can be safer than handing an app the master secret. It can also create standing permissions that outlive the user's intention. Scope, recovery and revocation become part of the custody analysis, not extras.

Self-custody is not the same as a hardware wallet

The defining question is who can authorize a spend, not which object sits on the desk.

• A software wallet whose user holds the seed is self-custodial.
• A hardware wallet that also uses a vendor backup is not automatically custodial or self-custodial. What matters is whether another party can reconstruct the signing secret, authorize transactions without the user, or recover only under a threshold or encrypted scheme the user still controls.
• Keys on an exchange, even if the app shows a “wallet” tab, are usually custodial.
• A 2-of-3 multisig across two laptops and a paper backup can be self-custodial without any specialized signer.
• A smart account with institutional guardians sits somewhere in between, depending on whether those guardians can move funds or only rotate keys after a delay.

Hardware isolation is one security control. Custody is a question of authority.

Custody as a spectrum

Sophisticated account systems blur a binary label.

A user might:

• keep a spending balance on an exchange;
• hold savings in a single-signature hardware wallet;
• put a treasury in a 3-of-5 Safe;
• allow a session key to trade inside a daily limit;
• name guardians who can recover, but not spend, after 72 hours;
• stake through a service that holds validator signing keys while the user keeps withdrawal credentials.

Each line is a different bundle of control, liveness and failure modes. Calling the whole stack “self-custody” or “not self-custody” hides those differences. It is more accurate to ask which actions each party can take, how recovery works, and what happens if any one party disappears.

Remain precise about keys, phrases, accounts and wallets. A phrase can recreate keys. A wallet can hold keys without being the account. A contract can own assets without a single private key. Those distinctions are what make custody describable.