A market maker’s job looks simple from the outside: keep buy and sell orders in the book and update them as the market moves.
What is less visible is everything that has to happen before those orders can be updated correctly. The strategy needs to receive the latest market data, decide how its prices should change, send instructions to the exchange and learn what happened to its previous orders. All of that can happen through different connections with different speed, delivery and recovery characteristics.
So when a market maker evaluates an exchange, “Does it have an API?” — is only the starting point. The more useful question is whether the entire path from a market event to the next order is reliable enough to trade on.
What happens before an order reaches the book
A simplified market-making cycle looks like this:
market event → order-book update → pricing decision → order entry → execution → inventory update → next order
Every step depends on the one before it. If market data is late or incomplete, the pricing decision is based on the wrong market. If an order reaches the venue later than expected, the price may already be outdated. If a fill is not reflected quickly enough, the strategy can continue quoting without an accurate view of its inventory.
That is why connectivity is part of the trading system itself, not simply the technical work required to connect the system to an exchange.
Three Layers Behind Every Quote
The stack can be simplified into 3 main layers:
Market data. The strategy needs a current view of bids, asks and order-book changes. With incremental feeds, that usually means building a local book from a snapshot and applying every subsequent update in the correct sequence.Order entry. New orders, cancellations and amendments need a channel with low and, importantly, predictable latency. A strategy that cannot estimate when an instruction reaches the venue has a harder time controlling its exposure.Execution state. Acknowledgements, fills, partial fills and cancellations need to flow back quickly enough to update inventory and trigger the next quote.
Different venues may expose these functions through WebSocket, FIX, REST, drop-copy feeds or other channels. What matters is not having the largest number of protocols, but using the right channel for each part of the trading cycle.
Why state consistency matters at scale
Raw latency gets most of the attention, but synchronization can be just as important.
Consider an incremental order-book feed. If one delta is dropped and the consumer misses the gap, later updates can continue arriving normally. The connection still looks healthy, but the local book is now being updated from the wrong state.
That creates one of the most dangerous situations for a market maker: the strategy keeps quoting, but the market it is quoting against is no longer the market the venue sees.
Recovery therefore has to be part of the design. The system needs to detect missing sequences, stop relying on corrupted state, retrieve a valid snapshot and rebuild the book before normal quoting resumes.
Three connectivity stacks in practice
There is no single architecture used by every venue. Current institutional offerings show several ways to separate market data, order entry and account or execution events.
WhiteBIT Market Making Program
rebates and discounts are based on the market maker’s 30-day maker volume;fees can go as low as -0.012% maker on both spot and futures, with taker fees from 0.020% on spot and 0.025% on futures;the program includes API access, subaccounts and 24/7 institutional support;qualification within the MM grid is based on a share of total volume rather than only a fixed absolute threshold.
Bybit Market Maker Program
the program covers Spot, Perpetuals/Futures and Options, with market-maker levels reviewed monthly;on Spot, qualification starts at more than $25M in 30-day trading volume for MM1, while higher tiers depend on maker-volume share or liquidity requirements;current Spot maker rebates range from -0.001% to -0.0075% depending on tier;new market makers receive a one-month trial period, while institutional clients also get REST/WebSocket API integration and dedicated support.
new market makers can qualify for an initial tier through account assets, proof of market-maker status on another exchange or existing maker volume; asset thresholds currently range from 50,000 USDT for Tier 5 to 2M USDT for Tier 1;current Spot maker rebates reach -0.010% on Group A and -0.015% on Group B for Tier 1, while Futures rebates reach up to -0.010% depending on the pair group;tiers are reassessed monthly using weighted maker volume and market-making performance;higher tiers also receive increased infrastructure capacity: Tier 1 UTA accounts can reach 300 API requests per second, alongside an institutional dedicated cluster and technical support.
The comparison is therefore broader than the headline maker rebate. A market maker is also choosing the qualification model, available infrastructure and the operating conditions under which its strategy will have to maintain liquidity.
Evaluate the path, not just the API
For a market maker choosing a venue, a basic API checklist does not go far enough. The better questions are:
How does market data reach us? What happens if an update is missed? How do we send and cancel orders? How do we learn that an order has been filled? How do sessions recover after a disconnect? How quickly can we rebuild a trustworthy state?
Those questions connect infrastructure directly to the job the market maker is trying to do: keep orders in the market while prices, executions and inventory are constantly changing.
A strong connectivity stack does not eliminate trading risk. It gives the market maker the information and execution channels needed to understand that risk fast enough to act on it.
Disclaimer: This is not financial or investment advice. DYOR before making any decisions. Use at your own risk.
From Market Data to Execution: How Market Making Works was originally published in Coinmonks on Medium, where people are continuing the conversation by highlighting and responding to this story.