DEV Community: Boris Fesenko

Why crypto arbitrage windows close before your REST poll completes

Boris Fesenko — Tue, 02 Jun 2026 12:53:03 +0000

TL;DR: Crypto arbitrage windows on liquid pairs now close in under 100 ms. A REST polling loop typically takes 1–1.5 seconds round-trip. WebSocket delivers the same data in 20–100 ms. If you're still polling REST endpoints for orderbook data in 2026, you're missing the majority of opportunities — not because your strategy is wrong, but because your data plane is fundamentally too slow.

This post walks through the math, shows a benchmark I ran on a handful of major exchanges, and provides production-grade Python code for a WebSocket client that handles reconnects, heartbeats, and orderbook reconstruction.

1. The numbers that broke REST polling

When I started writing crypto arbitrage bots a few years ago, polling Binance's REST API every 500 ms was perfectly acceptable. Spreads were wide, arbitrage windows lasted multiple seconds, and the orderbook for BTCUSDT moved slowly enough that a half-second-old snapshot was still tradeable.

In 2026, the same approach doesn't work. Here are the numbers as they stand today:

Metric	Value
Median crypto arbitrage window on liquid pairs	30–80 ms
Window closes in under 100 ms	~90% of cases
REST round-trip latency (request → response → JSON parse)	1.0–1.5 seconds
WebSocket update delivery latency (push from exchange to client)	20–100 ms

The math is brutal. A 100 ms window cannot be caught by a 1500 ms poll. By the time your REST response arrives, the orderbook you're reading is 15 cycles stale. You're not "slow" — you're not even in the same temporal universe as the event you're trying to react to.

2. Why REST is fundamentally slow

REST APIs over HTTPS carry overhead that adds up:

TCP handshake — three packets to establish, typically 50–150 ms on intercontinental hops.
TLS handshake — another full round-trip, 30–100 ms.
HTTP request/response — the actual data exchange.
JSON parse — depending on payload size, 5–50 ms.
Rate-limit budget — most exchanges cap REST to 10–20 requests per second per IP. Polling faster gets you banned.

Yes, modern clients use HTTP keep-alive to avoid steps 1 and 2 on every request. But you still pay them periodically. And rate limits are the real killer — even if you could parse responses in 1 ms, the exchange will throttle you after 20 requests.

# This is what every REST polling loop looks like.
# Every. Single. Iteration. Pays full round-trip cost.

import time
import requests

def poll_orderbook(url, interval_ms=500):
    while True:
        start = time.perf_counter()
        response = requests.get(url, timeout=2)
        book = response.json()
        elapsed_ms = (time.perf_counter() - start) * 1000
        print(f"Got {len(book['bids'])} bids in {elapsed_ms:.0f} ms")
        time.sleep(max(0, interval_ms / 1000 - elapsed_ms / 1000))

Running this against https://api.binance.com/api/v3/depth?symbol=BTCUSDT&limit=20 from a typical residential or VPS connection produces round-trip times of 800–1500 ms consistently. Best case: maybe 600 ms from a co-located server. Still 6× too slow for a 100 ms window.

3. WebSocket: push, not poll

WebSocket inverts the model. Instead of the client asking "what's the orderbook now?" twice a second and accepting that the answer is already stale, the client opens one persistent connection and the exchange pushes updates the instant they happen.

Concretely:

One TCP/TLS handshake at connection time. Amortised across thousands of messages.
One subscription message declaring what streams you want.
A continuous stream of deltas flowing from server to client over the same connection.
No rate limit on inbound messages (the exchange controls the rate).

The delivery latency on a properly-configured WebSocket client to a major crypto exchange is 20–100 ms, depending on geographic distance. That's the time between the exchange's matching engine processing an event and your code receiving the update. There is no polling overhead because there is no polling.

Here's the bare-minimum Python client for Binance's depth stream:

import asyncio
import json
import websockets

async def stream_depth(symbol="btcusdt"):
    uri = f"wss://stream.binance.com:9443/ws/{symbol}@depth20@100ms"
    async with websockets.connect(uri) as ws:
        async for raw in ws:
            update = json.loads(raw)
            best_bid = float(update["bids"][0][0])
            best_ask = float(update["asks"][0][0])
            spread = best_ask - best_bid
            print(f"bid={best_bid:.2f} ask={best_ask:.2f} spread={spread:.2f}")

asyncio.run(stream_depth())

Run this and you'll get updates every 100 ms (the slowest tier — Binance offers @100ms, @1000ms, and unthrottled real-time streams). Each update arrives with the new top-of-book state. No polling. No rate-limit risk. The connection stays open as long as your process runs.

4. A simple benchmark

Here's a script that measures REST round-trip vs WebSocket inter-message arrival time for the same orderbook data. It's not a perfect apples-to-apples comparison (REST gives a full snapshot; WebSocket gives a stream of updates), but it makes the order-of-magnitude difference impossible to miss.

import asyncio
import json
import statistics
import time
import requests
import websockets

# ----------------------------------------------------------------
# REST: measure round-trip for orderbook snapshot
# ----------------------------------------------------------------
def benchmark_rest(url, samples=50):
    latencies = []
    for _ in range(samples):
        start = time.perf_counter()
        r = requests.get(url, timeout=5)
        r.json()
        elapsed_ms = (time.perf_counter() - start) * 1000
        latencies.append(elapsed_ms)
        time.sleep(0.1)  # respect rate limits
    return {
        "median_ms": round(statistics.median(latencies), 1),
        "p90_ms": round(statistics.quantiles(latencies, n=10)[8], 1),
        "p99_ms": round(max(latencies), 1),
    }

# ----------------------------------------------------------------
# WebSocket: measure time between pushed updates
# ----------------------------------------------------------------
async def benchmark_websocket(uri, samples=50):
    gaps = []
    async with websockets.connect(uri) as ws:
        last = time.perf_counter()
        for _ in range(samples + 1):  # +1 to discard the first
            await ws.recv()
            now = time.perf_counter()
            gaps.append((now - last) * 1000)
            last = now
    gaps = gaps[1:]  # discard first
    return {
        "median_ms": round(statistics.median(gaps), 1),
        "p90_ms": round(statistics.quantiles(gaps, n=10)[8], 1),
        "p99_ms": round(max(gaps), 1),
    }

# ----------------------------------------------------------------
# Run both
# ----------------------------------------------------------------
if __name__ == "__main__":
    rest_url = "https://api.binance.com/api/v3/depth?symbol=BTCUSDT&limit=20"
    ws_uri = "wss://stream.binance.com:9443/ws/btcusdt@depth20@100ms"

    print("REST:", benchmark_rest(rest_url, samples=50))
    print("WebSocket:", asyncio.run(benchmark_websocket(ws_uri, samples=50)))

A representative run from a European VPS to Binance:

REST:       {'median_ms': 920.4, 'p90_ms': 1180.5, 'p99_ms': 1485.2}
WebSocket:  {'median_ms': 100.2, 'p90_ms': 105.1, 'p99_ms': 142.8}

The WebSocket median is the throttle setting (@100ms), not the underlying delivery latency — that's faster. The REST median is genuine round-trip cost. A 9× gap on the median; closer to 12× on the p99.

Switching to Binance's unthrottled depth stream (btcusdt@depth) drops the WebSocket median below 50 ms, widening the gap further.

5. The architectural shift

Moving from REST polling to WebSocket isn't just changing a library — it changes the architecture of your bot.

Before (REST polling):

┌─────────────────┐    ┌──────────────────┐
│  Poll loop       │ ── │ Strategy engine │
│  every 500 ms    │    │ runs on snapshot │
└─────────────────┘    └──────────────────┘

A single thread asks for state on a timer, hands the snapshot to the strategy, repeats. The strategy is stateless between polls — it has no idea what happened in the gap.

After (WebSocket event-driven):

┌──────────────────┐    ┌──────────────────┐    ┌──────────────────┐
│  WS connection    │ ── │ Local orderbook │ ── │ Strategy engine │
│  pushes deltas    │    │ kept current    │    │ reacts to events│
└──────────────────┘    └──────────────────┘    └──────────────────┘

Now the client maintains a local replica of the orderbook, applying deltas as they arrive. The strategy engine reacts to specific events (a bid lifted, an ask hit, a spread widening past a threshold). State is continuous, not sampled.

This is more code. It's also the only way to react inside a 100 ms window.

6. Production-grade WebSocket client

The bare-minimum example earlier works for a demo. For a real arbitrage bot, you need:

Automatic reconnect on disconnect
Heartbeat / ping-pong to detect dead connections faster than the OS will
Sequence number validation to detect dropped messages (most exchanges include a sequence ID)
Local orderbook state that applies deltas correctly
Backoff on reconnects to avoid hammering the exchange after an outage

Here's a more robust skeleton (Binance-style stream, simplified):

import asyncio
import json
import logging
import random
import websockets

log = logging.getLogger("ws_client")

class CryptoOrderbookClient:
    def __init__(self, uri, on_update):
        self.uri = uri
        self.on_update = on_update
        self._stop = False
        self._backoff_s = 1

    async def run(self):
        while not self._stop:
            try:
                async with websockets.connect(
                    self.uri,
                    ping_interval=20,    # heartbeat every 20 s
                    ping_timeout=10,     # treat as dead after 10 s no pong
                    max_size=2**20,      # 1 MB message cap
                ) as ws:
                    self._backoff_s = 1  # reset on successful connect
                    log.info("WS connected to %s", self.uri)
                    await self._consume(ws)
            except (websockets.ConnectionClosed, OSError) as e:
                log.warning("WS disconnected: %s; backing off %ss", e, self._backoff_s)
                await asyncio.sleep(self._backoff_s + random.uniform(0, 1))
                self._backoff_s = min(self._backoff_s * 2, 30)  # exponential up to 30s

    async def _consume(self, ws):
        async for raw in ws:
            try:
                msg = json.loads(raw)
                await self.on_update(msg)
            except json.JSONDecodeError:
                log.warning("non-JSON message dropped")
            except Exception:
                log.exception("handler crashed; continuing")

    def stop(self):
        self._stop = True


async def my_handler(msg):
    bid = float(msg["bids"][0][0])
    ask = float(msg["asks"][0][0])
    # ... your strategy logic ...
    print(f"bid={bid:.2f} ask={ask:.2f}")


client = CryptoOrderbookClient(
    "wss://stream.binance.com:9443/ws/btcusdt@depth20@100ms",
    my_handler,
)
asyncio.run(client.run())

Notes on what this gives you:

ping_interval=20, ping_timeout=10 is the single most important pair of settings. Exchanges will silently drop your connection during network blips; the OS-level TCP timeout is minutes. Without explicit ping-pong, you'll think you're connected for ages while receiving nothing. With it, you detect the dead connection in ~30 s and reconnect.
Exponential backoff on reconnect prevents you from being the bot that DDoSes an exchange during their outage.
Catch all handler exceptions at the top level. A bug in your strategy code should not kill the WebSocket loop and lose minutes of market data.

For orderbook reconstruction with full delta application and sequence-number gap detection, see the Binance WebSocket reference implementation — every major exchange has a similar document, and following it exactly is the only way to avoid subtle desync bugs.

7. What still needs REST

WebSocket replaces REST for market data. It does not replace REST for everything. Things that still belong on REST:

Order placement and cancellation on most exchanges (some have WebSocket order entry; coverage is uneven).
Account balance queries, position queries, fee tier lookups — infrequent enough that polling cost is irrelevant.
Historical data fetches — REST is the right tool for "give me the last 1000 trades".
One-shot administrative calls — withdrawals, API key management, etc.

A real arbitrage bot in 2026 typically runs a WebSocket data plane and a REST control plane side by side. Market events arrive on WebSocket, orders go out on REST (or WebSocket order entry where available).

8. What happens to retail bots that don't make this transition

A polling-based crypto arbitrage bot in 2026 isn't broken — it just runs into a degraded version of the problem:

Signals fire slower because the bot only sees market state 2× per second.
Most opportunities have already closed by the time the strategy reacts.
Per-trade edge collapses as the bot consistently takes the worst price of the window.
Win rate drops to the point where execution costs (fees + spread + slippage) exceed gross edge.

The strategy logic might be perfect. The execution layer is what kills it.

This is the same dynamic that broke retail latency arbitrage on forex brokers a decade ago — except in crypto the resolution is happening over months, not years, because every major exchange now offers WebSocket and the technical bar is lower. The asymmetry will only get worse: traders running on WebSocket are pulling away from traders running on REST.

9. Where I came from on this

For context: I'm one of the developers behind BJF Trading Group's crypto arbitrage software. We migrated the entire market-data path from REST polling to WebSocket through late 2025 and Q1 2026. Internal measurements showed that signal-to-fill rate improved by roughly an order of magnitude on liquid pairs, and that strategies which had become marginal under polling (especially cross-exchange Hedge and intra-exchange Latency) were viable again under WebSocket.

We rolled the lessons into a focused product configuration — SharpTrader Crypto — built specifically around WebSocket-native execution for crypto exchanges, with Latency and Hedge strategy modules. It also integrates with US-accepting exchanges (Coinbase, Kraken, Gemini, Bitstamp), which mattered to us because most retail crypto arbitrage tools rely on Binance/Bybit and geo-block US residents.

If you're maintaining your own bot, the rest of this article is everything you need to do the transition yourself. If you'd rather skip the connection-management plumbing and use something off-the-shelf, that's what we built.

10. TL;DR for the impatient

Crypto arbitrage windows close in under 100 ms on liquid pairs.
REST polling takes 1–1.5 seconds round-trip. You will miss most opportunities.
WebSocket pushes updates in 20–100 ms. You will catch most opportunities.
Migration is not optional in 2026.
The minimum reliable client needs: ping_interval, ping_timeout, exponential backoff, exception isolation, sequence-number validation. Skip any of these and the bot will silently lose minutes of market data when the connection blips.
Keep REST for order placement, balances, history.
The strategy logic in your bot is probably fine. The data plane is what's killing it.

How Forex Brokers Detect Latency Arbitrage in 2026: A Technical Breakdown

Boris Fesenko — Fri, 10 Apr 2026 20:50:52 +0000

Latency arbitrage has existed as long as electronic forex trading has. The concept is straightforward: if you receive a price update faster than a broker reflects it, you can trade on the broker's stale quote before it catches up. For two decades, this was primarily an infrastructure problem — whoever had faster pipes won.

In 2026, the infrastructure gap has largely closed for retail participants. Co-location at LD4, NY4, or TY3 is accessible to anyone willing to pay $100–400/month. Sub-5ms round-trip to most retail brokers is achievable. The bottleneck has shifted from hardware to detection: brokers have deployed increasingly sophisticated AI systems to identify and neutralize arbitrage order flow.

This article breaks down exactly how those detection systems work — from simple heuristics to behavioral AI — and what the detection signature of latency arbitrage actually looks like from the broker's side.

Why brokers care: the conflict of interest

Before discussing detection mechanics, it's worth understanding the broker's incentive structure.

Most retail forex brokers operate as market makers — they take the opposite side of client trades. When a client executes a profitable trade, the broker loses that amount. Conventional retail traders are unprofitable maybe 70% of the time; the statistical edge favors the broker. A latency arbitrageur running a well-configured setup might be profitable 65–75% of the time on short-hold positions. Across hundreds of trades per day, this is directly and measurably expensive for a market maker.

ECN/STP brokers have less financial incentive to detect arbitrage — they earn commissions regardless of client P&L — but many still deploy detection systems due to pressure from liquidity providers who don't want to be the "fast feed" being arbitraged against their own retail distribution.

The result: detection is financially motivated and has been improving consistently since around 2018.

Generation 1: Simple heuristics (2010–2018)

Early detection systems were rule-based and relatively easy to circumvent. They looked for obvious patterns:

Short hold time filters. If an account's average position duration was below a threshold (e.g., 30 seconds), it was flagged. Solution: add a time filter to hold positions longer.

Win rate on short-duration trades. A 70%+ win rate on positions held under 60 seconds, sustained over weeks, has no non-arbitrage explanation. Brokers tracked this per-account.

Fixed lot size uniformity. Arbitrage bots often trade identical lot sizes across every signal. Statistical distribution of lot sizes across a genuine retail account looks nothing like this. Some brokers flagged accounts where 90%+ of trades were the same size.

IP-based correlation. Two accounts connecting from the same IP with mirrored P&L (one profits when the other loses) is the lock arbitrage signature. First-generation detection caught this at the network metadata level.

These heuristics were effective against unsophisticated setups but generated significant false positives — legitimate algorithmic traders were caught in the same nets. They were also easy to work around: vary lot sizes slightly, hold positions longer, use different IPs.

Generation 2: Statistical behavioral analysis (2018–2022)

The second generation moved from hard thresholds to statistical modeling. Instead of "flag if hold time < 30s," the system builds a statistical profile of each account and compares it against a population model.

Temporal correlation analysis. This is the most powerful single latency arbitrage signal. The detection system timestamps every price update on its feed and every incoming order. For a latency arbitrageur, there is a statistically significant correlation between moments when the fast feed diverges from the broker's own price and the moment orders arrive.

Specifically: if the broker measures the time delta between its own last price update and the arrival of an order, arbitrage accounts cluster orders at small deltas (they're trading the discrepancy). Normal retail accounts place orders without any correlation to the broker's internal price update timing.

This is difficult to fake. You cannot make your order arrival time uncorrelated with price events without destroying the arbitrage signal itself.

Position lifetime distribution analysis. A latency arbitrageur's position lifetime distribution is highly abnormal from a population perspective. The distribution is heavily skewed toward very short hold times (under 30 seconds) with a long tail. No conventional trading strategy produces this shape. The broker doesn't need a hard cutoff — they fit the distribution and flag accounts whose parameters fall outside the population's confidence interval.

Adverse selection measurement. For market makers, the key metric is how often the price moves against them after filling a client order. Latency arbitrage fills are almost always immediately followed by adverse price movement (that's the point — the price is about to move). A normal retail account generates adverse selection at roughly random rates. An arbitrage account's fills are systematically followed by price movement in one direction. This signal is robust and hard to fake.

Cross-account P&L correlation. For lock arbitrage, the detection signature is: Account A profits at roughly the same times Account B loses. The correlation is high. Second-generation systems tracked this at the broker's clearing level. Two accounts whose P&L streams are strongly negatively correlated are almost certainly running a lock strategy.

Generation 3: Machine learning behavioral clustering (2022–present)

The current generation uses machine learning to identify arbitrage accounts without relying on any single signal. The key innovation is clustering: rather than flagging accounts individually, the system builds behavioral feature vectors for every account and identifies clusters of accounts whose behavior is similar.

Feature vector construction. For each account, the system constructs a high-dimensional feature vector including:

Mean and variance of position hold time
Temporal correlation coefficient between orders and fast feed updates
Win rate conditioned on hold time
Lot size distribution (mean, variance, skewness)
Time-of-day trading density (arbitrageurs concentrate on high-volatility sessions)
Slippage distribution (positive vs negative slippage ratio)
Order-to-fill time (consistent fast fills suggest algorithmic execution)
IP metadata and session behavior

Clustering. Accounts are clustered by behavioral similarity. A cluster of accounts that all entered long EUR/USD positions within 200ms of each other on Tuesday at 13:47:23 UTC isn't coincidence — they're running the same software. The ML system doesn't need to know it's arbitrage software; it just knows these accounts are behaviorally correlated.

Continuous retraining. The system retrains on new data regularly. When arbitrage software adds new masking techniques, the behavioral fingerprint changes — and the detection system adapts. This is the arms race dynamic that makes the 2026 landscape fundamentally different from 2018.

Cross-broker data sharing. This is the most concerning development for arbitrage operators. There is no regulatory prohibition on brokers sharing behavioral metadata about client trading patterns. Some broker networks and shared liquidity arrangements informally share account flagging data. An account flagged at one broker in a network can be pre-flagged at another before any trades are placed.

What detection actually looks like from the trader's perspective

Detection rarely manifests as an immediate account closure. The typical progression:

Phase 1 — Monitoring. The account is flagged as potentially arbitrage. No action is taken. The broker accumulates data to confirm.

Phase 2 — Soft countermeasures. The broker introduces artificial execution delays specifically on this account — typically 30–150ms added to order processing. The trader sees execution times increasing gradually. Slippage becomes systematically negative. The arbitrage window closes before the order fills. Profitability drops without any visible restriction.

Phase 3 — Targeted spread widening. The broker applies per-account spread markup on instruments used most frequently for arbitrage. From the trader's perspective, spreads appear wider than published rates. This is applied at the server level and isn't visible in standard platform spread displays.

Phase 4 — Account action. Depending on the broker's ToS and appetite for risk: profit confiscation on flagged trades, account restriction, or closure with capital returned.

The gradient approach is deliberate: it makes it harder for the trader to identify exactly when detection occurred and allows the broker to extract more data before acting.

The detection-resistance problem

The fundamental challenge is that temporal correlation — the primary detection signal — is intrinsic to latency arbitrage. You cannot remove it without removing the strategy itself. Every order that is causally related to a fast-feed price event will be temporally correlated with that event.

The countermeasures that exist work by adding noise to the signal rather than eliminating it:

Behavioral blending. Running technical indicator-based entry triggers (RSI, candlestick patterns) in parallel with arbitrage execution creates an order history that partially resembles retail technical trading. The temporal correlation signal is diluted but not eliminated.

Virtual order systems. Decoupling re-entry timing from fast-feed events by using software-side virtual orders that execute based on price levels rather than signal timing. The broker sees an order placed when price reached a certain level — not when the fast feed moved.

Account rotation and profile separation. Maintaining multiple accounts with distinct behavioral profiles, IPs, and execution patterns to prevent clustering detection from linking them.

Noise trading. Adding deliberately unprofitable or breakeven trades to normalize the win rate distribution and adverse selection metrics.

None of these fully eliminate the detection signal — they reduce its statistical strength. The detection system needs sufficient signal strength to confidently flag an account; countermeasures aim to keep the signal below that threshold.

Conclusions

The 2026 broker detection landscape reflects a genuine technological arms race. The progression from simple hold-time heuristics to ML-based behavioral clustering represents a substantial increase in detection capability.

What hasn't changed: latency arbitrage remains legal in all major jurisdictions. No financial regulator has classified it as market manipulation or any prohibited activity. The detection and restriction that traders face is contractual — brokers enforcing terms of service — not legal.

What has changed: the infrastructure edge that defined latency arbitrage profitability for its first decade is now table stakes. The differentiating factors in 2026 are detection resistance, broker selection, and behavioral profile management.

For a more detailed technical breakdown of infrastructure requirements and masking strategy mechanics, see: Latency Arbitrage: Complete Guide 2026 — which covers VPS colocation benchmarks, fast feed architecture, and the specific masking strategies (Phantom Drift, BrightDuo) currently in production use.

The author develops arbitrage trading software at BJF Trading Group, a Canadian HFT software company active in the arbitrage space since 2000.

Tags: HFT algorithmic trading forex arbitrage market microstructure trading systems