Production pitfalls

3 notes, read out of this brain and free to use. Each one was extracted from a source and is re-checked against its exam.

My bot got IP-banned after an outage — how do I avoid retry storms?

Classic failure: exchange API blips, every strategy instance retries instantly in a tight loop, the IP hits 429 then 418, and now you are banned for hours-to-days DURING the volatility you wanted to trade. Prevention: one shared throttled HTTP client per process (all strategies draw from the same budget); exponential backoff with full jitter on every 429/5xx; a circuit breaker on 418 that halts trading and pages you; and bounded concurrency for order placement. After recovery, expect a flood of stale state — reconcile via REST before resuming order flow, and assume every in-flight order's outcome is unknown until queried. Log ban events with headers (`Retry-After`, used-weight) so you can tune budgets from evidence, not guesses.

Why is my balance slightly less than my accounting says (dust and BNB fees)?

Spot fees are taken per fill, often in the received asset or in BNB: net received quantity is less than `executedQty`, so position sizing off gross quantities drifts over hundreds of trades. The BNB fee discount (as of early 2026, roughly 25% on spot — verify the current rate) silently consumes your BNB balance; when BNB runs out, fees flip back to the traded asset and your cost model changes mid-flight — alert on low BNB. Leftover dust (balances below `minNotional`) cannot be sold on the book; sweep periodically via small-asset conversion (convert dust to BNB) or book it as a cost. Futures fees are simpler (quote currency per fill) but funding payments hit the wallet balance and therefore move your liquidation price — another quiet drift to account for.

What production traps hide in markets cache, testnet, keys, and withdrawals?

Markets: refresh `loadMarkets`/`exchangeInfo` on a schedule and on -1013/BadSymbol errors — delisted pairs and changed tick sizes break stale caches at the worst time. Testnet ≠ prod: thin books, generous fills, sometimes different limits and features; validate plumbing on testnet, then re-validate sizing with minimum live orders. Keys: env vars or a secret manager, never in the repo or logs; trade-only permissions (disable withdrawals), IP whitelist on, separate keys per bot so one compromise does not drain everything. Withdrawals: API withdrawal needs explicit permission, and new addresses may require a whitelist with a holding delay — never design a strategy that depends on instant withdrawals. Finally: clock drift and filter changes are the two 'worked yesterday' causes — monitor both before blaming the exchange.

Give your agent this brain