Exchange APIs, order management, market data and backtesting bugs in trading systems.
We built an internal assistant that researches crypto markets and drafts a briefing for analysts, using a planner and specialised sub-agents. The lessons: isolating sub-agent context, a file scratchpad instead of one huge conversation, cost and tool caps, and evals. It does research, never trading.
Our order manager occasionally raised KeyError: unknown order when a fill event arrived on the websocket before the REST place-order call returned. It keyed orders by exchange order id, which it only learned from the REST response. Keying by client order id and buffering unknown events fixed it.
Automated trading fails fast: a bug can place hundreds of orders before a human notices. This guide covers the monitoring and stopping mechanisms we run for every bot: heartbeats, position and loss limits, cancel-all on disconnect, a tested kill switch, and runbooks for the first five minutes.
After a configuration refactor, a bot meant for the testnet connected to the production exchange with test parameters: order sizes ten times larger than production limits. A risk check caught it after four orders. This postmortem covers how environment selection failed and the guardrails we added.
Our settlement bot sends several transactions per minute from one address. After we parallelised it, sends failed with nonce too low and replacement transaction underpriced, and some transactions sat stuck for hours. A single nonce manager per address and correct fee bumping fixed it.
Our treasury rebalancing service swapped on a DEX and about a quarter of swaps reverted on volatile days with Too little received, wasting gas. Quotes were computed seconds before submission and transactions waited in the mempool. Fresh quotes, simulation and a deadline fixed it without loosening slippage.
A trading system that cannot explain its balances to the cent will eventually make decisions on wrong numbers. This guide shows how we keep an internal double-entry ledger for trades, fees, funding and transfers, reconcile it with exchange balances, and handle the differences we find.
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.
Most trading bot failures we have seen are not strategy bugs; they are state bugs: lost fills, duplicate orders, wrong positions after a restart. This guide describes an architecture that keeps state correct: separated components, an order state machine, persistence, risk checks and reconciliation.
Paper trading usually fills every order instantly at the price you asked for. Real markets do not: there is slippage, partial fills, queue position, fees, latency and market impact. This guide explains each gap, how to measure it from live data and how to model it in simulation.
Our daily signals disagreed with the exchange chart, and intraday signals appeared and disappeared within the same bar. We resampled UTC millisecond timestamps in local time and included the still-forming last candle. UTC everywhere and using only closed candles fixed both problems.
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.
A hedging bot meant to short perpetual futures placed spot sell orders instead, selling inventory it was supposed to hedge. In ccxt's unified symbols, BTC/USDT is spot and BTC/USDT:USDT is the linear perpetual. Explicit market types and assertions on market metadata 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.
Our order router ran fine as one process. When we scaled to two workers, a third of private API calls failed with EAPI:Invalid nonce. Kraken requires an increasing nonce per API key, and two processes generating millisecond timestamps raced each other. One key per worker fixed it.
A moving-average strategy showed strong backtest returns and nothing like it in paper trading. The backtest computed the signal from a candle's close and filled the order at that same close, a price nobody could trade at once the signal was known. Shifting signals to the next bar fixed the simulation.
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.