Hot wallets are where the money lives. They're designed to move fast, which means every attacker on the planet has you on a list. The real question isn't whether someone cracks in. It's how much they walk out with.

FTX disappeared $8B. Wintermute got hollowed for $160M. Poly Network, $600M. The pattern's the same. Find the keys. Extract everything before anyone notices. The only difference between a survivable hack and a company-ending one is what you built.

You want fast withdrawals. That means holding cash. Cash is a target. Defenses slow things down. Slower means unhappy users. You're caught between two bad options unless your architecture forces you to be paranoid.

Size your hot wallet to what you can afford to lose

Here's the trade. How much do you sit liquid, and how hard do you protect it?

More liquid means happy customers. Fewer complaints about delays. Withdrawals are instant. Less liquid means you're cutting off one of your own arms but the wallet's harder to drain.

Look at historical data. Three months of withdrawals. Find the 99th percentile hourly spike. Double it. That's the bare minimum you keep hot. Everything else sleeps in cold storage or earns somewhere safer.

Say you're doing $5M a day. The 99th percentile peak hour is probably $500K. Keep $1M hot. Push $4M elsewhere. Covers all normal traffic and you've got a buffer.

Now think about this. Your hot wallet gets stolen tomorrow. How long does the company survive? Days of revenue? A week? Most teams can't take more than a few days of total loss. If you're sitting on $10M, one hack and you're insolvent. $500K and you've got time to rotate keys, kill access, call your customers.

Your loss tolerance should be explicit. Write it down. How much money can actually disappear before we're dead.

Velocity limits stop the bleeding

You can't stop hackers entirely. But you can make sure they can't drain the wallet in one transaction.

Build velocity limits into the smart contract itself. No address moves more than X per hour, period. No transaction above Y, ever. These are on-chain rules. No human can flip a switch and bypass them.

Wintermute's problem was simple. $160M in one wallet. No limits. When someone got the key they took all of it in one movement. A $5M per hour limit would have capped the damage at $5M plus whatever they grabbed in that first window before alarms went off.

Velocity limits aren't perfect. But they buy time.

Circuit breakers go harder. Watch each wallet for weird behavior. If someone tries to move cash somewhere new, or velocity spikes, the wallet locks for 30 minutes. A multi-sig person has to manually approve or reject. That 30-minute friction is the difference between a manageable loss and bankruptcy.

Use Gnosis Safe or something similar. Add a rule to your withdrawal contract that kills everything if limits get exceeded. Trigger an alert. Someone logs in, sees the transaction, approves or rejects it. Takes 30 seconds once a quarter when a real customer tries a bulk withdrawal. Worth it for preventing catastrophe.

The operational load is basically nothing.

Multi-sig keeps the thieves honest

Your hot wallet needs multi-sig. Non-negotiable. Three-of-five is standard. Five authorized keys. Any three can sign. Attacker needs three, not one. Plus if you notice one key's compromised, you revoke it.

Where do these keys live though? This is where people screw up. Some teams keep all five in the same HSM or vault. That's theater. Compromise the vault, you've got them all.

Distribute. Different people. Different locations. Different hardware. One signer's got a key on a ledger in their house. Another's got one in a vault at an offsite storage place. Third's on a KMS in the cloud. An attacker has to compromise multiple systems across different places to sign anything.

Don't use a dashboard to sign. Use a ceremony. Each signer logs in from their own machine, looks at what they're signing, and approves. No system holds all the keys. One compromise doesn't burn everything.

And rotate quarterly. Everyone generates a new key. Update the contract. Destroy the old ones. It's annoying. Do it anyway.

Breach is when, not if

Stop thinking about prevention. Think about recovery.

Write a playbook. What happens when someone breaches it. Who notifies who. How fast do you freeze. What's the messaging to customers. Where's backup liquidity coming from. Test it. When Wintermute got hit, panic made recovery worse. You want to already know what you're doing.

Keep a warm backup wallet. Same balances. Different keys. If primary's burned, you flip to backup in minutes. Document how to access cold storage. Test those procedures monthly. When chaos starts, you don't want to be learning your own system.

Plan for the breach. Because it's coming.