Part of the CustodyStress archive of observed Bitcoin custody incidents

Bitcoin Custody Documentation Rates by Custody Type

Which custody system types most often fail without any written documentation of the arrangement? This comparison shows documentation completeness rates across custody types in documented failure cases — the share of cases with no documentation, partial documentation, ambiguous documentation, and full documentation.

Documentation absence is not uniformly distributed. Different custody types attract different user behaviour around documentation — and the structural properties of each custody type create different documentation requirements. A single-key hardware wallet requires documentation of the seed phrase location; a collaborative custody arrangement adds the service relationship and co-signer contacts; an exchange account adds account credentials and recovery email. The more components a system has, the more documentation failure modes exist.

Percentages are calculated from cases with known documentation status. Cases where documentation status is unknown are shown in total count but excluded from percentage calculations. Bar shows: no documentation (dark red) / partial (amber) / ambiguous (light amber) / full (green).

Documentation completeness by custody type

No documentation Partial Ambiguous Full documentation

Hardware wallet (single key)

70 cases · 70 with known status

0% no documentation 63% partial 36% full documentation

64% have absent, partial, or ambiguous documentation

Hardware wallet with passphrase

18 cases · 18 with known status

0% no documentation 78% partial 22% full documentation

78% have absent, partial, or ambiguous documentation

Software wallet

455 cases · 455 with known status

0% no documentation 71% partial 23% full documentation

77% have absent, partial, or ambiguous documentation

Exchange custody

265 cases · 265 with known status

0% no documentation 49% partial 49% full documentation

51% have absent, partial, or ambiguous documentation

Institutional custody

5 cases · 5 with known status

0% no documentation 60% partial 40% full documentation

60% have absent, partial, or ambiguous documentation

What the documentation patterns reveal

Hardware wallet (single key) has the highest no-documentation rate in the archive at 0% of cases with known status — 70 total cases. This reflects both the structural properties of this custody type and the user behaviour it tends to attract.

Self-custody types — hardware wallets and software wallets — tend toward higher no-documentation rates than exchange custody. This reflects a structural difference: exchange custody, whatever its other failure modes, at minimum requires account credentials that create a starting point for heirs. Self-custody puts full documentation responsibility on the holder. No institution creates a record. No statement arrives in the mail. The arrangement exists only in physical materials and the holder's memory — both of which can disappear without a trace.

The CustodyStress assessment directly models this documentation requirement. For each custody arrangement, the assessment captures whether a seed phrase backup exists, whether it is stored independently of the device, whether a passphrase is documented separately, and whether recovery instructions exist that a non-technical person could follow. The documentation dimension of the assessment corresponds directly to the patterns visible in this archive data.

Multisig custody has a distinct documentation failure mode that does not appear in single-key custody: the quorum setup itself may be undocumented. A surviving heir or executor may locate individual hardware wallet devices — and even have seed phrase backups for them — but not know the threshold, the other participants, or the software required to construct and broadcast a transaction. Documentation for multisig arrangements must cover both the key material and the coordination architecture.

Institutional custody has the lowest no-documentation rate at 0%. This reflects the documentation structure inherent to this custody type — account credentials, platform records, and institutional relationships provide a starting point that pure self-custody does not.

Documentation and outcomes

Documentation absence does not produce blocked outcomes uniformly — the outcome depends on the custody type and stress condition. A hardware wallet case with no documentation and a surviving owner who simply forgot where they stored the seed phrase is recoverable. The same hardware wallet case with no documentation and a deceased owner who never told anyone what they held is not. Documentation absence is a precondition for failure, not the failure itself.

The relationship between documentation and outcome is quantified in the archive's outcome by documentation comparison. This page shows where documentation tends to be absent; that page shows what happens when it is.

Outcome by documentation Outcome by custody type No documentation cases Archive statistics

Figures describe observed documentation status within documented cases in this archive. Documentation status reflects what was known at time of case entry — not all cases have documentation status recorded. Bitcoin Custody Incident Archive — CustodyStress · custodystress.com/cases · 895 documented incidents

This archive documents cases where a legitimate owner, heir, or authorized party encountered barriers accessing or recovering Bitcoin due to a failure in the custody arrangement. The central question for inclusion is: did the custody structure fail a legitimate access or recovery attempt?

A case must satisfy all three of the following to be included:

Legitimate access attempt. The person attempting to access or recover the Bitcoin was the owner, a designated heir, an executor, a legal authority, or another party with a legitimate claim — not a thief, attacker, or unauthorized third party.
Custody structure failure. The failure was caused by a property of the custody arrangement — missing credentials, structural dependencies, documentation gaps, knowledge concentration, legal barriers, or institutional constraints — not market conditions, individual-level fraud or theft, or protocol-level issues. Platform-level failures that block legitimate user access are in scope regardless of their cause.
Documentable outcome or access constraint. The case must have a stated or inferable outcome: access blocked, access constrained, access delayed, or access eventually achieved through a recovery path. Cases with entirely unknown outcomes are included only where the structural failure is documented and the constraint is unambiguous.

Owner death or incapacity — Bitcoin held in self-custody that becomes inaccessible to heirs or designated parties because credentials, documentation, or operational knowledge were not transferred
Passphrase loss — BIP39 passphrase forgotten or unavailable, blocking access to a funded wallet even where the seed phrase is present
Seed phrase or wallet backup unavailable — no independent recovery path existed or the backup was destroyed, lost, or never created
Device loss without independent backup — hardware wallet, phone, or computer lost or destroyed with no recovery path outside the device
Documentation absent or ambiguous — heirs or executors cannot determine that Bitcoin exists, which wallet holds it, or how to access it
Knowledge concentration — only one person knew the procedure, passphrase, or access method; that person is dead, incapacitated, or unreachable
Multisig quorum failure — a threshold signature arrangement cannot be completed because signers are unavailable, uncooperative, incapacitated, or have lost their keys
Legal authority / access mismatch — a court order, probate ruling, or power of attorney establishes legal entitlement but provides no technical path to access
Institutional custody barrier — exchange or platform hacks, insolvency, regulatory seizure, or operational failure that caused a access constraint or failure for legitimate users, whether temporary, prolonged, or permanent. The failure of the custodian to remain available or solvent is itself the in-scope event.
Forced relocation or geographic constraint — physical access to a device or location required for recovery is blocked by displacement, border restrictions, or political circumstances
Coercion — the holder was compelled under threat to transfer Bitcoin or disclose credentials during an access event
Hidden asset discovery — heirs or executors locate a wallet or account but cannot access it due to missing credentials or operational knowledge

Market losses, investment losses, yield scheme losses, or Ponzi scheme losses
Hacks or theft targeting an individual's personal security (phishing, SIM swap, social engineering, malware) where the custody architecture itself did not fail
Unauthorized transfers where the holder's custody system was not the cause of the failure
Ordinary transaction mistakes — wrong-address sends, fee errors, mistaken amounts
Protocol-level failures — cryptographic vulnerabilities, consensus bugs, firmware integrity failures
Deliberate burns or tribute burns
Cases where the stated loss is unverifiable and no structural custody failure is described

Cases are drawn from public sources including forum posts, news reporting, court documents, academic research, and direct submissions. Each case is reviewed against the inclusion criteria above before publication. Source material is retained and available on request for documented cases.

The archive is observational and descriptive. It does not attempt to document all Bitcoin custody failures — only those meeting the criteria above with sufficient documentation to describe the structural failure and its outcome.