The point of an exchange sub-account is containment. If one strategy blows up, the loss stays inside the container instead of reaching the balance that funds everything else. The mechanics are simple, but the details vary by venue, and the differences matter more than the marketing suggests.

• Sub-accounts separate margin and positions, but not always the custody risk of the venue itself.
• Most venues let you scope API keys per sub-account, which limits the blast radius of a leak.
• Transfers between sub-accounts are usually internal and free, unlike withdrawals to an external chain.
• Segmentation fails if the master account keeps withdrawal rights or shared collateral enabled.

What an exchange sub-account actually isolates

It isolates margin, positions, order history and permissions. It does not isolate counterparty risk. Funds on the same venue share the same custodian, the same operational failures and the same withdrawal queue.

That distinction should drive how you use them. Sub-accounts are excellent at stopping one strategy from liquidating another. They are useless against the venue itself freezing withdrawals, and they do not protect you if the entity holding the assets fails. For that risk you need a different venue, not a different sub-account.

The four things that are separated

Balance, margin, positions and API credentials are what typically move into a sub-account. Each one has its own consequences.

• Balance — the collateral available to that container only. A loss elsewhere cannot touch it, and vice versa.
• Margin — leverage is calculated per account, so a heavily used strategy does not consume the borrowing capacity of a conservative one.
• Positions — netting happens within the container. Two opposing positions in different sub-accounts stay open instead of offsetting.
• API credentials — keys issued to a sub-account normally cannot read or trade the master account, which is the single most useful property.

What stays shared

KYC identity, fee tier treatment, deposit addresses, and the legal relationship with the venue usually remain at master level. Some venues aggregate volume across sub-accounts for fee tiers; others do not. Some allow internal transfers instantly; others batch them.

Check three settings before you rely on the structure: whether the master can withdraw from sub-accounts without approval, whether negative balances in one sub-account can be covered from another, and whether margin is shared by default. Any of these enabled quietly defeats the purpose.

Why separating risk with an exchange sub-account pays off

Because the most common account failure is not theft — it is one strategy consuming the collateral that another strategy needed.

Consider a funding-rate position that is correctly hedged but temporarily underwater, running in the same account as a directional position with a tight stop. The hedge needs margin to stay open. The directional trade’s losses reduce available margin. The venue liquidates whichever position is closest to the line, which may be the hedge you intended to keep. Two sub-accounts make that interaction impossible.

Operational separation beats mental separation

Keeping strategies apart “in a spreadsheet” is not separation. If they share one balance, one liquidation engine treats them as one portfolio. The engine does not care about your labels.

This is also why sub-accounts matter for automation. A bot with a key that can only touch its own container cannot drain the rest of your account through a bug, a bad config, or a compromised API secret. That is a real limit, not a theoretical one.

How sub-account models compare

Models differ in where the boundary sits, and the differences change what you can safely automate.

Segmentation is only real when the failure of one container cannot reach the collateral of another. Everything else is bookkeeping.

Setting one up without creating new failure modes

Setup takes minutes, and the ordering matters more than the clicks.

1. Decide the boundary first: one sub-account per strategy, per client, or per risk budget. Mixed boundaries produce containers nobody can reconcile.
2. Create the sub-account and fund it with only the collateral that strategy needs, not a round-share of your total.
3. Disable master-level withdrawal rights over the sub-account if the venue allows it, or remove withdrawal permission from every key.
4. Issue a fresh API key scoped to that sub-account, with IP allowlisting where available and no withdrawal permission.
5. Set a notional cap in your own code as well, because venue-side limits are the second line of defence, not the first.
6. Record which key belongs to which container in one place, and test the separation with a small deliberate transfer.
7. Review monthly: dormant sub-accounts accumulate balance and become an unmonitored attack surface.

A simple allocation example

Suppose 10,000 units of quote currency are split three ways: 5,000 for a spot core position, 3,000 for a hedged basis trade, 2,000 for a high-turnover experimental strategy. If the experimental container loses its entire 2,000, the other two are untouched, because the liquidation engine never saw them. In a single account, that same loss would have reduced shared margin by 20 percent and could have forced a partial unwind of the hedge at the worst moment.

The arithmetic is the argument. Containment converts an unbounded portfolio event into a bounded, pre-agreed loss.

Mistakes that quietly undo the separation

Most failures come from configuration drift rather than from the model itself.

• Shared collateral switched on for convenience, which links every container again.
• One master key reused across bots, so a single leak reaches everything.
• Sub-accounts used as a filing cabinet, with balances left idle in containers nobody watches.
• Withdrawal permission granted to a trading key “just in case”, which turns a trading bug into a full loss.

Each of these is reversible, and each is worth checking before the next deposit rather than after the next incident.

Reconciliation is the other quiet failure. Once balances live in several containers, your total exposure is no longer visible on one screen, and a position you believe is hedged may be hedged in a container that no longer holds enough collateral. Export balances on a fixed schedule and add them up yourself.

The post Sub-Accounts: Separating Risk appeared first on FogChain.

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.