Spot trading bot: where the logic breaks and why trades get lost
A spot trading bot breaks not where people usually look for the problem.
The strategy can be mathematically correct, but trades get lost at the junction with the exchange: between the moment a signal is calculated and the moment it is actually executed, tens of milliseconds pass, during which the order book has time to rebuild.
It is precisely in this gap that price slippage occurs — the bot sends an order at one quote, but it fills at another, and over a series of hundreds of trades the discrepancy eats up the entire projected profitability of the strategy.
The second class of failures is order book desynchronization. The bot keeps a local copy of the order book and updates it with the exchange's data stream, but when the connection drops or a packet is missed, the copy diverges from reality.
The bot continues to believe that liquidity exists at the required level, sends an order — and gets a partial fill or a rejection. Worse is when the desynchronization goes unnoticed: the logic operates on stale data and makes decisions that are unprofitable in the real market.
The third failure is stuck orders. An order was sent to the exchange, but no confirmation came back: the network hung, the exchange responded with a timeout, the connection broke mid-response.
The bot does not know whether the trade executed, and either duplicates the order or loses track of the position. Without reconciling state with the exchange for every order, such "phantoms" accumulate and distort position accounting.
A separate category is rejections under peak load. During sharp market moves, the exchange throttles the request rate and returns rate-limit errors, while response delays grow severalfold.
A bot not designed for this either floods the exchange with requests and gets blocked, or freezes while waiting and misses the entry window.
Let's break down how this is addressed: idempotent orders with unique identifiers, periodic reconciliation of positions with the exchange, slippage control before sending, and a request queue that accounts for rate limits.
What a Properly Designed Bot Delivers: Measurable Effects
A spot trading bot designed for the task changes not "convenience" but measurable trading characteristics: the share of executed orders, reaction time to a market event, and the class of failures the system survives without manual intervention.
Below are five areas where these metrics shift after reworking the execution core and the resilience layer.
Share of Executed Trades
The logic of placing and re-placing orders is built around the real order book, not around an ideal price from a calculation. The bot accounts for partial fills, recalculates the remainder, and does not leave "hanging" orders that distort the position.
In practice, the share of trades carried through to completion grows, and the discrepancy between planned and actual entry price shrinks.
Bot Reaction Time
Market data processing and order dispatch are separated by priority: the critical path does not wait for logging, analytics, or database writes. Reaction to a price change or a fill becomes predictable — without spikes during moments of high activity. This directly affects whether the bot manages to enter at the price it saw.
Failure Classes and Their Handling
We separate failures by nature: exchange interface failure, network timeout, rejected order, desynchronization of local state with the exchange state. Each class has its own scenario: retry with delay, cancel and re-place, position reconciliation. The portion of failures that previously halted trading is now extinguished automatically.
Resilience Under Load
As the number of instruments and event frequency grow, the bot does not degrade: queues do not grow indefinitely, resource consumption stays within a corridor, and latencies do not sprawl. We verify this with load runs on historical and synthetic streams, not only in a calm market.
Trading Stability
The result is predictable strategy behavior: identical market conditions produce a comparable outcome, rather than depending on how luckily the launch moment coincided. We work on professional infrastructure, so the client gets a stable result, not one-off lucky sessions.
Spot bot operating modes: comparison of approaches and limitations
The choice of mode determines not only profitability, but also the class of risks the bot will deal with every day. Below are four basic approaches that most often form the foundation of a spot bot, and their real-world limits of applicability.
| Option | When it fits | Limitations |
|---|---|---|
| Market making | Liquid pairs with a narrow spread, a stable flow of trades | Requires fast execution and position control; during a sharp trend, accumulated inventory goes negative, and fees eat into the margin |
| Arbitrage strategy | Price divergence between exchanges or pairs, high trade frequency | Sensitive to execution latency and order book depth; the opportunity window closes within seconds, and some trades fail to go through |
| Trailing order | Trending segments, managing an already open position | Does not work in flat markets: the stop trails the price and gets knocked out on a pullback; requires careful step configuration |
| Grid bot | Sideways market with a pronounced range, volatile pairs | When the price moves beyond the grid boundaries, the position gets stuck; in a trend it accumulates losses instead of profit |
How the mode is chosen
In practice, the mode is selected to match the character of the pair and the position holding horizon. Market making and arbitrage live on seconds and require low latency to the exchange, while grid and trailing order live on minutes and hours and forgive more.
Mixing them in a single bot without separate position accounting and limits is risky: the strategies start to interfere with each other.
What is important to build in advance
Any of the options runs into the same limitations: exchange rate limits on request frequency, fees, slippage, and behavior when the connection drops. That is why hard exit rules, maximum position control, and correct state recovery after a restart are built into the bot.
Describe your pair and your task — we will come back with an assessment and a plan for a suitable mode.
How we implement a bot: stages of engineering work
We start with an audit of the trading logic: we break down which signals you use, on which timeframes, how you calculate position size, and what you do during a drawdown.
The output is a formalized description of the strategy where every rule is unambiguous: no "if the market looks weak" and no manual caveats that cannot be reproduced in code.
Next, we design the bot as a set of independent modules — data source, signal calculation, order management, risk control, and trade log. This separation allows you to change the entry logic without rewriting execution, and vice versa.
We separately define behavior during a connection loss and partial order execution — these are the scenarios that most often break naive implementations.
- Audit of the trading logic. We gather the strategy rules, compare them with actual trades, and find discrepancies between how you trade and how it is described in words.
- Bot design. We define the modules, data flows, state storage format, and failure points; we agree on the scheme before any code is written.
- Setting up exchange connections. Keys with restricted permissions (trading without withdrawal), request limits, reconnect, time and balance synchronization after every restart.
- Implementation of the trading core. Signal calculation, placing and managing orders, handling partial fills and cancellations.
- Backtesting. Running on historical data taking commissions and slippage into account, then testing on the exchange's test environment without real funds.
- Launch in restricted mode. Starting with the minimum position size, reconciling actual trades with calculated ones, monitoring discrepancies.
- Handover of the solution. Access credentials, configurations, instructions for starting and stopping, review of typical failures — so that the team can maintain the bot independently.
Backtesting cuts off strategies that look good on a chart but fall apart on commissions and slippage. The handover of the solution includes not only the code but also a clear procedure: how to stop the bot, how to update parameters, and what to do if the balance diverges.
What the client receives: configurations, diagrams, regulations
The project is closed out not with a "working bot on a server," but with a package your team can use to operate it, change parameters, and hand it over for maintenance. Below is exactly what goes to the client.
- Bot configuration — parameter files for each trading instrument: order size, price step, position and daily turnover limits, order placement mode. Edits are made without rebuilding the code, and values are validated at startup.
- Order flow diagram — from receiving market data to trade confirmation: where an order is placed, how partial execution is handled, what happens when the exchange rejects it, and how a stuck order is canceled.
- API access policies — which permissions are granted to the key, what is prohibited (withdrawing funds), where secrets are stored, how key rotation is performed, and who has access to the environment.
- Documentation — strategy description, entry and exit logic, list of external dependencies, instructions for local launch, and breakdown of typical errors.
- Operations regulations — startup and shutdown procedures, limit monitoring, response to a connection loss with the exchange, and points for taking state backups.
- Set of checks — tests for volume calculation, rejection handling, and order resubmission, so that parameter changes do not break the logic.
- Deployment diagram — environments, monitoring of key metrics, alerts on limit triggers and emergency shutdown.
The package is handed over with a walkthrough: an engineer guides your team through each artifact and answers questions about the code. After that, you either run the bot yourselves or hand it over for maintenance — without contacting us for every parameter change.
Case study: how we eliminated stuck orders and increased the fill rate
The client is a team trading spot on several exchanges through their own bot. Orders were being placed, but some would "get stuck": the price moved away, the order remained in the order book and turned into an unplanned position.
During peak movements, the bot reacted with a delay, and when the number of orders spiked sharply, some requests to the exchange interface timed out and were lost without a retry.
What it was before
The share of stuck orders reached 18% of those placed per shift — they had to be canceled manually.
The reaction time to price changes in a calm market stayed around one second, and under peak load it grew severalfold: while the bot recalculated the conditions, the price moved several ticks away.
Execution tracking was done via logs and did not reconcile with exchange reports, so no one saw the real fill rate.
What we changed
We rewrote the order handling cycle: the state of each order is stored separately from the calculation logic, and reconciliation with the exchange runs as a stream of events rather than polling on a timer.
We added idempotent request retries — if the connection drops, the order is neither duplicated nor lost, but brought to a known state.
The order queue received priorities and a limit on the number of simultaneous calls to the exchange, so that the peak flow would not overwhelm the connections. Separately, we built a metrics dashboard: fill rate, number of stuck orders, reaction time, queue depth.
What it became
The share of stuck orders dropped from 18% to 1-2% — the bot cancels them itself based on a staleness condition. The reaction time to price changes was reduced to tenths of a second and barely grows under peak load: the queue maintains order instead of dumping everything at once.
Reconciliation with the exchange matches down to the last trade, so the fill rate is calculated based on actual results, not logs.
The stack and reconciliation logic were selected for the client's specific exchanges — we worked with their interfaces and limits directly.
How a spot bot differs from a futures bot and what to consider when migrating
A spot bot and a futures bot differ not by a couple of configuration parameters, but by the risk model itself.
On spot, you buy the asset with your own funds: the position cannot go negative, and the worst-case scenario is that the asset's value has dropped while the amount in coins remains the same.
On futures, the position is opened with leverage, and the exchange holds collateral — margin. As soon as the loss on the position eats into that support, liquidation triggers: the exchange force-closes the position and writes off the collateral.
A bot that on spot would simply "wait out" a drawdown loses the deposit in minutes on futures.
Hence the second difference — margin calculation. A futures bot must calculate maintenance margin in real time, monitor the liquidation price, and either top up the collateral or reduce the position.
A spot bot does not need this at all: it has no obligations to the exchange, only a balance and open orders.
If you port the logic "as is" — the same signals, the same position sizes — the futures setup inherits a risk that was not in the original code: the position size is multiplied by leverage, and a stop-loss calculated from the spot volume ends up far beyond the liquidation boundary.
The third difference is execution mechanics. On spot, the bot works with a real asset: orders are limited by the balance, partial fills are predictable, and the fee is charged on turnover.
On futures, funding is added — periodic payments between longs and shorts — as well as margin modes (isolated and cross). With isolated margin, risk is limited to a single position; with cross margin, a loss on one position pulls in the entire account's collateral. Capital management logic has to be rewritten separately for each mode.
When porting logic from spot to futures, four layers change: position sizing (accounting for leverage and allowable drawdown), the margin and liquidation control block, the handling of funding payments, and the failure model — instead of "the order didn't go through," you get "the position was liquidated." The reverse migration is simpler: by removing leverage, you get a conservative setup, but you lose some strategies that simply do not work on spot.
That is why we first pin down which signals and assumptions are baked into the current bot, and only then decide what carries over as is and what is designed anew.
Technical concerns: answering frequently asked questions
Before going live, clients ask the same questions — about reliability, keys, behavior during exchange failures, testing, and support. Below are direct answers without marketing, so you understand exactly how a spot trading bot behaves in real operation.
How reliable is the bot during exchange failures?
We build in handling of connection drops and API errors from the very start: retries with increasing backoff, idempotent order identifiers, reconciliation of the actual position state with the local state after every reconnection.
If the exchange returns an error or delays a response, the bot doesn't go "blind" — it switches to a safe mode and restores the picture from exchange data.
How are exchange access keys stored?
Private keys never end up in code or logs. They reside in an isolated secrets vault, accessible only to the bot process, and on the exchange side you set minimal permissions for the key — trading without withdrawal. Additionally, we restrict access by an address whitelist and rotate keys according to policy.
What happens during a connection drop or exchange outage?
The bot detects that the venue is unavailable and doesn't blindly send new orders. Open orders are tracked, state is reconciled once connectivity is restored, and discrepancies are logged. This eliminates "phantom" positions and duplicate trades.
How do you test a strategy before real money?
First a run on historical data, then on the exchange's test environment with real quote streams but no funds. Separately, we check behavior under failures: connection drops, rejected orders, rate limits. Only after that does the bot go to a live account with a limited volume.
What does post-launch support include?
We monitor metrics, investigate incidents, and update the logic to match changes in exchange rules.
You receive operation logs, failure alerts, and a clear escalation procedure — if behavior deviates from expectations, the bot can be quickly stopped and the configuration rolled back.
If you still have questions about your task — describe your trading scenario and risk requirements, and we'll come back with an estimate and a plan.
Let's discuss your task and come back with an estimate and a plan
To come back with an estimate and a work plan, rather than generalities, we need a minimum of input from you. The initial review takes one conversation: we examine the task in substance and immediately say where we see risks and where there is a standard solution. The more specific the input, the more accurate the estimate of timelines and scope.
What we need from the client at the start:
- Exchange and trading mode: spot, specific pairs, API and rate limit restrictions.
- Strategy logic: entry and exit signals, volume handling, averaging and stop rules.
- Risk requirements: maximum drawdown, position limits, behavior on connection loss.
- Access and environment: the exchange's test environment where the strategy can be run without real trades.
- Reporting: which metrics and logs are needed, where to store them, who reviews them.
- Timeline constraints and what already exists — prior work, scripts, the previous contractor.
Based on the review, we assemble a work plan: bot architecture, exchange connection scheme, strategy module, risk-control layer, logging and monitoring, the order of tests and going live.
In the plan we fix the stages, what we check at each one, and by what criteria we consider it ready.
The next steps are simple: you describe the task in free form, we ask clarifying questions and come back with an estimate and a work plan. Describe the task — we'll come back with an estimate and a plan.