A protective stop on a perpetual futures position did not trigger during a sharp wick that clearly crossed the stop on the last-price chart. The order was set to trigger on mark price, which moved much less. We now choose the trigger price type explicitly per order and test both behaviours.
Our quoting bot stayed far below request weight limits and still got -1015 Too many new orders at the worst moments. Order placement has its own per-account count limits, and our cancel-and-replace loop doubled order churn when prices moved fast. An order rate limiter and order amendment fixed it.
A new bot received order updates for one hour after start, then nothing, while the websocket stayed connected. The listenKey expires after 60 minutes without a keepalive. We fixed keepalives and expiry handling, then moved to the WebSocket API subscription before listenKey retirement.
Our perpetual futures bot reported a monthly PnL 6 percent higher than the exchange's account history. It ignored trading fees on some fills, never recorded funding payments, and valued open positions at last trade price instead of mark price. Building PnL from the income ledger fixed it.
During a volatile minute, our place-order request timed out and the bot retried. Both requests reached the exchange, and we held twice the intended position. A timeout does not mean the order failed. Client order ids, query-before-retry and an unknown state fixed it.
Our bot believed two orders were still open when they had filled hours earlier. The exchange closes websocket connections after 24 hours; our reconnect logic resubscribed but never checked what happened while disconnected. Reconnect with backoff plus REST reconciliation fixed the state drift.
An exchange API key with withdrawal rights on a bot host is a hot wallet with extra steps. This guide covers the controls we use for trading bot keys: least-privilege permissions, IP allowlists, sub-accounts, secret storage, rotation, logging without leaking signatures, and incident response.
Our monitoring service polled depth and klines for 40 symbols every two seconds. During a volatile hour it hit 429 Too much request weight, kept retrying, and earned an HTTP 418 IP ban that also blocked our trading bot on the same IP. Weight-aware limiting and websockets fixed it.
A grid trading bot written in TypeScript sent quantities like 0.30000000000000004 and got error -1111. Binary floating point cannot represent most decimal fractions, and serialising numbers to strings exposed it. A decimal library end to end and string serialisation fixed it.
Our local copy of the BTCUSDT order book slowly diverged from the exchange: crossed books, levels that never disappeared, and a best bid above the best ask. We applied depth diffs without buffering, skipped the snapshot alignment rules and never detected gaps. Following the sync procedure fixed it.
Our rebalancing bot computed order sizes as fractions of a portfolio and about one order in five was rejected with Filter failure: LOT_SIZE or PRICE_FILTER. Quantities and prices must sit on each symbol's step and tick grid. Reading exchangeInfo filters and rounding with Decimal fixed it.
Our trading bot's signed requests started failing with error -1021 a few times an hour, then constantly. The VM's clock had drifted almost two seconds because time sync was not running. Fixing NTP, measuring the offset against server time and handling -1021 explicitly ended it.