The challenge with "large amounts" is that the threshold is personal, but the architecture doesn't have to be. Once you hold enough that losing it would be materially harmful — not just frustrating — the security model needs to shift from hygiene to architecture.
Most security advice for crypto is calibrated to a wallet holding a few hundred dollars. Use a hardware wallet. Don't share your seed phrase. Back up your keys. These are fine baseline rules, but they're not sufficient when the amount at stake is significant. The threat model changes, and the setup needs to change with it.
The Threat Model First
Before any specific approach makes sense, it helps to be clear about what you're actually defending against.
The threats aren't abstract. For large crypto holdings, the realistic attack surface includes:
- Remote software attacks: Malware that captures keystrokes, screen data, or clipboard contents on an internet-connected device
- Physical theft: Someone gaining physical access to your hardware or your seed phrase backup
- Social engineering: Phishing, SIM swapping, fake support staff, or coercion
- Single-point-of-failure loss: Device failure, fire, flood, or your own death without documented recovery instructions
- Counterparty failure: Exchange insolvency, custodian shutdown, or platform errors
A good storage setup addresses as many of these simultaneously as possible. The reason most advice falls short is that it addresses one threat (remote software, via a hardware wallet) while leaving others intact.
Hardware Wallets: The Baseline, Not the Solution
A hardware wallet stores your private key inside a secure element chip that never exposes the key to any internet-connected device. Transactions are signed on the device, then broadcast. This is a genuine and significant security improvement for remote attack vectors.
But the hardware wallet doesn't protect against physical theft of the device (though the PIN provides some protection), physical theft or discovery of the seed phrase backup, single-point-of-failure loss, or the inheritance problem.
The seed phrase is the recovery mechanism — which also makes it the most critical vulnerability. Write it down on paper, store it in one place, and you now have a physical document that grants total access to anyone who finds it. This tension doesn't go away by using a hardware wallet; it just shifts from device to backup.
Multisig: The Architecture That Actually Scales
The most important structural change for large holdings is moving from a single-key model to a multisig model.
Multi-signature (multisig) requires M signatures from a set of N possible keys before any transaction can be authorized. The most common setup is 2-of-3: any two of three keys can sign, but no single key can act alone.
This changes the threat model in a fundamental way. A single key can be stolen, lost, or seized — and funds remain secure. The most likely physical failure modes (one device breaks, one seed phrase is lost) don't cause total loss. And if one key is compromised, you can move funds to a new multisig using the remaining two keys before the attacker can reach a second.
On Bitcoin, multisig is a native protocol feature (P2SH and P2WSH address types). On Ethereum, it's implemented through smart contracts — the most established being Safe (formerly Gnosis Safe). Both have years of production use at scale.
The tradeoff is coordination. Every transaction requires gathering two signatures, which might involve multiple devices, multiple people, or both. A multisig setup that isn't well-documented is arguably more dangerous than a well-documented single-key setup — if you can't reconstruct the signing process, the funds might be effectively inaccessible even to legitimate holders.
Key Ceremony and Documentation
Generating and distributing keys for a multisig setup is called a key ceremony. Getting this right is as important as the cryptographic design itself.
The principle: keys should be generated on hardware that has never been online and never will be. An air-gapped computer — physically disconnected from all networks — generates keys with substantially lower compromise risk than any machine with a network history.
Practically, this involves purpose-bought hardware set up offline, a fresh operating system installed from verified media, key generation performed with the device fully offline, and private keys backed up on metal (not paper — paper degrades and is flammable), stored in separate physical locations.
The documentation question matters as much as the key generation itself. The recovery process needs to be written clearly enough that someone unfamiliar with the setup — a spouse, a lawyer, a trustee — could execute it correctly under stress. Test the recovery before you need it.
Geographic and Custodial Distribution
For amounts where a single-location event represents meaningful risk, distributing key custody across geographies adds real protection.
With a 2-of-3 multisig, a common distribution pattern: Key 1 in a home safe or safety deposit box. Key 2 with a professional collaborative custody service (Casa and Unchained Capital are the most established options for individuals; institutional providers include Coinbase Custody, Anchorage, and BitGo). Key 3 in a second location — a safety deposit box at a different bank, a family member in another city, a separate jurisdiction.
The point is that no single physical event or single compromised party controls enough keys to move funds alone. Two independent failure modes have to coincide.
Institutional custodians add counterparty risk but also add legal infrastructure — insurance, estate planning compatibility, regulatory oversight. For certain structures or amounts, that tradeoff is worth it.
What Would Break These Approaches
The multisig model breaks if keys were generated on a compromised device — the security model was never real, regardless of the setup structure. It also breaks if documentation fails: keys exist but the signing process isn't clear when someone actually needs to use it. And it breaks if all key holders are subject to simultaneous legal or physical pressure — jurisdiction and key-holder selection matter here.
No setup eliminates all risk. The goal is to remove the most likely attack vectors while keeping legitimate access — including by heirs or authorized parties — genuinely possible.
Timing
Now: The architecture questions are relevant at any amount where loss would be material. For most holders, a hardware wallet combined with carefully stored seed phrase backups in multiple locations is sufficient. Multisig becomes worth the complexity when the setup cost is justified by the amount at risk.
Next: Collaborative custody products have made multisig significantly more accessible. Casa and Unchained both offer assisted multisig without requiring full DIY key management — worth exploring as a middle-ground option.
Later: Account abstraction on EVM chains is moving toward programmable key management: social recovery, guardian systems, and time-locked transactions. Still early and unproven at scale, but the direction is toward more flexible security models than seed-phrase custody alone.
Boundary
This covers the security architecture and threat models behind large-amount crypto storage. It doesn't constitute security advice for any specific situation, nor does it address tax, estate planning, or legal implications of self-custody at scale — all of which are material considerations beyond mechanism explanation.
The architectures described are established and in active use. How much complexity is warranted depends on the amount, the risk tolerance, and whether the setup can be maintained and understood by whoever would need to use it.
