Three Exchanges, 7 Bugs, One Year of Lessons
For the past year I have run live trading bots simultaneously on Binance Futures, Bybit USDT-M perpetuals, and Bitget USDT-FUTURES. Three exchanges, three different APIs, three slightly different mental models of what an order even is. The strategies were similar across all three. The execution layers were not. Roughly eighty percent of the work translated cleanly between venues. The remaining twenty percent is where every meaningful production bug lives, and that twenty percent is what this post is about. Building a multi exchange trading bot in Python is not just about writing three API integrations and combining them.
Seven bugs. Each one cost me real capital, real sleep, or both. None of them appear in any official documentation in the form they actually present in production. All seven were debugged on live accounts during live market hours, which is an expensive way to learn but the only way that produces durable understanding. The list, in the order I encountered them: a Binance minimum notional rejection that masqueraded as an insufficient balance error, a Binance leftover order problem that broke every subsequent entry, a Bybit V5 migration that rejected every order with a generic “invalid order type” message, a Bybit symbol format mismatch that returned empty positions for live trades, a Bybit position reversal pattern that bled equity in low-volatility regimes, a Bitget margin coin error that no amount of credential rechecking would solve, and a class of cross-cutting infrastructure bugs around timestamps, idempotency, and rate limits that hit all three exchanges in slightly different ways.
This post is the post-mortem. If you are running, or planning to run, automated execution across multiple exchanges, the seven failure modes documented here will save you most of what I had to learn the hard way. The webhook receiver from my previous piece on TradingView integration is the front door of this architecture. What follows is what happens behind that door, and where it breaks.
Why a Unified Execution Module Beats Three Separate Bots
The intuitive first approach to a multi exchange trading bot is to write three separate bots. One for Binance, one for Bybit, one for Bitget. Each bot has its own connection logic, its own order placement, its own position tracking. This is what most tutorials show, and it works fine for one exchange. It collapses under its own weight at three.
The structural problem is that strategy logic and execution logic are completely different concerns, but the three-bot pattern fuses them. When I wanted to change a stop-loss calculation, I had to change it in three codebases. When an exchange released a breaking API update, I had to debug the same logical bug three times in three slightly different contexts. The cognitive load was not three times higher. It was closer to nine times higher, because the bugs in each codebase interacted with each other through shared state in ways that were impossible to reason about cleanly.
The structurally correct answer is a unified execution module that exposes a single interface to the strategy layer and absorbs the per-exchange differences internally. CCXT gets you about eighty percent of the way there with its unified API surface, but the remaining twenty percent is the difference between a bot that runs and one that fails silently in production. That twenty percent is where the seven bugs in this post live.
The architecture I converged on after a year of debugging consists of seven small classes, each with a single clear responsibility. The ExchangeRouter manages CCXT instances and routes calls to the correct exchange. The OrderRouter normalizes symbols, categories, and margin coin parameters across the three venues. The RiskGuard performs pre-trade validation including minimum notional, available margin, and leverage caps. The RetryPolicy handles transient errors with exponential backoff. The IdempotencyManager generates and tracks client order IDs to prevent duplicate fills. The RateLimiter respects each exchange’s weight system. The BalanceReconciler refreshes account state after position changes to prevent stale-balance bugs. None of these classes are large. The total code size is under fifteen hundred lines. The organizational discipline is what makes the difference, not the volume.
Binance Bug One: The Phantom Insufficient Balance Error
The first Binance bug I hit was the most confusing because the error message lied to me. I was running a small-account bot with about three hundred dollars of trading equity, placing TP and SL orders sized to match the underlying position. Every entry succeeded. Every protective order failed with what looked like an insufficient balance error. My first day was spent verifying the account had the balance I expected. It did. My second day was spent reading the CCXT source for clues. None.
The actual error, when I finally captured the raw API response, was Binance error code -4164: “Order’s notional must be no smaller than 100.” Binance Futures enforces a one hundred USDT minimum notional value on every order. Not just opening orders. Every order, including reduceOnly TP and SL orders attached to existing positions. With a three hundred dollar account placing partial-size protective orders, the notional was falling under one hundred USDT and Binance was rejecting them silently to my code, loudly to its own logs.
The fix has two parts. First, the RiskGuard rejects any planned order whose notional would fall below the minimum, before it ever reaches the API. Second, when placing reduceOnly orders, the size must be the full position size, not a partial protective slice. The relevant snippet:
from typing import Optional
import logging
logger = logging.getLogger("nql.execution.binance")
BINANCE_MIN_NOTIONAL_USDT = 100.0
def validate_binance_order(
symbol: str,
side: str,
quantity: float,
price: float,
reduce_only: bool = False,
) -> Optional[str]:
notional = quantity * price
if notional < BINANCE_MIN_NOTIONAL_USDT:
return (
f"binance min notional violation: notional={notional:.2f} "
f"required={BINANCE_MIN_NOTIONAL_USDT} symbol={symbol}"
)
if reduce_only and quantity <= 0:
return f"reduce-only order requires positive quantity: {quantity}"
return None
async def place_binance_order(
exchange,
symbol: str,
side: str,
quantity: float,
price: float,
order_type: str = "MARKET",
reduce_only: bool = False,
) -> dict:
error = validate_binance_order(symbol, side, quantity, price, reduce_only)
if error:
logger.warning("rejected_pre_validation %s", error)
raise ValueError(error)
params = {"reduceOnly": reduce_only} if reduce_only else {}
order = await exchange.create_order(
symbol=symbol,
type=order_type,
side=side,
amount=quantity,
price=price if order_type != "MARKET" else None,
params=params,
)
logger.info("binance_order_placed id=%s symbol=%s side=%s qty=%.6f",
order.get("id"), symbol, side, quantity)
return orderThe lesson is broader than this specific bug. Exchange minimum notional rules are enforced server-side and the error messages are often unhelpful. The RiskGuard pattern, where every planned order passes through a deterministic pre-trade validation that mirrors the exchange’s own rules, is the only way to surface these issues at the application layer where they can be reasoned about and fixed cleanly.
Most of the Binance debugging in this post comes from my live V3 bot. If you are setting up a new Binance Futures account, my Binance referral link applies the standard fee discount to new signups. Disclosure: this is a referral link and I receive a commission at no cost to you.
Binance Bug Two: The Leftover Order Problem
The second Binance bug took longer to find because it was intermittent. Some entries worked perfectly. Some failed with cryptic order placement errors. The pattern emerged only after I correlated it with prior trade history: every failure occurred on a symbol where a previous SL or TP had triggered.
The root cause is that Binance Futures does not natively support OCO order pairs. When you place a TP and an SL on a position, they are independent conditional orders. When one of them fires and closes the position, the other one is not automatically cancelled. It remains live in the order book, sized to the now-zero position. The next time your bot tries to enter on that symbol, the leftover order can interfere with the new entry in subtle ways including position-side mismatches, reduceOnly conflicts, and incorrect leverage state.
The fix is a defensive double-cleanup pattern. After every candle close where the bot detects a closed position, it sweeps the open orders for that symbol and cancels any conditional orders. Just before any new entry, it sweeps again as a paranoia check. The double cleanup costs almost nothing in API calls and eliminates an entire class of bugs.
async def clean_leftover_orders(
exchange,
symbol: str,
aggressive: bool = False,
) -> int:
try:
open_orders = await exchange.fetch_open_orders(symbol)
except Exception as exc:
logger.warning("fetch_open_orders failed symbol=%s err=%s", symbol, exc)
if aggressive:
return 0
raise
cancelled_count = 0
for order in open_orders:
order_type = (order.get("type") or "").upper()
if order_type in {"STOP_MARKET", "TAKE_PROFIT_MARKET", "STOP", "TAKE_PROFIT"}:
try:
await exchange.cancel_order(order["id"], symbol)
cancelled_count += 1
logger.info("cancelled_leftover id=%s symbol=%s type=%s",
order["id"], symbol, order_type)
except Exception as exc:
logger.warning("cancel failed id=%s err=%s", order.get("id"), exc)
return cancelled_count
async def safe_entry_with_cleanup(
exchange,
symbol: str,
side: str,
quantity: float,
price: float,
) -> dict:
await clean_leftover_orders(exchange, symbol, aggressive=True)
await asyncio.sleep(0.1)
return await place_binance_order(exchange, symbol, side, quantity, price)The pattern generalizes. Any exchange that does not provide native OCO semantics requires application-layer cleanup. Bybit V5 has improved on this with its trading-stop endpoint, but even there the principle holds: assume nothing about residual state, verify and clean before every meaningful action.
Bybit Bug One: The V5 Migration That Rejected Everything
When Bybit released its V5 unified API, I migrated my bot expecting a few hours of work. It became three days. The first symptom was that every order placement returned a generic error: “invalid order type.” The CCXT documentation showed examples that looked correct. My code matched the examples. The orders failed anyway.
The first issue was that V5 requires an explicit category parameter on every request to a derivatives endpoint, and the value must be exactly "linear" for USDT perpetuals. CCXT had been silently inferring this on V2, but on V5 the inference was incomplete and category had to be passed explicitly through the params dictionary.
The second issue was that V5 is case-sensitive about order type strings in ways V2 was not. Passing "Market" instead of "market" would fail. Passing "MARKET" would also fail. The exact lowercase string was required, and the error message was the unhelpful “invalid order type” regardless of which incorrect variant I tried.
The OrderRouter pattern emerged directly from this debugging. Rather than scattering exchange-specific normalization throughout the codebase, every order passes through a single function that knows the quirks of each venue and produces the correct parameter set.
from typing import Dict, Any
EXCHANGE_ORDER_NORMALIZERS: Dict[str, callable] = {}
def register_normalizer(exchange_id: str):
def decorator(fn):
EXCHANGE_ORDER_NORMALIZERS[exchange_id] = fn
return fn
return decorator
@register_normalizer("bybit")
def normalize_bybit_order(
symbol: str,
side: str,
quantity: float,
price: float,
order_type: str,
) -> Dict[str, Any]:
return {
"symbol": symbol,
"type": order_type.lower(),
"side": side.lower(),
"amount": quantity,
"price": price if order_type.lower() != "market" else None,
"params": {
"category": "linear",
"positionIdx": 0,
},
}
@register_normalizer("binance")
def normalize_binance_order(
symbol: str,
side: str,
quantity: float,
price: float,
order_type: str,
) -> Dict[str, Any]:
return {
"symbol": symbol,
"type": order_type.upper(),
"side": side.upper(),
"amount": quantity,
"price": price if order_type.upper() != "MARKET" else None,
"params": {},
}
@register_normalizer("bitget")
def normalize_bitget_order(
symbol: str,
side: str,
quantity: float,
price: float,
order_type: str,
) -> Dict[str, Any]:
return {
"symbol": symbol,
"type": order_type.lower(),
"side": side.lower(),
"amount": quantity,
"price": price if order_type.lower() != "market" else None,
"params": {
"productType": "USDT-FUTURES",
"marginCoin": "USDT",
},
}
def build_order_params(exchange_id: str, **kwargs) -> Dict[str, Any]:
normalizer = EXCHANGE_ORDER_NORMALIZERS.get(exchange_id)
if normalizer is None:
raise ValueError(f"no normalizer registered for {exchange_id}")
return normalizer(**kwargs)The structural value of this pattern compounds. Each exchange’s quirks live in one place. When Bitget releases a breaking change, I touch one function. When CCXT updates its abstraction layer in a way that breaks one venue but not the others, the blast radius is bounded.
Bybit Bug Two: The Symbol Format That Returned Empty Positions
The second Bybit bug was subtle and took two days to isolate. fetch_positions consistently returned an empty array even when I knew positions were open on the account. Manual checks through the Bybit web interface confirmed the positions existed. The API confirmed the account was authenticated. CCXT confirmed it was talking to V5. Yet positions appeared empty.
The fix was the symbol format. CCXT’s unified format for Bybit USDT perpetuals is "BTC/USDT:USDT", with the trailing :USDT suffix indicating the settlement currency. I had been passing "BTCUSDT" (the native Bybit format) and "BTC/USDT" (the spot CCXT format), neither of which matched. CCXT silently returned no positions rather than raising an error, because the symbol it received was technically valid for spot pairs that simply did not exist on the account.
This is a class of bug worth naming explicitly: the silent mismatch. The system does not crash, does not raise, does not log a warning. It returns empty data, which downstream code interprets as “no positions” and acts accordingly. In trading systems, “no positions detected” is a particularly dangerous default because it can lead the bot to open new positions on top of existing ones, doubling exposure without any warning.
def to_ccxt_symbol(exchange_id: str, base: str, quote: str = "USDT") -> str:
if exchange_id == "bybit":
return f"{base}/{quote}:{quote}"
if exchange_id == "binance":
return f"{base}/{quote}:{quote}"
if exchange_id == "bitget":
return f"{base}/{quote}:{quote}"
raise ValueError(f"unknown exchange: {exchange_id}")
async def fetch_positions_safely(exchange, exchange_id: str, symbols: list) -> list:
ccxt_symbols = [to_ccxt_symbol(exchange_id, s) for s in symbols]
try:
positions = await exchange.fetch_positions(ccxt_symbols)
except Exception as exc:
logger.exception("fetch_positions failed exchange=%s err=%s", exchange_id, exc)
return []
non_empty = [p for p in positions if float(p.get("contracts") or 0) > 0]
logger.info("fetch_positions exchange=%s requested=%d returned=%d non_empty=%d",
exchange_id, len(ccxt_symbols), len(positions), len(non_empty))
return non_emptyIf your strategy depends on accurate position state, see also my discussion of position tracking patterns in the multi-exchange arbitrage guide. For anyone following the V5 migration path, my Bybit referral link activates V5 unified account by default for new signups, which avoids the legacy account migration step entirely. Disclosure: this is a referral link and I receive a commission at no cost to you.
Bybit Bug Three: The Position Reversal That Bled Equity
The third Bybit bug was the one that cost me actual capital before I caught it. The strategy was running on a fifteen-minute timeframe with reasonable signal logic. The backtest showed steady positive expectancy. The live account was bleeding equity at a rate that could not be explained by drawdown alone.
The forensics took an evening of staring at trade logs side by side with the strategy logs. The pattern was that on certain candle closes, the bot would close a position and immediately reopen one in the opposite direction. The reversal was triggered by what looked like a fresh signal, but the timestamps showed the close and the reopen happening within milliseconds of each other on the same candle.
The root cause was a stale balance read. After closing a position, the bot called fetch_balance to update its state before checking for new signals. Bybit’s balance endpoint returned the pre-close balance for several hundred milliseconds after the close was filled, because the internal accounting was eventually consistent rather than immediately consistent. The bot interpreted the unchanged balance as “I have margin available, and there is a fresh signal in the opposite direction, therefore enter the reverse position.” The reverse position was a phantom signal triggered by the bot’s own previous action.
The fix has three layers. The first is a minimum hold period that prevents any new entry on a symbol within a configurable number of candles after a close. The second is a forced sleep after position closes, giving the exchange’s internal accounting time to converge. The third is using the free balance field rather than total for available-margin calculations, since total includes locked margin that is not actually available for new positions.
import asyncio
from datetime import datetime, timezone
MIN_HOLD_CANDLES = 3
POST_CLOSE_SETTLE_SECONDS = 0.5
class PositionStateTracker:
def __init__(self):
self._last_close_time: dict = {}
def record_close(self, symbol: str) -> None:
self._last_close_time[symbol] = datetime.now(timezone.utc)
def can_enter(self, symbol: str, candle_seconds: int) -> bool:
last_close = self._last_close_time.get(symbol)
if last_close is None:
return True
elapsed = (datetime.now(timezone.utc) - last_close).total_seconds()
min_elapsed = MIN_HOLD_CANDLES * candle_seconds
return elapsed >= min_elapsed
async def close_position_safely(
exchange,
state: PositionStateTracker,
symbol: str,
quantity: float,
side: str,
) -> dict:
close_side = "sell" if side.lower() == "buy" else "buy"
result = await exchange.create_order(
symbol=symbol, type="market", side=close_side,
amount=quantity, params={"reduceOnly": True},
)
state.record_close(symbol)
await asyncio.sleep(POST_CLOSE_SETTLE_SECONDS)
balance = await exchange.fetch_balance()
free_usdt = float(balance.get("USDT", {}).get("free") or 0)
logger.info("close_complete symbol=%s free_balance=%.4f", symbol, free_usdt)
return resultThe broader lesson is that exchange APIs are not databases. They have eventual consistency in places where you would expect immediate consistency, and the consistency window is long enough that strategy logic running at high frequency will routinely see stale state. The application layer must compensate for this, either through explicit hold periods or through more sophisticated state tracking that tracks expected versus observed account state across multiple polling cycles.
Bitget Bug One: The Margin Coin Trap
The Bitget bug that consumed an entire weekend of debugging time was a single missing parameter. I had migrated the same unified module to Bitget assuming the CCXT abstraction would handle the differences. fetch_positions failed immediately with error code 400172: “Margin Coin cannot be empty.” I rechecked credentials. They were correct. I rechecked the symbol format. It was correct. I rechecked the CCXT version. Latest stable.
The problem was that Bitget USDT-M futures requires both productType and marginCoin parameters on every futures-related call, and most CCXT example code in circulation only includes productType. The Bitget V2 API splits its derivatives venues into multiple product types (USDT-FUTURES, COIN-FUTURES, USDC-FUTURES) and within each product type the margin coin must be explicitly specified even though it seems implied by the product type itself.
The fix lives in the Bitget normalizer shown earlier: every call passes params={"productType": "USDT-FUTURES", "marginCoin": "USDT"}. The structural lesson is that exchange documentation and CCXT abstractions occasionally diverge, and when they do, the gap must be closed at a specific architectural layer rather than through scattered fixes throughout the codebase. The OrderRouter pattern is exactly that layer.
BITGET_REQUIRED_PARAMS = {
"productType": "USDT-FUTURES",
"marginCoin": "USDT",
}
async def fetch_bitget_positions(exchange, symbols: list) -> list:
try:
positions = await exchange.fetch_positions(
symbols, params=BITGET_REQUIRED_PARAMS,
)
except Exception as exc:
if "400172" in str(exc):
logger.error(
"bitget margin coin error - verify productType and marginCoin params"
)
raise
return [p for p in positions if float(p.get("contracts") or 0) > 0]If you want to mirror this Bitget setup, my Bitget referral link covers the standard fee discount tier for new accounts. Disclosure: this is a referral link and I receive a commission at no cost to you.
The Cross-Cutting Patterns That Hit All Three Exchanges
Beyond the venue-specific bugs, four patterns affected all three exchanges in slightly different forms. Each one is small individually but together they are the difference between a fragile bot and a production-grade execution module.
Timestamp Serialization
The first time I tried to log a trade record to a JSON file, Python crashed with TypeError: Object of type Timestamp is not JSON serializable. The culprit was a pandas Timestamp object that had snuck into the trade record from a market data fetch. Every place where trade data was serialized for logging, dashboard streaming, or external analysis needed a normalization layer that converted pandas timestamps, datetime objects, and numpy numeric types into JSON-safe primitives.
import json
import math
from datetime import datetime, timezone
from typing import Any
def to_json_safe(obj: Any) -> Any:
if obj is None or isinstance(obj, (str, bool)):
return obj
if isinstance(obj, (int, float)):
if isinstance(obj, float) and (math.isnan(obj) or math.isinf(obj)):
return None
return obj
if isinstance(obj, datetime):
return obj.astimezone(timezone.utc).isoformat()
if hasattr(obj, "isoformat"):
return obj.isoformat()
if hasattr(obj, "item"):
return obj.item()
if isinstance(obj, dict):
return {k: to_json_safe(v) for k, v in obj.items()}
if isinstance(obj, (list, tuple)):
return [to_json_safe(v) for v in obj]
return str(obj)
def safe_dumps(obj: Any) -> str:
return json.dumps(to_json_safe(obj), separators=(",", ":"))Heartbeat Readability
Bot logs that print Unix millisecond timestamps are unreadable during live debugging. When a bot is misbehaving at 2 AM and you have ten minutes to diagnose before the next signal, you do not want to mentally convert 1730459432187 into wall-clock time. The fix is to format timestamps in heartbeat logs as ISO 8601 with timezone, and to include a relative time delta from the previous heartbeat for spotting gaps.
def format_heartbeat(now_ms: int, last_ms: int) -> str:
now_dt = datetime.fromtimestamp(now_ms / 1000, tz=timezone.utc)
delta_sec = (now_ms - last_ms) / 1000.0
return f"{now_dt.strftime('%Y-%m-%d %H:%M:%S UTC')} (+{delta_sec:.1f}s)"Idempotency With Client Order IDs
Network timeouts during order placement create a particularly nasty failure mode. The order may have been received and filled by the exchange even though the client never received the response. Naive retry logic will submit the order again, resulting in a duplicate fill. The fix is to attach a unique client order ID to every order, generated before the request is sent, and to check it on retry.
import uuid
from typing import Optional
class IdempotencyManager:
def __init__(self):
self._sent_ids: dict = {}
def generate_id(self, strategy: str, symbol: str) -> str:
client_id = f"nql-{strategy}-{symbol}-{uuid.uuid4().hex[:12]}"
self._sent_ids[client_id] = datetime.now(timezone.utc)
return client_id
async def safe_create_order(
self, exchange, exchange_id: str, **order_kwargs
) -> dict:
client_id = self.generate_id(
order_kwargs.get("strategy", "default"),
order_kwargs["symbol"],
)
params = order_kwargs.pop("params", {})
if exchange_id == "binance":
params["newClientOrderId"] = client_id
elif exchange_id == "bybit":
params["orderLinkId"] = client_id
elif exchange_id == "bitget":
params["clientOid"] = client_id
order_kwargs["params"] = params
return await exchange.create_order(**order_kwargs)Rate Limit Handling
Each exchange has a different rate limit weight system, and exceeding the weight produces different error codes that all reduce to “your bot is now banned for the next minute.” The mitigation is exponential backoff with jitter on rate limit errors, plus a coarse rate budget that throttles non-critical calls during high-traffic periods.
import random
RATE_LIMIT_ERROR_PATTERNS = ["rate limit", "too many requests", "429", "418"]
async def call_with_backoff(
fn, max_retries: int = 5, base_delay: float = 1.0,
) -> Any:
for attempt in range(max_retries):
try:
return await fn()
except Exception as exc:
err_msg = str(exc).lower()
is_rate_limit = any(p in err_msg for p in RATE_LIMIT_ERROR_PATTERNS)
if not is_rate_limit or attempt == max_retries - 1:
raise
delay = base_delay * (2 ** attempt) + random.uniform(0, 1.0)
logger.warning("rate_limited attempt=%d delay=%.2fs err=%s",
attempt + 1, delay, str(exc)[:100])
await asyncio.sleep(delay)
raise RuntimeError("call_with_backoff exhausted")The rate limit handling is also where VPS choice matters most. A VPS that shares its IP with other traders running aggressive strategies can find itself banned by association when the upstream IP triggers the exchange’s rate limiter. Dedicated IPs and properly isolated VPS instances are worth the small additional cost. I cover the operational side of VPS selection in my VPS deployment guide.
What This Architecture Becomes in Production
The seven bugs documented here are not the only bugs I have hit in a year of multi-exchange operation. They are the ones that recurred across multiple debugging sessions and that fundamentally shaped the architecture I converged on. The OrderRouter, RiskGuard, IdempotencyManager, and BalanceReconciler patterns came directly out of needing to solve these specific problems in a way that did not require resolving them again every time CCXT or an exchange released a breaking change.
The execution module sketched across this post is what feeds my live trading. The full production version of these patterns, with all the edge cases, error handling, monitoring hooks, and recovery logic that did not fit into a blog post, is integrated into Aurora Layer XQ on the MT5 side and documented in detail in chapters seven through twelve of the Masterclass Volume 1 ebook. If you are building a multi-exchange execution layer from scratch, that material is the fastest path to production-grade reliability without spending a year debugging the same seven bugs I did.
The next piece in this series moves to the MT5 side specifically, covering how the Python analytical layer feeds into MQL5 execution for the forex and indices strategies that benefit from MT5’s mature execution infrastructure. The architecture is the same. The venue is different. The bugs, predictably, are entirely new.
Educational content only. The code patterns in this post are extracted from my live trading infrastructure but are not financial advice. Trading derivatives carries substantial risk including total loss of capital. Past results do not predict future performance.