According to Tangem’s glossary, self-custody requires exactly two things: a wallet that generates and stores private keys on your own device rather than on a company’s server, and a backup of that key — usually a seed phrase — that is secure, redundant, and tested before you ever need it. Everything else discussed under the banner of self-custody, from hardware wallet brands to multisig setups, is built on top of those two requirements, not a substitute for them.
A private key is the cryptographic secret that authorizes movement of funds at a specific blockchain address, according to Chainscore Labs’ glossary. Whoever holds that key can move the funds; whoever does not, cannot. On a custodial exchange, the exchange generates and holds the key, and the user’s balance is an entry on the exchange’s internal ledger rather than direct on-chain ownership, per Pocket Network’s documentation. Self-custody removes that intermediary: the wallet software generates the key locally, signs transactions on the user’s device, and broadcasts them straight to the network, Chainscore Labs’ glossary explains. The crypto industry’s own shorthand for this, cited by Tangem, is “not your keys, not your coins.”
This is, on the evidence gathered here, a mechanical shift in who holds the secret rather than a security upgrade in itself — an inference the sources below support but do not state in these words. Tangem’s glossary frames the tradeoff directly: self-custody removes counterparty risk from an exchange, but the user takes on full responsibility for protecting the key with no support line and no recovery process if it is lost.
Most non-custodial wallets do not ask a user to memorize a raw private key. Instead they generate a seed phrase — a sequence of 12 or 24 common English words, following the BIP-39 standard — from which the wallet’s private keys are mathematically derived, according to Pocket Network’s documentation and Chainscore Labs’ glossary. A technical summary of BIP-39 published by Bitclawd describes the process: the words are run through 2,048 rounds of a hashing function (PBKDF2 using HMAC-SHA512) to produce a 512-bit master seed, and a 24-word phrase draws from a keyspace of 2^256 possible combinations. That summary is a third-party restatement of the specification rather than the primary Bitcoin Improvement Proposal document itself, so treat the exact parameters as reported by Bitclawd, not verified against the original text here.
The practical point both Bitclawd’s summary and Pocket Network’s documentation make is that the mathematics is not the weak point. A single seed phrase can generate thousands of addresses across multiple blockchains, Pocket Network’s documentation notes, which means losing that one phrase — or having someone else obtain it — puts everything derived from it at risk simultaneously. Pocket Network’s own comparison of a seed phrase against a standalone private key, paraphrased below, illustrates the difference in blast radius:
| Seed phrase | Private key | |
|---|---|---|
| What it controls | Every address generated from it | One specific address |
| Format | 12 to 24 words, written out | A long string of letters and digits (hex or base58) |
| If it is exposed | Every wallet derived from it is compromised | Only that one wallet is compromised |
| If it is lost | Every derived wallet becomes inaccessible | Only that one wallet becomes inaccessible |
(Table content is paraphrased from Pocket Network’s self-custody documentation, not quoted directly.)
Two independent technical guides — Pocket Network’s documentation and the Security Alliance’s wallet-security framework — converge on the same baseline practices, despite being written for different audiences. Both say a seed phrase should never touch an internet-connected system: no cloud storage, no screenshots, no notes app, no email, no messaging app. Security Alliance’s framework goes further and lists password managers among prohibited storage locations for the phrase itself, even though it separately recommends storing any encryption passphrase used to protect the seed in a password manager — a distinction worth reading carefully rather than skimming.
Pocket Network’s documentation recommends a “3-2-1” structure for the physical backup: three copies, across two different physical media (paper and metal, for instance), with at least one copy stored away from the primary home. Security Alliance’s framework recommends the same underlying idea — geographically separate storage, ideally in a personal safe, a trusted family member’s home, or a bank deposit box — and adds that a stainless steel or titanium plate protects the words against fire and water damage that would destroy paper. Both sources single out one behavior as the most common cause of loss: writing the phrase down but never actually testing a restore. Pocket Network’s documentation recommends deliberately deleting the wallet, restoring it from the written backup on a separate device, and confirming the addresses match, before relying on the backup for real funds.
For larger holdings, the Security Alliance’s framework describes splitting the seed phrase into overlapping pieces — for example, words 1 through 16 in one location, words 9 through 24 in a second, and words 1 through 8 combined with 17 through 24 in a third — so that any two of the three pieces reconstruct the full phrase, but no single piece on its own does. The same framework also describes Shamir’s Secret Sharing, an algorithm for splitting a key into a chosen number of shards distributed among trusted parties. Encryption of a seed phrase is explicitly discouraged for most users by the Security Alliance, which warns that a forgotten encryption method or passphrase leaves funds “permanently inaccessible” with no recovery option — a risk the framework argues often exceeds the risk of an attacker finding a well-hidden, unencrypted backup in the first place.
Multi-signature wallets are the other major variant. Cobo’s explainer describes a 2-of-3 multisig arrangement, where any two of three designated keys must sign to move funds, removing the single point of failure that a lone seed phrase represents. Pocket Network’s documentation notes that this option currently exists for wPOKT on Ethereum and Base through Gnosis Safe, but that native multisig support on POKT itself depends on separate Cosmos SDK tooling. Security Alliance’s framework treats multisig as reducing — not eliminating — the seed-phrase problem: individual signers in a multisig group still need reliable personal backups, since losing access to too many signing keys at once defeats the arrangement.
Self-custody is often described as removing risk from crypto ownership. What the independent technical sources here actually describe is a relocation of risk, not its removal. Tangem’s glossary states this plainly: self-custody trades away counterparty risk — the danger that an exchange freezes, is hacked, or becomes insolvent — for personal operational risk, since “no third-party risk” comes with “no third-party safety net either.” Chainscore Labs’ glossary makes the same point from the technical side: self-custody shifts the entire security burden from an institution’s security team to the individual user’s own discipline and technical competence.
The SEC’s Investor.gov bulletin states, for retail investors, that with self-custody “you have sole responsibility for keeping track of the private keys and seed phrases for your crypto assets,” and that losing or having them stolen may mean losing access to the assets entirely. That bulletin is a general investor-education document, not a rule.
Separately, the SEC’s Division of Trading and Markets issued a statement on Dec. 17, 2025 setting out its staff views on how broker-dealers can treat custody of tokenized crypto securities under Rule 15c3-3. That statement instructs broker-dealers to have written plans in advance for disruption events including “blockchain malfunctions, 51% attacks, hard forks, or airdrops.” This statement governs regulated broker-dealers holding tokenized securities for customers — it does not set, and should not be read as setting, any standard for what an individual must do to self-custody personal crypto holdings.
This page cannot cite the original BIP-39 specification directly. The cryptographic detail on iteration counts and keyspace size comes from a third-party technical summary published by Bitclawd, not from the primary Bitcoin Improvement Proposal document itself, and neither source carries a publication date.
Two of the sources drawn on here — Tangem and Cobo — sell custody-related products. Tangem sells hardware wallets and frames self-custody’s usability problems in terms its own seedless card design addresses; Cobo sells institutional custody infrastructure and frames self-custody as one option on a spectrum leading toward its own MPC and qualified-custody products. Their comparisons and framing are commercial positioning, not independent findings, and are presented here as attributed claims rather than facts.
No source examined for this page provides a measured rate of how often self-custody wallets are actually lost, stolen, or permanently locked, whether in absolute terms or relative to exchange failures. The technical guides agree on which failure modes matter most — digital storage of a seed phrase, a single unbacked copy, an untested restore, phishing sites requesting the phrase directly — but none of them quantifies how frequently each one occurs. Readers should treat this page as a description of agreed failure modes, not a risk statistic.
Finally, the SEC’s December 2025 statement on broker-dealer custody is included here only to show what it does not cover. Nothing in that statement, or in the Investor.gov bulletin, constitutes legal or financial advice about how to structure an individual’s own self-custody setup.
Every fact above is attributed to one of these reports. Where they disagree, the article says so.
We measure how many people read this site. That is all it is used for — there is no ad network, no advertising cookie, and nothing sold to anyone. Decline and the site works exactly the same. What we collect