How much to keep in a hot wallet is a loss-tolerance question, not a security question. The security answer is always zero; the practical answer is the largest balance whose total loss would not change your behaviour.
Deciding how much to keep in a hot wallet means writing that number down before you fund anything. Once the balance is set by an explicit tolerance, top-ups and sweeps become routine operations instead of judgement calls made under pressure.
- Tolerance first, balance second. Pick the loss you can absorb without changing plans, then work out what balance produces it.
- Underfunding is also a failure. A hot wallet too small for daily work pushes you into rushed transfers from cold storage.
- Expected loss beats worst case. Multiply a realistic annual compromise probability by the balance; the product is the number to compare against the cost of caution.
- The cap is per device, not per person. Two hot wallets mean two caps, and the total is what matters.
Four components of a hot wallet balance
How much to keep in a hot wallet is the sum of four separate requirements, and each has a different failure mode when it is short.
| Component | What sets it | If it is too small |
|---|---|---|
| Spending float | Your normal transaction volume over the sweep interval | Constant top-ups and repeated exposure of cold-storage addresses |
| Largest single transaction | The biggest payment you must make without delay | A failed or delayed payment at the worst moment |
| Fee buffer | Network fee volatility during busy periods | Stuck transactions, or a balance that cannot cover its own exit |
| Settlement timing | How long incoming funds take to become usable | A gap between paying out and being paid |
| Recovery reserve | What you need if the primary device fails mid-week | Panic restoration under time pressure |
Add the four, then compare the total with your tolerance cap. If the operational requirement is the larger of the two, the fix is usually to change the workflow — smaller, more frequent payments — rather than to raise the cap.
Sizing a hot wallet: a worked calculation
The tolerance ceiling
Assume you would accept an expected loss of 150 in your functional currency per year from hot-wallet compromise, and you judge the annual probability of compromise at about 5% for a device you use daily. The balance that produces that expected loss is 150 ÷ 0.05 = 3,000.
The operational floor
Now check the operational side. Your normal spending is 120 a day and you sweep weekly, so the float is 840. Your largest routine payment is 900, and you sometimes have two in flight, so the transaction requirement is 1,800. Fees during a busy week might add 60. Settlement timing adds nothing because incoming funds are usable immediately. Total operational need: 2,700.
2,700 is below the 3,000 cap, so the balance is set at 2,700 and everything above that is swept. If the operational need had come out at 6,000, the sensible response would be to halve the payment size or sweep twice as often — not to accept an expected loss of 300 a year for convenience.
The probability estimate is the weak link, and it should be treated as one. For a device that only runs wallet software and never browses, 1% may be realistic; for a general-purpose laptop, 5% is optimistic. Recalculate whenever your usage changes rather than treating the number as fixed.
A hot wallet is a fuse, not a vault. Its job is to fail cheaply, which means the amount behind it should be chosen so that failure is an inconvenience rather than a restructuring.
Failure modes in both directions
Most guidance warns about holding too much. Holding too little causes its own damage, and it is more common among careful people.
Overfunded
An overfunded hot wallet turns one compromised browser extension into a total loss. The warning signs are recognisable: a balance that has not been swept since it was set, a device that also reads email and opens documents, and a seed phrase that exists in a password manager “for convenience”.
The risk also compounds with time. A balance left untouched for a year has had twelve months of exposure for no operational benefit, and the sweep that would have fixed it takes a minute.
Underfunded
An underfunded hot wallet forces you to move funds from cold storage at the moment you are least careful — usually while something is already going wrong. Repeatedly unlocking a hardware signer for small amounts erodes the habit of treating it as rare, and each unlock is a chance to mistype an address under time pressure.
The second-order cost is address exposure. Every transfer from cold storage reveals a new receiving address and adds a record you must reconcile later. Frequent small top-ups multiply that bookkeeping.
Setting and maintaining the cap
The cap is only useful if it is enforced by a routine rather than by memory. A short procedure is enough.
- Write down the loss you would absorb without changing any plan, as a single number in your functional currency.
- Estimate the annual compromise probability for the specific device, and be pessimistic if the device does anything besides signing.
- Divide the tolerance by the probability to get the ceiling.
- Add the four operational components and compare the total with the ceiling.
- Set the balance to the smaller of the two, and document which constraint bound it.
- Sweep on a fixed schedule, and record the sweep so an unswept balance is visible rather than assumed.
- Re-run the calculation when the device, the payment pattern or the software stack changes.
0 comments
No comments yet — ask a question and we will answer it here.