Most "arbitrage bot" demos have the same shape: subscribe to two exchanges,
compare best bid and best ask, print a spread, declare profit. I wanted to
know what happens when you keep going — when you model the depth behind that
top-of-book quote, the fact that your second leg can partially fill, the
sequence gap that silently corrupts your order book, and the restart that
happens at the worst possible time.
CrossVenue is the result: a multi-venue market data and execution
simulation engine in Go, built to be honest about where cross-exchange
trading actually breaks.
The gap between best-bid/best-ask and reality
A top-of-book spread is not an opportunity. CrossVenue computes
opportunities from actual depth: it walks the book, prices the fill at
VWAP, then subtracts configurable fees, modeled slippage, and a latency
penalty. Most "obvious" spreads don't survive that math — which is the
point.
And even when the math works, execution isn't atomic. You can't buy on
Binance and sell on OKX in one transaction. The simulator models partial
second-leg fills and surfaces the residual directional exposure you're left
holding when leg two only half-completes.
The unglamorous parts that matter
The core of the project is correctness under failure:
- Venue-specific sequence rules. Binance, OKX, and Bybit each handle ordering and gaps differently. A missed message invalidates the book — no silent delta loss, no trading on corrupt state. The book resyncs, and until it does, no opportunities are computed from it.
- Risk before execution, not after. Notional and exposure limits, stale quote rejection, a daily loss limit, and a kill switch — all evaluated pre-trade.
- Deterministic record/replay. Same recording + config + seed produces byte-identical books, opportunity streams, executions, balances, PnL, and a journal digest. There's an automated parity test proving it. Debugging a live trading incident without this is archaeology; with it, it's a unit test.
- Honest recovery. Restart restores portfolio state, but the system never resumes trading from stored book state. Books rebuild from fresh market data, because a stale book is worse than no book.
Eight failure scenes — sequence gaps, disconnects, stale quotes, partial
fills, duplicate order IDs, restarts, kill switch, queue overload — are
automated tests, not bullet points.
What it is not
CrossVenue does not claim profitable trading performance. Execution is
simulated by default, no live funds are required, and the default binary
cannot submit real orders. It's not HFT and it's not a production exchange
gateway. It's an engineering project about the infrastructure problems —
order-book correctness, non-atomic execution, inventory-aware risk,
deterministic replay — that decide whether a real system survives contact
with real markets.
Try it
# Offline demo: synthetic 3-venue feeds, no internet or Postgres needed
go run ./cmd/crossvenue --mode synthetic --config config.example.yaml
# Real public market data, paper execution
go run ./cmd/crossvenue --mode live-market-sim --config config.example.yaml
# Prove determinism: identical digests across runs
go run ./cmd/loadgen --venues 3 --events-per-second 200 --duration 5s --seed 42 --out data/demo.recording
go run ./cmd/replay --recording data/demo.recording --speed max
go run ./cmd/replay --recording data/demo.recording --speed max
There's an HTTP API for books, opportunities, and portfolio state, plus
Prometheus metrics, and make verify runs the full local validation:
tests, race detector, replay parity, failure scenes, and a Docker build.
If you work on trading infrastructure — or you've ever suspected that the
interesting part of arbitrage is everything except the spread — I'd
genuinely like your feedback.
Top comments (0)