Crypto Custody Decision Tree (2026): Self-Custody vs Exchange vs Multisig vs MPC + Failure Modes

A friend loses their phone number for 12 minutes.

Not their phone. Their number. A carrier rep gets talked into “porting” it to a new SIM. The attacker resets email, resets the exchange login, turns off the only alerts that matter, and starts withdrawing. By the time the victim’s screen says “No Service,” the money is already in flight.

That’s custody in 2026: not an ideology fight. A design problem about failure. Your cryptography is fine. Your process isn’t.

The uncomfortable truth: your biggest custody risk is operational, not cryptographic

What custody really means (control, recoverability, and who can say “no”)

When people say “custody,” they usually mean “where my coins are.” That’s not the useful definition.

Custody is a control system with three questions:

1. Control: Who can move funds?
2. Recoverability: If something breaks (lost device, lost access, death, legal issue), can funds be recovered?
3. Veto power: Who can stop a transfer that’s suspicious, coerced, or just wrong?

Every custody model is a different answer to those three questions. And every answer has a failure mode.

Threat model in one sentence: theft, loss, lockout, coercion

Most real-world custody incidents are one of these:

• Theft: someone sends your funds without permission (account takeover, phishing, malware)
• Loss: you can’t sign anymore (destroyed seed, destroyed device, no backups)
• Lockout: you should be able to sign, but you can’t (provider dependency, KYC hold, guardians unavailable)
• Coercion: someone forces a transaction (the “$5 wrench problem”)
• Policy risk: withdrawals blocked, accounts frozen, jurisdictions change

Notice what’s not here: “private keys got cracked.” That’s not how this ends for almost anyone.

A quick “blast radius” idea: how to lose $5k vs how to lose everything

You don’t need perfect security. You need bounded damage.

• If your spending wallet gets phished, you want to lose one month of spend, not your net worth.
• If your exchange account gets compromised, you want the attacker to hit a withdrawal allowlist + delay, not an instant drain.
• If a team signer disappears, you want continuity, not a frozen treasury.

Design custody like you design fire safety: compartments, alarms, and exits.

The custody options (what you’re actually buying with each)

Here’s the honest trade: what each model optimizes for—and what it makes worse.

Exchange custody: convenience, liquidity, and hidden balance-sheet risk

What it’s great at:
Fast trading, fiat rails, simplicity, “I forgot my password” recovery, and sometimes customer support.

What it makes worse:

• Account takeover surface (email, phone number, recovery flows)
• Policy/jurisdiction risk (withdrawal holds, freezes, KYC/AML escalations)
• Balance-sheet opacity (how assets are held, lent, or encumbered may be unclear)

In practice, exchange custody is a service relationship. Services can fail, change terms, or be unavailable exactly when volatility hits.

Single-key self-custody: maximum sovereignty, minimum forgiveness

What it’s great at:
No counterparty freeze. No rehypothecation by default. Clean ownership. You can always move—if you can sign.

What it makes worse:
One human mistake can be final:

• seed exposure
• bad backups
• “temporary” seed handling that becomes permanent risk (photos, notes apps, cloud sync)
• signing on compromised devices

Single-key self-custody is the purest version of “you are the bank.” Banks have procedures. Most people don’t.

Multisig: shared control, more moving parts

What it’s great at:

• Shared approval (teams, partners, treasuries)
• Veto power (one compromised signer shouldn’t equal instant loss)
• Policy controls (depending on wallet/contract design)

What it makes worse:
Coordination and configuration risk:

• signer compromise
• signer unavailability (travel, illness, lost keys, departure)
• correlated risk (everyone uses the same everything)
• misconfigurations (wrong owners/thresholds/modules)
• upgrade/admin risk in smart contract wallets

Multisig is usually the right answer for shared funds—if you treat it like an ops system, not a group chat.

MPC: shared control with different failure modes (and different trust assumptions)

MPC (multi-party computation) is an umbrella term. The chain may see a “normal” signature, but off-chain multiple parties/devices participate.

What it’s great at:

• smoother UX than traditional multisig in some designs
• no single seed phrase (in many implementations)
• flexible recovery models (implementation-dependent)

What it makes worse:

• Recovery ceremony pitfalls: you don’t lose “a key,” you lose a share or an account needed to reconstruct signing
• Provider dependency/gatekeeping: in some architectures, a provider can delay or block signing (even if they can’t steal)
• Opaque trust assumptions: “MPC” can mean 2-of-2 (you + server), 2-of-3 (add recovery share), guardian-based recovery, and more

If you can’t explain what happens when you lose your phone, you don’t understand the custody you picked.

Hybrid setups: trading float + cold reserve + treasury controls

Most people shouldn’t choose one custody model. They should choose three balances:

• Cold reserve: rarely moves, never touches random dApps
• Warm spending wallet: regular activity, capped downside
• Trading float on exchange: only what you need this week

Hybrid custody is how you buy convenience without renting catastrophe.

Failure modes: how custody setups die in the real world

This is the spine of the decision: pick a system that survives the failures you’re most likely to experience.

SIM swaps & account takeover: why your phone number is a skeleton key

How it happens (typical path):
An attacker gets enough personal data to convince a carrier to port your number or issue a new SIM. With your number, they intercept SMS codes and—more importantly—trigger password resets for email and exchanges that still treat SMS as “proof.”

Why it’s so lethal:
Phone numbers are used as a recovery credential. Recovery flows often bypass your best security.

Damage control moves:

• Remove SMS as a factor wherever possible (especially for email + exchanges).
• Lock down your carrier account (port-out PIN, account freeze features where available).
• Treat email as Tier-0 custody infrastructure.

Phishing & token approvals: the “sign-in” that is actually a spend

Phishing isn’t just fake logins. It’s signature capture.

How it happens:
You connect a wallet to a site that looks right (or a real site reached through malicious ads/SEO poisoning), then you sign:

• a transaction that moves funds now, or
• an approval/allowance that lets an attacker move funds later

On EVM chains, approvals are the long con. You can approve today and get drained next week, after you’ve stopped watching.

Mitigations that actually work:

• Keep a cold reserve wallet that never connects to dApps.
• Use a warm wallet for dApps with limited funds.
• Prefer limited allowances where the UI supports it; revoke regularly.
• Don’t blind sign—if you can’t verify what you’re signing, don’t sign.

Exchange failure modes: rehypothecation, freezes, KYC holds, jurisdiction shocks

There are two broad classes of exchange risk:

1. Account-level risk: you get hacked, locked out, or flagged.
2. Platform-level risk: the exchange can’t or won’t honor withdrawals on your timeline.

Rehypothecation/commingling (say it precisely):
Rehypothecation is the reuse of assets as collateral or lending onward, increasing counterparty exposure. Many platforms’ internal asset usage and legal segregation aren’t fully visible to customers. Even with proof-of-reserves, you may not see the full liabilities picture unless there’s a credible liabilities attestation and clear methodology.

Freeze/hold reality:
Even legitimate users can hit withdrawal holds due to:

• KYC/AML reviews
• suspicious activity triggers
• jurisdiction changes
• “maintenance” during volatility

This doesn’t mean “exchanges are scams.” It means exchange custody includes policy risk you don’t control.

Single-key failure modes: seed exposure, bad backups, device compromise

How it happens in the wild:

• seed phrase typed into a notes app “just for a second”
• seed photographed “for safety”
• seed stored in email drafts
• recovery phrase entered on a computer during a “recovery test”
• clipboard malware swaps addresses during a send

Single-key self-custody fails less from cryptography and more from future you making a stressed decision at the worst time.

Multisig failure modes: signer risk, correlated failure, misconfig, and upgrade risk

Multisig reduces single-point theft risk, but introduces multi-point operational risk.

Common endings:

• Signer compromise: one signer gets phished. If the threshold is low and controls are weak, the treasury drains.
• Signer unavailability: someone loses a device, travels, gets sick, leaves, or dies. If the threshold is too tight, funds freeze.
• Correlated risk: three signers, same password manager, same email provider, same phone carrier, same laptop profile. One breach becomes “multisig” in name only.
• Misconfiguration: wrong owners, wrong threshold, unsafe modules/permissions, or an unnoticed owner-change transaction.
• Upgrade/admin risk: some multisig systems rely on upgradeable contracts or admin keys. If upgrades are rushed or admin controls are compromised, you can lose funds without any signer “messing up.”

MPC failure modes: recovery ceremony pitfalls, provider dependency, share loss vs device loss

MPC failure stories often look like “support ticket hell” rather than a clean theft narrative.

How it happens:

• You lose a device that holds a key share.
• Recovery requires an email/phone/provider account you also lost.
• Guardians/social recovery assumptions fail (people unreachable, collusion, identity verification breaks).
• Provider outage or policy blocks signing during “review.”

Important nuance: some MPC designs aim to ensure the provider can’t steal, but they may still be able to block. You have to decide whether that’s acceptable.

The silent killer: operational mistakes (wrong chain, wrong address, bad allowances, fee mismanagement)

No attacker needed. Just one rushed send:

• depositing to the wrong network (sending on a chain the destination doesn’t support)
• sending to the wrong address format
• confusing L2 vs L1 deposit routes
• forgetting you left unlimited approvals on a warm wallet
• fee mistakes: stuck transactions, replacement confusion, accidental overpayment, or forgetting to keep native gas

Custody isn’t only about stopping theft. It’s about making normal operations hard to screw up.

The decision tree (pick the smallest system that survives your likely failure)

You want the smallest system that survives your most likely failure—not the fanciest one.

Step 1 — What’s the job?

• Hold (rare moves, long horizon)
• Trade (frequent moves, exchange access)
• Pay/use dApps (regular on-chain activity, approvals risk)
• Treasury (shared funds, auditability, continuity)

Step 2 — What’s the loss tolerance?

Be honest:

• Annoying: it stings, life continues
• Painful: meaningful setback
• Life-changing: hard to recover

Loss tolerance decides whether you need blast-radius controls by default.

Step 3 — Who must approve movement?

• Just me
• Me + partner
• Small team (2–8)
• DAO / public governance process

Shared control nudges you toward multisig or MPC (or smart-account policy), because “single key shared in Slack” isn’t a custody model—it’s a future incident report.

Step 4 — How often do you move funds?

• Few times a year: prioritize robustness and recovery
• Monthly/weekly: you need workable process and segmentation
• Daily/intraday: you need an exchange float or a streamlined signing flow

Frequency determines how much friction you can tolerate—and how much exposure you’ll have to phishing/dApp risk.

Step 5 — What’s your worst plausible failure?

Pick what’s actually plausible:

• I might get phished while using dApps
• I might lose my phone / email access
• A signer might disappear or go dark
• An exchange might freeze withdrawals when I need them
• A provider might go down or lock my account
• I might make a rushed operational mistake

Step 6 — Choose a model

• Exchange if you must trade intraday and accept policy risk—but cap exposure with a float model.
• Single-key self-custody if you’re solo, disciplined with backups, and want minimal dependencies.
• Multisig if shared control, auditability, and portability matter—and your team can run process.
• MPC if you need shared control with smoother UX and you can verify the recovery story and provider dependency.
• Hybrid if you’re like most people: hold + spend + trade.

Step 7 — Add guardrails (these matter more than the model)

Guardrails shrink blast radius:

• Segregate balances (cold/warm/exchange float)
• Withdrawal address allowlists (and delays if available)
• Spending caps / per-tx limits
• Time delays for large moves (timelocks)
• Monitoring + alerts
• A written incident plan (even if it’s one page)

Scenario playbooks (minimum viable custody setups)

These are “choose-your-own-adventure”: likely failures → minimum viable setup → upgrade path.

Scenario A: Long-term hold (individual) — “I move coins a few times a year”

Your likely failures:

1. Seed exposure during a panicked moment (“I’ll just type it in to check”)
2. Bad backups (lost, destroyed, stolen)
3. Phishing via dApps if you ever connect this wallet

Minimum viable setup (weekend-ready):

• Cold reserve: single-key self-custody on a dedicated signing device (hardware wallet or equivalent signing environment).
• Warm wallet: separate address for small amounts you actually use.
• Backups: two physically separated backups of recovery material, stored so a single burglary/fire doesn’t take both. No cloud storage, photos, or notes apps.

Details people skip:

• Keep the cold reserve wallet out of your daily browser. Ideally: never connect it to dApps.
• Do a recovery drill without exposing the seed to an online device. The point isn’t to type the seed into a laptop—it’s to prove your backups are readable and you know the steps under stress.

Upgrade path when balance grows:

• Add a second factor via multisig (e.g., 2-of-3 with one signer as a geographically separated backup device) if theft is your bigger fear than lockout.
• Add a time-delay policy for large moves (if using a smart account) so one bad sign doesn’t mean instant finality.

Scenario B: Active trading (individual) — “I need exchange access, but I don’t want exchange risk”

Your likely failures:

1. Exchange account takeover (email/SIM swap/phishing)
2. Withdrawal freeze during volatility
3. Leaving too much on-exchange “temporarily”

Minimum viable setup: trading float model

• Exchange float: only what you need for near-term trading.
• Self-custody reserve: profits/long-term holdings swept out on a schedule (daily/weekly).
• Exchange hardening:
  • Use passkeys or hardware security keys if supported.
  • Disable SMS-based recovery where possible.
  • Enable withdrawal address allowlisting; treat allowlist changes as high-risk events (ideally with a delay).

Practical details:

• Your email account is part of your exchange custody. Secure it like a wallet: strong auth, recovery codes stored safely, no SMS recovery if avoidable.
• Turn on alerts for new logins, API key creation, and withdrawal requests. Time-to-detection matters.

Upgrade path:

• Separate identities: one email/phone footprint for exchanges, another for public life, to reduce targeted social engineering.
• Use a second exchange only as contingency for withdrawal outages (don’t double your attack surface without a reason).

Scenario C: Small team treasury (2–8 people) — “shared funds, travel, sick days”

Your likely failures:

1. One signer gets phished or their laptop is compromised
2. A signer becomes unavailable right when you need to act
3. Correlated failures (same password manager, same email provider, same carrier)
4. Process gaps during team changes

Minimum viable setup: multisig with policy

• Choose threshold based on availability:
  • 2-of-3 for small teams that need speed and redundancy
  • 3-of-5 when you can tolerate more coordination and want stronger theft resistance
• Signer separation (non-negotiable):
  • separate devices
  • separate recovery channels (don’t let everyone depend on the same email provider + phone carrier)
  • at least one signer “cold-ish” (used only for signing, not daily browsing)

Guardrails for teams:

• A timelock/delay for large transfers (even short delays can save you if compromise is detected quickly).
• A written signer offboarding + rotation process. When someone leaves, rotate owners the same day.

Upgrade path:

• Role separation: proposer vs executor. One drafts transactions; others verify independently.
• Monitoring for owner changes, module/permission changes, and large transfers.

Scenario D: DAO treasury (onchain governance) — “public process, attacker attention”

Your likely failures:

1. Execution mistakes (wrong address, wrong call data, wrong chain)
2. Compromised signer keys
3. Misconfigured permissions/modules that allow bypass
4. Social engineering during rushed proposals

Minimum viable setup: multisig + timelocks + execution pipeline

• Multisig for execution with a threshold sized for resilience.
• Timelock for material transfers/parameter changes, giving time for review and incident response.
• Clear separation between proposal creation, simulation/verification, and execution.

Practical details:

• Treat transaction building like a software release:
  • multiple reviewers
  • reproducible simulation of what will be executed
  • explicit sign-off criteria
• Monitor for permission/owner changes, approvals that grant spending power, and governance actions that change execution authority.

Upgrade path:

• Security council processes, emergency pause policies (where appropriate), and incident runbooks.
• Specialized treasury ops tooling—after you have thresholds, separation, timelocks, and monitoring.

Scenario E: High-risk regions / coercion risk — “the $5 wrench problem”

Sensitive territory. Don’t treat internet advice as a complete safety plan—legal and personal safety realities vary.

Your likely failures:

1. Physical coercion
2. Forced disclosure of devices/accounts
3. Targeting based on public identity and visible balances

Minimum viable setup (principles, not cosplay):

• Keep visible wallets small (warm spending) and reserves harder to discover.
• Reduce linkability between your public identity and reserve custody operations.
• Decide what you can reveal under pressure—and keep that plan consistent.

Upgrade path:

• Get professional advice if you’re genuinely at high risk. Coercion isn’t a “wallet feature” problem; it’s personal security and operations.

Minimum viable setups (templates you can copy)

These are meant to be doable in a weekend. If you can’t maintain it, it’s not security—it’s theater.

Template 1: Minimum viable self-custody (single-key) with real backups

Goal: survive device loss without making seed theft easy.

• Wallet roles

  • Cold reserve address: long-term holdings, rare sends
  • Warm address: spending/dApps, capped funds

• Backup design

  • Two copies, physically separated
  • Stored so one event (fire/flood/burglary) doesn’t take both
  • No cloud photos, no notes apps, no email drafts
  • Labeling that helps you later without advertising to a thief what it is

• Drill

  • Do a small test send from cold to warm and back.
  • Validate you can locate and read backups under mild stress (a timer helps).
  • Don’t type seeds into internet-connected apps “to test.”

Template 2: Minimum viable exchange usage (reduce takeover + withdrawal shock)

Goal: use exchanges without letting them become a single point of ruin.

• Account hardening

  • Prefer passkeys or FIDO2/WebAuthn hardware security keys where supported
  • If limited to authenticator apps (TOTP), protect TOTP recovery and avoid SMS fallback
  • Lock down the email account tied to the exchange (it’s the real master key)

• Withdrawal safety

  • Enable withdrawal allowlist
  • Turn on withdrawal/login alerts
  • If the exchange supports withdrawal delays for new addresses, use them

• Balance policy

  • Define a maximum exchange float
  • Sweep on a schedule (and actually do it)

Template 3: Minimum viable multisig (2-of-3 / 3-of-5) for small teams

Goal: survive one compromised signer and one unavailable signer.

• Threshold selection

  • 2-of-3: best when you need speed and have 3 reliable people/devices
  • 3-of-5: better theft resistance, worse coordination—use when size justifies it

• Signer hygiene

  • One signer device per person
  • Separate ecosystems: don’t let all signers share the same password manager + email + phone carrier
  • Keep at least one signer on a “clean” device profile used only for signing

• Process

  • Transaction draft + independent verification (addresses, amounts, chain)
  • Explicit offboarding: rotate signers immediately on departure
  • Record what happened (who approved, why) without putting secrets in a shared doc

Template 4: Minimum viable MPC (what to demand from the recovery story)

Goal: smoother shared-control UX without discovering too late that recovery is a trap.

Before using an MPC wallet/provider, get clear answers to these:

• Who holds the shares? (your devices, provider servers, guardians?)
• Can you sign if the provider is down? If not, what’s the downtime plan?
• Can the provider block signing? Under what conditions?
• What happens if you lose your phone today? Step-by-step.
• What happens if you lose email access? Step-by-step.
• Can you rotate devices/shares without a support ticket?
• Can you export/migrate custody without being trapped?

If any answer is vague, treat it as a lockout risk until proven otherwise.

Template 5: Minimum viable hybrid (cold reserve + warm spending + trading float)

Goal: cap worst-case loss from any single failure.

• Cold reserve: never connects to dApps, rarely signs
• Warm wallet: daily use, approvals risk accepted, limited funds
• Exchange float: only near-term trading capital, swept out regularly
• Monitoring: alerts for approvals/owner changes (wallet) + logins/withdrawals (exchange)
• Rules: any transfer above a threshold requires an extra verification step (second device, second person, or time delay)

Operational hygiene that pays rent (regardless of model)

Account security basics that matter: passkeys, authenticator, hardware keys—and why SMS is dead

If you do one thing: stop treating SMS as security.

• Best: passkeys or hardware security keys (when supported)
• Good: authenticator app (TOTP), with protected recovery
• Worst: SMS 2FA, especially when tied to account recovery

Also: secure your email. Many exchange compromises are “email compromise → password reset → takeover,” not “exchange got hacked.”

Device segmentation: one environment that signs, one that browses

The separation that works:

• Reserve signing environment: used for signing only, not random browsing
• Daily browsing environment: where phishing lives

If you mix them, you’re betting your net worth that you’ll never click the wrong thing.

Allowance discipline: revoke strategy and spending caps

For EVM users, approvals are a hidden liability.

• Prefer exact/limited approvals where possible.
• Regularly review and revoke old allowances on warm wallets.
• Don’t grant unlimited approvals from a wallet that holds meaningful reserves.

Address books, test sends, and chain sanity checks

Operational errors are boring and expensive.

• Use an address book/allowlist for frequent destinations.
• For new routes, do a test send with an amount you can afford to lose.
• Before bridging or depositing, verify chain/network compatibility twice. Same symbol isn’t compatibility.

Monitoring: alerts for approvals, sign attempts, withdrawals, and governance actions

Monitoring is part of custody because it buys you time.

• Wallet alerts: approvals, owner changes, large transfers
• Exchange alerts: new login, new API key, withdrawal initiation
• Treasury/DAO alerts: proposals, execution transactions, permission changes

The goal is to reduce time-to-detection from days to minutes, so delays/allowlists/timelocks can actually save you.

Incident response: what to do in the first 30 minutes after you suspect compromise

Write this down before you need it.

In the first 30 minutes:

1. Assume credentials are burned. Move fast; don’t “investigate” first.
2. Exchange: freeze withdrawals if possible, revoke sessions/API keys, change password, lock down email access.
3. Wallet: if a warm wallet is compromised, move remaining funds to a known-safe address from a safe device. Then revoke allowances (from a safe environment).
4. Email: rotate password and factors; remove SMS recovery if present.
5. Notify co-signers/team: pause outgoing actions; verify signer devices.
6. Preserve evidence (screenshots, timestamps, addresses) after containment.

You don’t need perfect forensics in minute 10. You need containment.

FAQ

Is self-custody always safer than leaving crypto on an exchange?

Not automatically. Self-custody removes balance-sheet and freeze risk, but concentrates operational risk: seed exposure, bad backups, device compromise, and irreversible mistakes. “Safer” is whatever survives your most likely failure mode and fits how you actually operate.

What’s the fastest way an exchange account gets drained today?

Account takeover: compromised email, successful phishing, or a SIM swap that triggers SMS-based recovery. Once an attacker gets in, they race to withdrawals. If your exchange supports it, passkeys or hardware security keys beat SMS by a mile.

What does exchange rehypothecation mean, and why should I care?

Rehypothecation is when assets are reused as collateral or lent onward, increasing counterparty risk that can be hard to see from the outside. If you can’t verify segregation, liabilities, and withdrawal rights, treat it as uncertainty with real downside.

Multisig vs MPC: what’s the practical difference?

Multisig usually means multiple on-chain signers with a visible threshold (e.g., 2-of-3). MPC splits control via key shares and an off-chain signing protocol; the chain often sees one signature. Multisig tends to be more transparent and portable. MPC can be smoother, but the risk depends heavily on recovery design and whether a provider can block signing.

What are the most common multisig failure modes for small teams?

Three killers: (1) signer compromise, (2) signer unavailability, and (3) correlated risk (everyone depends on the same account ecosystem). Multisig removes one kind of fragility and adds another: coordination.

What can go wrong with MPC wallet recovery?

Recovery is where MPC lives or dies: unclear share ownership, dependence on provider accounts, a “ceremony” that fails when one piece is missing, and provider gatekeeping (delay/block) in some architectures. Verify the “lost phone today” story before trusting it.

How do phishing attacks drain wallets without stealing the seed phrase?

On EVM chains, attackers often trick you into signing an approval (allowance) or a malicious transaction. The drain can happen later, after you forget the approval exists. Defense is separation (cold reserve never touches dApps) plus strict allowance hygiene (limited approvals + regular revocation).

What custody setup makes sense for long-term holding with minimal transactions?

A simple split: cold reserve (hardware wallet or equivalent) that rarely signs, plus a small warm wallet for spending/testing. The real upgrade is boring: redundant backups and a recovery drill—without ever typing a seed into an internet-connected notes app or cloud doc.

What’s a sensible custody model for active trading without taking full exchange risk?

A trading float model: keep only near-term trading capital on the exchange and sweep profits to self-custody regularly. Add withdrawal allowlists, strong login security, and alerts so time-to-detection is minutes, not days.

What’s the minimum viable custody setup for a small team treasury?

Multisig with a threshold sized for availability (often 2-of-3 or 3-of-5), signers on separate devices and separate recovery channels, plus guardrails: limits, delays for large moves, and an explicit signer rotation/offboarding process. Most losses are process failures.

How should a DAO treasury approach custody differently?

DAOs need transparency, auditability, and a safe execution pipeline. Multisig plus timelocks and role separation (proposal vs execution) reduces governance and ops risk. The biggest threats are rushed execution and misconfigured permissions as much as compromised keys.

What’s the single best question to test a custody setup?

What happens if I lose my phone today? If the answer is “I’m locked out,” “support needs to help,” or “I’m not sure,” your recovery path is a liability.

A pragmatic conclusion: custody is a system, not a wallet

The cleanest way to level up custody isn’t jumping to the most complex tool. It’s evolving your system as your balance and surface area grow:

• Separate cold reserve from warm activity.
• Use exchanges as a controlled float, not a default bank account.
• Move to multisig or MPC when human reality requires shared control and continuity.
• Add delays, allowlists, and monitoring when you realize the real enemy is speed: attackers move fast; you notice slowly.

If you do nothing else this weekend, answer this in writing:

What happens if I lose my phone today?

Then build custody so the answer is boring. Not heroic. Not “support will help.” Just boring. That’s what safe looks like.

crypto custody, self-custody, multisig, MPC wallets, exchange risk, SIM swap, phishing, token approvals, wallet security, DAO treasury, treasury management, operational security