How to Build a Crypto Market Making Bot with Level 3 Order Book Data

Think of a crowded ticket counter. If you only see the first two people (Level 1 data) or a grouped estimate of people by row (Level 2), you miss the nuance. Real market makers need to see every single customer in line when they join, cancel, or move forward. That’s Level 3 order book data.

Market-making bots, like Bybit’s, rely on this microscopic view to continuously quote both sides of the book and manage risk in real time. Without L3, you’re trading blind.

What Makes Market Making Different

Unlike directional traders, you don’t chase price trends. You post both buy and sell orders, capture spreads, and provide liquidity. Your edge depends on:

1. Complete visibility: Every active order, not just price levels.
2. Microsecond awareness: Detecting cancellations and iceberg orders before the next trader.
3. Low-latency reaction: Canceling, replacing, or adding quotes faster than competitors.

For a deeper dive into how tick-level order book data works in practice, see CoinAPI’s Crypto Order Book Data: A Look at Tick-Level Information.

The Market Making Blueprint

Bybit and other exchanges run market-making systems that continuously quote both sides of the book (bid and ask) to earn the spread while providing liquidity. To replicate this, your bot needs to:

1. See all orders in the book (L3) Not just aggregated price levels (L2), but the individual orders behind them.
2. Track microstructure events in real time Additions, matches, cancellations - L3 captures them tick-by-tick.
3. React with low latency A market maker’s edge vanishes if your bot reacts slower than competitors.

With this feed, your bot can:

• Detect when a large iceberg order is slowly unwound.
• Spot when liquidity vanishes before a breakout.
• Prioritize cancel/replace decisions ahead of slower participants.

L1 vs L2 vs L3: Why L3 Wins for Bots

Example L3 snapshot (BTC/USDT):

This level of detail tells you when liquidity vanishes, how iceberg orders unwind, and whether you should pull your quotes to avoid toxic flow.

Challenges in Working with L3 Data

• Data firehose: Millions of updates per day overwhelm naive systems.
• Inconsistent formats: Exchanges use different update codes and order ID handling.
• Backtesting gap: Live feeds differ from what you can reconstruct historically.

We covered these pitfalls in detail in What Everyone Gets Wrong About L3 Data in Crypto, including how misinterpreting ADD/DELETE sequences leads to broken models.

How CoinAPI Helps

• Normalized L3 feeds: Unified ADD, SUB, MATCH, DELETE semantics.
• WebSocket & FIX streaming: Optimized for real-time bots.
• Flat Files for history: Daily CSV/GZ archives of full order books for accurate backtesting.

You can’t test market making with L2. Without L3 tick data, you’re modeling liquidity on averages, not reality.

CoinAPI’s Flat Files include full L3 order book data with per-order IDs. That means you can replay queue dynamics exactly as they happened - tracking adds, cancels, and matches at the order ID level. This goes far beyond aggregated L2 approximations and allows for realistic testing of market-making logic before deploying live.

Our Market Data WebSocket documentation explains how to subscribe to order book channels with proper sequencing, and the Historical Order Book REST API lets you retrieve snapshots and updates for replay.

When to Use L3 Data

If you’re building a market-making bot like Bybit’s, L3 isn’t optional - it’s the foundation.

Operational Burdens of L3: What You Must Plan For

Running a market-making bot on L3 is not just about connecting to a feed, it’s about handling a firehose of microstructure events without losing sync. Three practical challenges matter most:

• Memory footprint A single BTC/USDT book can hold 100k–300k active orders. Keeping every ID, timestamp, and update type in memory requires 0.5–1.5 GB of RAM per symbol. Scale that to dozens of pairs and you need tens of GBs for stable order book state.
• Replay logic L3 isn’t forgiving. If you miss a packet, your book drifts. Best practice: maintain an in-memory book with live updates, and reload a fresh snapshot every few minutes to reconcile. Without this, you’re trading against a “ghost book.”
• WebSocket backpressure During volatility, updates can spike to hundreds of thousands per second. If your consumer lags, messages queue up and drop. Avoid this by:
  • Using asynchronous message handling
  • Batching updates before passing them downstream
  • Monitoring sequence gaps and reconnecting on drift

Failing to plan for these realities is how desks burn six-figure budgets before strategies even go live.

How Fast Is Fast Enough? CoinAPI’s Latency Tiers

Latency is not a single number - it depends on your setup, geography, and budget. CoinAPI delivers the fastest technically possible speeds at each tier:

• Shared Infrastructure (50–500ms) Optimized WebSockets on cloud servers. Perfect for monitoring, dashboards, and mid-frequency bots. Not suitable for tight-spread market making.
• Enterprise (5–50ms) Dedicated servers, FIX API, regional routing. Strong fit for professional market makers who don’t co-locate but still need consistent sub-50ms reaction times.
• HFT-Grade (<1ms) Achieved with VPC peering, direct fiber, or physical cross-connects at exchange data centers. CoinAPI supports this, but you need custom infra, specialized hardware, and budgets in the $50k–500k+ range annually.

For most professional market-making operations quoting across multiple venues, the Enterprise tier is “fast enough.” If your business model is queue sniping or latency arbitrage, you’ll need HFT-grade setups.

Expect a small normalization overhead of about 1–2ms when using CoinAPI compared to raw exchange feeds. In practice, most of your latency budget comes from the exchange’s internal processing and your server’s geography. Normalization overhead is negligible compared to those factors.

If you’re still comparing providers, our guide on choosing the best crypto exchange API breaks down coverage, latency, and support models across the market.

FAQ: Market Making and L3 Data

What’s the practical difference between L2 and L3 for a bot?

L2 shows totals per price; L3 shows each order’s lifecycle. You model fill probability and cancel risk correctly only with L3.

Can I backtest market making on L2?

You can approximate, but your queue model and adverse selection math will be off. L3 is the right substrate for market-making backtests.

Which exchanges expose L3 today?

Availability is limited. Coinbase documents a true L3 view and strongly encourages WebSocket for maintaining the book; Bitso offers a non-aggregated full book API. Always check current docs before you build.

Is L3 overkill for non-HFT?

If you quote continuously or care about queue position, L3 helps. If you hold for days, L1/L2 may be enough.

How does L3 help with manipulation risk?

Order-level sequences make spoofing/layering more visible; recent papers use L3 to detect spoofability in real time.

We’ve also published real-world insights in How Level 3 Market Data Transforms Trading Performance - showing exactly how order-by-order visibility changes execution quality.

Conclusion: L3 Is Your Market Making Foundation

Market making lives and dies by microstructure. If you want to compete with systems like Bybit’s, you need Level 3 order book data. CoinAPI delivers normalized L3 feeds and backtestable archives so you can focus on writing smarter bots, not parsing messy feeds.

Market making lives and dies by microstructure. If your edge depends on queue position, cancellation patterns, or the lifecycle of individual orders, you cannot model it with L2. You need true L3, and you need infrastructure sized to handle its firehose. For desks serious about quoting across venues, Level 3 is not an upgrade, it’s the foundation.

Next step: Check CoinAPI’s Market Data API docs and Flat Files documentation to start building your quoting engine.