Day 2 of 7: Building a Polymarket Market Maker Bot From Zero to Complete
Before building a market-making bot, you need to understand how a trading market actually works.
In the first article of this series, we explored what a Polymarket market maker bot is, how bid-ask spreads work, and why automated liquidity provision can be an interesting trading strategy.
Today, we're going one step deeper: understanding the order book.
The order book tells your bot what buyers are willing to pay, what sellers are asking for, and how much liquidity is available at different prices.
Without this information, a bot might place poor orders, accumulate unwanted positions, or fail to react to changing market conditions.
In this tutorial, we'll explore:
- How an order book works
- How YES and NO tokens are traded
- How to calculate the spread and midpoint
- Why a wide spread doesn't guarantee profit
- How to measure order book liquidity
- How limit orders work
- What market data a Python trading bot needs
Let's get started.
1. What Is an Order Book?
An order book is a list of outstanding buy and sell orders for a particular token.
It has two main sides:
- Bids: Prices buyers are willing to pay.
- Asks: Prices sellers are willing to accept.
Imagine that your bot is analyzing a Polymarket YES token. The order book currently looks like this:
| Side | Price | Available Size |
|---|---|---|
| Ask | $0.54 | 100 tokens |
| Ask | $0.53 | 200 tokens |
| Ask | $0.52 | 150 tokens |
| Bid | $0.49 | 100 tokens |
| Bid | $0.48 | 250 tokens |
| Bid | $0.47 | 300 tokens |
The best bid is $0.49 because it is the highest available buy price.
The best ask is $0.52 because it is the lowest available sell price.
The difference between these prices is called the bid-ask spread.
Calculating the spread
The formula is simple:
Spread = Best Ask - Best Bid
Using our example:
$0.52 - $0.49 = $0.03
The spread is $0.03 per token.
For a market-making bot, this information helps determine where to place buy and sell orders.
However, the order book only shows available orders at a particular moment. Orders can be canceled, executed, or replaced as the market changes.
Your bot must continuously account for these changes rather than assume that displayed prices will remain available.
2. Understanding YES and NO Tokens
Polymarket markets commonly offer two complementary outcomes: YES and NO.
Consider this question:
Will Bitcoin be above $100,000 at the specified time?
A trader can buy:
- YES if they believe the condition will be satisfied.
- NO if they believe the condition will not be satisfied.
For a binary market with standard settlement, one winning outcome token pays $1 per share when the market resolves, while the losing token becomes worthless.
Here is an illustrative order book:
| Outcome | Best Bid | Best Ask |
|---|---|---|
| YES | $0.59 | $0.62 |
| NO | $0.38 | $0.41 |
These prices reflect supply and demand for each token. They are not guaranteed probabilities or guaranteed execution prices.
An important detail for developers
YES and NO are separate tradable tokens with their own order books.
You should not assume that their best bid and ask prices always add up to exactly $1.
Differences can arise because of spreads, available liquidity, and the fact that the two books may not contain executable orders at corresponding prices and sizes.
Practical takeaway: Retrieve the actual order book for the token your bot intends to trade. Don't assume you can calculate an executable price simply by subtracting the other token's price from $1.
Official reference: Polymarket FAQ
3. What Is the Midpoint?
The midpoint is the average of the best bid and best ask.
It provides a useful reference for understanding the current market.
The formula is:
Midpoint = (Best Bid + Best Ask) / 2
Suppose:
- Best bid: $0.49
- Best ask: $0.52
Then:
($0.49 + $0.52) / 2 = $0.505
The midpoint is $0.505.
But here's something important: the midpoint is not necessarily an executable price.
If the best bid is $0.49 and the best ask is $0.52, you cannot assume that you can immediately buy or sell at $0.505.
For a market-making bot, the midpoint can serve as a starting reference for calculating quotes. A more advanced strategy can adjust that reference based on inventory, volatility, and other market conditions.
Polymarket's displayed market price may use the order book midpoint or the last traded price when the spread exceeds its specified threshold. Therefore, a displayed probability should not automatically be treated as an executable price.
Further reading: How Are Prices Calculated?
4. Spread Is Not the Same as Profit
This is one of the most important lessons in market making.
A wide spread may look attractive, but it doesn't automatically create a profitable trading opportunity.
Let's examine two scenarios.
Scenario A: Both orders execute
Your bot buys 100 YES tokens at $0.48.
The total purchase cost is:
100 × $0.48 = $48
Your bot then sells 100 tokens at $0.52.
The gross difference is:
100 × ($0.52 - $0.48) = $4
If both orders execute as expected, the bot captures a gross difference of $4 before fees and other costs.
Scenario B: The market moves against your bot
Now imagine that the buy order executes, but the market price falls immediately afterward.
Your bot still owns 100 YES tokens purchased at $0.48 each.
However, buyers are now offering only $0.43 per token.
The indicative value of your position at that bid is:
100 × $0.43 = $43
Your original purchase cost was $48.
The difference is:
$43 - $48 = -$5
Your position has an indicative loss of $5 before other costs.
The sell order at $0.52 may never execute.
This is why a market-making strategy must evaluate more than the displayed spread.
A reliable bot should track:
- Completed round-trip trades
- Current inventory and its value
- Open and partially filled orders
- Execution costs and applicable incentives
- Price movements after orders execute
The goal isn't simply to find a wide spread. It's to quote prices that offer a reasonable expected return after accounting for execution and inventory risk.
5. What Is Order Book Depth?
Order book depth describes the quantity of buy and sell orders available at different price levels.
Let's compare two hypothetical markets:
| Metric | Market A | Market B |
|---|---|---|
| Best bid | $0.49 | $0.45 |
| Best ask | $0.51 | $0.55 |
| Bid size at best price | 1,000 | 20 |
| Ask size at best price | 1,200 | 25 |
| Spread | $0.02 | $0.10 |
Market A has a tighter spread and more displayed liquidity at the best prices.
Market B has a spread five times wider, but much less quantity available at its best bid and ask.
A beginner might conclude that Market B is the better opportunity.
That conclusion would be premature.
A wide spread might indicate low competition, but it can also reflect uncertainty, low trading activity, or difficulty finding counterparties.
If your bot places a large order in a market with limited depth, it may struggle to execute at the expected price or exit its position.
Also remember that displayed orders can be canceled before your order executes. Displayed depth is not guaranteed liquidity.
For a market maker, spread and depth must be evaluated together.
Further reading: Polymarket Trading Limits and Liquidity
6. How Does a Limit Order Work?
A limit order specifies the price at which you're willing to trade, subject to the exchange's matching rules.
Suppose the best ask for a YES token is $0.52.
Your bot submits a buy limit order at $0.49.
The order may remain in the order book until a compatible sell order arrives, unless it is canceled or otherwise expires.
But what happens if your bot submits a buy limit order at a price that crosses the available asks?
Depending on the order type and instructions, it may execute immediately against existing sell orders.
For market-making strategies, developers often want resting orders that add liquidity instead of immediately consuming existing liquidity.
Post-only instructions can help when supported. Their precise behavior depends on the API and order instructions.
Understand the order lifecycle
Your bot must distinguish between several different events:
- Submitting an order
- Having the order accepted
- Having the order resting in the order book
- Receiving a partial fill
- Receiving a complete fill
- Successfully canceling the order
These states are not interchangeable.
For example, a successful API response confirming that an order was submitted does not necessarily mean a trade occurred.
If your bot assumes that every submitted order has executed, its internal balance and inventory calculations can become incorrect.
Reliable order-state tracking is therefore a fundamental part of the system.
7. What Market Data Does a Polymarket Bot Need?
Now let's connect these concepts to the actual software architecture.
Before placing an order, a market-making bot needs several categories of information.
Market information
The bot needs to identify the market it wants to trade and retrieve the relevant token identifiers.
It should also understand the market's outcome definitions and resolution rules before trading.
Order book data
The bot needs the current bids and asks for its selected token.
From this information, it can calculate:
- Best bid and best ask
- Spread and midpoint
- Available quantity at each price level
- Changes in displayed depth
- Potential prices for its own orders
Order and account information
Market data alone isn't enough.
The bot also needs to know:
- Its open orders
- Current order statuses
- Available balances
- Current token positions
- Recent executions and partial fills
Imagine that the best bid changes from $0.49 to $0.47.
If your bot doesn't know whether its previous order filled, it might make its next decision using an incorrect inventory position.
That can lead to unintended exposure.
Real-time updates
A simple prototype can retrieve periodic order book snapshots using REST requests.
However, frequent polling can introduce unnecessary requests and miss changes between snapshots.
For a more responsive system, a market-data WebSocket can deliver updates as the order book changes.
Your bot must still maintain a consistent view of the order book and recover correctly after a connection disconnects.
Official developer documentation: Polymarket Developer Docs
8. Liquidity Rewards and Maker Rebates
Market makers may also encounter Polymarket's liquidity rewards and maker rebate programs.
Although both relate to liquidity provision, they are not identical.
Liquidity rewards generally depend on how useful qualifying resting orders are to the market. Eligible markets may have specific spread, size, and scoring requirements.
Maker rebates redistribute a portion of eligible taker fees to qualifying liquidity providers whose orders are filled, according to the program's rules.
Program details can change, and not every market necessarily qualifies.
Before incorporating incentives into your bot's profitability calculations, verify the current rules and market eligibility.
Don't assume that every limit order earns rewards or that incentives will compensate for trading losses.
Official references:
For the first version of your bot, treat incentives as a secondary consideration. Focus first on reliable order management, inventory tracking, and actual trading performance.
9. Checklist Before Building Your Market Maker
Before moving to Python implementation, make sure you understand the following concepts.
- [ ] Identify the YES and NO token identifiers for the selected market.
- [ ] Retrieve the actual order book for the token.
- [ ] Identify the best bid and best ask.
- [ ] Calculate the spread and midpoint correctly.
- [ ] Understand available depth across multiple price levels.
- [ ] Distinguish displayed prices from executable prices.
- [ ] Understand resting orders, partial fills, and cancellations.
- [ ] Check market-specific order requirements and trading rules.
- [ ] Verify which liquidity incentives, if any, apply.
- [ ] Track balances, inventory, and open orders.
These fundamentals will help you avoid common mistakes when implementing your strategy.
Conclusion
The Polymarket order book is the foundation of an automated market-making system.
It tells your bot what prices traders are offering, how much liquidity is available, and how the market changes over time.
But it doesn't guarantee that an order will fill or that a displayed spread can be captured profitably.
A reliable market maker combines order book data with accurate order management, inventory controls, and careful performance measurement.
The key lessons are straightforward:
- Order book: Understand the current supply and demand.
- YES/NO tokens: Retrieve the actual book for the token you intend to trade.
- Spread: Measure the difference between the best ask and best bid.
- Midpoint: Use it as a reference, not a guaranteed execution price.
- Liquidity: Evaluate both available quantity and spread.
- Risk management: Track inventory, fills, and changing market conditions.
In the next lesson, we'll move from theory to implementation by setting up a Python project, connecting to Polymarket market data, and retrieving the information our bot needs to make quoting decisions.
The goal is to build the system step by step, rather than rush into live trading before understanding the mechanics.
Follow the Project
GitHub repository:
https://github.com/Benj4minCup/Polymarket-Trading-Bot-python
YouTube tutorial:
https://www.youtube.com/watch?v=UCF7MA1Kekk
Contact and discussion:
https://telegram.me/BenjaminCup
If you're building your own market-making bot, share which part of order book analysis you find most challenging: spread calculation, liquidity analysis, order execution, or inventory management.
I'd love to hear what you're working on.
