Design a Crypto Market-Making Bot (AMM or Order Book)

Hard45 min
1 / 29
understanding•11 min read

Problem Statement: Continuous Two-Sided Quoting Under Adverse Selection

Frames the bot as a real-time risk engine that happens to place orders, not a trading script.

Problem statement

Design a market-making bot that continuously posts two-sided liquidity — a bid and an offer — on a centralized exchange (CEX) order book or an automated market maker (AMM) pool, while holding a bounded inventory of base and quote tokens. The system must ingest real-time market data, recompute spreads and quote sizes every decision cycle, detect large trades that move fair value, manage inventory risk, hedge on correlated venues, and for AMM liquidity provision, control impermanent loss by rebalancing concentrated ranges.

Market making is often misdescribed as 'placing buy and sell orders'. The correct framing is: the bot is selling insurance against short-term price moves and collecting the spread as premium. Every resting quote is an open option that can be filled precisely when the market moves against us — that is adverse selection. A toxic flow detector lifting our quotes milliseconds before a large market order arrives is worth more than any spread optimization. Therefore the architecture must be designed around four planes, and the weakest plane defines the PnL.

Why this problem is distinctive

A payment backend can retry for seconds; a market maker that is 500ms late to cancel during a flash crash is donating inventory to faster participants. The design separates decision correctness from execution survivability. Decision correctness: quotes priced off a fair value that is itself fresh. Execution survivability: when a venue feed gaps, a WebSocket drops, or an RPC node returns stale state, the system fails toward flat and canceled — never toward hoping.

The brief requires exchange/pool connectivity, spread and inventory strategy logic, real-time risk checks with optional cross-market hedging, and logging/analytics, with low latency, reliability, scalability, and key security as the non-functional spine. The deliverable must handle both venue classes because their physics differ: on a CEX the bot is a price-setter racing other bots; on an AMM the bot is a liquidity provider whose 'order' is a blockchain transaction whose latency is measured in block times (12s Ethereum mainnet, ~2s Base, sub-second on some L2s) and whose competition is arbitrageurs who see the same mempool.

Published scale context versus design assumptions

Public figures anchor the category. Binance has publicly described its matching engine handling on the order of 1.4 million orders per second at peak. Uniswap v3 has processed over $100B in monthly volume during high-activity periods and introduced concentrated liquidity, which is the exact mechanic an AMM market-making bot must manage. Hummingbot, the open-source market-making framework, reports community-reported aggregate trading volumes in the tens of billions of dollars per quarter across connected venues. Chainlink reports its oracle network securing tens of billions in value across hundreds of price feeds. These are cited company figures and set the environment; our bot operates far below exchange scale but must react to it.

For capacity planning, this answer assumes a professional small fund running 200 pairs across 8 CEX venues plus 40 AMM pools, with $50M total inventory, roughly 12,000 market data messages per second aggregated, and a peak order-update rate of about 2,000 per second. Unless tied to a citation, every number is a stated design assumption.

The four architectural planes

  1. Perception plane: normalized market data ingestion, order book reconstruction, trade tape, on-chain pool state, and fair value computation.
  2. Strategy plane: spread model, sizing model, inventory targeting, AMM range policy, and signal fusion.
  3. Execution plane: order routing, idempotent placement, cancel/replace, hedging orders, and AMM transaction construction.
  4. Risk and evidence plane: limits, kill switch, reconciliation, PnL attribution, and the audit trail that makes every loss explainable.

A strong answer keeps these planes separate. Strategy may degrade, perception may resync, execution may throttle — but the risk plane must be able to flatten the book on any venue within a hard budget regardless of the other three.

Key Highlights

  • •A resting quote is an open short-optionality position; adverse selection, not spread width, is the primary killer.
  • •CEX physics are millisecond races; AMM physics are block-time races against arbitrageurs; one bot must speak both.
  • •Binance's publicly cited ~1.4M orders/sec matching throughput is the environment our 2,000 msg/s bot must survive.
  • •Failure posture is fail-flat: feed gap or venue outage triggers quote pulls, not optimistic continuation.
  • •Four planes: perception, strategy, execution, risk — the risk plane can veto and flatten all three.
Lead With Adverse Selection
Say in the first two minutes that a resting quote is short optionality and that toxic-flow detection drives the cancel path. That instantly separates a market-making design from a generic trading-bot answer.
Do Not Draw a Polling Toy
A design that REST-polls the order book every second and market-orders the imbalance will lose to latency and to fees. Continuous quoting needs streaming data and a streaming order lifecycle.

Section Rescue Kit

Buzzwords to use:

Adverse SelectionFail-Flat Posture

Safe statements:

  • "I will separate making money from not losing it: strategy optimizes spread, but the risk plane decides when we are allowed to quote at all."
  • "Before choosing databases, let me define which decisions are latency-critical, which are correctness-critical, and which are merely auditable."
Design a Crypto Market-Making Bot (AMM or Order Book) - System Design | WinJob | WinJob