Getting how much to keep in hot wallet right is a sizing problem, not a security problem. Security decides whether the wallet can be drained; sizing decides whether that day is an inconvenience or an exit from the asset class.

• The number is a loss tolerance, not a percentage. A fixed five percent means a bigger loss every time the portfolio grows.
• Size against spending, not holdings. The wallet exists to move funds, so the spend rate sets the useful balance.
• Compromise is fast and total. There is no partial drain and no chargeback, so the loss is the whole balance on the day it happens.
• Friction has a price too. Moving everything offline has a real time cost, and pretending otherwise produces a wallet people stop using correctly.

The limit is a loss tolerance, not a percentage

A percentage feels prudent and behaves badly. If you keep ten percent hot and the portfolio doubles, the hot balance doubles with it, and the amount at risk grows without anyone deciding that it should. The wallet did not become safer or more necessary; the arithmetic just moved.

A tolerance is a fixed number in the currency you actually spend. It is the amount whose loss you would notice, absorb, and continue from. That number changes when your income changes, not when the price does.

This is also why the useful question is not “what proportion” but “what would I do the morning after”. If the answer is that you would keep operating, the balance is sized correctly. If the answer involves borrowing or cancelling something, it is not.

Three ways to size how much to keep in hot wallet

Each method produces a number. Where they disagree, take the smallest, because the disagreement is usually about optimism rather than about facts.

The burn-rate method

Take what you actually spend from the wallet in a month and divide by thirty. Multiply by the number of days you want to cover before you next top up. Two weeks of cover is a common target, because it survives a holiday and a forgotten top-up without forcing an emergency transfer from cold storage at a bad moment.

The largest-transaction method

Size to three times your largest routine transaction. If you regularly move a few hundred in a single transfer, the wallet should hold enough to do that twice with margin, so that a single failure does not leave the next payment stranded. This method produces a larger number than the burn rate when your transfers are lumpy.

The single-signature method

Ask what one signature could move if you approved the wrong thing while tired. A hot wallet has no second confirmation, so the answer is the balance. If that number makes you uncomfortable, it is too large, regardless of what the other methods say.

A worked example

Assume a portfolio worth $18,000, monthly spending from the wallet of $600, and a largest routine transfer of $400. The burn-rate method gives $20 a day, so fourteen days of cover is $280, rounded to $300. The largest-transaction method gives three times $400, or $1,200. The two numbers differ by $900, and choosing between them is a decision about friction rather than about security.

Price the friction first. A cold signing session takes about fifteen minutes once the device, cable and app are all in the right place. At three sessions a month that is 45 minutes, or roughly $22 at a $30 hourly rate. Over a year, that is about $270 of your time.

Now price the risk. Suppose you judge a drain of the hot wallet to be a one-in-twenty event in a given year. The extra $900 kept hot therefore costs about $45 a year in expected loss. The comparison is $45 of expected loss against $270 of saved time, which argues for the larger balance, and the argument holds until the loss estimate or the time estimate changes.

Two things break the comparison. The first is the tail: a drain is total and immediate, while the time cost is spread evenly and quietly, so the two feel nothing alike on the day. The second is that the estimate of a one-in-twenty year is a guess, and people systematically underestimate it after a quiet year. If the true rate were one in five, the expected loss becomes $180 and the gap narrows sharply.

Size the hot wallet to the amount you would still be calm about the morning after, then keep the rest where a single mistake cannot reach it.

What changes how much to keep in hot wallet

The number moves for reasons that have little to do with price, and reviewing it on a schedule beats reviewing it after an incident.

How often you actually transact

Someone paying for things weekly needs a larger float than someone who moves funds twice a quarter. Track a month of real activity before setting the number, because remembered habits are usually busier than actual ones.

What the wallet is connected to

A wallet that only sends to addresses you have saved has a smaller attack surface than one that approves contracts on new sites every week. The second kind should hold less, and should be a separate wallet from the first kind rather than the same one used for both.

How fast you can top up

If replenishing means a two-day transfer from cold storage, the hot balance needs more headroom. If it means a card purchase or an incoming payment, less. Speed of replenishment is the reason the burn-rate method uses days rather than a fixed amount.

The post Hot Wallet Limits: How Much Is Too Much appeared first on FogChain.

Most losses attributed to an exchange API key do not come from a sophisticated break of the venue’s security. They come from a key that was too powerful for its job and was then copied somewhere it should not have been. Permissions and storage decide the damage; the incident is usually just the trigger.

• Grant the smallest permission set that makes the strategy work, and never enable withdrawals on a trading key.
• Use IP allowlisting where the venue supports it; it turns a stolen key into a useless string.
• One key per service, so revocation is surgical and usage is attributable.
• Assume any key pasted into a chat, screenshot or repository is already compromised.

What permissions an exchange API key can carry

Most venues expose a small menu: read, spot trade, futures trade, transfer, withdraw. Each one is a separate risk decision, and they are rarely independent in practice.

Read is often treated as harmless. It is not. Read access exposes balances, positions, order history and sometimes deposit addresses and account identifiers. That is a map of your account, useful to anyone planning a social-engineering approach or tracking how much you hold. Treat read as sensitive, just less immediately destructive than trade.

Trade permission is not one permission

Trade access lets software place, amend and cancel orders. On venues with derivatives, it can also change leverage and margin mode, which changes how quickly a position can be liquidated without any further trade being placed.

That is why leverage and margin settings deserve their own attention. A key that cannot withdraw but can set leverage to the maximum is still a key that can lose the account. Some venues let you restrict this; check whether yours does.

Withdrawal and transfer are the ones that end accounts

Withdrawal permission moves assets off the venue. Transfer permission moves them between accounts, including to an address you do not control if the venue allows internal transfers by key.

Neither is needed for trading. Automated strategies need to trade, read balances, and occasionally check status. They do not need to withdraw. If a workflow genuinely requires automated withdrawals, the correct pattern is a separate key used by a separate process with its own allowlist, not a broader permission on the trading key.

Designing an exchange API key policy that limits damage

Good policy answers one question: if this key leaks right now, what is the worst that can happen before I revoke it?

If the answer is “it can trade my whole balance at maximum leverage”, the key is over-scoped regardless of how careful you are with storage. If the answer is “it can place orders up to a fixed notional on one sub-account and nothing else”, the leak is survivable.

A key is a promise about what software may do. Every extra permission is a promise you made to a program that cannot read the context you had in mind.

Where exchange API key secrets leak in practice

They leak through ordinary engineering habits, not exotic attacks: a repository that was public for twenty minutes, a screenshot in a support ticket, a log line that printed the request headers, a shared laptop, an old CI variable nobody rotated.

Three habits remove most of this. Keep secrets out of source control entirely and use environment variables or a secret manager. Never print request headers, even at debug level, and scrub them from error reports. Assume anything visible on a screen may end up in an image someone else sees.

Storage rules that survive a mistake

Store keys where the process can read them and nowhere else. On a server, that means file permissions restricted to the service user, not a world-readable config file. On a workstation, that means an encrypted store, not a note-taking app.

Rotation is the other half. A key you have never rotated is a key whose exposure window is unbounded. Rotate on a schedule, and rotate immediately after any staff change, any laptop loss, and any moment you are unsure. Rotation should be boring enough that you actually do it.

Detection: noticing before the balance is gone

Most venues let you see last-used timestamps and, on some, IP addresses per key. Check them. A trading key that last authenticated from a region you have never operated in is an incident, not a curiosity.

Set alerts on the things that indicate misuse: order rate spikes, cancellations you did not send, position changes outside your strategy’s normal pattern, and failed authentication attempts. Alerting on your own balance is the last resort, not the first.

Operating keys day to day

1. Create one key per service, named for the service, so usage is attributable at a glance.
2. Select only read and the specific trade permission the strategy uses; leave withdrawal and transfer off.
3. Apply an IP allowlist if the venue supports it, and keep it current when infrastructure changes.
4. Store the secret in a secret manager or environment variable, never in the repository.
5. Set a notional cap in your own code as well as any venue-side limit, so a bug cannot spend the balance.
6. Record creation date and owner, and rotate on a fixed schedule or after any suspected exposure.
7. Revoke rather than disable when a key is retired, and confirm it no longer authenticates.

A worked check on exposure: a strategy with 4,000 units of collateral and a 2x leverage cap can lose at most 4,000 if positions are liquidated, but a leaked key that can raise leverage to 20x changes the ceiling entirely. Permission scope, not collateral, sets the real maximum loss.

Incident response when a key is exposed

Revoke first, investigate second. A key that is still valid while you read logs is still trading.

Then work outward: check orders and transfers in the exposure window, confirm whether IP restrictions were active, and rotate any other secret that shared the same storage or the same pipeline variable. Secrets have a habit of travelling in groups.

Finally, change the process that allowed the exposure. An incident that ends with a revocation and no process change will recur, usually within the same quarter, because the habit that caused it is still in place.

The post API Keys: Permissions and Leaks appeared first on FogChain.