Most crypto losses do not come from broken cryptography. They come from a phishing approval, a fat-fingered send, a backup nobody ever tested, or someone dying with the seed phrase in their head. Those failures have one thing in common: a single point of failure that nobody planned around.
This is the capstone of the "Beyond the Seed Phrase" series. The earlier parts each took apart one primitive. This part puts them back together into something you can actually commit to: a personal threat model. The goal is not to memorise one perfect secret. It is to engineer a system where any single component can fail without losing your funds.
What a threat model actually is (and why a checklist isn't one)
A threat model is not a list of products to buy. It is a set of answers to four questions, written down before you spend a cent:
- WHAT are you protecting? Your balance size, how often you touch it, which chains it sits on.
- From WHOM or what? Remote malware, phishing, physical theft or coercion, your own mistakes, and death or incapacity.
- How BAD would a loss be? Your loss tolerance is the honest answer to "what could I afford to lose and still sleep?"
- How much CONVENIENCE will you trade for safety?
That last question matters more than it looks. Security is a tradeoff curve, not a maximum. The "most secure" setup you find too annoying to use is less secure than a moderate setup you maintain correctly. Before anything else, write down what you're actually protecting and from whom in plain language.
It helps to name five distinct threat classes, because each one maps to a different defence:
- Remote compromise or malware
- Phishing and social engineering
- Physical theft and coercion
- Self-inflicted loss (lost device, forgotten phrase, wrong address)
- Death or incapacity, leaving heirs locked out forever
Weight your model toward classes 2, 4, and 5. Phishing, user error, and "died with the seed in their head" cause far more real-world losses than exotic cryptographic breaks.
Mapping threats to primitives: each tool kills a specific failure
The series explained the primitives; here is how each one cancels a specific failure mode.
- Hardware wallet (cold signing). The private key never touches an internet-connected device, which defeats remote malware and most key theft. It is worth knowing what a hardware wallet does and doesn't defend against — it does nothing about a phishing approval you confirm yourself.
- Passphrase / 25th word. A second factor on top of the seed, and a plausible-deniability layer. A decoy wallet holds a sacrificial balance you can surrender under coercion while the real wallet stays hidden.
- MPC (multi-party computation). There is no single complete seed phrase to steal anywhere. As Part 2 covered, the key is split into shares via distributed key generation, and a threshold (say 2-of-3) signs without ever reconstructing the full key.
- Passkeys. A phishing-resistant factor: the credential is cryptographically bound to the real site's domain, and the private key never leaves the device's secure enclave, so it cannot be used on a spoofed site. Part 3 explained why a passkey is a factor, not a key. RIP-7212 made verifying these P256 signatures on-chain cheap — roughly 3,450 gas, about a 100x reduction — which is what makes them practical for smart accounts.
- Social recovery. Defends against loss and death without a single backup secret. Part 4 walked through guardians: a set of at least three, a majority of whom can reassign your signing key after a time delay if you lose it.
- Smart accounts. The programmable container that lets you combine the above plus spending limits, daily caps, and session keys. ERC-4337 brought this to mainnet on March 1, 2023 without changing the Ethereum protocol; the Pectra upgrade (mainnet, May 7, 2025) added EIP-7702, which lets even an ordinary externally owned account temporarily adopt these features.
The throughline: layer primitives so their failure modes do not overlap. A stolen device alone, a leaked phrase alone, or a single dead guardian alone should never equal total loss.
Decision framework: pick a stack by who you are
There is no universal answer. Pick the profile that fits, and note that one person often spans several.
Casual holder (small balance, wants simplicity). A single reputable hardware wallet plus a securely stored seed backup, optionally a passphrase. Your real risk is losing the backup or approving a phishing transaction, not a targeted attacker. Keep it simple enough that you maintain it.
Active DeFi user (frequent signing, multi-chain, approval-heavy). A smart account (ERC-4337 or EIP-7702-enabled) for spending limits and session keys; a hardware wallet as the cold signer for large moves; a passkey as the phishing-resistant day-to-day factor; and a separate hot account funded with only what you would risk this week.
High-net-worth (large balance, named target). MPC or multisig with key shares stored in geographically separate locations, so no single person or place can move funds and coercing one person cannot complete a transfer. Add a passphrase decoy wallet for the coercion threat, and run strict operational security.
Inheritance and estate planning. Social recovery with guardians, or a multisig where a lawyer or family member holds a key, plus a documented, time-locked recovery path and written instructions. The point is that heirs can recover without you ever handing a live secret to anyone while you are alive.
Spanning profiles is normal — casual savings plus an active DeFi habit. The fix is multiple accounts with different stacks, not one account trying to do everything.
The 8-point operational pre-commit checklist
Commit to these before, not after, you fund anything.
- Write it down. One paragraph per threat class — what you protect and from whom — before buying any hardware.
- Separate balances by purpose. A cold vault for long-term holdings; a hot account funded only with what you can lose this week.
- Anchor signing offline. Use hardware (or MPC shares) so no key sits on an internet-connected device.
- Add a phishing-resistant factor. Use a passkey, and verify every approval on the device screen — assume the dApp interface can lie.
- Decide your recovery model now. Guardians, multisig co-signers, or distributed shares — and confirm it works with a dry run.
- Plan for coercion. A decoy wallet via passphrase and/or geographically split keys, so you genuinely cannot hand over everything.
- Test your backups. Actually restore from your seed or shares onto a spare device. An untested backup is not a backup.
- Document inheritance. Who recovers what, how, and where the instructions live — then review the whole model annually.
Closing the loop: redundancy, not memorisation
The series traces a single arc. Part 1 showed why the seed phrase alone is a single point of failure. The middle parts removed those failures one at a time: MPC removes the single seed, passkeys remove the phishing vector, social recovery removes the single backup secret. Smart accounts tie them together into one programmable account.
What is new in 2026 is not the ideas but their maturity. ERC-4337 has been live since 2023, EIP-7702 since Pectra in May 2025, and cheap P256 verification via RIP-7212 means redundancy is now practical for ordinary users, not just institutions. Self-custody has shifted from "guard one secret perfectly forever" to "engineer a system where any single component can fail."
A threat model is a living document. Pick your profile's stack today, run the eight-point checklist, and revisit it as your balance and the tooling evolve.
Key takeaways
- A threat model answers four questions — what, from whom, how bad, how convenient — and most real losses are phishing, user error, and inheritance gaps, not broken cryptography.
- Each primitive cancels a specific failure: hardware kills remote malware, passphrases enable a decoy, MPC removes the single seed, passkeys resist phishing, social recovery survives loss and death.
- Pick a stack by profile — casual, active DeFi, high-net-worth, or inheritance — and use multiple accounts rather than one account doing everything.
- The eight-point checklist turns the model into action: separate balances, sign offline, test backups, plan for coercion and inheritance.
- The 2026 goal is redundancy, not memorisation — a system where no single failure is catastrophic.
