Timechain Wiki

Common failure modes in self-custody

21 min read

The modal ways Bitcoin holders actually lose Bitcoin to themselves — the silent, undramatic failure modes that account for the bulk of permanently-lost coins. Drawn from Lopp's Physical Bitcoin Attack database, the LegacyCipher synthesis, and the broader practitioner literature: the passphrase no one knew about (the most-cited inheritance failure); the forgotten passphrase (memorized at setup, never written down); the untested metal backup (stamped but never verified by restoration); co-located multisig (three keys in three drawers in one home — functionally one location); the lost wallet descriptor (intact seeds but no descriptor turns recovery into expensive forensics); the seed photo (taken "temporarily," synced to cloud, forgotten); the phishing signature (urgent email leads to a signed malicious transaction); the KYC-data-to-home-invasion pipeline (exchange breach feeds targeting); the novel scheme (personal obfuscation the holder cannot reliably reconstruct under stress). The closing principle: most permanently-lost Bitcoin was not stolen — it was forgotten, misplaced, or improperly documented.

Why this note matters

Loss-side failures are structurally invisible. There is no incident report, no news story, no public catalogue of “Bitcoin lost to forgotten passphrases this year.” The losses accumulate silently across the holder population. The note matters because:

  • It makes the silent failure modes visible in a way that catalogued exposure attacks are visible. Newcomers worry about hackers; the synthesis is direct that user error dominates.
  • It establishes the specific patterns that recur across practitioners — the inheritance passphrase, the untested backup, the novel scheme. These are not abstract concerns; they are documented patterns.
  • It provides the diagnostic framework for evaluating a setup. “Does my setup have a non-trivial chance of failing in one of these specific ways? If so, fix that first.”

The defensible position: every meaningful self-custody setup should be evaluated against this catalogue. Failure modes the setup is exposed to should be addressed before exposure-side defences are added. The order matters: defend against loss (which dominates) before defending against exposure (which is more newsworthy but less frequent).

The failure mode catalogue

Each pattern is presented with: what it is, how it unfolds, why it happens, the estimated share of total loss it accounts for, and the mitigation. The estimated share is qualitative per the synthesis; precise data does not exist (the failures are silent).

The passphrase no one knew about

What it is: The holder dies, becomes incapacitated, or experiences cognitive decline. The seed phrase is found in the holder’s papers. The heir loads it into a wallet and sees an empty (or decoy-balance) wallet. The real wallet — protected by a BIP-39 passphrase — is never discovered.

How it unfolds:

The holder set up the wallet with a passphrase years earlier. They backed up the seed phrase to metal. They memorized the passphrase. They did not write the passphrase down (or wrote it down in a place no one finds). Or they did write it down but the documentation doesn’t make clear that a passphrase exists.

The heir, holding the seed phrase, loads it into a wallet. The wallet shows no funds (the decoy) or a small balance. The heir concludes that the holder must have moved or spent the Bitcoin elsewhere. The real wallet remains accessible only to someone who knows about and can supply the passphrase — which is no one.

Why it happens:

  • The passphrase-only-in-head pattern is the most-common implementation of “passphrase protection”
  • Holders often feel the passphrase backup defeats the purpose of having a passphrase
  • Inheritance documentation that should reveal the passphrase’s existence is missing or unclear
  • The seed phrase being backed up creates the false impression that the wallet is recoverable

Estimated share: High. The synthesis treats this as the largest single inheritance-failure pattern. Lopp and others describe it as routine in the cases they’re consulted on.

Mitigation:

  • Back up the passphrase separately from the seed, in a different location
  • Clearly document the passphrase’s existence in the inheritance documentation
  • For substantial holdings, consider SLIP-39 split of the passphrase (see SLIP-39 and Shamir Secret Sharing) so that a threshold of trusted parties can reconstruct it post-mortem
  • Inheritance rehearsal — walk the heir through the recovery; the rehearsal catches the documentation gap

The forgotten passphrase

What it is: The holder chose a strong passphrase, memorized it, never wrote it down (“if someone finds it, the whole point is defeated”). Years later, the holder tries to access the wallet and can no longer reliably reconstruct the passphrase. The seed is intact; the wallet is irrecoverable.

How it unfolds:

The holder selected the passphrase under specific cognitive conditions — perhaps a complex phrase with personal significance, or a randomly-generated string they tried to memorize. The memorization was strong at the time. Over years, memory drifts. The holder tries variations; none match the fingerprint the hardware wallet displays. After many attempts, the holder concludes the passphrase is irretrievable.

Why it happens:

  • Memorization fails over decades; the holder cannot reliably reproduce the passphrase under stress
  • The holder may experience cognitive decline that compounds the failure
  • Stress at the moment of recovery (something happened that required the wallet) further degrades recall
  • Without a written backup, there is no way to verify the holder is remembering correctly until they try

Estimated share: Medium-high. Less common than the inheritance pattern (the holder is still alive to discover the problem) but still significant.

Mitigation:

  • Every passphrase needs a backup; “I’ll just remember it” is not a backup
  • For the privacy-conscious, the passphrase backup can be split (SLIP-39) or held by a trusted party
  • Verification at intermediate intervals — when initially setting up, also periodically rehearse the passphrase entry (without committing to a transaction) to maintain the recall

The untested metal backup

What it is: The seed was stamped onto a metal plate at setup. The plate was stored securely. The metal was never used to restore a wallet. When the time comes to use it, the restoration fails — a word is wrong, or the stamping order doesn’t match the order written down, or a character is illegible.

How it unfolds:

At setup, the holder generates the seed on a hardware wallet. They write it on paper, then transfer to metal. They feel the metal backup is now the authoritative record and may destroy the paper. They store the metal in a safe location. They do not perform the wipe-and-restore test.

Months or years later, recovery is needed. The holder reads the metal, enters the words into a wallet, and the wallet displays a different wallet than expected (because a word was wrong) or refuses to load (because the checksum doesn’t validate).

Why it happens:

  • Stamping is error-prone; a misalignment or a character-position swap can produce wrong words
  • The BIP-39 checksum catches some errors but not all (a different combination of words can produce a valid checksum)
  • Without rehearsal, the holder doesn’t discover the problem until they need to use the backup

Estimated share: Medium. The wipe-and-restore discipline catches this when applied; the failure pattern is common where the discipline isn’t applied.

Mitigation:

  • Always verify a metal backup by restoring from it before funding the wallet (see Recovery rehearsal practice)
  • Periodic full rehearsals catch drift between setup verification and use
  • Practice stamping on a sacrificial seed before stamping the real one

Co-located multisig

What it is: A 2-of-3 multisig where all three hardware wallets and all three seed backups are in the same home, building, or geographic area. A single catastrophic event — fire, flood, burglary — compromises everything at once.

How it unfolds:

The holder adopts multisig for the structural protection. They obtain three hardware wallets. They store them in three drawers, three rooms, or three secure containers — all within the same residence. The geographic distribution is implicit and shallow rather than explicit and substantial.

When the catastrophic event occurs, all three keys are affected simultaneously. The multisig’s structural protection collapses to the same single-point-of-failure profile as single-sig — but with more complexity.

Why it happens:

  • The holder doesn’t have access to multiple geographic locations
  • The holder underestimates how thoroughly a single event can compromise a single location
  • The holder treats “three different rooms” as geographic distribution
  • The holder values convenience over the explicit geographic requirement

Estimated share: Medium for holders who attempt multisig without external locations.

Mitigation:

  • Geographic distribution is non-negotiable for multisig. See Multisig setups.
  • Minimum two physically distinct locations; ideally three for 2-of-3 setups
  • Use bank safe deposit boxes, trusted family members in different cities, attorney’s offices, second properties
  • For holders without access to multiple geographic locations, collaborative custody (see Collaborative custody services) is structurally better than DIY multisig

The lost wallet descriptor

What it is: A multisig setup where the three seed phrases are backed up properly but the wallet descriptor (the configuration file specifying which keys form the wallet and on what derivation path) was never backed up. Recovery requires reconstructing the descriptor through trial-and-error, which is expensive and unreliable.

How it unfolds:

The holder sets up a 2-of-3 multisig. The coordinator software (Sparrow, Specter, etc.) generates the descriptor. The holder backs up the three seeds carefully — to metal, in geographic distribution. They do not separately back up the descriptor; the coordinator-saved state is the only record.

Later, the coordinator’s state is lost (computer crash, lost device, software incompatibility, holder’s death). The holder or heir has the three seeds but cannot reconstruct which multisig configuration they were part of. The recovery becomes an expensive forensic exercise — trying combinations of script types, derivation paths, key orderings — that may or may not succeed.

Why it happens:

  • The descriptor is invisible during normal operation; the holder doesn’t realize it exists separately from the seeds
  • The coordinator-saved state feels like the wallet; the holder doesn’t distinguish coordinator-state from wallet-state
  • Inheritance documentation often focuses on the seeds and omits the descriptor

Estimated share: Medium for DIY multisig holders.

Mitigation:

  • For any multisig setup, back up the wallet descriptor as a first-class artifact (see PSBT and wallet descriptors)
  • Store a copy of the descriptor alongside each seed backup
  • Use canonical formats (BIP-380 output descriptors) for portability
  • Verify by importing the descriptor into an alternative coordinator
  • Include descriptor documentation in the inheritance plan

The seed photo

What it is: The holder took a photo of the seed phrase “just for a minute” — to send to a different device, to use during travel, to have a backup. The photo synced automatically to iCloud, Google Photos, or another cloud service. Eventually, the cloud account is compromised and the seed is exposed.

How it unfolds:

The holder generates the seed at setup. While transcribing to durable media, they take a quick phone photo as an intermediate. The phone has cloud-backup enabled (the default for most users). The photo syncs to the cloud immediately.

The holder intends to delete the photo. They forget. Months or years later, the cloud account is compromised — either through targeted attack (credential stuffing of a password reused elsewhere) or through a cloud-provider breach. The seed is exfiltrated. The funds are moved.

Why it happens:

  • The “temporary” framing makes the photo feel low-risk
  • Cloud backup is enabled by default on most phones
  • The compromise often happens years after the original exposure
  • The holder doesn’t realize the photo still exists

Estimated share: Medium-high. The pattern is structurally common and the temptation is real.

Mitigation:

  • Never photograph a seed phrase. Ever. For any reason.
  • If a photo is somehow taken, immediately delete it AND verify cloud-side deletion (a deleted photo may still be in a recycle bin or sync history)
  • Disable cloud backup of camera roll if cloud sync is a concern
  • The discipline must be absolute; “just this once” is the structural pattern that produces the loss

The phishing signature

What it is: The holder receives an urgent-looking email, text, or call. They click through to a spoofed site, enter their seed phrase, or sign a malicious transaction. The funds are immediately moved by the attacker.

How it unfolds:

The attacker has obtained the holder’s email or phone number (from a leaked database). They send a message impersonating a trusted entity — exchange, wallet vendor, “customer support.” The message contains urgency: “Security verification required,” “Suspicious activity detected,” “Your account will be locked.”

The holder, under emotional or time pressure, clicks the link. The spoofed site asks for “verification” — entering the seed, signing a transaction. The holder complies. The attacker moves the funds.

Why it happens:

  • Phishing exploits urgency and emotional response
  • The spoofed site is often nearly indistinguishable from the legitimate one
  • The holder’s cognitive vigilance is unreliable under stress
  • Hardware wallets can be tricked into signing a malicious transaction if the holder doesn’t verify the destination on the device screen

Estimated share: High. Phishing dominates incident counts across all sources.

Mitigation:

  • Never enter the seed phrase into any software interface
  • Verify URLs by typing them, not by clicking links
  • Verify destination addresses on the hardware wallet’s screen, always
  • Use a password manager that refuses to autofill on spoofed domains
  • Verify unusual requests through a separate channel

The KYC-data-to-home-invasion pipeline

What it is: An exchange or hardware-wallet vendor’s customer-data leak exposes the holder’s name, home address, and approximate holdings. Criminals use the data to identify and target the holder for burglary, robbery, or extortion.

How it unfolds:

The exchange or vendor has a data breach. The leaked database becomes available on criminal forums. Attackers cross-reference the database with other public data (Twitter posts, public records) to identify high-value targets. They plan a physical attack — burglary in the holder’s absence, robbery at the home, or the “$5 wrench” coercion.

The Ledger 2020 leak (270,000+ customer records with home addresses) is the canonical example. The data is still actively used in 2026 targeting per Lopp’s database.

Why it happens:

  • KYC requirements and consumer-product purchases create customer databases
  • Databases get breached; the data is permanent once leaked
  • The targeting pipeline is well-established and operational

Estimated share: Growing. Lopp’s database shows the 2024-2025 surge tied closely to data-leak-driven targeting.

Mitigation:

  • Compartmentalize KYC identity from holdings — separate emails, distinct profiles
  • Avoid tying home address to hardware-wallet purchases where possible (PO box, business address, shipping to different residence)
  • Don’t be identifiable as a Bitcoin holder (Lopp’s discipline)
  • For affected holders, treat the leaked address as permanently compromised in the threat model

The novel scheme

What it is: The holder, in pursuit of maximum security, invents a personal obfuscation scheme — encoding the seed in an unusual way, splitting it across custom-defined locations, using a custom passphrase derivation. The scheme works at setup. Later, the holder cannot reliably reconstruct it.

How it unfolds:

The holder reads about Bitcoin security and decides to go beyond standard practices. Common schemes:

  • “I write every fourth word backward and XOR it with my birthday”
  • “The seed is split across three unrelated documents in my house — the photo album page numbers, the recipe book ingredients, and the marginalia in book X”
  • “The passphrase is the answer to my favorite riddle, rotated by 3 ASCII positions”

The scheme works at setup; the holder can demonstrate the recovery. Years later, the holder cannot reliably reproduce the scheme. The scheme’s failure modes — which the holder didn’t analyze — emerge under stress.

Why it happens:

  • The holder underestimates how memory degrades over decades
  • Novel schemes feel more secure because they’re personalized
  • The schemes are often optimized against threats the holder doesn’t actually face while creating threats they didn’t anticipate

Estimated share: Medium. Less common than the basic patterns but still meaningful, particularly among technically-inclined holders who over-engineer.

Mitigation:

  • Use standards others have reviewed (BIP-39, BIP-85, SLIP-39, standard multisig)
  • Do not invent cryptographic schemes
  • If novel-scheme tendency is strong, restrict the novelty to layers that fail gracefully (additional documentation, supplementary verification) rather than load-bearing components

Inadequate inheritance documentation

What it is: The holder has a complete and verified setup. The heir finds documents that reference Bitcoin but cannot interpret them — what the metal backup is, how to use it, where to find related artifacts (passphrase, descriptor). The wallet is structurally accessible but practically inaccessible.

How it unfolds:

The holder dies. The heir, often grieving and overwhelmed, encounters the Bitcoin-related materials. Without clear documentation, the heir’s responses are uneven:

  • They may discard the metal backup as “an old document”
  • They may keep the materials but never engage them, deferring to a future moment that doesn’t come
  • They may attempt recovery but stop when the procedure becomes technical
  • They may engage a professional, who may or may not have the expertise

Why it happens:

  • Holders don’t engage inheritance planning during their lifetime
  • Documentation focuses on the technical setup without the human-readable layer
  • Heirs are often not technically engaged with Bitcoin
  • The holder’s death is an emotional event that compounds the operational complexity

Estimated share: High over long horizons. The dominant inheritance-failure mode for substantial holdings.

Mitigation:

  • See Inheritance planning for bitcoin for the full framework
  • Documentation in physical form, in language a non-technical person can follow
  • Bitcoin inheritance is a special case of the broader estate-planning framework (findability as primary failure mode, beneficiary mechanisms, trust-design considerations); the general principles operate as background
  • Inheritance rehearsal — walk the heir through the procedure during the holder’s lifetime

Operating under stress

What it is: The holder makes a custody decision under cognitive impairment — stress, grief, fatigue, time pressure, coercion. The decision is wrong; the consequences are irreversible.

How it unfolds:

The holder needs to send funds quickly (deadline, opportunity, emergency). They rush the verification. They miss the destination address mismatch. They sign a transaction sending to the wrong place. Or under coercion, they execute a transaction they would have refused under normal cognitive conditions.

Why it happens:

  • Wallet operations are irreversible
  • Stress degrades verification quality
  • The cognitive-state rule is hard to enforce through willpower alone
  • Time pressure compounds with emotional pressure

Estimated share: Medium. Not the dominant failure mode but a recurring one for active spenders.

Mitigation:

  • Don’t operate the wallet under stress; defer until cognitive state improves
  • Build delay into the configuration (time-locked transactions, multi-party signing, remote confirmers)
  • For routine operations, develop habits that include verification (always check the destination on the hardware wallet screen)
  • For substantial transactions, use a 24-hour cooling-off period

Tradeoffs and considerations

Loss-side failures are silent

The catalogue above is built from cases practitioners are consulted on. The cases where no one is consulted — where the loss is private and never discussed — are not in the catalogue but exist. The dark figure of self-inflicted loss is large.

The implication: even the catalogue understates the prevalence. Defending against these patterns is structurally more important than the visible-incident framing suggests.

The patterns compound

Many of the failure modes interact. A holder with the passphrase-only-in-head pattern who also has inadequate inheritance documentation faces both failures simultaneously. A holder with a co-located multisig and a lost descriptor faces multiple structural problems at once.

The implication: setups should be evaluated against the whole catalogue, not against individual patterns. A setup defensible against any single failure mode may still be exposed via correlation.

The patterns are persistent

These failure modes have been documented for years; they continue to recur. The reason is structural: each pattern represents a specific behavioural or procedural failure that the standard practices defend against — but the standard practices require discipline to apply, and discipline degrades over time and under stress.

The procedural defences (write everything down, test the backup, document for heirs) are not novel discoveries. They are recurring lessons from the persistent failure modes.

The patterns scale with holding size

The cost of each failure scales with the holding. A Tier 1 holder who loses funds to a forgotten passphrase loses thousands. A Tier 3 holder who loses funds to the same pattern loses millions. The discipline should scale accordingly — Tier 3 holders should engage every pattern explicitly; Tier 1 holders should focus on the high-prevalence patterns.

Tiered defensive posture

Tier 0: Focus on phishing avoidance and never-photograph-seeds. Most patterns above don’t apply at the scale of a phone hot wallet.

Tier 1: Address: untested metal backup; passphrase backup (if using passphrase); inheritance documentation basics; phishing discipline.

Tier 2: All Tier-1 plus: descriptor backup; geographic distribution; inheritance rehearsal; KYC-compartmentalization; novel-scheme avoidance.

Tier 3: All Tier-2 plus: continuous operational practice; family-and-heir-readiness; jurisdictional considerations; potentially professional security consultation.

In all tiers, the diagnostic: does your setup have a non-trivial chance of failing in any of these specific ways? If so, fix that first — before adding additional layers of defence.

Common pitfalls

Treating loss-side failures as low-probability. The aggregate over decades is high. Most holders affected by these patterns did not believe in advance that the patterns would affect them.

Defending against exposure attacks while ignoring loss. Loss is the dominant failure mode; exposure is more newsworthy. The defensive priority should reflect the actual risk distribution.

Believing “I’d never make that mistake.” Most holders who lost funds to these patterns believed the same. The patterns are persistent specifically because they fail at the human-discipline layer.

Adopting multiple defences without addressing the patterns. Adding a passphrase to a wallet doesn’t help if the passphrase is then only in the holder’s head. Each defence must be implemented with the discipline that makes it effective.

Treating inheritance as a future problem. The inheritance failure modes apply throughout the holding horizon. Early planning is structurally easier than late planning.

Underestimating cognitive-state failures. “I won’t make a mistake under pressure” is unreliable. Build procedural defences that don’t depend on the holder being sharp.

The “I’ve done this for years without a problem” pattern. The patterns surface at low base rates over long horizons. A 10-year track record without incident doesn’t mean the next 20 years will be similar — particularly as the holder ages.

Tooling and resources

The synthesis document (canonical for the section):

  • Bitcoin Self-Custody & Security: A Synthesis of Contemporary Best Practices, LegacyCipher discussion, April 2026 — the failure-mode catalogue.

Primary practitioner sources:

  • Lopp — 21 tips for securing your bitcoin; ongoing essays; the Physical Bitcoin Attack database. See Jameson Lopp.
  • Casa — case studies; the seedless-security model documentation
  • Unchained — operational-security guides; inheritance documentation
  • The Bitcoin Adviser — inheritance-focused failure-mode analysis
  • Blockchain Commons — Smart Custody Book; the 27-adversary framework includes the self-inflicted failure modes

Empirical references:

  • Chainalysis published estimates on permanently-lost Bitcoin
  • Lopp’s Physical Bitcoin Attack database
  • Various exchange and vendor breach disclosures

As of 2026-05-14: the failure-mode catalogue is stable; new patterns occasionally emerge but the principal ones above are well-documented. The remaining variable is operational — whether holders engage the catalogue and adjust their setups accordingly.

Open questions for further development

  • The “silent loss” question — what is the actual prevalence of each failure mode? Empirical data is hard because the failures are silent; the estimates above are qualitative.
  • AI-assisted inheritance planning could reduce documentation-failure modes. Are there emerging tools that materially help?
  • The cognitive-decline question is increasingly relevant as the Bitcoin holder population ages. What failure modes emerge specifically in late-life custody?
  • The institutional-capture trajectory (more Bitcoin held by ETFs and corporate treasuries) shifts the failure-mode profile. Are there new patterns emerging at the institutional scale that the framework should engage?

The framing context:

Adjacent operational notes:

Backup, recovery, rehearsal:

Storage and key concepts:

Hardware wallets:

Custody configurations:

Inheritance:

The principal practitioner:

  • Jameson Lopp — the empirical foundation for the catalogue

The sub-MOC home:

Graph View

Backlinks