HostDeFi › Guides › Hot-wallet compartmentalization
Hot-wallet compartmentalization
Every wallet compromise is a blast-radius question before it's a security question. The fix isn't a perfect wallet — it's an architecture where the worst day has a ceiling.
Most drained wallets weren't cracked open — they were asked politely for access and said yes. A signature on a malicious site, an approval granted to a drainer contract, a phrase typed into a fake claim page: the failure was a moment of judgment, and the cost was the entire balance because the wallet held the entire balance. Compartmentalization is the discipline that makes a moment of judgment survivable: you separate funds by risk role, so the wallet that touches hostile territory never holds what you can't lose.
The standard architecture
The vault
Long-term holdings live here — a hardware wallet or a phrase-backed wallet that has never connected to a website. It receives deposits and sends to your own addresses only. No dApp sessions, no approvals, no signatures beyond transfers to yourself. A vault that has never met the internet cannot be phished.
The trading wallet
Your everyday hot wallet — the one connected to the DEXes and apps you actually use, holding a float you size on purpose: enough for this week's activity, not a month of it. This wallet sees routine hostile traffic (approvals, swaps, signatures) and is where a compromise is likely eventually — so it holds an amount you're prepared to lose without it being the story of your year.
The burners
For airdrop claims, new sites, mint rushes, and anything you don't fully trust — a wallet you fund with gas and pocket change, treat as already compromised, and retire when the job's done. A burner that gets drained is a lesson, not a loss. Fake claim sites are exactly what burners are for →
The rules that make it work
Fund forward, never back. Money flows vault → trading → burner, one direction. A burner that ends up holding value sweeps to the vault through the trading wallet — and if a burner might be compromised, its funds are simply abandoned with it. Never rescue a dirty wallet's contents into a clean one through a path that links them carelessly.
Approvals stay with the wallet that signed them. Your trading wallet's approvals are scoped to its float, so the worst a stale approval can touch is the float. Revoke on a schedule — approval hygiene is the other half of this → — and treat every new-site approval as writing a cheque the site could cash while you sleep.
The vault never "just this once." The moment a vault connects to a dApp — for one mint, one claim, one signature — it becomes a hot wallet with a large balance. The whole architecture is one boundary, and it's binary: the vault doesn't sign things for strangers, ever.
Fresh phrases per layer, never reused. Compartments that share a seed phrase are one compartment with extra steps. Each layer gets its own phrase, stored under the rules in the seed-phrase surface map → — and the burner's phrase is the one you can afford to be casual about, because it protects pocket change.
Sizing the float honestly
The trading float is a number you choose, not a residue. A workable heuristic: one to two weeks of real activity — swaps, entries, gas — rounded down, not up. If losing that number would change your month, it's too big; if topping it up weekly feels like friction, the friction is the point — it's the toll you pay for a ceiling on the worst case. The vault's job is to make that toll feel cheap.
The math of the ceiling: if your burner's worst case is gas money, your trading wallet's is two weeks of float, and your vault's is zero because it never signs — then no single click, on any site, at any hour, in any state of tiredness, can cost you more than a bounded, pre-decided amount. That's the entire product. Security you can't execute at 2am isn't security; a bounded blast radius is.
What this doesn't fix
Compartmentalization caps the loss from your mistakes and hostile sites — it does nothing for a token that rugs underneath you. A burner holding a honeypot loses the same way a vault would; the difference is only what else was in the wallet. Reading the token itself — its liquidity posture, authorities, holder spread — is a separate check that happens before the trade, not a property of which wallet you used. Scan the token, size the wallet, in that order.
The wallet limits the blast — the scan reads the token
Before anything enters any compartment, check what it actually is. Paste the contract — liquidity, authorities, and holder spread in one read.
If the compartments are already linked
Most people's real setup is "one wallet with history." Migrating out is cheap and unglamorous: generate fresh phrases (one per layer), move long-term assets to the new vault first in a plain transfer, then seed the trading float, and leave the old wallet with gas money as a tripwire — a drain attempt on it tells you the old surface is compromised without costing anything that matters. If it's already draining, this is the hour-one playbook →
Frequently asked
How many wallets do I actually need?
Three roles cover it: a vault that never connects, a trading wallet with a capped float, and disposable burners for untrusted sites. More layers usually degrades hygiene rather than improving it.
Isn't moving money between wallets expensive?
Fees are trivial on Solana and L2s and modest on mainnet — a predictable toll versus an unbounded compromise. Size the float for weekly, not daily, top-ups.
Does a hardware wallet replace compartments?
No — it protects keys from extraction but still signs what you approve. A drainer signed from a Ledger drains the Ledger. Compartments bound what a bad signature can reach.
The biggest compartmentalization mistake?
Connecting the vault 'just once.' One dApp session makes it a hot wallet holding everything — the boundary is binary.
Can burners be extra accounts in the same wallet?
No — same-account shares a seed phrase, so a phrase leak takes every compartment. Burners need their own phrase, safe only because they hold pocket change.