DEV Community: Benjamin-Cup

Building Polymarket Trading Bot: From Backtesting to Live Trading(Market Maker)

Benjamin-Cup — Fri, 06 Nov 2026 18:45:18 +0000

Day 10 — Polymarket Trading Bot Development Series

A market-making strategy can perform well in historical simulations. But can it survive in a real market?

Moving from backtesting to live trading introduces a completely different set of engineering challenges.

Your bot must do more than calculate bid and ask prices. It needs to communicate with the exchange, manage orders, handle partial fills, recover from network failures, monitor inventory, and protect capital.

Consider this situation:

Your bot submits a BUY order for 100 YES tokens.
The exchange fills 40 tokens.
The remaining 60 tokens are still open.
The market price suddenly changes.
Your bot requests cancellation.
The network connection times out.

What should happen next?

Should the bot assume the order was canceled? Should it submit another order?

Making the wrong decision could create unexpected exposure.

In this article, we'll explore how to build a safer production architecture for a Python-based Polymarket market maker.

We'll cover:

Backtesting vs. paper trading vs. live trading
Production system architecture
Separating strategy from execution
Order lifecycle management
API errors and network recovery
Risk management
Production monitoring
Database persistence
VPS deployment

1. Understand the Three Stages of Trading

Before deploying a trading bot, understand these three development stages.

Stage 1: Backtesting

Backtesting uses historical market data to simulate how your strategy would have performed.

Typical operations include:

Replaying historical YES and NO prices.
Calculating bid and ask prices.
Simulating order fills.
Tracking inventory.
Calculating historical P&L.

The goal is to evaluate your strategy using past market conditions.

However, historical simulations cannot perfectly reproduce real exchange execution.

Stage 2: Paper Trading

Paper trading runs your strategy against current market data without submitting real orders.

For example:

Market midpoint: 0.50

Bot calculates:
BUY YES:  0.48
SELL YES: 0.52

Paper Trading:
BUY YES: 0.48
Status: Simulated Open Order

Market changes:
Best Ask: 0.48

Simulated Fill:
20 YES tokens

No real money is involved.

Paper trading helps test:

Live market data connections.
Strategy calculations.
Order management.
Inventory tracking.
Logging and monitoring.
Recovery after restarting the bot.

However, simulated fills cannot perfectly reproduce real queue priority, matching behavior, or exchange latency.

Stage 3: Live Trading

Live trading connects your bot to the actual exchange and submits real orders.

Now your system must handle:

Real account balances.
Actual order execution.
Partial fills.
Trading fees.
API failures.
Network interruptions.
Cancellation requests.
Financial risk.

Important: Never move directly from backtesting to large live orders.

2. Design a Production Architecture

A common mistake is putting the entire trading system into one Python file.

A better approach is separating responsibilities into independent components.

Here is a recommended architecture:

              Polymarket
                  |
                  v
          Market Data Service
                  |
                  v
            Strategy Engine
                  |
                  v
             Risk Manager
                  |
                  v
           Order Management
                  |
                  v
           Execution Adapter
                  |
                  v
              Polymarket
                  |
                  v
           Order / Trade Events
                  |
                  v
           Portfolio Manager
                  |
             +----+----+
             |         |
             v         v
         Monitoring  Database
             |         |
             +----+----+
                  |
                  v
              Dashboard

Let's understand the responsibilities.

Market Data Service

Collects order book updates, best bid and ask prices, trades, token identifiers, and market status.

Strategy Engine

Contains the market-making logic. It calculates reference prices, spreads, inventory adjustments, and desired order sizes.

Risk Manager

Checks whether proposed orders are allowed before they reach the exchange.

Order Management

Tracks order creation, open orders, partial fills, cancellation requests, and order replacement.

Execution Adapter

Communicates with the exchange API and translates internal order instructions into exchange requests.

Portfolio Manager

Tracks available cash, YES and NO inventory, average cost, realized P&L, unrealized P&L, fees, and open-order exposure.

Monitoring

Tracks bot health, active orders, market data freshness, API latency, errors, and risk-limit violations.

Separating these responsibilities makes the system easier to test, debug, and maintain.

3. Separate Strategy from Execution

One of the most important architectural decisions is separating the strategy engine from the execution engine.

Why?

Because the same strategy should work in three different environments:

Historical backtesting
Paper trading
Live trading

The strategy should decide what it wants to do.

The execution layer should decide how to perform that action.

For example, define an internal order model:

from dataclasses import dataclass
from decimal import Decimal
from typing import Literal

@dataclass
class OrderIntent:
    token_id: str
    side: Literal["BUY", "SELL"]
    price: Decimal
    quantity: Decimal

This object describes a proposed order. It does not submit anything to Polymarket.

Next, define an execution interface:

from typing import Protocol

class ExecutionClient(Protocol):

    async def submit_order(
        self,
        order: OrderIntent
    ) -> str:
        ...

    async def cancel_order(
        self,
        order_id: str
    ) -> None:
        ...

    async def get_open_orders(self):
        ...

    async def get_balances(self):
        ...

Different execution implementations can follow the same interface:

          ExecutionClient
                 |
       +---------+---------+
       |         |         |
       v         v         v
    Backtest   Paper     Live
    Client     Client    Client

The strategy doesn't need to know which execution environment is being used.

This makes testing much easier because you can evaluate the same strategy without risking real capital.

Note: This is an internal interface example, not a claim that Polymarket's SDK provides these exact method names.

4. Build a Safe Order Lifecycle Manager

Order management is one of the most important parts of a market-making system.

Imagine your bot submits a BUY order for 100 YES tokens.

The exchange reports:

Original Quantity: 100
Filled Quantity:    30
Remaining Quantity: 70
Status: PARTIALLY_FILLED

The strategy recalculates its quotes and decides to cancel the original order.

But cancellation takes time.

During that period, another 20 tokens might be filled.

Your final filled quantity is now 50, not 30.

Your bot must correctly handle this situation.

Recommended internal order states

             NEW
              |
              v
          SUBMITTING
              |
              v
             OPEN
              |
       +------+------+
       |             |
       v             v
PARTIALLY_FILLED  CANCEL_PENDING
       |             |
       |        +----+----+
       |        |         |
       v        v         v
    FILLED   CANCELED  PARTIALLY_FILLED
                         |
                         v
                       FILLED

The exact exchange statuses may differ. These are suggested internal states.

The most important distinction is:

Requesting cancellation is not the same as confirming cancellation.

For example, an order may receive additional fills while cancellation is pending.

Your system must process the final exchange state rather than assume that the cancellation request immediately stopped execution.

Also, every execution should have a unique identifier so duplicate trade events cannot increase inventory twice.

5. Handle API Errors and Network Failures

Live trading systems must expect failures.

Common problems include:

Network timeouts
API rate limits
Authentication failures
Insufficient balances
Exchange maintenance
WebSocket disconnections
Delayed responses
Unexpected API responses

One particularly dangerous situation happens when an order submission times out.

Consider this:

Bot submits BUY order for 100 YES
                |
                v
       Exchange accepts order
                |
                v
       Network connection fails
                |
                v
          Bot receives timeout
                |
                v
       Bot submits another order
                |
                v
       Potential duplicate exposure

The bot doesn't know whether the original order was accepted.

Blindly retrying could create two orders instead of one.

Use an uncertain-order state

A safer workflow is:

          SUBMITTING
               |
               v
             TIMEOUT
               |
               v
       SUBMISSION_UNKNOWN
               |
               v
      RECONCILE WITH EXCHANGE
               |
         +-----+-----+
         |     |     |
         v     v     v
       FOUND NOT FOUND
               |
               v
         STILL UNCERTAIN

When a submission response is uncertain:

Do not immediately submit another identical order.
Check the exchange's current order state.
Search using available order identifiers.
Reconcile open orders and recent trades.
Retry only when there is sufficient evidence that the original request was not accepted.

Use client-generated identifiers or idempotency mechanisms only where officially supported by the exchange API.

For read operations, exponential backoff can help:

import asyncio

async def retry_read_operation(
    operation,
    max_attempts=3
):
    for attempt in range(max_attempts):
        try:
            return await operation()

        except TimeoutError:
            if attempt == max_attempts - 1:
                raise

            await asyncio.sleep(2 ** attempt)

Do not apply this same blind retry approach to financial actions such as order creation.

6. Implement Risk Management

A profitable strategy is not automatically a safe strategy.

The risk manager should have the final decision about whether an order can be submitted.

Here are some essential controls.

Maximum order size

Prevent individual orders from becoming too large.

def validate_order_size(
    quantity,
    maximum_quantity
):
    return quantity <= maximum_quantity

Maximum inventory

Set separate limits for YES and NO positions.

def validate_inventory(
    current_quantity,
    proposed_quantity,
    maximum_quantity
):
    return (
        current_quantity + proposed_quantity
        <= maximum_quantity
    )

A complete implementation must also account for sells, existing orders, pending cancellations, and potential fills.

Maximum capital allocation

Don't allow the strategy to use all available funds just because it finds trading opportunities.

Example configuration:

risk:
  max_capital_allocation: 100
  max_order_value: 10
  max_yes_inventory: 100
  max_no_inventory: 100
  max_open_orders: 10
  max_daily_loss: 20

These values are illustrative, not financial recommendations.

Stale market data protection

Imagine your WebSocket disconnects.

Your bot still remembers that the market midpoint was 0.50, but the actual market has moved to 0.42.

Continuing to submit orders using old prices can create unnecessary risk.

A simple freshness check:

import time

def is_market_data_fresh(
    last_update_timestamp,
    maximum_age_seconds=3
):
    age = time.time() - last_update_timestamp

    return age <= maximum_age_seconds

If market data becomes too old, stop submitting new quotes until the feed is restored and reconciled.

Emergency stop

Every production trading bot needs a way to stop new trading activity.

class TradingSafety:

    def __init__(self):
        self.enabled = True

    def stop(self):
        self.enabled = False

    def can_trade(self):
        return self.enabled

Remember that stopping new orders and canceling existing orders are two different operations.

Your emergency-stop procedure should define both behaviors and be tested before deployment.

Consider open-order exposure

A common mistake is checking only filled inventory.

For example:

Current YES Inventory: 80
Open BUY Orders:       50

Potential Exposure:   130

Even though the bot currently holds only 80 YES tokens, another 50 could still be filled.

Risk management must consider this potential exposure.

7. Monitor Your Bot in Production

A bot that is running is not necessarily a bot that is working correctly.

Imagine your VPS runs overnight.

At 03:00:

The WebSocket disconnects.
Market data stops updating.
An order remains open.
The strategy continues using old prices.

Without monitoring, you might not discover the problem until much later.

A production monitoring system should track four main categories.

Market Data

Last market update time
WebSocket connection status
Order book update frequency
Data validation failures

Execution

Submitted orders
Open orders
Canceled orders
Partial and full fills
Submission errors
Cancellation errors
Execution latency

Portfolio

Available balance
YES and NO inventory
Open-order exposure
Realized and unrealized P&L
Trading fees
Total portfolio equity

System

CPU and memory usage
Process uptime
Restart count
API response time
Database errors
Application exceptions

Use structured logging so you can search by order ID, market ID, token ID, and error type.

Never put private keys, passwords, or API secrets into application logs.

8. Build a Production Dashboard

A dashboard helps you understand your bot's condition without reading every log entry.

For example:

====================================
       POLYMARKET MARKET MAKER
====================================

BOT STATUS
Status: RUNNING
Mode: PAPER
Uptime: 12h 34m

MARKET DATA
WebSocket: CONNECTED
Last Update: 0.2s ago
Market: BTC YES/NO

ORDERS
Open Orders: 4
Submitted Today: 25
Partial Fills: 6
Completed Fills: 12

PORTFOLIO
YES Inventory: 80
NO Inventory: 60
Available Balance: $85.00

PERFORMANCE
Realized P&L: $2.50
Unrealized P&L: $0.80
Trading Costs: $0.35

RISK
Maximum Inventory: NORMAL
Daily Loss Limit: NORMAL
Market Data: FRESH

====================================

The dashboard should clearly distinguish paper-trading results from actual live account values.

It should also show when data is unavailable or stale instead of displaying old values as if they were current.

9. Preserve Trading State with a Database

What happens if your VPS restarts unexpectedly?

If your bot stores everything only in Python variables, it may lose important information about previous orders and inventory.

A database helps preserve the system's state.

You may need tables such as:

Table	Responsibility
`bot_orders`	Order IDs, prices, quantities, and statuses
`bot_trades`	Individual executions
`inventory`	Current YES and NO positions
`market_snapshots`	Historical market data
`bot_events`	Important operational events
`risk_events`	Risk violations and emergency stops

A simplified SQL example:

CREATE TABLE bot_orders (
    id BIGSERIAL PRIMARY KEY,
    exchange_order_id TEXT UNIQUE,
    market_id TEXT NOT NULL,
    token_id TEXT NOT NULL,
    side TEXT NOT NULL,
    price NUMERIC(18, 8) NOT NULL,
    original_quantity NUMERIC(18, 8) NOT NULL,
    filled_quantity NUMERIC(18, 8) NOT NULL DEFAULT 0,
    status TEXT NOT NULL,
    created_at TIMESTAMPTZ NOT NULL DEFAULT NOW()
);

For execution records:

CREATE TABLE bot_trades (
    id BIGSERIAL PRIMARY KEY,
    exchange_trade_id TEXT UNIQUE,
    exchange_order_id TEXT,
    token_id TEXT NOT NULL,
    side TEXT NOT NULL,
    price NUMERIC(18, 8) NOT NULL,
    quantity NUMERIC(18, 8) NOT NULL,
    executed_at TIMESTAMPTZ NOT NULL
);

The unique execution identifier helps prevent duplicate fills from being recorded twice.

For financial calculations, use exact decimal arithmetic rather than ordinary floating-point calculations.

Important: Your local database should not automatically be treated as the source of truth for current exchange state.

After restarting, reconcile your stored records against the exchange's open orders, recent trades, and account balances.

10. Recover Safely After a Restart

Restarting a trading bot requires more than simply running the Python application again.

Imagine:

Three orders were open.
Two orders had partial fills.
The VPS restarted.
The Python process started again.

The bot must understand what happened before it starts trading.

A recommended startup sequence:

          Start Bot
              |
              v
       Load Configuration
              |
              v
       Connect to Exchange
              |
              v
        Retrieve Balances
              |
              v
       Retrieve Open Orders
              |
              v
       Retrieve Recent Trades
              |
              v
      Reconcile Local Database
              |
              v
       Validate Market Data
              |
              v
          Run Risk Checks
              |
              v
       Enable New Quoting

If the exchange state and local database disagree, stop new trading and investigate.

For example, your database says an order is canceled, but the exchange reports that it is still open.

You must reconcile that order before continuing.

11. Deploy the Bot on a VPS

A VPS (Virtual Private Server) allows your bot to run continuously without keeping your personal computer switched on.

A basic deployment architecture:

Developer Computer
        |
        v
      Git Push
        |
        v
   Git Repository
        |
        v
       VPS
        |
   +----+----+----+
   |         |    |
   v         v    v
 Python   Database Monitoring
Environment
   |
   v
Market Maker Bot

Basic deployment steps

Step 1 — Prepare the server

Install Python and the required system dependencies.

Step 2 — Clone the repository

git clone YOUR_REPOSITORY_URL
cd polymarket-market-maker

Step 3 — Create a virtual environment

python3 -m venv .venv
source .venv/bin/activate

Step 4 — Install dependencies

pip install -r requirements.txt

Step 5 — Configure environment variables

Store authentication credentials securely.

Never commit real credentials to GitHub.

Step 6 — Start in paper mode

python -m src.main --mode paper

This assumes your application implements a --mode argument.

Step 7 — Check logs

Verify that:

Market data is updating.
Strategy calculations are working.
Simulated orders are recorded.
Inventory calculations are correct.
Risk checks are active.
No unexpected errors appear.

Step 8 — Configure process supervision

Use an appropriate process manager to monitor the application and control restarts.

However, automatic restarts do not guarantee trading safety.

Your application must complete its recovery and reconciliation process before enabling new orders.

12. Protect API Credentials

Security is part of production engineering.

Your bot may need credentials or signing permissions to submit orders.

Important practices:

Never publish private keys on GitHub.
Never hardcode secrets in Python files.
Use environment variables or a secure secret manager.
Restrict server access.
Prefer SSH keys over password-only access.
Keep dependencies updated.
Separate testing credentials from production credentials.
Rotate credentials if they may have been exposed.
Never print authentication headers or private keys in logs.

Evaluate restricted signing permissions or session-based authorization when supported by the current official documentation.

The goal is to reduce potential damage if your server or application is compromised.

13. Follow a Gradual Live-Trading Plan

Don't move directly from backtesting to large live orders.

Use a controlled rollout.

Phase	Main objective
1. Backtesting	Validate strategy and historical performance
2. Paper Trading	Test against current market data
3. Operational Testing	Simulate failures and recovery
4. Small Live Deployment	Test real execution with strict limits
5. Gradual Evaluation	Evaluate actual performance before increasing exposure

During operational testing, deliberately simulate:

WebSocket disconnections.
VPS restarts.
API timeouts.
Invalid market data.
Risk-limit violations.
Partially filled orders.

Confirm that the bot behaves safely in every scenario.

There is no fixed number of paper-trading hours that proves a strategy is safe. The testing period should depend on market activity and the amount of execution data collected.

14. Production Readiness Checklist

Before enabling real orders, review the following checklist.

Strategy

[ ] Bid and ask calculations are tested.
[ ] Dynamic spread logic is tested.
[ ] Inventory adjustments are working.
[ ] Stale market data prevents new quotes.

Execution

[ ] Order submission is implemented.
[ ] Order cancellation is implemented.
[ ] Partial fills are handled.
[ ] Duplicate execution events are prevented.
[ ] Unknown submission states are reconciled.
[ ] Existing orders are checked before replacement.

Portfolio

[ ] YES inventory is tracked.
[ ] NO inventory is tracked.
[ ] Available balances are checked.
[ ] Open-order exposure is included.
[ ] Realized and unrealized P&L are separated.
[ ] Fees and resolution outcomes are accounted for.

Risk

[ ] Maximum order size is configured.
[ ] Maximum inventory is configured.
[ ] Capital allocation is limited.
[ ] Daily loss limits are configured.
[ ] Emergency-stop behavior is tested.
[ ] Strategy code cannot bypass risk checks.

Infrastructure

[ ] Logs are available.
[ ] Monitoring is configured.
[ ] Database records are persistent.
[ ] Startup reconciliation is implemented.
[ ] Credentials are protected.
[ ] VPS access is secured.
[ ] Backups and recovery procedures are tested.

Conclusion

Building a Polymarket market maker is not just about calculating profitable bid and ask prices.

A production trading system must manage the entire process:

Collect reliable market data.
Generate trading quotes.
Validate risk limits.
Submit and manage orders.
Track partial fills.
Manage inventory.
Recover from failures.
Monitor performance.
Preserve state after restarts.

The most important lesson is:

Never assume an order was filled, canceled, or rejected until you have enough information to confirm its actual state.

Backtesting helps evaluate your strategy.

Paper trading helps test the system under current market conditions.

Production engineering makes the system more reliable.

However, none of these guarantees profitable trading. Real execution introduces financial risks that simulations cannot completely reproduce.

Before increasing trading activity, focus on making your bot predictable, observable, and recoverable.

Continue Building Your Polymarket Trading Bot

If you're following this development series, you can explore the project and tutorials here:

GitHub: https://github.com/Benj4minCup/Polymarket-Trading-Bot-python
YouTube: https://www.youtube.com/watch?v=UCF7MA1Kekk
Telegram: https://telegram.me/BenjaminCup

Coming Next — Day 11

Advanced Polymarket Market Maker Architecture: WebSockets, Real-Time Order Book Processing, and Low-Latency Execution

In the next article, we'll explore:

WebSocket market data connections.
Processing real-time order book updates.
Maintaining local order book state.
Detecting stale or missing data.
Asynchronous Python architecture.
Separating market data and execution tasks.
Reducing unnecessary API requests.
Building a more responsive trading system.

The goal is to understand how to build a market maker that reacts to changing market conditions without relying on slow, repeated polling.

polymarket #trading #bot #tutorial #python

Polymarket Trading Bot :Market Maker - How to Backtest Strategies and Optimize Trading Parameters

Benjamin-Cup — Thu, 05 Nov 2026 23:00:10 +0000

Day 9 — Building a Python backtesting framework to simulate order execution, measure performance, and optimize market-making strategies.

Introduction

In the previous article, we built an adaptive market-making strategy that adjusts its spreads based on volatility, liquidity, and inventory.

But an important question remains:

How do we know whether our strategy actually works?

Imagine your Polymarket bot places:

YES buy order at $0.48
YES sell order at $0.52
Order quantity: 100 tokens

The theoretical gross profit is:

(0.52 - 0.48) * 100 = $4.00

Looks profitable, right?

But what if:

Your buy order never gets filled?
Your order is only partially filled?
The market moves against you immediately after execution?
Other traders are ahead of you in the order queue?
Trading costs eliminate your spread?

This is why we need backtesting.

In this article, we'll build the foundation of a Python backtesting framework for a Polymarket market maker bot.

We'll cover:

Backtesting fundamentals
Historical market data
Market-making quote calculations
Limit-order execution simulation
Inventory and P&L tracking
Performance metrics
Parameter optimization
Avoiding overfitting
Preparing for paper trading

1. What Is Backtesting?

Backtesting means testing a trading strategy against historical market data to estimate how it would have performed in the past.

Instead of immediately connecting your bot to a real trading account, you replay historical market conditions and simulate the decisions your bot would have made.

Think of it like a flight simulator.

You can test different situations without risking a real aircraft. Backtesting provides a similar environment for trading strategies.

For example, we can compare three configurations:

Strategy	Half-spread	Order size
A	$0.01	10 tokens
B	$0.02	10 tokens
C	$0.03	10 tokens

Using the same historical data, we can compare:

Number of executed orders
Captured spread
Inventory exposure
Maximum drawdown
Net profitability

Backtesting vs. Paper Trading vs. Live Trading

Stage	Purpose	Real money
Backtesting	Replay historical data	No
Paper trading	Simulate current market conditions	No
Live trading	Execute real orders	Yes

A successful backtest does not guarantee successful live trading. Each stage reveals different problems.

2. Understand the Backtesting Architecture

Before writing code, let's understand the main components.

A basic backtesting system needs six components:

       Historical Market Data
                |
                v
        Market Replay Engine
                |
                v
           Strategy Engine
                |
                v
        Execution Simulator
                |
                v
         Portfolio Manager
                |
                v
       Performance Analyzer
                |
                v
          Backtest Results

Each component has a separate responsibility.

Component	Responsibility
Historical Data	Stores market snapshots and trades
Replay Engine	Replays historical events chronologically
Strategy Engine	Calculates bid and ask prices
Execution Simulator	Simulates order fills
Portfolio Manager	Tracks inventory, cash, and P&L
Performance Analyzer	Calculates performance and risk metrics

One important design principle:

The strategy should propose orders, but the execution simulator should decide whether those orders get filled.

This separation makes the system easier to test and improve.

3. Collect Historical Market Data

A backtesting system is only as reliable as its historical data.

For a Polymarket market maker, useful data includes:

Data	Purpose
Timestamp	Reconstruct market events
YES best bid/ask	Track YES market prices
NO best bid/ask	Track NO market prices
Bid/ask depth	Measure available liquidity
Trade price	Track executed prices
Trade size	Track executed quantities
Market ID	Identify the market
Token ID	Identify YES or NO tokens
Tick size	Validate quote prices
Fee information	Calculate trading costs
Market status	Identify active or resolved markets

Why Is Order Book Depth Important?

Consider two markets:

Market A

Price	Available quantity
$0.49	1,000
$0.48	800
$0.47	500

Market B

Price	Available quantity
$0.49	10
$0.48	5
$0.47	3

Both markets have the same best bid.

However, their liquidity is completely different.

If your bot wants to buy 100 tokens, Market A has much more available liquidity.

This is why using only the best bid and ask is insufficient.

Snapshots vs. Event-Level Data

There are two common approaches:

Order book snapshots

Record the order book at specific intervals.

Event-level data

Record individual changes, such as orders being added, removed, or executed.

Event-level data provides more detailed information and is preferable for realistic execution simulation when available.

4. Calculate Market Metrics and Quotes

Let's start with basic market calculations.

The midpoint is:

midpoint = (best_bid + best_ask) / 2

The spread is:

spread = best_ask - best_bid

For example:

best_bid = 0.48
best_ask = 0.52

midpoint = (best_bid + best_ask) / 2
spread = best_ask - best_bid

print(midpoint)  # 0.50
print(spread)    # 0.04

Now calculate the market-making quotes.

def calculate_quotes(midpoint, half_spread):
    bid = midpoint - half_spread
    ask = midpoint + half_spread

    return {
        "bid": round(bid, 4),
        "ask": round(ask, 4)
    }

Example:

quotes = calculate_quotes(
    midpoint=0.50,
    half_spread=0.02
)

print(quotes)

Output:

{
    "bid": 0.48,
    "ask": 0.52
}

This is our basic quoting model.

In production, we must also validate tick size, order quantity, available balance, market status, and inventory risk.

5. Simulate Realistic Order Execution

This is one of the most important parts of backtesting.

A market price touching your limit order does not automatically mean your order gets filled.

Imagine your bot places a YES buy order at $0.48.

There are already 300 tokens ahead of your order at that price.

Another trader sells 50 tokens at $0.48.

Your order receives nothing because the earlier orders have priority.

This is called queue position.

A simplified execution model:

def calculate_fill_quantity(
    trade_volume,
    quantity_ahead,
    remaining_order_quantity
):
    available = max(
        0,
        trade_volume - quantity_ahead
    )

    return min(
        available,
        remaining_order_quantity
    )

Example:

fill = calculate_fill_quantity(
    trade_volume=150,
    quantity_ahead=100,
    remaining_order_quantity=80
)

print(fill)  # 50

The estimated fill is 50 tokens.

This is only an educational approximation. A realistic simulator must account for actual matching rules, queue changes, and available historical data.

Important Execution Scenarios

Your simulator should eventually support:

No fills
Full fills
Partial fills
Multiple partial fills
Order cancellations
Cancellation delays
Order replacements
Expired orders
Network interruptions

A realistic execution simulator is often more valuable than adding another complicated trading indicator.

6. Track Order States and Inventory

Your backtesting engine needs to understand the lifecycle of each order.

A simplified order state machine:

       NEW
        |
        v
       OPEN
        |
        v
     PARTIAL
      /   \
     v     v
  FILLED  CANCELED

For example, your bot submits an order for 100 YES tokens.

First execution: 30 tokens
Second execution: 40 tokens
Remaining quantity: 30 tokens

Your system must accurately track the executed quantity and remaining quantity.

You also need to track YES and NO inventory separately.

Example:

class Inventory:

    def __init__(self):
        self.yes_quantity = 0
        self.no_quantity = 0

        self.yes_cost = 0.0
        self.no_cost = 0.0

    def buy_yes(self, quantity, price):
        self.yes_quantity += quantity
        self.yes_cost += quantity * price

    def buy_no(self, quantity, price):
        self.no_quantity += quantity
        self.no_cost += quantity * price

Usage:

inventory = Inventory()

inventory.buy_yes(100, 0.48)
inventory.buy_no(50, 0.47)

print(inventory.yes_quantity)  # 100
print(inventory.no_quantity)   # 50

A complete portfolio manager should also track:

Average cost basis
Sell quantities
Realized P&L
Unrealized P&L
Trading fees
Cash balance
Resolution payouts

Remember: a market maker is not automatically market-neutral.

Accumulating too many YES or NO tokens can create significant directional exposure.

7. Calculate P&L and Performance Metrics

Let's calculate a simple completed trade.

Assume:

Buy price: $0.48
Sell price: $0.52
Quantity: 100
Trading costs: $0.30

Gross P&L:

gross_pnl = (0.52 - 0.48) * 100

print(gross_pnl)  # 4.00

Net P&L:

net_pnl = gross_pnl - 0.30

print(net_pnl)  # 3.70

But total profit is not enough to evaluate a strategy.

We also need to measure risk.

Important Performance Metrics

1. Net P&L

How much money did the strategy make after trading costs?

2. Fill Rate

What percentage of submitted order quantity was executed?

fill_rate = filled_quantity / submitted_quantity

A higher fill rate is not always better. Aggressive quotes can receive more fills but suffer from adverse selection.

3. Maximum Drawdown

Measures the largest decline from a previous portfolio equity peak.

For example:

Time	Portfolio equity
1	$1,000
2	$1,100
3	$1,050
4	$950
5	$1,150

The drawdown from $1,100 to $950 is:

drawdown = (1100 - 950) / 1100

print(drawdown)  # 0.1364

That's approximately 13.64%.

4. Adverse Selection

This happens when your order gets filled and the market immediately moves against you.

Example:

Your bot buys YES at $0.50.
The order gets filled.
The midpoint falls to $0.47.
Your position loses approximately $0.03 per token at the new midpoint.

A useful measurement is markout:

buy_markout = midpoint_after - fill_price
sell_markout = fill_price - midpoint_after

Measure markout over multiple time horizons, such as 1, 5, and 30 seconds.

5. Inventory Exposure

Track how much capital is tied up in YES and NO positions.

Also consider the possible resolution outcomes instead of relying only on token quantity differences.

8. Optimize Trading Parameters

Now we can start comparing different strategy configurations.

Some important parameters include:

Parameter	Example values
Minimum half-spread	0.01, 0.02, 0.03
Maximum half-spread	0.03, 0.05, 0.08
Order size	5, 10, 20
Maximum inventory	50, 100, 200
Inventory skew	0.0001, 0.0002
Quote refresh interval	1s, 2s, 5s

We can define experiments in Python:

experiments = [
    {
        "name": "baseline",
        "half_spread": 0.02,
        "order_size": 10,
        "max_inventory": 100
    },
    {
        "name": "wider_spread",
        "half_spread": 0.03,
        "order_size": 10,
        "max_inventory": 100
    },
    {
        "name": "smaller_inventory",
        "half_spread": 0.02,
        "order_size": 5,
        "max_inventory": 50
    }
]

Run every configuration against the same historical dataset.

Then compare the results:

Strategy	Net P&L	Fill rate	Max drawdown
Baseline	$50	45%	8%
Wider spread	$42	30%	4%
Smaller inventory	$38	35%	2%

These numbers are hypothetical examples.

The baseline generates the highest profit, but it also has the largest drawdown.

The smaller-inventory strategy earns less but has lower risk.

Don't optimize only for maximum historical profit.

Consider profitability, drawdown, inventory exposure, adverse selection, and consistency.

9. Avoid Overfitting

Overfitting is one of the biggest problems in quantitative trading.

It happens when you adjust a strategy so heavily to historical data that it performs well on past observations but poorly on new market conditions.

A practical solution is to divide historical data into three periods.

Dataset	Purpose
Training	Develop the strategy
Validation	Compare configurations
Testing	Evaluate unseen historical data

For example:

January–March: Training
April: Validation
May: Testing

These dates are illustrative.

Keep the periods chronological. Never allow future market information to influence earlier trading decisions.

Walk-Forward Testing

Another useful approach is walk-forward testing.

Tune parameters using an earlier period.
Test the selected configuration on the next unseen period.
Move the testing window forward.
Repeat.
Compare performance across all periods.

This helps determine whether your strategy can adapt to changing market conditions.

10. Account for Realistic Trading Conditions

A good backtest should not assume perfect execution.

Consider these factors:

Factor	Why it matters
Trading fees	Reduce captured spread
Queue position	Orders may not receive fills
Partial fills	Orders may execute gradually
Latency	Prices can change before execution
Cancellation delays	Orders may fill before cancellation completes
Adverse selection	Filled orders may move against you
Resolution risk	Open positions have final settlement outcomes

I recommend testing three execution scenarios:

Optimistic: Higher fill probability and lower latency.

Base case: Conservative queue and execution assumptions.

Stress case: Lower fill probability, higher costs, and delayed cancellations.

If your strategy only works under optimistic assumptions, it needs further investigation.

11. Organize the Python Project

As the backtesting system grows, avoid putting everything into one Python file.

A modular project structure could look like this:

polymarket-market-maker/
│
├── config/
│   ├── backtest.yaml
│   └── strategy.yaml
│
├── data/
│   ├── historical/
│   └── processed/
│
├── src/
│   ├── data/
│   │   ├── loader.py
│   │   └── validator.py
│   │
│   ├── strategy/
│   │   ├── market_maker.py
│   │   ├── spread_model.py
│   │   └── inventory_skew.py
│   │
│   ├── execution/
│   │   ├── simulator.py
│   │   ├── order.py
│   │   └── fill_model.py
│   │
│   ├── portfolio/
│   │   ├── inventory.py
│   │   └── pnl.py
│   │
│   ├── backtesting/
│   │   ├── engine.py
│   │   └── metrics.py
│   │
│   └── main.py
│
├── tests/
├── results/
├── requirements.txt
└── README.md

Each directory has a clear responsibility.

The main advantage is that the strategy can eventually be reused with different execution adapters:

Backtesting execution
Paper trading execution
Live exchange execution

This makes the system easier to maintain and extend.

12. Common Backtesting Mistakes

Before finishing, remember these common mistakes:

Assuming every order gets filled.
Ignoring trading fees.
Ignoring partial executions.
Using future information.
Optimizing only for historical profit.
Ignoring remaining inventory.
Testing on insufficient historical data.
Treating paper trading as proof of live execution.
Changing too many parameters simultaneously.

A backtest should help you understand where your strategy fails, not just where it succeeds.

Conclusion

Building a Polymarket market maker bot is not just about calculating attractive bid and ask prices.

You also need to understand:

Whether your orders can realistically get filled.
How much inventory they accumulate.
How execution costs affect profitability.
How the strategy behaves under different market conditions.
Whether its performance remains consistent on unseen data.

Remember these three lessons:

Realistic execution matters more than impressive backtest profits.
Always test your strategy on historical data it has never seen before.
Risk management and inventory exposure matter as much as profitability.

A strategy that survives realistic simulations and unseen historical periods is a stronger candidate for paper trading.

However, even a strong backtest cannot guarantee future profitability.

What's Next? Day 10

Polymarket Market Maker Bot: From Backtesting to Live Trading and Production Monitoring

In the next article, we'll explore:

Connecting the strategy to an execution engine.
Moving from backtesting to paper trading.
Monitoring orders and partial fills.
Handling API failures and network interruptions.
Managing risk during live operation.
Building production monitoring workflows.

Follow the Project

If you're interested in building a Polymarket trading bot with Python, check out the project:

GitHub:

Benj4minCup / Polymarket-Trading-Bot-python

polymarket Twap Bot polymarket Arbitrage Bot polymarket bot

Polymarket Trading bot system

An open-source and Strong Strategy collection of Polymarket trading bot and Polymarket arbitrage bot and Polymarket TWAP trading bot in Python for high-performance automated trading on polymarket crypto 5min and 15min markets.

This repository is primarily intended for educational and research purposes. It includes strategy concepts, implementation approaches, and selected performance screenshots to help developers understand how different automated trading strategies can be designed and tested.

The repository does not provide a complete production-ready trading bot source code. Instead, it provides strategy descriptions and research materials that you can use as a foundation for developing your own system.

If you are interested in building a Polymarket Trading Bot, you can follow my tutorials and use the concepts in this repository to develop your own implementation.

For users who prefer a ready-to-deploy solution or require custom strategy development, commercial bot development and customization are also available.

Features
…

View on GitHub
YouTube:

src="https://www.youtube.com/embed/UCF7MA1Kekk"
width="710"
height="399"
style="width: 100%; height: auto; aspect-ratio: 16 / 9;"
allowfullscreen
loading="lazy">
Telegram: https://telegram.me/BenjaminCup

Disclaimer: This article is for educational purposes only and does not constitute financial advice. Backtesting and simulated performance do not guarantee future results. Prediction-market trading involves financial risk, including the possibility of losing your entire trading capital.

Advanced Polymarket Market Making Strategy: Dynamic Spreads, Volatility, and Market Conditions in Python

Benjamin-Cup — Wed, 04 Nov 2026 13:23:33 +0000

Day 8: Taking Your Polymarket Market Maker Bot Beyond the Basics

In the first seven articles, we built the foundation of a Polymarket market maker bot.

We learned how to understand the order book, retrieve market data, calculate bid and ask prices, manage orders, handle partial fills, control inventory risk, and prepare a bot for deployment.

But there is still one important question:

Should your market maker use the same spread and order size in every market condition?

Imagine two situations.

Situation A: A quiet market

BTC is moving slowly. The Polymarket order book has reasonable liquidity, and the best bid and ask prices are relatively stable.

Situation B: A volatile market

BTC suddenly moves sharply. The order book changes quickly, liquidity disappears, and the probability of a YES outcome changes rapidly.

Should your bot use exactly the same bid, ask, and order size in both situations?

Probably not.

A fixed-spread market maker is easier to build, but it does not automatically adapt to changing market conditions.

In this article, we'll explore how to build a more adaptive market maker using dynamic spreads, volatility measurements, liquidity checks, and market-regime filters.

We'll cover:

Why fixed spreads can be dangerous.
How to estimate short-term volatility.
How to adjust spreads dynamically.
How to adapt order size to market liquidity.
How to identify unstable market conditions.
How to combine volatility and inventory controls.
How to implement a basic adaptive pricing model in Python.
How to evaluate whether dynamic quoting actually improves performance.

The goal is to make the bot respond intelligently to changing conditions instead of using one fixed configuration all the time.

1. Why Fixed-Spread Market Making Has Limitations

Let's start with a simple market maker.

Suppose the YES token has a midpoint of $0.50.

Your bot always uses a half-spread of $0.02.

It calculates:

[
Bid=0.50-0.02=0.48
]

[
Ask=0.50+0.02=0.52
]

The resulting spread is four cents.

This is easy to understand and implement.

However, market conditions do not remain constant.

When volatility is low, a four-cent spread might be unnecessarily wide. Other traders may offer better prices, making your orders less competitive.

When volatility is high, the same four-cent spread might be too narrow. Your orders may be filled just before the market moves against you.

This creates two different problems:

In calm markets: Your quotes may be too conservative.

In volatile markets: Your quotes may be too aggressive.

A dynamic market maker attempts to adjust its behavior based on the current market environment.

It does not guarantee better results, but it gives the strategy a way to respond to changing risk.

2. Understand Market Volatility

Volatility describes how much a price changes over time.

A market with small, gradual price movements has relatively low short-term volatility.

A market with large and frequent price movements has relatively high short-term volatility.

For a Polymarket crypto market maker, you might monitor two different types of prices:

The Polymarket YES or NO token price.
The underlying cryptocurrency reference price, such as BTC.

These prices provide different information.

The Polymarket token price reflects the market's changing probability estimate and available trading liquidity.

The BTC price reflects movement in the underlying asset.

For a BTC Up/Down market, both can be useful, but they should not be mixed into one measurement without a clearly defined model.

A simple example

Imagine these BTC prices:

Time	BTC price
10:00:00	$100,000
10:00:05	$100,010
10:00:10	$100,008
10:00:15	$100,012

The movement is relatively small.

Now imagine:

Time	BTC price
10:00:00	$100,000
10:00:05	$100,150
10:00:10	$99,920
10:00:15	$100,180

The second sequence shows much larger price changes.

A market maker should consider whether its current spread and order size are appropriate for each environment.

3. Calculate Short-Term Volatility in Python

One simple approach is to calculate price returns.

A return measures the percentage change between two consecutive prices.

[
r_t=\frac{P_t-P_{t-1}}{P_{t-1}}
]

For example, if BTC moves from $100,000 to $100,100:

[
r_t=\frac{100100-100000}{100000}=0.001
]

That is a return of 0.1%.

We can calculate the standard deviation of recent returns to estimate short-term volatility.

from collections import deque
from decimal import Decimal
from statistics import pstdev


class VolatilityTracker:
    def __init__(self, max_samples=30):
        self.prices = deque(maxlen=max_samples)

    def add_price(self, price: Decimal):
        if price <= 0:
            raise ValueError("Price must be positive")

        self.prices.append(price)

    def calculate_volatility(self):
        if len(self.prices) < 3:
            return None

        returns = []

        for previous, current in zip(
            list(self.prices)[:-1],
            list(self.prices)[1:],
        ):
            returns.append(
                float((current - previous) / previous)
            )

        return pstdev(returns)

This example calculates the population standard deviation of the observed returns.

It is intentionally simple. A production implementation should define its sampling interval, handle missing data, use consistent timestamps, and consider whether a rolling or exponentially weighted volatility estimate is more appropriate.

Also remember that the output depends on the data frequency.

Thirty price observations collected every second describe a different time horizon from thirty observations collected every minute.

Do not compare volatility values without considering their sampling intervals.

4. Use Volatility to Adjust the Spread

Now let's connect volatility to quote calculation.

In Day 4, we used a fixed half-spread.

Now we want the half-spread to change according to market conditions.

A simplified formula is:

[
H=H_{\min}+\alpha V
]

Where:

(H) is the dynamic half-spread.
(H_{\min}) is the minimum half-spread.
(V) is the measured volatility.
(\alpha) controls how strongly volatility affects the spread.

This is an illustrative model. The volatility measure must be scaled appropriately before using it in a pricing formula.

Let's look at a simplified example.

Suppose:

Minimum half-spread = $0.01.
Volatility measurement = 0.002.
Volatility coefficient = 5.

Then:

[
H=0.01+(5 \times 0.002)
]

[
H=0.02
]

If the midpoint is $0.50, the candidate quotes become:

Bid: $0.48.
Ask: $0.52.

When volatility increases, the half-spread increases.

This gives the bot more room between its buy and sell prices.

However, a wider spread does not eliminate adverse selection. If the market is moving extremely quickly, even a wide quote can become outdated.

Sometimes the safer decision is not to quote at all.

5. Implement Dynamic Spread Calculation

Let's turn the basic formula into Python.

from decimal import Decimal


def calculate_dynamic_half_spread(
    min_half_spread: Decimal,
    volatility: Decimal,
    volatility_factor: Decimal,
    max_half_spread: Decimal,
):
    if min_half_spread <= 0:
        raise ValueError("Minimum spread must be positive")

    if volatility < 0:
        raise ValueError("Volatility cannot be negative")

    if volatility_factor < 0:
        raise ValueError("Volatility factor cannot be negative")

    if max_half_spread < min_half_spread:
        raise ValueError("Invalid maximum spread")

    dynamic_spread = (
        min_half_spread
        + volatility * volatility_factor
    )

    return min(dynamic_spread, max_half_spread)

Example:

half_spread = calculate_dynamic_half_spread(
    min_half_spread=Decimal("0.01"),
    volatility=Decimal("0.002"),
    volatility_factor=Decimal("5"),
    max_half_spread=Decimal("0.05"),
)

print("Half spread:", half_spread)

The function calculates a candidate half-spread and prevents it from exceeding the configured maximum.

A production bot should also define what happens when the calculated spread is too wide to quote competitively or violates the market's valid price increments.

Do not assume that a larger spread is always better.

The objective is to balance execution probability against adverse-selection and inventory risk.

6. Adjust Order Size Based on Liquidity

Spread is only one part of the strategy.

Order size matters too.

Imagine the order book looks like this:

Market A

Price	Available quantity
$0.49	1,000
$0.48	1,500
$0.47	2,000

Market B

Price	Available quantity
$0.49	20
$0.48	35
$0.47	50

Both markets may show similar best prices, but their available liquidity is very different.

Placing a 500-token order in Market A may be reasonable under your strategy's limits.

Placing the same order in Market B could represent a much larger portion of the available liquidity.

This is why order size should consider:

Available order-book depth.
Current inventory.
Available funds.
Outstanding orders.
Volatility.
Maximum permitted exposure.

A basic liquidity ratio

You can estimate how large your order is compared with available depth:

[
L=\frac{Q_{\text{order}}}{Q_{\text{available}}}
]

For example:

Proposed order size: 50 tokens.
Available quantity near the relevant price: 500 tokens.

[
L=\frac{50}{500}=0.10
]

Your order is 10% of the selected available quantity.

This ratio does not predict whether the order will fill. It is simply a way to understand how large your order is relative to the visible liquidity you chose to measure.

Visible liquidity can disappear or change, and it does not necessarily represent the full amount available at execution time.

7. Create a Basic Adaptive Order Size Function

We can also adjust the proposed order size according to volatility.

For example, we might reduce the size when volatility rises.

from decimal import Decimal


def calculate_order_size(
    base_size: Decimal,
    volatility: Decimal,
    volatility_sensitivity: Decimal,
    minimum_size: Decimal,
):
    if base_size <= 0:
        raise ValueError("Base size must be positive")

    if volatility < 0 or volatility_sensitivity < 0:
        raise ValueError("Invalid volatility parameters")

    size = base_size / (
        Decimal("1")
        + volatility * volatility_sensitivity
    )

    return max(minimum_size, size)

Suppose the base size is 100 tokens.

As volatility increases, the calculated size decreases.

This is a simple educational model. It does not include inventory, liquidity, balance, minimum order sizes, or the market's actual execution constraints.

In a real market maker, order size should be calculated only after the risk manager checks all relevant exposure.

8. Combine Dynamic Spreads With Inventory Skew

Now let's combine the ideas from Day 4 and Day 6.

A market maker needs to consider at least two things:

How risky is the current market?
How much inventory does the bot already hold?

Volatility can influence the spread.

Inventory can influence the reference price.

A simplified model is:

[
P_{\text{adjusted}}=P_{\text{mid}}-kI
]

[
Bid=P_{\text{adjusted}}-H
]

[
Ask=P_{\text{adjusted}}+H
]

Where:

(P_{\text{mid}}) is the reference midpoint.
(I) is the inventory deviation from the target.
(k) is the inventory-skew coefficient.
(H) is the dynamic half-spread.

Let's consider an example.

Assume:

Midpoint = $0.50.
Inventory deviation = 100 tokens.
Inventory skew = 0.0001.
Dynamic half-spread = $0.03.

The adjusted midpoint becomes:

[
0.50-(100 \times 0.0001)=0.49
]

The quotes become:

[
Bid=0.49-0.03=0.46
]

[
Ask=0.49+0.03=0.52
]

The bot has both widened its spread and shifted its reference price downward.

This is a basic way to combine market-condition risk with inventory risk.

But there is an important limitation: the formula assumes that the volatility and inventory measurements are meaningful and correctly scaled.

It also assumes that a two-sided quote remains appropriate.

If the market is unstable or the bot has exceeded its risk limit, it may be better to reduce exposure or pause quoting instead.

9. Detect Market Regimes

Not every market condition requires the same behavior.

You can divide market conditions into simple categories.

Market regime	Possible characteristics	Example response
Calm	Stable prices and reasonable depth	Normal quoting
Active	More frequent price changes	Recalculate quotes more often
Volatile	Large and rapid movements	Wider spreads and smaller orders
Illiquid	Thin order book and large gaps	Reduce size or pause
Uncertain	Stale data or unreliable state	Stop new quoting until reconciled

These are conceptual categories, not universal thresholds.

Your bot needs measurable rules to determine which category applies.

For example, a volatility filter might compare recent volatility with a configured threshold.

A liquidity filter might compare available depth with the intended order size.

A data-quality filter might check how old the latest market update is.

A production system should also use hysteresis or minimum time-in-regime rules where appropriate.

Why?

Because a market can move around a threshold.

If your bot switches between normal and volatile mode every second, its behavior may become unstable.

Hysteresis means using different conditions to enter and exit a regime.

For example:

Enter volatile mode when volatility rises above 0.003.
Return to normal mode only when volatility falls below 0.002.

The gap between the thresholds helps prevent rapid switching.

10. Know When Not to Make a Market

An advanced market maker must understand that sometimes the correct decision is to do nothing.

Consider these situations:

Situation 1: Market data is stale

Your bot has not received a fresh order-book update.

It cannot safely assume that its previous quotes are still appropriate.

Situation 2: Liquidity disappears

The visible order book becomes extremely thin.

A normal order size may now represent a large share of available liquidity.

Situation 3: Volatility becomes extreme

The underlying crypto price moves rapidly, and the Polymarket token price changes faster than your strategy can safely react.

Situation 4: Inventory exceeds the limit

The bot already holds more tokens than its strategy allows.

Submitting additional buy orders could increase the exposure.

Situation 5: The order state is uncertain

A previous submission or cancellation timed out, and the bot cannot determine the current exchange state.

In these cases, the bot should follow its configured safety policy.

This might mean reducing orders, canceling certain resting orders, or pausing new submissions.

The exact action should depend on the risk condition and the bot's current exposure.

A market maker should not be forced to quote at every moment.

11. Build a Simple Adaptive Quote Engine

Let's combine the ideas into one educational function.

It will:

Calculate the inventory-adjusted midpoint.
Calculate a volatility-adjusted spread.
Produce candidate bid and ask prices.
Check basic price boundaries.

It will not place orders or replace the risk manager.

from decimal import Decimal


def calculate_adaptive_quotes(
    midpoint: Decimal,
    inventory: Decimal,
    inventory_target: Decimal,
    volatility: Decimal,
    base_half_spread: Decimal,
    volatility_factor: Decimal,
    inventory_skew: Decimal,
):
    if not Decimal("0") < midpoint < Decimal("1"):
        raise ValueError("Invalid midpoint")

    if volatility < 0:
        raise ValueError("Volatility cannot be negative")

    if base_half_spread <= 0:
        raise ValueError("Base spread must be positive")

    inventory_deviation = inventory - inventory_target

    adjusted_midpoint = (
        midpoint
        - inventory_deviation * inventory_skew
    )

    dynamic_half_spread = (
        base_half_spread
        + volatility * volatility_factor
    )

    bid = adjusted_midpoint - dynamic_half_spread
    ask = adjusted_midpoint + dynamic_half_spread

    min_price = Decimal("0.01")
    max_price = Decimal("0.99")

    bid = max(min_price, min(bid, max_price))
    ask = max(min_price, min(ask, max_price))

    if bid >= ask:
        raise ValueError("Invalid quote relationship")

    return {
        "bid": bid,
        "ask": ask,
        "adjusted_midpoint": adjusted_midpoint,
        "half_spread": dynamic_half_spread,
        "inventory_deviation": inventory_deviation,
    }

Example:

quotes = calculate_adaptive_quotes(
    midpoint=Decimal("0.50"),
    inventory=Decimal("100"),
    inventory_target=Decimal("0"),
    volatility=Decimal("0.002"),
    base_half_spread=Decimal("0.01"),
    volatility_factor=Decimal("5"),
    inventory_skew=Decimal("0.0001"),
)

print(quotes)

This is a starting point for experimentation, not a complete production quoting algorithm.

A real implementation must additionally validate:

The actual market tick size.
Minimum and maximum order sizes.
Market status.
Available balance.
Current order-book liquidity.
Outstanding orders and possible fills.
Maximum inventory and loss limits.
Data freshness.
Whether quoting should be paused.

It should also account for the fact that YES and NO tokens may need separate pricing and inventory models.

12. How Do You Know Dynamic Quoting Is Better?

Adding more parameters does not automatically improve a trading strategy.

A complicated bot can perform worse than a simple bot if its filters are poorly calibrated or its data is unreliable.

You should compare the fixed-spread and dynamic-spread strategies under the same evaluation conditions.

For example:

Metric	Fixed spread	Dynamic spread
Net P&L	Measure	Measure
Fill rate	Measure	Measure
Maximum inventory	Measure	Measure
Average order size	Measure	Measure
Post-fill price movement	Measure	Measure
Fees and execution costs	Measure	Measure
Time spent quoting	Measure	Measure
Risk-limit breaches	Measure	Measure

Do not fill this table with expected improvements. Collect actual results from your own tests.

A dynamic strategy might reduce inventory exposure but also receive fewer fills.

It might improve post-fill price movement while missing some trading opportunities.

It might perform better in volatile markets but worse in calm markets.

These are trade-offs to measure, not assumptions to make.

Run controlled experiments

A useful process is:

Build a fixed-spread baseline.
Record the data and decisions it produces.
Add volatility-based spread adjustment.
Compare the results using the same data and execution assumptions.
Add inventory-aware size adjustment.
Evaluate the new version separately.
Test on data that was not used to tune the parameters.

Change one major feature at a time where possible.

This helps you understand which modification actually caused a performance difference.

Conclusion: Build a Market Maker That Adapts to the Market

A basic market maker can calculate a bid and ask using a fixed spread.

But real markets do not remain constant.

Volatility changes. Liquidity changes. Inventory changes. Order-book conditions change.

A more advanced market maker should recognize these changes and adjust its behavior accordingly.

The key lessons from Day 8 are:

Fixed spreads have limitations. The same quote may be too wide in a calm market and too narrow in a volatile market.
Measure volatility consistently. The sampling interval and data source matter.
Adjust spreads carefully. Wider quotes may reduce some execution risks but do not guarantee better results.
Adapt order size to risk and liquidity. A large order can be inappropriate in a thin market.
Combine inventory and volatility controls. Both influence how aggressively the bot should quote.
Recognize unsafe market conditions. Sometimes pausing is better than placing another order.
Measure every improvement. More sophisticated logic is useful only when testing demonstrates a meaningful benefit.

The next step is not simply adding more filters or more complicated formulas.

It is building a strategy that can explain why it is quoting, how much risk it is taking, and when it should stop.

That is the difference between a basic trading script and a more sophisticated market-making system.

Continue the project

GitHub repository: https://github.com/Benj4minCup/Polymarket-Trading-Bot-python
YouTube tutorial: https://www.youtube.com/watch?v=UCF7MA1Kekk
Telegram: https://telegram.me/BenjaminCup

Follow the project and experiment with the concepts in this tutorial series.

Building a Polymarket Market Maker Bot in Python: Testing, Monitoring & Deployment

Benjamin-Cup — Tue, 03 Nov 2026 15:15:35 +0000

Day 7 of 7 — From Zero to a Complete Market Maker Bot

Building a market maker bot is not just about placing buy and sell orders. A reliable bot must also manage inventory, control risk, handle API failures, and measure actual trading performance.

In this final part of the series, we'll bring everything together and look at how to prepare a Polymarket market maker bot for deployment.

1. Complete Bot Architecture

A market maker bot consists of several components:

Market Data Collector: Retrieves order books, prices, and market updates.
Pricing Engine: Calculates bid and ask prices.
Risk Manager: Checks inventory, balance, and exposure limits.
Order Manager: Submits, tracks, cancels, and replaces orders.
Monitoring System: Tracks performance, errors, and system health.

The key principle is separation of responsibility: pricing decides what to quote, risk management decides whether it's safe, and order management handles execution.

2. Test Before Live Trading

Never connect a new strategy directly to a live account.

Use four testing stages:

Historical data analysis.
Strategy simulation.
Real-time paper trading.
Limited live testing with strict risk limits.

Paper trading helps identify problems such as duplicate orders, partial fills, incorrect inventory calculations, and stale market data.

Remember: simulated fills do not guarantee real-world execution.

3. Measure Real Trading Performance

A profitable-looking spread does not necessarily mean a profitable strategy.

Track these important metrics:

Realized P&L: Profit or loss from completed trades.
Unrealized P&L: Current estimated profit or loss from open positions.
Net P&L: Results after applicable fees and trading costs.
Fill Rate: Percentage of submitted order quantity that gets filled.
Inventory Exposure: How much inventory the bot holds and for how long.
Adverse Selection: Whether prices move against the bot after its orders fill.

These metrics help identify whether your strategy is actually working.

4. Implement Risk Management

Before submitting an order, check:

Is market data fresh?
Is the market active?
Is the order price valid?
Is sufficient balance available?
Is inventory within limits?
Are existing open orders creating additional exposure?

If something is wrong, the bot should pause new orders or reduce exposure instead of continuing blindly.

5. Handle API Failures and Restarts

Network failures and unexpected crashes are normal in production systems.

After restarting, the bot should:

Load its saved configuration.
Connect to Polymarket.
Retrieve open orders and trade history.
Reconcile local records with exchange state.
Recalculate inventory and available balance.
Verify market data freshness.
Resume trading only when the state is understood.

Never blindly resubmit an order after an API timeout. The original order might already exist.

6. Deploy and Monitor

A VPS (Virtual Private Server) allows your bot to run continuously without depending on your personal computer.

Before deployment, prepare:

Secure API credentials.
Environment-based configuration.
Structured logs.
Automatic process recovery.
Health checks and alerts.
Emergency-stop procedures.

Monitor market data, open orders, inventory, P&L, API errors, and system resources.

Automatic restarts alone are not enough. Always reconcile exchange state before resuming trading.

Final Thoughts

Over these seven articles, we've explored the essential components of building a Polymarket market maker bot:

Understanding the order book.
Collecting market data.
Calculating bid and ask prices.
Managing orders and partial fills.
Controlling inventory risk.
Testing strategies.
Monitoring and deploying the system.

The biggest lesson is simple:

A trading bot is more than a script that places orders. It's a complete system that must understand its exposure, handle failures, and measure its real performance.

A good architecture and successful backtest cannot guarantee profitability. Test carefully and increase trading limits only when the evidence supports it.

Continue Building

GitHub:

Benj4minCup / Polymarket-Trading-Bot-python

polymarket Twap Bot polymarket Arbitrage Bot polymarket bot

Polymarket Trading bot system

An open-source and Strong Strategy collection of Polymarket trading bot and Polymarket arbitrage bot and Polymarket TWAP trading bot in Python for high-performance automated trading on polymarket crypto 5min and 15min markets.

This repository is primarily intended for educational and research purposes. It includes strategy concepts, implementation approaches, and selected performance screenshots to help developers understand how different automated trading strategies can be designed and tested.

The repository does not provide a complete production-ready trading bot source code. Instead, it provides strategy descriptions and research materials that you can use as a foundation for developing your own system.

If you are interested in building a Polymarket Trading Bot, you can follow my tutorials and use the concepts in this repository to develop your own implementation.

For users who prefer a ready-to-deploy solution or require custom strategy development, commercial bot development and customization are also available.

Features
…

View on GitHub
YouTube:
Telegram: https://telegram.me/BenjaminCup

Thanks for following this seven-day series!

Python #Polymarket #TradingBot #MarketMaking #AlgorithmicTrading #CryptoTrading #OpenSource

Building a Polymarket Market Maker Bot in Python: Inventory Risk, Adverse Selection & Risk Management

Benjamin-Cup — Mon, 02 Nov 2026 13:43:41 +0000

Day 6 of 7 — Building a Polymarket Market Maker Bot From Zero to Complete

In Day 4, we learned how to calculate bid and ask prices. In Day 5, we explored order management, partial fills, cancellations, and uncertain API responses.

Today, we're going to tackle another critical challenge in automated market making:

How do you protect your trading bot when it accumulates tokens and the market moves against its position?

Imagine your Polymarket bot purchases 100 YES tokens at $0.48 each.

Your strategy expects to earn money by selling those tokens at a higher price.

But before your sell order executes, the market changes:

Your purchase price: $0.48
New best bid: $0.42
New best ask: $0.44

Your tokens are now worth less than what you paid.

Your pricing algorithm might be working perfectly. Your API integration might be reliable. Your order manager might correctly track every transaction.

Yet your strategy is still losing money.

This is why professional market-making systems need more than a pricing algorithm. They need an inventory management and risk-control system.

In this tutorial, we'll explore:

Inventory risk and why it matters.
Adverse selection and how it affects market makers.
How to measure trading positions and financial exposure.
Inventory-aware pricing strategies.
Implementing risk-management logic in Python.
Maximum inventory, exposure, and loss limits.
Detecting unfavorable fills.
Testing risk-management systems before live trading.

By the end, you'll understand how to make your Polymarket bot aware of the risks created by its own orders.

1. Understanding Inventory Risk

Before discussing risk management, let's understand inventory.

Inventory is the collection of tokens your trading bot currently holds.

In a Polymarket binary market, this usually means YES and NO tokens.

Inventory risk occurs when the value or potential payout of those positions changes in a way that negatively affects your strategy.

A practical example

Suppose your bot purchases:

100 YES tokens
Purchase price: $0.48 per token

Your initial investment is:

100 * 0.48 = $48

Later, the YES token price falls to $0.43.

Its indicative market value becomes:

100 * 0.43 = $43

Your unrealized loss is:

43 - 48 = -$5

You've lost approximately $5 in estimated position value, even though you haven't sold anything.

This is called an unrealized loss.

Note that this simplified calculation doesn't include fees, execution costs, or the possibility that the entire position cannot be sold at the displayed price.

Why does inventory risk happen?

Market makers generally place buy and sell orders around a reference price.

They want to:

Buy tokens at a lower price.
Sell tokens at a higher price.
Earn the difference, known as the spread.

However, buy and sell orders don't always execute equally.

Consider this situation:

Bot places BUY orders
        |
        v
Buy orders execute repeatedly
        |
        v
Bot accumulates YES tokens
        |
        v
Sell orders remain unfilled
        |
        v
Market price starts falling
        |
        v
Inventory loses value

The bot might have executed many successful purchases, but it now holds more inventory than intended.

The important lesson: A market maker must continuously monitor its inventory, not just the number of orders it has submitted.

2. What Is Adverse Selection?

Inventory risk describes the position your bot holds.

Adverse selection describes a different problem:

Your orders may be filled because another trader has information or market signals that make your quoted price unfavorable.

Let's look at an example.

The YES token is trading around $0.50.

Your bot places a sell order at $0.51.

Another trader immediately purchases your tokens.

A moment later, new information enters the market, and the YES token price rises to $0.56.

Your order was successfully executed, but you sold at a price that quickly became unfavorable.

The opposite can happen when your buy order executes just before the market price falls.

This is adverse selection.

Why can other traders have an advantage?

Other traders may react faster to:

Changes in the underlying cryptocurrency price.
Sudden increases in market volatility.
New information affecting the probability of an outcome.
Changes in liquidity and order-book depth.
Markets approaching their resolution time.

For example, imagine your bot is trading a Polymarket BTC Up/Down market.

BTC suddenly moves sharply upward.

The probability of the YES outcome changes, but your bot hasn't updated its quotes yet.

Your existing sell order may now be too cheap.

Another trader can purchase your tokens at your outdated price before your bot has time to react.

Why is this dangerous?

A wide spread doesn't automatically protect your market maker.

If your prices are outdated, other traders may consistently execute against your orders when those prices are unfavorable.

Your apparent spread profit can be overwhelmed by:

Adverse price movements.
Trading fees.
Execution costs.
Unfavorable order fills.

This is why market makers need to monitor both inventory and market conditions.

3. Measuring Inventory and Financial Exposure

You cannot manage risk if you don't know what your bot currently owns.

At a minimum, your system should track:

Data	Purpose
YES quantity	Current YES token position
NO quantity	Current NO token position
Average cost	Average acquisition price
Current reference price	Estimated current token value
Open buy orders	Potential additional inventory
Open sell orders	Potential inventory reduction
Available funds	Remaining buying capacity
Potential exposure	Risk if outstanding orders execute

Let's use an example.

Your bot currently holds:

Position	Quantity	Average Cost
YES	100	$0.48
NO	40	$0.46

The total acquisition cost is:

yes_cost = 100 * 0.48
no_cost = 40 * 0.46

total_cost = yes_cost + no_cost

print(total_cost)
# 66.40

Your bot spent $66.40 acquiring these positions.

However, acquisition cost alone doesn't tell you the current financial risk.

You also need to understand the current market prices and what the tokens represent.

For standard binary markets, a winning token generally pays $1 at resolution, while a losing token pays $0, subject to the specific market's resolution rules.

Before resolution, token prices change as market expectations and trading conditions change.

It's important to distinguish five different measurements:

1. Cost Basis

The amount originally paid to acquire the position.

2. Mark-to-Market Value

The estimated current value of the position using a selected market price.

3. Realized P&L

Profit or loss from completed transactions.

4. Unrealized P&L

Estimated profit or loss on positions that are still open.

5. Resolution Value

The final payout determined by the market's resolution rules.

These measurements answer different questions. A reliable trading system should not treat them as interchangeable.

4. Tracking YES and NO Inventory Separately

One simple way to measure inventory imbalance is to calculate the difference between YES and NO token quantities.

Formula:

inventory = yes_quantity - no_quantity

Mathematically:

[
I = Q_{YES} - Q_{NO}
]

Where:

(Q_{YES}): Number of YES tokens held.
(Q_{NO}): Number of NO tokens held.
(I): Net token-count difference.

Example:

yes_quantity = 100
no_quantity = 40

inventory = yes_quantity - no_quantity

print(inventory)
# 60

Your bot holds 60 more YES tokens than NO tokens.

This metric is useful for identifying an imbalance.

However, net token quantity is not the same as financial exposure.

Why?

Because YES and NO tokens can have different market prices.

Their payout characteristics also depend on the specific market.

Furthermore, outstanding orders can change your position even before they execute.

For better risk management, track:

Net token inventory.
Monetary exposure.
Outstanding order exposure.
Individual YES and NO position limits.
Total portfolio exposure.

A balanced YES/NO token count does not automatically eliminate every type of financial risk.

5. Implementing Inventory-Aware Pricing

Now let's connect inventory management with the pricing algorithm we built in Day 4.

A basic market maker calculates its prices using:

[
Bid = Midpoint - HalfSpread
]

[
Ask = Midpoint + HalfSpread
]

Suppose:

Midpoint:   $0.50
Half-spread: $0.02

The bot generates:

Bid: $0.48
Ask: $0.52

This is a reasonable starting point.

But what happens if your bot already holds 500 YES tokens?

Should it continue buying at the same price?

Probably not.

It should become less aggressive about accumulating additional inventory.

This is where inventory-aware pricing becomes useful.

The inventory-skew formula

A simplified inventory-adjusted reference price is:

[
P_{adjusted} = P_{mid} - kI
]

Where:

(P_{mid}): Original reference midpoint.
(I): Inventory deviation from the target.
(k): Inventory-skew coefficient.

When inventory exceeds its target, the adjusted reference price decreases.

This makes buying less aggressive and selling more attractive.

When inventory is below its target, the adjusted reference price can increase, encouraging the bot to rebuild its position.

Practical example

Assume:

Midpoint:                  $0.50
Half-spread:               $0.02
Inventory deviation:       100 tokens
Inventory-skew coefficient: 0.0001

Calculate the adjusted midpoint:

[
P_{adjusted} = 0.50 - (100 \times 0.0001)
]

[
P_{adjusted} = 0.49
]

Now calculate the new quotes:

[
Bid = 0.49 - 0.02 = 0.47
]

[
Ask = 0.49 + 0.02 = 0.51
]

Compare the results:

Quote	Original	Inventory Adjusted
Bid	$0.48	$0.47
Ask	$0.52	$0.51

The bot now offers a lower buying price and a lower selling price.

This discourages additional buying while making it easier to sell existing inventory.

The coefficient is illustrative. It must be calibrated to the market, trading costs, inventory limits, and strategy.

Also, inventory should be measured against a target position, not necessarily zero. Some strategies intentionally maintain a nonzero position.

6. Writing Inventory-Aware Pricing Logic in Python

Let's implement this concept.

We'll use Python's Decimal instead of ordinary floating-point numbers.

Financial calculations can suffer from floating-point rounding errors, so Decimal is useful when working with prices and quantities.

from decimal import Decimal


def calculate_inventory_aware_quotes(
    midpoint: Decimal,
    half_spread: Decimal,
    inventory: Decimal,
    inventory_target: Decimal = Decimal("0"),
    skew_per_token: Decimal = Decimal("0.0001"),
):
    if not Decimal("0") < midpoint < Decimal("1"):
        raise ValueError("Midpoint must be between 0 and 1")

    if half_spread <= 0:
        raise ValueError("Half-spread must be positive")

    if skew_per_token < 0:
        raise ValueError("Skew must not be negative")

    inventory_deviation = inventory - inventory_target

    adjusted_midpoint = (
        midpoint - inventory_deviation * skew_per_token
    )

    bid = adjusted_midpoint - half_spread
    ask = adjusted_midpoint + half_spread

    # Illustrative binary-token price bounds.
    bid = max(Decimal("0.01"), min(bid, Decimal("0.99")))
    ask = max(Decimal("0.01"), min(ask, Decimal("0.99")))

    if bid >= ask:
        raise ValueError("Invalid quotes: bid must be below ask")

    return {
        "bid": bid,
        "ask": ask,
        "inventory_deviation": inventory_deviation,
        "adjusted_midpoint": adjusted_midpoint,
    }


quotes = calculate_inventory_aware_quotes(
    midpoint=Decimal("0.50"),
    half_spread=Decimal("0.02"),
    inventory=Decimal("100"),
    inventory_target=Decimal("0"),
    skew_per_token=Decimal("0.0001"),
)

print(quotes)

Understanding the results

Try changing the inventory value:

Inventory	Expected behavior
0	No inventory adjustment
100	Lower adjusted midpoint
-100	Higher adjusted midpoint
Very large positive or negative value	Candidate prices may become invalid

One important detail: the example clamps prices to an illustrative range, but this doesn't guarantee valid quotes.

A production implementation must also validate:

Actual market tick size.
Minimum and maximum allowed prices.
Bid/ask relationship.
Market-specific order rules.
Inventory and exposure limits.

The function only calculates candidate quotes. It does not submit orders or guarantee profitability.

7. Why Inventory Skew Is Not Enough

Inventory-aware pricing is useful, but it cannot solve every risk problem.

Imagine your bot holds 500 YES tokens.

Suddenly, the market becomes extremely volatile.

Your inventory-skew formula adjusts the bid and ask prices.

However, the market may still be moving too quickly for those prices to be safe.

This is why professional trading systems need additional risk controls.

A. Maximum Inventory Limit

Define the maximum number of tokens your bot is allowed to hold.

For example:

MAX_YES_INVENTORY = 200

If your bot reaches 200 YES tokens, it should stop increasing its YES position.

Possible actions include:

Canceling or reducing open buy orders.
Blocking new exposure-increasing orders.
Allowing permitted inventory-reducing actions.

B. Maximum Outstanding Exposure

An order doesn't need to execute to create potential risk.

Suppose:

Current YES inventory: 150
Open YES buy orders:   100
Maximum inventory:    200

Your potential inventory is:

potential_inventory = 150 + 100

print(potential_inventory)
# 250

Even though the bot currently owns only 150 tokens, it could own 250 if all open buy orders execute.

That exceeds the configured limit.

A simplified calculation is:

[
Q_{potential} = Q_{held} + Q_{open\ buys}
]

A production risk manager must also account for:

Partial fills.
Pending cancellations.
Multiple outstanding orders.
Orders that reduce exposure.
Orders whose execution state is uncertain.

C. Maximum Loss Limit

Define the maximum acceptable loss for:

An individual market.
The entire strategy.
A trading session.

For example:

MAX_SESSION_LOSS = Decimal("50.00")

When the configured loss threshold is reached, the bot can stop submitting new orders and enter a controlled risk-reduction mode.

The calculation should distinguish realized and unrealized P&L and include relevant fees and costs.

Define the policy before trading rather than changing it whenever the market becomes uncomfortable.

D. Stale Market Data Detection

Imagine your bot stops receiving market updates.

Its last known midpoint is $0.50, but the actual market has already moved to $0.42.

If the bot continues quoting around $0.50, it may create extremely unfavorable orders.

A stale-data rule should prevent new pricing decisions from using outdated information.

Depending on the system design, the bot may also need to cancel resting orders.

E. Market and Resolution Risk

A market approaching resolution can behave differently from one with plenty of time remaining.

For example, in a short-interval BTC Up/Down market, a sharp BTC movement can rapidly change the probability of the outcome.

Your bot should consider:

Time remaining until resolution.
Current market conditions.
Volatility.
Reliability of reference data.
Potential price changes before an order executes.

The same quoting parameters are not necessarily appropriate throughout every stage of a market.

8. Detecting Adverse Selection After Order Fills

How can you determine whether your bot is repeatedly getting unfavorable fills?

One useful approach is to compare the reference price at the time of a fill with the reference price after the fill.

Let's consider a BUY transaction.

Purchase price:             $0.48
Reference price at fill:    $0.49
Reference price 5s later:   $0.45

The reference price decreased by $0.04.

This is a warning sign that the buy order may have been adversely selected.

Calculate post-fill price movement

For a buy:

[
\Delta P = P_{after} - P_{at\ fill}
]

Using our example:

[
\Delta P = 0.45 - 0.49
]

[
\Delta P = -0.04
]

A negative value means the reference price decreased after the purchase.

For a sell, an increase in the reference price after the fill can be unfavorable because the bot sold before the market moved higher.

What should your bot record?

For every executed order, store:

Field	Description
Market ID	Which market was traded
Token ID	Which token was traded
Side	BUY or SELL
Fill price	Actual execution price
Fill quantity	Number of executed tokens
Reference price	Price at the time of execution
Post-fill price	Price after a selected interval
Inventory before	Position before execution
Inventory after	Position after execution
Fees	Associated trading costs

You can then measure post-fill price movement over different periods:

1 second.
5 seconds.
30 seconds.

The appropriate time intervals depend on your market and strategy.

This analysis helps answer important questions:

Are buy orders frequently filled before prices fall?
Are sell orders frequently filled before prices rise?
Does adverse selection become worse during volatile periods?
Are certain order sizes associated with worse outcomes?

Remember that reference-price movement is not the same as realized profit or loss.

You need consistent reference prices, observation windows, and enough historical observations before changing your strategy.

9. Building a Risk-Control Decision Process

A reliable market maker needs explicit rules for when it should continue quoting, reduce exposure, or stop placing orders.

Here is a simplified decision process:

          Receive Market Update
                   |
                   v
         Is Market Data Fresh?
                   |
             +-----+-----+
             |           |
            No          Yes
             |           |
             v           v
        Pause or      Check Inventory,
        Cancel as     Exposure and
        Needed        Loss Limits
                          |
                          v
                   Are Limits Safe?
                          |
                    +-----+-----+
                    |           |
                   No          Yes
                    |           |
                    v           v
               Reduce Risk   Calculate
               or Pause      Adjusted Quotes
                                  |
                                  v
                            Validate Orders
                                  |
                                  v
                             Manage Orders

The appropriate response depends on the specific risk condition.

For example:

Risk condition	Possible response
Inventory too high	Reduce buying pressure
Outstanding exposure too high	Block additional exposure
Market data stale	Pause new quoting
Uncertain order state	Reconcile orders before submitting more
Loss threshold reached	Activate predefined risk policy

One important point: canceling every order is not always the safest response.

A cancellation can race with an execution. A risk-reducing order might also be canceled unnecessarily.

Your system should define how to respond to each risk condition instead of relying on a single emergency action.

10. Testing Risk Management Before Live Trading

Never wait for a real trading loss to discover that your inventory calculations are incorrect.

Your risk-management system should be tested against specific scenarios.

Here is a practical test checklist:

Test Scenario	Expected Behavior
Inventory is zero	Quotes use the original reference price
Inventory exceeds target	Quotes discourage additional accumulation
Inventory falls below target	Quotes shift in the opposite direction
Maximum inventory reached	New exposure-increasing orders are blocked
Open buy orders could exceed the limit	Additional buying is restricted
Market data becomes stale	New quoting pauses
Partial fill arrives	Inventory and remaining quantity are updated
Duplicate trade event arrives	Inventory is not counted twice
Cancellation is pending	Potential exposure remains accounted for
Maximum loss reached	Configured risk response activates
Candidate prices are invalid	Orders are rejected before submission

You should also test situations where several problems happen simultaneously.

For example:

Current inventory is near its maximum
             +
Market price is changing rapidly
             +
Cancellation request times out
             |
             v
      Risk Manager Activated
             |
             v
   Reconcile Actual Order State
             |
             v
   Recalculate Potential Exposure
             |
             v
   Apply Configured Risk Policy

This is especially important because trading systems often experience multiple events at nearly the same time.

A reliable risk manager must avoid making an uncertain situation worse by blindly submitting additional orders.

The goal isn't to build a bot that never loses money. That's impossible to guarantee.

The goal is to build a bot that understands its exposure, respects its limits, and responds predictably when something goes wrong.

Conclusion: Risk Management Is Part of the Trading Strategy

Inventory risk and adverse selection are two of the most important challenges in automated market making.

Your bot can calculate reasonable bid and ask prices and correctly manage every API request, but it can still lose money if it accumulates an unwanted position or repeatedly gets filled at unfavorable prices.

Let's summarize the most important lessons from Day 6:

Track inventory continuously. Know what your bot owns and what outstanding orders could add to its position.
Use inventory-aware pricing. Adjust quotes when the current position moves away from its target.
Measure adverse selection. Analyze how reference prices move after order execution.
Implement explicit risk limits. Monitor inventory, outstanding exposure, market-data freshness, and losses.
Stop quoting when critical information is unreliable. Never let your bot trade blindly using outdated data.
Test failure scenarios. Make sure your risk controls work when fills, cancellations, and market movements happen together.

Remember: inventory skew and risk limits help control exposure, but they do not guarantee profitability. Market making remains exposed to volatility, fees, execution costs, and unfavorable fills.

What's Next? Day 7 — Testing, Monitoring and Deployment

We've now covered market data, pricing, order management, inventory risk, and risk controls.

In the final article, we'll bring the project together.

We'll explore:

Testing the complete trading bot.
Measuring market-making performance.
Monitoring live trading operations.
Handling failures and unexpected behavior.
Preparing a safer deployment workflow.
Evaluating whether the strategy is actually profitable.

The final goal is to move from a collection of trading components to a complete, testable market-making system.

Continue the Project

GitHub Repository: https://github.com/Benj4minCup/Polymarket-Trading-Bot-python
YouTube Tutorial: https://www.youtube.com/watch?v=UCF7MA1Kekk
Telegram: https://telegram.me/BenjaminCup

Follow the series to learn how to build a Polymarket trading bot step by step, from market data and quote calculation to order management and risk control.

Polymarket Trading Bot:How to Build a Market Maker Bot: Order Management, Limit Orders, and Partial Fills

Benjamin-Cup — Thu, 29 Oct 2026 00:22:28 +0000

Day 5 of 7: Building a Polymarket Market Maker Bot From Zero to Complete

In Day 4, we explored how a Polymarket market maker bot calculates bid and ask prices, manages spreads, and adjusts quotes based on inventory.

But calculating the right price is only half the job.

What happens after your bot places an order?

Imagine your Python trading bot wants to buy YES tokens at $0.48 and sell them at $0.52.

Before either order fills:

The market price changes.
Another trader takes the available liquidity.
Your order gets partially filled.
Your API request times out.
Your bot crashes while orders remain active.

If your bot cannot handle these situations, even a good market-making strategy can lose control of its positions.

In this tutorial, we'll explore how to build the order-management foundation of a Polymarket trading bot.

We'll cover:

How limit orders work
How to track an order's lifecycle
How to handle partial fills
When to cancel and replace orders
How to avoid duplicate orders after API timeouts
How to combine WebSockets with REST reconciliation
How to protect open orders when a bot crashes
How to test order-management failures before live trading

The examples use Python and Decimal for financial values. They demonstrate the decision-making logic, not a complete integration with the live Polymarket API.

1. What Is Order Management?

Order management is the part of a trading bot responsible for controlling the orders it sends to the exchange.

It answers questions such as:

Which orders are currently active?
How many tokens have been filled?
How many tokens remain?
Does an existing order still match the target price?
Should the bot cancel an outdated order?
What happens if an API request times out?

A market maker typically has three main components:

Component	Responsibility
Pricing engine	Calculates target bid and ask prices
Order manager	Places, tracks, updates, and cancels orders
Risk manager	Checks inventory, available funds, and exposure limits

For example, the pricing engine calculates a YES bid of $0.48.

Before submitting the order, the order manager checks whether a similar order already exists. The risk manager checks whether buying more YES tokens would exceed the configured position limit.

Only then should the bot consider submitting the order.

This separation makes the code easier to test, debug, and maintain.

2. Understand Limit Orders

A limit order specifies the maximum price you're willing to pay when buying or the minimum price you're willing to accept when selling.

Imagine the YES token order book looks like this:

Order	Price	Quantity
Best ask	$0.52	100
Second ask	$0.53	200
Best bid	$0.47	150
Second bid	$0.46	250

The spread is:

$0.52 - $0.47 = $0.05

Your market maker calculates a bid at $0.48 and an ask at $0.51.

If accepted and resting on the book, these orders offer to buy at $0.48 and sell at $0.51.

However, an accepted order is not necessarily a filled order.

A buy order at $0.48 might remain open because no seller is willing to trade at that price.

Similarly, a sell order at $0.51 might remain open because no buyer accepts the offer.

Your bot must track actual fills instead of assuming that an accepted order has executed.

What about post-only orders?

Where supported, a post-only order is intended to rest on the order book rather than immediately match against an existing order.

This can help a market maker provide liquidity instead of unintentionally taking it.

However, post-only orders don't guarantee profit. Your order might still be filled just before the market moves against you.

Always verify the supported order types and rules for the current Polymarket client and market.

3. Track the Order Lifecycle

A reliable bot needs to know the state of every order it manages.

A simplified order lifecycle looks like this:

Calculate target quote
        |
        v
Create order
        |
        v
Submit to exchange
        |
        +------> Rejected
        |
        v
      Accepted
        |
        v
     Open order
        |
        +------> Partially filled
        |                |
        |                v
        |       Update remaining quantity
        |                |
        +------> Fully filled
        |
        +------> Canceled

Real order lifecycles are more complicated. An order can be partially filled before cancellation, and a fill can occur while a cancellation request is being processed.

Let's define a simple data model.

from dataclasses import dataclass
from decimal import Decimal


@dataclass
class TrackedOrder:
    order_id: str
    token_id: str
    side: str
    price: Decimal
    original_size: Decimal
    matched_size: Decimal
    status: str

    @property
    def remaining_size(self) -> Decimal:
        return max(
            Decimal("0"),
            self.original_size - self.matched_size,
        )

This model tracks the order ID, token, side, price, original quantity, matched quantity, and current status.

The remaining quantity is:

Remaining quantity = Original quantity - Matched quantity

Suppose your bot submits an order to buy 100 YES tokens.

If 35 tokens have been filled:

100 - 35 = 65 tokens remaining

The order manager must now manage the remaining 65 tokens, not the original 100.

This is a small example, but the principle is essential for accurate inventory management.

4. Why Partial Fills Matter

Partial fills are one of the most important challenges in market making.

Imagine your bot submits these orders:

Buy 100 YES tokens at $0.48
Sell 100 YES tokens at $0.52

The buy order fills for 70 tokens, but the sell order remains unfilled.

Your position has changed. You now own 70 additional YES tokens while the sell order may still have 100 tokens available to execute.

If market conditions change, the remaining sell order might no longer match your strategy.

The bot may need to reduce its size, reprice it, or cancel it.

Three rules help prevent common mistakes:

Rule 1: Update inventory using confirmed trade information.

An order acknowledgment doesn't mean the trade has completed.

Rule 2: Recalculate the remaining quantity.

Always account for the quantity already matched.

Rule 3: Recalculate risk after every fill.

A partial fill can make previously acceptable quotes too risky.

There is another important production consideration: duplicate trade events.

If the same trade update arrives twice, your bot must not add the filled quantity to inventory twice. Use stable trade identifiers and idempotent processing to prevent duplicate accounting.

5. When Should You Cancel and Replace an Order?

Market prices change constantly.

Suppose your bot has a resting buy order at $0.48.

A few seconds later, the best bid moves to $0.50, and the best ask moves to $0.51.

Your order is still valid, but it is now less competitive.

Your bot has several choices:

Keep the existing order.
Cancel it and submit a new order.
Reduce the order size because inventory is too large.
Stop quoting because the market has become too risky.

The correct decision depends on your strategy and risk limits.

Avoid excessive repricing

A beginner might replace an order every time the best bid changes by one tick.

That sounds responsive, but it can cause:

Excessive API requests
Frequent cancellations
More opportunities for race conditions
Unnecessary order-management complexity
Increased exposure while orders are being updated

Instead, define explicit repricing rules.

For example, reconsider an order when:

The target price changes by a configured amount.
The order exceeds its maximum age.
Inventory crosses a risk threshold.
Market data becomes stale.
Market conditions make quoting unsafe.

These are example rules, not universally optimal settings.

Here's a simple price-comparison function:

from decimal import Decimal


def should_reprice(
    current_price: Decimal,
    target_price: Decimal,
    min_change: Decimal,
) -> bool:
    return abs(current_price - target_price) >= min_change

Example:

current_price = Decimal("0.48")
target_price = Decimal("0.49")
min_change = Decimal("0.01")

print(should_reprice(
    current_price,
    target_price,
    min_change,
))
# True

The function returns True because the price difference meets the configured threshold.

In production, use the market's actual tick size and valid price increments. Don't assume every market uses the same increment.

Also remember that deciding to reprice is different from successfully replacing an order.

6. The Dangerous Part: Canceling and Replacing Orders

Consider this sequence:

Your bot has a buy order open at $0.48.
The target price changes to $0.49.
Your bot requests cancellation of the old order.
It immediately submits a new order at $0.49.
The old order fills before the cancellation takes effect.

Now both orders may have executed or remain relevant to your exposure.

Your bot could buy more tokens than intended.

This is called a race condition: two operations happen close together, and their timing affects the result.

A safer workflow is:

Target price changes
        |
        v
Mark old order for replacement
        |
        v
Request cancellation
        |
        v
Reconcile order status and fills
        |
        v
Recalculate inventory and exposure
        |
        v
Check risk limits
        |
        v
Submit replacement if still safe

The important part is reconciliation.

A cancellation response doesn't erase fills that happened before cancellation. Likewise, an API timeout doesn't prove that the cancellation failed.

Before creating additional exposure, your bot should determine the old order's actual state as accurately as possible.

7. What Happens When the API Times Out?

This is one of the most dangerous order-management problems.

Your bot submits an order, but the request times out.

Did the exchange receive the order?

There are at least two possibilities:

The exchange never received it.
The exchange accepted it, but your bot never received the response.

If your bot blindly retries the request, the second situation can create a duplicate order.

Use an explicit unknown state

Your internal order manager can track states such as:

from enum import Enum


class OrderStatus(str, Enum):
    PENDING_SUBMISSION = "pending_submission"
    OPEN = "open"
    PARTIALLY_FILLED = "partially_filled"
    PENDING_CANCEL = "pending_cancel"
    FILLED = "filled"
    CANCELED = "canceled"
    REJECTED = "rejected"
    UNKNOWN = "unknown"

These are example internal states, not a claim that Polymarket returns these exact status strings.

The UNKNOWN state is especially important.

It means your bot doesn't yet know what happened.

When a submission times out:

Mark the submission as uncertain.
Avoid blindly sending another order.
Query the exchange's order or account information where possible.
Process available order and trade updates.
Reconcile the exchange state with local records.
Retry only after the previous attempt is understood and the strategy still permits another order.

If the API supports a documented idempotency mechanism, use it correctly. Otherwise, build a reconciliation process that accounts for uncertain outcomes.

A timeout is a lack of information, not proof that an order was rejected.

8. WebSockets and REST: Why You Need Both

A market maker needs two kinds of information:

What is happening in the market?
What is happening to the bot's own orders?

A practical architecture combines WebSocket updates with REST reconciliation.

Market data stream

Provides order-book updates used by the pricing engine to calculate new quotes.

User and account updates

Where supported, provides updates related to your own orders and trades.

REST reconciliation

Allows the bot to query the current state of orders or trades and recover from missed events or reconnects.

Why not use WebSockets alone?

Connections can disconnect, applications can restart, and events can be missed while the bot is offline.

Why not use REST polling alone?

Frequent polling can create unnecessary API traffic and may be less responsive to market changes.

A useful architecture looks like this:

Market WebSocket
       |
       v
Market Data Cache
       |
       v
Pricing Engine
       |
       v
Risk Manager
       |
       v
Order Manager
       |
       v
Polymarket CLOB
       |
       +------> Order/Trade Updates
       |
       +------> REST Reconciliation
                       |
                       v
               Local Order State

WebSockets provide timely updates. REST reconciliation helps the bot recover when its local view becomes incomplete.

Check the current official Polymarket documentation for the supported endpoints, authentication, subscription formats, and client methods before implementing this architecture.

9. Build a Basic Order Manager in Python

Let's bring the main concepts together.

The following code implements a small decision-making layer. It does not submit real orders or call the Polymarket API.

from dataclasses import dataclass
from decimal import Decimal
from enum import Enum


class OrderStatus(str, Enum):
    PENDING_SUBMISSION = "pending_submission"
    OPEN = "open"
    PARTIALLY_FILLED = "partially_filled"
    PENDING_CANCEL = "pending_cancel"
    FILLED = "filled"
    CANCELED = "canceled"
    REJECTED = "rejected"
    UNKNOWN = "unknown"


@dataclass
class Order:
    order_id: str
    side: str
    price: Decimal
    original_size: Decimal
    matched_size: Decimal
    status: OrderStatus

    @property
    def remaining_size(self) -> Decimal:
        return max(
            Decimal("0"),
            self.original_size - self.matched_size,
        )


def needs_replacement(
    order: Order,
    target_price: Decimal,
    min_price_change: Decimal,
) -> bool:
    active_states = {
        OrderStatus.OPEN,
        OrderStatus.PARTIALLY_FILLED,
    }

    if order.status not in active_states:
        return False

    if order.remaining_size <= 0:
        return False

    return (
        abs(order.price - target_price)
        >= min_price_change
    )

Let's understand what this code does.

First, it defines the possible states the bot tracks.

Second, it calculates how much of an order remains unfilled.

Third, it checks whether an active order should be considered for replacement.

For example, an open buy order at $0.48 may need reconsideration when the target price changes to $0.50.

However, this function does not cancel or replace anything automatically.

A complete implementation must also check:

Market data freshness
Available balance
Inventory and exposure limits
Duplicate or conflicting orders
Open-order limits
Outstanding cancellation requests
Exchange connectivity and market status

Keeping these responsibilities separate makes the system easier to reason about and test.

10. Add Risk Checks Before Sending Orders

Never place an order simply because the pricing engine produced a price.

Before submission, check the following:

Check	Question
Market data	Is the order book fresh enough?
Price	Is the price valid for this market?
Quantity	Is the order size permitted?
Balance	Are sufficient funds or tokens available?
Inventory	Could this order exceed the position limit?
Open orders	Does a duplicate or conflicting order exist?
Order state	Is another submission or cancellation unresolved?
Market status	Is the market still accepting orders?
Connectivity	Can the bot monitor and reconcile its orders?

One especially important rule is to consider potential exposure from open orders, not just current inventory.

Suppose your bot currently holds 80 YES tokens and has two open buy orders for 50 additional YES tokens each.

Its current inventory is 80 tokens.

If both orders fill, inventory could reach:

80 + 50 + 50 = 180 tokens

If the configured inventory limit is 150 tokens, the bot must account for those possible fills before submitting more orders.

The exact exposure calculation depends on your strategy, available collateral, related positions, and other outstanding orders.

Start with conservative limits and test the calculations carefully.

11. Protect Your Orders When the Bot Crashes

Imagine your bot runs on a VPS and has several active orders.

Then the process crashes because of a software bug or server restart.

The orders may remain active even though the process that manages them is no longer running.

The market can continue moving while your bot is unable to react.

A production system needs a recovery plan.

Before shutdown or restart

Decide whether open orders should be canceled or preserved for controlled recovery.
Persist enough information to identify previously submitted orders.
Never assume that stopping the process automatically cancels exchange orders.

After restart

Reconnect to the exchange.
Retrieve relevant open orders and trade information.
Rebuild local order state.
Reconcile fills that occurred while offline.
Recalculate inventory and available funds.
Resume quoting only when the account state is sufficiently understood.

Where supported, investigate heartbeat or dead-man-switch functionality that can cancel resting orders if required heartbeats stop. Verify its exact behavior and timeout semantics before relying on it.

Additional protections can include maximum order lifetimes, stale-data shutdown rules, and emergency cancellation procedures.

These protections complement reconciliation; they don't replace it.

12. Test Failure Scenarios Before Live Trading

A bot that works during a normal demonstration isn't necessarily reliable.

Before using real funds, test how it responds to failures.

Scenario	Expected behavior
Order accepted	Track it as active
Order rejected	Record the rejection and avoid treating it as filled
Partial fill	Update inventory and remaining quantity
Full fill	Mark the order complete
Cancellation races with a fill	Reconcile the final status and matched quantity
Submission times out	Mark the outcome uncertain and avoid blind retries
Duplicate trade event arrives	Do not count the same fill twice
WebSocket disconnects	Reconnect and reconcile missed updates
Bot restarts with open orders	Rebuild local state before resuming
Market becomes inactive	Stop submitting inappropriate orders
Balance changes	Recalculate available funds and exposure
Market data becomes stale	Stop new quoting until data is reliable

For every scenario, define the expected behavior before writing the test.

For example:

Scenario: The order-submission request times out.

Expected behavior: The bot marks the outcome as uncertain, checks the exchange state, avoids blindly resubmitting, and prevents additional exposure from exceeding its risk limits while the outcome is unresolved.

This is how you move from a simple trading script toward a reliable trading system.

13. The Complete Order-Management Loop

A market maker's order-management loop can be summarized in ten steps:

Read fresh market data.
Calculate target bid and ask prices.
Check market and account risk.
Compare target prices with tracked orders.
Decide whether to keep, cancel, or replace orders.
Submit only permitted orders.
Track acknowledgments and trade updates.
Reconcile uncertain order states.
Update inventory and available funds.
Repeat.

The bot should stop placing new orders when market data becomes stale, account state cannot be reconciled, or a configured risk limit is breached.

A reliable market maker doesn't keep trading just because its main process is still running.

It trades only when it has enough reliable information to make a controlled decision.

Conclusion

Building a Polymarket market maker bot requires much more than calculating bid and ask prices.

The bot must manage the complete order lifecycle, including partial fills, cancellations, API timeouts, reconnects, and recovery after a crash.

Here are the most important lessons from Day 5:

An accepted order is not necessarily a filled order.
Partial fills must update inventory and remaining quantity.
Cancellation and replacement require careful state management.
An API timeout does not prove that an order failed.
WebSocket updates should be combined with reconciliation.
Risk checks must account for open orders as well as current inventory.
Restarting a bot must not mean blindly trusting its previous local state.

In Day 6, we'll move from order management to inventory risk, market conditions, and adverse selection. We'll explore why market makers sometimes get filled just before the market moves against them, and how a bot can respond.

Continue the Project

GitHub repository: [Polymarket Trading Bot in Python]

Benj4minCup / Polymarket-Trading-Bot-python

Polymarket Trading Bot Twap Bot polymarket Arbitrage Bot

Polymarket Trading bot system

An open-source and Strong Strategy collection of Polymarket trading bot and Polymarket arbitrage bot and Polymarket TWAP trading bot in Python for high-performance automated trading on polymarket crypto 5min and 15min markets.

This repository is primarily intended for educational and research purposes. It includes strategy concepts, implementation approaches, and selected performance screenshots to help developers understand how different automated trading strategies can be designed and tested.

The repository does not provide a complete production-ready trading bot source code. Instead, it provides strategy descriptions and research materials that you can use as a foundation for developing your own system.

If you are interested in building a Polymarket Trading Bot, you can follow my tutorials and use the concepts in this repository to develop your own implementation.

For users who prefer a ready-to-deploy solution or require custom strategy development, commercial bot development and customization are also available.

Features

…

View on GitHub

YouTube tutorial: [Watch the Polymarket trading bot tutorial]

Telegram: Join the discussion

Follow along as we build a Polymarket trading bot step by step, from market data and pricing to order execution and risk management.

Building a Polymarket Market Maker in Python: Quotes, Spreads, and Inventory Management

Benjamin-Cup — Tue, 27 Oct 2026 16:08:51 +0000

Day 4 of 7 — Building a Polymarket Market Maker Bot From Zero to Complete

How does a trading bot decide when to buy, when to sell, and which prices to use?

In the previous articles in this series, we explored what a Polymarket trading bot is, how prediction market order books work, and how to retrieve market data using Python.

Today, we're moving from reading the order book to calculating our own quotes.

We'll build a simple market-making strategy that calculates bid and ask prices, adjusts quotes based on inventory, and validates its output before any order reaches the exchange.

By the end of this tutorial, you'll understand:

How to calculate a reference price from the order book
How bid-ask spreads work
How inventory affects market-making decisions
How to implement inventory-aware pricing in Python
How to write unit tests for your strategy
What needs to happen before connecting the strategy to live order execution

This is an educational implementation, not a production-ready trading bot. We'll keep the pricing logic separate from order execution so we can test it independently.

1. What Is a Market-Making Strategy?

Imagine a Polymarket market asking whether Bitcoin will finish above a particular price at a specified time.

The YES token currently has the following order book:

Order book item	Price
Best bid	$0.48
Best ask	$0.52
Midpoint	$0.50

The best bid is the highest price someone is currently offering to pay. The best ask is the lowest price someone is currently willing to accept.

Our bot wants to place its own orders.

For example:

Buy YES at $0.49.
Sell YES at $0.51.

These prices would improve on the existing bid and ask in this hypothetical example, provided the market's tick size and other trading rules permit them.

But should the bot always use these prices?

No.

The market changes constantly. Liquidity can disappear, competing orders can arrive, and the bot can accumulate more tokens than it wants to hold.

A market-making strategy converts market data, trading parameters, and current inventory into desired quotes.

The goal is to provide liquidity while managing execution risk and inventory exposure. A positive spread alone does not guarantee a profit.

2. Calculate the Reference Price

Before generating quotes, we need a reference price.

For a simple market maker, we can start with the midpoint between the best bid and the best ask.

The formula is:

[
M = \frac{B + A}{2}
]

Where:

(M) = midpoint
(B) = best bid
(A) = best ask

Using our example:

[
M = \frac{0.48 + 0.52}{2} = 0.50
]

Our reference price is $0.50.

The midpoint is easy to calculate, but it has limitations. It doesn't necessarily represent the token's true value, and it may not be executable at meaningful size.

A more advanced strategy could incorporate order book imbalance, recent price movements, volatility, and other signals to estimate a fair value.

For now, we'll use the midpoint to keep the implementation simple.

Important: If market data is stale, the book is empty, or the best bid is greater than or equal to the best ask, the bot should stop generating quotes until the data has been validated.

3. Calculate the Bid and Ask

A basic market maker places its bid below the reference price and its ask above it.

We can express this as:

[
\text{Bid} = M - h
]

[
\text{Ask} = M + h
]

Here, (h) represents the target half-spread.

Suppose our parameters are:

Midpoint: $0.50
Half-spread: $0.02

The result is:

Parameter	Value
Midpoint	$0.50
Half-spread	$0.02
Target bid	$0.48
Target ask	$0.52
Total spread	$0.04

The total spread is:

[
S = \text{Ask} - \text{Bid}
]

Therefore:

[
S = 0.52 - 0.48 = 0.04
]

This gives us a simple starting point for calculating quotes.

However, a fixed spread ignores market conditions. A narrow spread might be competitive in a liquid market but risky during rapid price movements. A wide spread might protect against some risks but make our orders less competitive.

Let's look at how inventory changes the calculation.

4. Why Inventory Management Matters

Imagine our bot starts with zero YES tokens.

It places:

A buy order for 100 YES tokens at $0.48.
A sell order at $0.52.

The buy order fills, but the sell order doesn't.

Our bot now holds 100 YES tokens.

If it continues placing the same buy and sell quotes, it could accumulate even more tokens without reducing its existing position.

This is called inventory risk.

A market maker must consider not only the price of its next trade but also how that trade changes its overall position.

When inventory grows, the strategy might:

Make its buy quote less competitive.
Adjust its sell quote to encourage inventory reduction.
Reduce order sizes.
Stop placing additional buy orders at its maximum inventory limit.

These are separate controls. Adjusting prices can influence trading behavior, but it cannot guarantee that inventory will decrease.

5. Implement Inventory-Aware Pricing

Let's introduce a simple inventory adjustment.

Instead of generating quotes directly from the midpoint, we'll adjust our reference price first:

[
R = M - qk
]

Where:

(R) = inventory-adjusted reference price
(M) = market midpoint
(q) = current inventory, measured in tokens
(k) = inventory adjustment per token

Positive inventory shifts the reference price downward. Negative inventory shifts it upward, assuming inventory is measured relative to a target position of zero.

For example:

Midpoint = $0.50
Inventory = 100 YES tokens
Inventory adjustment = $0.0001 per token

Then:

[
R = 0.50 - (100 \times 0.0001)
]

[
R = 0.49
]

Our adjusted reference price is $0.49.

With a half-spread of $0.02:

[
\text{Bid} = 0.49 - 0.02 = 0.47
]

[
\text{Ask} = 0.49 + 0.02 = 0.51
]

Compare the original and adjusted quotes:

Quote	Before adjustment	After adjustment
Bid	$0.48	$0.47
Ask	$0.52	$0.51

Both quotes have moved downward.

The lower bid makes the bot less eager to acquire additional YES tokens, while the lower ask may make selling more competitive.

This is a simplified inventory-skew model. In a production strategy, the adjustment should be calibrated to inventory limits, volatility, liquidity, time to market resolution, and the cost of reducing exposure.

6. Write the Pricing Function in Python

Now let's implement the pricing logic.

We'll use Python's Decimal type instead of floating-point numbers because trading prices require predictable decimal arithmetic.

Create a file called strategy.py:

from dataclasses import dataclass
from decimal import Decimal


@dataclass(frozen=True)
class Quote:
    bid: Decimal
    ask: Decimal


def calculate_quotes(
    midpoint: Decimal,
    half_spread: Decimal,
    inventory: Decimal,
    inventory_skew: Decimal,
    min_price: Decimal = Decimal("0.01"),
    max_price: Decimal = Decimal("0.99"),
) -> Quote:
    """
    Calculate inventory-aware candidate quotes.

    Positive inventory shifts both quotes downward.
    Negative inventory shifts both quotes upward.

    This function calculates prices only.
    It does not submit live orders.
    """

    if not min_price < max_price:
        raise ValueError("Invalid price bounds")

    if not min_price <= midpoint <= max_price:
        raise ValueError("Midpoint is outside allowed bounds")

    if half_spread <= 0:
        raise ValueError("Half-spread must be positive")

    if inventory_skew < 0:
        raise ValueError("Inventory skew must not be negative")

    adjusted_reference = (
        midpoint - inventory * inventory_skew
    )

    bid = adjusted_reference - half_spread
    ask = adjusted_reference + half_spread

    # Clamp candidate prices to configured bounds.
    bid = max(min_price, min(bid, max_price))
    ask = max(min_price, min(ask, max_price))

    if bid >= ask:
        raise ValueError(
            "Quotes are invalid after applying price bounds"
        )

    return Quote(bid=bid, ask=ask)


if __name__ == "__main__":
    quote = calculate_quotes(
        midpoint=Decimal("0.50"),
        half_spread=Decimal("0.02"),
        inventory=Decimal("100"),
        inventory_skew=Decimal("0.0001"),
    )

    print("Candidate bid:", quote.bid)
    print("Candidate ask:", quote.ask)

Run the script:

python strategy.py

Expected output:

Candidate bid: 0.4700
Candidate ask: 0.5100

We now have a function that transforms market conditions and inventory into candidate quotes.

Notice what the function doesn't do:

It doesn't retrieve market data.
It doesn't check whether the order book has changed.
It doesn't place or cancel orders.
It doesn't check account balances.
It doesn't guarantee that either quote can be executed.

Keeping these responsibilities separate makes the strategy easier to understand and test.

Implementation note: Clamping prices to a range is not enough to validate an actual order. Production code must also handle tick-size rounding, minimum order sizes, crossing the book, and the case where a valid bid and ask cannot be produced.

7. Order Size Is Just as Important as Price

Suppose two bots use the same quotes.

Bot A places orders for 5 tokens.

Bot B places orders for 1,000 tokens.

Their prices are identical, but their inventory exposure is very different.

If the buy orders fill, Bot B can accumulate a much larger position before the bot has an opportunity to react.

A basic order-sizing policy should consider:

Available capital
Current inventory
Maximum allowed position
Market liquidity
Minimum order requirements
Potential costs of exiting the position
Multiple orders filling before cancellations complete

For an initial implementation, use a small fixed order size and enforce a strict maximum inventory.

For example, if the bot has reached its maximum allowed YES inventory, the risk manager should prevent it from submitting additional buy orders.

This control should be enforced independently of the quote calculation. A valid price does not automatically mean the bot should be allowed to trade.

8. Validate Quotes Against Polymarket's Trading Rules

Our Python function calculates decimal prices, but a real Polymarket order must satisfy the selected market's current trading rules.

A candidate price such as $0.4837 may not be valid for a market with a different tick size.

Before submitting an order, the bot should:

Retrieve the market's current trading parameters.
Round prices to valid increments using a deliberate rounding policy.
Validate price bounds and order-size precision.
Check token balances and available funds.
Check whether the order would cross the current book.
Confirm that the market is still open for trading.
Verify inventory and risk limits.

Avoid hardcoding a single tick size or minimum order size for every market.

Also, the book may change between calculation and submission. Local validation reduces avoidable errors, but it cannot eliminate execution races.

9. Separate Strategy, Risk, and Execution

A market-making bot is easier to maintain when its responsibilities are separated.

A useful architecture looks like this:

Market Data
    |
    v
Quote Strategy
    |
    v
Risk Manager
    |
    v
Order Manager
    |
    v
Polymarket Trading Interface
    |
    v
Order and Fill Updates
    |
    v
Inventory State

Each component has a distinct responsibility.

Market Data

Retrieves order book updates and maintains a reliable view of current market conditions.

Quote Strategy

Calculates the desired bid and ask prices.

Risk Manager

Checks maximum inventory, order size, available capital, and other trading limits.

Order Manager

Decides whether to submit, retain, cancel, or replace existing orders.

Execution Tracking

Processes order updates, partial fills, completed fills, and cancellations, then reconciles the internal state with the actual account state.

For example, the strategy might calculate a bid of $0.47. But if the current best ask has moved to $0.46, submitting that bid could execute immediately instead of resting passively.

The order manager needs to detect this situation and follow the strategy's execution policy.

Likewise, if inventory has reached its maximum, the risk manager must block additional buy orders even if their prices are valid.

This separation is especially important when moving from a local Python experiment to a live trading system.

10. Test the Strategy Before Live Trading

Before connecting the strategy to an order manager, test its behavior independently.

Install pytest:

pip install pytest

Create test_strategy.py:

from decimal import Decimal

from strategy import calculate_quotes


def test_zero_inventory_produces_symmetric_quotes():
    quote = calculate_quotes(
        midpoint=Decimal("0.50"),
        half_spread=Decimal("0.02"),
        inventory=Decimal("0"),
        inventory_skew=Decimal("0.0001"),
    )

    assert quote.bid == Decimal("0.48")
    assert quote.ask == Decimal("0.52")


def test_positive_inventory_shifts_quotes_down():
    neutral = calculate_quotes(
        midpoint=Decimal("0.50"),
        half_spread=Decimal("0.02"),
        inventory=Decimal("0"),
        inventory_skew=Decimal("0.0001"),
    )

    long_position = calculate_quotes(
        midpoint=Decimal("0.50"),
        half_spread=Decimal("0.02"),
        inventory=Decimal("100"),
        inventory_skew=Decimal("0.0001"),
    )

    assert long_position.bid < neutral.bid
    assert long_position.ask < neutral.ask


def test_negative_inventory_shifts_quotes_up():
    neutral = calculate_quotes(
        midpoint=Decimal("0.50"),
        half_spread=Decimal("0.02"),
        inventory=Decimal("0"),
        inventory_skew=Decimal("0.0001"),
    )

    short_position = calculate_quotes(
        midpoint=Decimal("0.50"),
        half_spread=Decimal("0.02"),
        inventory=Decimal("-100"),
        inventory_skew=Decimal("0.0001"),
    )

    assert short_position.bid > neutral.bid
    assert short_position.ask > neutral.ask

Run the tests:

pytest -q

These tests verify three basic properties:

Zero inventory produces symmetric quotes around the midpoint.
Positive inventory shifts both quotes downward.
Negative inventory shifts both quotes upward.

You should also test invalid inputs, extreme inventory, price boundaries, and cases where clamping would make the bid equal to or greater than the ask.

Unit tests verify that the function behaves as intended. They do not demonstrate that the strategy is profitable.

11. How Can We Evaluate Market-Making Performance?

Once the pricing function passes its tests, the next step is to replay recorded order book data and simulate order execution.

A useful simulation should account for:

Orders that never fill
Partial fills
Queue priority
Cancellation delays
Price movements after a fill
Trading fees and other applicable costs
Inventory accumulation
The cost of reducing or closing a position

One important risk is adverse selection.

Imagine the bot buys YES at $0.48. A moment later, new information causes the token's fair value to fall to $0.42.

The bot may have earned the apparent spread on paper in other trades, but this particular fill creates an unrealized loss.

That is why spread size alone is not a sufficient measure of performance.

Track metrics such as:

Realized and unrealized P&L
Inventory over time
Fill rate
Average spread captured
Fees and execution costs
Adverse price movement after fills
Maximum inventory exposure

A credible evaluation should also account for the outcome of prediction-market positions at resolution. For a YES token, the final payout depends on the market's resolution rules, not simply on the last quoted price.

Use historical replay and paper trading to identify problems before considering live deployment.

12. What We've Built

In this lesson, we moved from observing the order book to calculating inventory-aware quotes.

We implemented a small Python strategy that:

Calculates bid and ask prices from a midpoint
Applies an inventory adjustment
Uses Decimal for price calculations
Checks basic price bounds
Can be tested without connecting to a live exchange

We also explored order sizing, market validation, risk management, execution architecture, and testing.

The key lesson is that calculating a price is only one part of building a market maker. A reliable system must also manage inventory, validate orders, track execution, and respond to changing market conditions.

What's Next? Day 5 — Automated Quoting and Order Management

In Day 5, we'll move from calculating candidate quotes to managing orders.

We'll explore how to:

Submit limit orders through Polymarket's supported trading interface
Track open orders and their status
Cancel or replace outdated quotes
Handle partial fills and uncertain API responses
Avoid duplicate orders
Reconcile internal state with actual account state

The goal is to connect our strategy to an order manager without losing control of inventory or execution state.

Follow the Project

GitHub repository: [Polymarket Trading Bot — Python]

Benj4minCup / Polymarket-Trading-Bot-python

Polymarket Trading Bot Twap Bot polymarket Arbitrage Bot

Polymarket Trading bot system

If you are interested in building a Polymarket Trading Bot, you can follow my tutorials and use the concepts in this repository to develop your own implementation.

For users who prefer a ready-to-deploy solution or require custom strategy development, commercial bot development and customization are also available.

Features

…

View on GitHub

YouTube : [Watch the Polymarket trading bot tutorial]

Telegram: [Join the discussion]
https://telegram.me/BenjaminCup

Follow the seven-day series as we build a Polymarket market maker bot, from understanding prediction markets to implementing pricing logic, order management, risk controls, and deployment.

Disclaimer: This tutorial is for educational purposes only and is not financial advice. Market making involves financial risk. The example strategy has not been demonstrated to be profitable. Test thoroughly with historical data and paper trading before considering live execution.

Polymarket Trading Bot: Build a Market Maker Bot in Python- Project Setup and API Integration

Benjamin-Cup — Wed, 21 Oct 2026 16:20:23 +0000

Day 3 of 7: Building a Polymarket Market Maker Bot From Zero to Complete

In the first two parts of this series, we explored what a Polymarket market maker bot is and how the Polymarket order book works.

We covered YES and NO outcome tokens, bid-ask spreads, market depth, limit orders, and the risks of providing liquidity.

Now, let's start building.

In this tutorial, we'll set up a Python project, connect to Polymarket's public market data API, discover available markets, retrieve outcome asset identifiers, and inspect an order book.

By the end, you'll have the foundation of a Python market maker bot that can read market data and calculate basic pricing metrics.

Important: This tutorial is read-only. It does not submit orders, spend funds, or require a private key.

What We'll Build

Our first version will perform five tasks:

Connect to Polymarket's public API.
Discover available markets.
Identify a market's YES and NO assets.
Retrieve the order book for a selected asset.
Calculate the best bid, best ask, spread, and midpoint.

The data flow looks like this:

Polymarket Market Data
        |
        v
   Market Discovery
        |
        v
    Select a Market
        |
        v
  Identify YES / NO Assets
        |
        v
    Fetch Order Book
        |
        v
 Calculate Spread & Midpoint
        |
        v
      Print Results

This is a small program, but it establishes an important component of every trading bot: the market data layer.

A production market maker would extend this foundation with real-time data subscriptions, strategy logic, order management, inventory tracking, risk controls, and monitoring.

1. Choose the Python SDK

Polymarket provides developer interfaces for market discovery, order books, pricing, and trading.

For this tutorial, we'll use the unified Python SDK identified in the project references:

Official repository: Polymarket Python SDK

The package used in the examples is polymarket-client.

The SDK is intended to provide access to market information and other Polymarket workflows. Public market-data access does not require you to configure trading credentials for this read-only exercise.

Before installing it, check the repository's current installation instructions and examples. SDK interfaces can change, and code written for an older client may not work with the current version.

2. Set Up Your Development Environment

You can follow this tutorial on Windows, macOS, or Linux.

Check Python

python --version

On some systems, use:

python3 --version

Create a project directory

mkdir polymarket-market-maker
cd polymarket-market-maker

Create a virtual environment

python -m venv .venv

Activate it on Windows PowerShell:

.venv\Scripts\Activate.ps1

On macOS or Linux:

source .venv/bin/activate

Install the SDK

python -m pip install --upgrade pip
pip install polymarket-client

Verify the import:

python -c "from polymarket import PublicClient; print('SDK import successful')"

If the import fails, check the SDK's current Python requirements and installation instructions before proceeding.

3. Create a Clean Project Structure

A common beginner mistake is putting market discovery, pricing calculations, and trading logic into one large Python file.

Let's separate responsibilities from the beginning.

polymarket-market-maker/
├── src/
│   └── polymarket_mm/
│       ├── __init__.py
│       ├── market_data.py
│       ├── orderbook.py
│       ├── pricing.py
│       └── main.py
├── tests/
├── .gitignore
└── README.md

Each module has a specific responsibility:

market_data.py — discovers markets and retrieves market information.
orderbook.py — retrieves and inspects order book levels.
pricing.py — calculates spread and midpoint.
main.py — connects the modules and runs the example.
tests/ — contains tests for pricing calculations and other logic.

This structure is intentionally simple. We don't need a complex architecture before our first API request works.

4. Discover Markets Through the SDK

Before inspecting an order book, the bot needs to discover which markets are available.

Create src/polymarket_mm/market_data.py:

from polymarket import PublicClient


def list_markets(limit: int = 10):
    """Return a page of markets from Polymarket."""

    with PublicClient() as client:
        page = client.list_markets(
            closed=False,
            page_size=limit,
        ).first_page()

        return page.items


if __name__ == "__main__":
    markets = list_markets()

    for market in markets:
        print(
            {
                "question": market.question,
                "slug": market.slug,
                "market_id": market.id,
            }
        )

Run the module from your project root.

On macOS or Linux:

PYTHONPATH=src python -m polymarket_mm.market_data

On Windows PowerShell:

$env:PYTHONPATH = "src"
python -m polymarket_mm.market_data

The program requests a page of markets and prints basic information about each result.

One important detail: closed=False does not necessarily mean a market is currently accepting orders. A production bot should separately validate market status, trading permissions, and the availability of a usable order book.

For the current implementation, consult the official market discovery example.

5. Understand Market IDs and Asset IDs

A market and a tradable asset are not the same thing.

A market represents an event or question.

An asset identifier identifies a tradable outcome or position associated with that market.

For a conventional binary market, there are typically YES and NO outcomes. However, market infrastructure can evolve, so avoid assuming every market exposes its tradable identifiers in exactly the same format.

The SDK's market model may expose a token ID, position ID, or another identifier depending on the market representation.

The key principle is simple:

Use the current SDK's market model and official examples instead of extracting identifiers from URLs or relying on undocumented raw JSON structures.

You can review the SDK's market helper examples to understand how outcome identifiers are accessed.

6. Retrieve an Order Book

Now let's inspect an actual market.

The following example searches a limited page of open markets until it finds one with a usable YES asset identifier. It then requests the corresponding order book.

Create src/polymarket_mm/orderbook.py:

from polymarket import PublicClient


def inspect_first_available_market():
    with PublicClient() as client:
        markets = client.list_markets(
            closed=False,
            page_size=100,
        ).first_page().items

        for market in markets:
            # Conventional binary-market example.
            # Check the SDK model for your market version.
            yes = market.outcomes.yes

            asset_id = yes.token_id or yes.position_id

            if asset_id is None:
                continue

            try:
                book = client.get_order_book(
                    asset_id=asset_id
                )
            except Exception as exc:
                print(
                    f"Skipping market {market.id}: "
                    f"could not retrieve its book: {exc}"
                )
                continue

            if not book.bids and not book.asks:
                continue

            return market, asset_id, book

    raise RuntimeError(
        "No market with a usable YES order book was found. "
        "Try again or refine market discovery."
    )


def main():
    market, asset_id, book = inspect_first_available_market()

    print("Market:", market.question)
    print("Market ID:", market.id)
    print("Asset ID:", asset_id)
    print("Number of bids:", len(book.bids))
    print("Number of asks:", len(book.asks))

    print("\nTop bids:")
    for level in sorted(
        book.bids,
        key=lambda item: item.price,
        reverse=True,
    )[:5]:
        print("Price:", level.price, "Size:", level.size)

    print("\nTop asks:")
    for level in sorted(
        book.asks,
        key=lambda item: item.price,
    )[:5]:
        print("Price:", level.price, "Size:", level.size)


if __name__ == "__main__":
    main()

Run it:

PYTHONPATH=src python -m polymarket_mm.orderbook

On Windows PowerShell, use the PYTHONPATH command from the previous section.

The program prints the market question, asset identifier, number of bid and ask levels, and the five best levels on each side.

A few things to remember:

The best bid is the highest available buy price.
The best ask is the lowest available sell price.
The size indicates the quantity available at a price level.
An empty order book does not provide enough information to calculate both sides of the spread.

The code is an educational starting point, not a guarantee that every market returned by the API will expose these exact fields. Verify the current SDK model before running it.

For another reference, see the official market prices example.

7. Calculate the Spread and Midpoint

Once we have the order book, we can calculate two basic market metrics.

Bid-ask spread

The spread measures the difference between the best ask and the best bid.

[
\text{Spread} = \text{Best Ask} - \text{Best Bid}
]

For example, suppose the best bid is $0.48 and the best ask is $0.52.

The spread is:

0.52 - 0.48 = 0.04

The spread is four cents per share.

Midpoint

The midpoint is the average of the best bid and best ask.

[
\text{Midpoint} =
\frac{\text{Best Bid}+\text{Best Ask}}{2}
]

Using the same example:

(0.48 + 0.52) / 2 = 0.50

The midpoint is $0.50.

Important: The midpoint is a reference price, not a guaranteed execution price. A market order or limit order may execute at a different price depending on liquidity and market conditions.

Implement the calculations

Create src/polymarket_mm/pricing.py:

def calculate_book_metrics(bids, asks):
    """Calculate basic metrics from order book levels."""

    best_bid = max(
        (float(level.price) for level in bids),
        default=None,
    )

    best_ask = min(
        (float(level.price) for level in asks),
        default=None,
    )

    if best_bid is None or best_ask is None:
        return {
            "best_bid": best_bid,
            "best_ask": best_ask,
            "spread": None,
            "midpoint": None,
        }

    if best_bid > best_ask:
        raise ValueError(
            "The book appears crossed; inspect the data "
            "and API response before using it."
        )

    return {
        "best_bid": best_bid,
        "best_ask": best_ask,
        "spread": best_ask - best_bid,
        "midpoint": (best_bid + best_ask) / 2,
    }

You can import this function into the order book example:

from polymarket_mm.pricing import calculate_book_metrics

metrics = calculate_book_metrics(
    book.bids,
    book.asks,
)

print("\nBook metrics:")
for name, value in metrics.items():
    print(f"{name}: {value}")

For financial calculations and order construction, prefer Decimal or the SDK's decimal-compatible types over binary floating-point arithmetic.

The example uses float for simplicity and educational display.

8. Add Error Handling and Logging

Real-world API requests can fail.

Common causes include:

Network timeouts.
Rate limits.
Invalid asset identifiers.
Temporary service errors.
Disconnected WebSocket connections.
Missing or stale market data.

Different errors require different responses.

A timeout may justify a controlled retry. A rate-limit response should trigger appropriate backoff. An invalid identifier may indicate a market-selection problem.

Stale data is particularly important for a market maker. If the order book is outdated, the bot should not continue generating quotes as if the information were current.

Start with Python's standard logging module:

import logging

logging.basicConfig(
    level=logging.INFO,
    format="%(asctime)s %(levelname)s %(message)s",
)

logger = logging.getLogger(__name__)

logger.info("Market data module started")

As the project grows, structured logs will help investigate market data updates, order submissions, fills, cancellations, and risk-limit events.

Avoid infinite retry loops. A robust bot should stop making trading decisions when its data cannot be trusted.

9. Why We Are Not Placing Orders Yet

At this stage, our program can retrieve market information, but it is not yet a market maker.

It does not know:

What prices it should quote.
How large its orders should be.
When it should cancel or replace orders.
How to manage inventory.
How to control exposure and capital usage.
How to reconcile partial fills and failed requests.

Adding live order placement before implementing these components would be premature.

A safer development sequence is:

Retrieve market data reliably.
Calculate candidate quotes.
Validate quotes against price and risk limits.
Simulate decisions using recorded or live market data.
Implement order lifecycle management.
Test failures, cancellations, and partial fills.
Consider controlled live testing only after sufficient validation.

Separating market data from order execution makes the bot easier to test and reduces the risk of an early coding mistake spending real funds.

10. What We Built Today

By completing Day 3, we have established the initial market data layer.

We now have a foundation for:

Installing and importing the Python SDK.
Discovering open markets.
Identifying a usable YES asset identifier.
Retrieving an order book.
Inspecting bid and ask levels.
Calculating spread and midpoint metrics.
Recognizing the importance of API errors and stale data.

This is the first step toward a more complete market maker bot.

Day 4: Design the Market-Making Strategy

In Day 4, we'll move from observing the market to generating candidate quotes.

We'll explore:

How to select a reference price.
How to calculate bid and ask quotes.
How to set a target spread.
How to choose order sizes.
How to adjust quotes based on inventory.
Why fixed-distance-from-midpoint strategies can perform poorly during rapid price movements.

The objective is to build a strategy layer that can be tested before connecting it to live order execution.

Follow the Project

GitHub repository: Polymarket Trading Bot in Python

YouTube tutorial: Watch the video

Contact and discussion: Telegram — BenjaminCup

Follow the series as we build a Polymarket market maker bot from the fundamentals toward a complete Python implementation.

Python #Polymarket #TradingBot #AlgoTrading #Crypto

Polymarket Trading Bot: How the Order Book Works: YES/NO Tokens, Bid-Ask Spreads, and Liquidity

Benjamin-Cup — Tue, 20 Oct 2026 13:50:04 +0000

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.

Polymarket #Python #TradingBot #AlgorithmicTrading #MarketMaking #Web3 #Crypto #SoftwareDevelopment #Programming #FinTech

Polymarket Trading Bot : Building Market Maker Bot With Python- A Beginner's Guide

Benjamin-Cup — Mon, 19 Oct 2026 13:33:18 +0000

Day 1 of 7 — Understanding Market Making, Liquidity, and Automated Trading

What does it take to build a trading bot that continuously monitors a market, places buy and sell orders, and manages risk automatically?

One interesting way to explore this problem is by building a Polymarket market maker bot using Python.

Polymarket is a prediction market where users trade outcome tokens associated with real-world events. These markets create an interesting engineering challenge: prices change, liquidity varies, orders may only partially fill, and a strategy that looks profitable on paper can lose money in practice.

In this tutorial series, we'll explore the fundamentals of market making and gradually work toward a complete automated trading system.

We'll cover market data, order book analysis, trading strategies, order management, inventory control, and risk management.

Let's start with the most important question.

1. What Is a Market Maker Bot?

A market maker bot is a program that automatically places and manages limit orders to provide liquidity.

Instead of simply buying an outcome because it expects that outcome to win, a market maker attempts to earn revenue by trading at favorable prices while managing the risks associated with its positions.

Imagine a prediction market asking:

Will Bitcoin be above $100,000 at the end of a specified period?

Suppose the YES token has the following order book:

Order	Price	Meaning
Best bid	$0.48	Highest price a buyer offers
Best ask	$0.52	Lowest price a seller accepts
Midpoint	$0.50	Average of the best bid and ask
Spread	$0.04	Difference between ask and bid

A market-making bot might place a buy order at $0.48 and a sell order at $0.52.

If both orders execute at those prices, the bot may capture the difference.

However, placing orders doesn't guarantee that they will execute, and executing both sides doesn't guarantee a profit after costs and inventory losses.

The real engineering challenge is managing orders and risk as market conditions change.

2. How Does a Market Maker Make Money?

The central concept is the bid-ask spread.

The spread is calculated as:

Spread = Best Ask - Best Bid

Using our example:

$0.52 - $0.48 = $0.04

Suppose the bot buys 100 YES tokens at $0.48 and later sells all 100 at $0.52.

The illustrative gross trading profit is:

100 × ($0.52 - $0.48) = $4.00

This calculation excludes trading costs, inventory losses, and other execution effects.

But here's the problem.

What happens if the buy order executes and the sell order doesn't?

The bot now holds 100 tokens. If the market price falls, the value of that inventory decreases. The bot may need to sell at a worse price or wait for better conditions.

This is why market making is not simply about placing orders far apart.

A practical strategy must consider:

Order-fill probability: How likely is each order to execute?
Inventory exposure: How much of each outcome does the bot hold?
Market volatility: How quickly can prices change?
Execution quality: Are orders being filled at favorable prices?
Trading costs: What costs and applicable incentives affect the final result?
Data freshness: Is the bot making decisions using current market information?

A wider spread isn't necessarily better. It may reflect a market with poor liquidity or significant risk.

3. Market Making vs. Arbitrage vs. Momentum Trading

These three approaches are useful to distinguish when designing an automated trading system.

Market making

The bot provides liquidity by placing limit orders.

Its potential revenue comes from favorable execution spreads and, where eligible, liquidity incentives or maker rebates.

The main challenges are inventory management, execution quality, and adverse selection.

Arbitrage

An arbitrage strategy searches for pricing inconsistencies between related assets, outcomes, or markets.

For example, a strategy might investigate whether complementary YES and NO positions can be acquired for less than their combined settlement value.

The bot must account for actual token mechanics, execution costs, liquidity, and whether all necessary trades can complete.

Momentum trading

A momentum strategy attempts to benefit from an emerging price movement.

For example, a bot might monitor Bitcoin's spot price and adjust its trading decisions when a significant movement occurs.

The main challenges are identifying meaningful signals, avoiding noisy price movements, and managing late entries.

These approaches can be combined, but it's easier to understand their behavior when each strategy is implemented and evaluated separately first.

4. Why Does Polymarket Need Market Makers?

Markets need buyers and sellers willing to trade.

When liquidity is limited, users may encounter wider spreads, larger price impact, and more difficulty executing orders at their desired prices.

Market makers help by providing resting orders that other traders can execute against.

Polymarket also operates liquidity incentive programs. Depending on the market and current program rules, eligible orders may qualify for liquidity rewards or maker rebates.

Official documentation:

These programs have their own eligibility requirements, and their terms can change.

Important: Liquidity incentives aren't guaranteed profit. A bot may receive rewards while losing money through unfavorable fills or changes in the value of its inventory.

Always evaluate the complete strategy rather than focusing on incentives alone.

5. Designing the Bot: A Simple Architecture

Before writing the trading logic, let's break the system into manageable components.

A practical Python market maker can start with five modules.

5.1 Market Data

This component retrieves market information and maintains an up-to-date view of the order book.

Its responsibilities include:

Reading market metadata and token identifiers.
Tracking the best bid and ask.
Monitoring available order book depth.
Detecting stale or incomplete data.
Providing market information to the strategy.

Reliable data is essential. If the bot uses an outdated order book, it may place orders at prices that are no longer appropriate.

5.2 Strategy Engine

The strategy engine decides where the bot should place its buy and sell orders.

A simple starting point is to calculate a reference midpoint:

Midpoint = (Best Bid + Best Ask) / 2

The bot can then calculate target prices around that reference point.

For example, a simplified quoting model might use:

Target Bid = Reference Price - Half Spread

Target Ask = Reference Price + Half Spread

This is only a starting model, not a complete profitable strategy. A production system may need to adjust quotes based on inventory, volatility, liquidity, and other signals.

5.3 Order Management

This component communicates with the trading interface to submit and manage orders.

It should track:

Order identifiers.
Order status.
Open and partially filled orders.
Cancellation and replacement requests.
Execution updates.
Available balances and reconciliation results.

Order management is more complicated than sending an API request.

For example, a network timeout doesn't necessarily mean an order failed. The exchange may have processed the request even though the bot didn't receive the response.

The system must reconcile its internal state with the actual order status before retrying potentially duplicated actions.

5.4 Risk Management

Risk management defines the conditions under which the bot is allowed to trade.

Examples include:

Maximum inventory per outcome.
Maximum order size.
Maximum capital allocation.
Limits on total exposure.
Protection against stale market data.
Emergency shutdown conditions.

Risk checks should happen before new orders are submitted, not only after a loss occurs.

5.5 Monitoring and Reporting

The monitoring component records what the bot does and why.

Useful metrics include:

Realized and unrealized profit and loss.
Inventory exposure.
Order-fill rate.
Partial-fill frequency.
Spread captured per completed trade.
Trading costs and applicable incentives.
API failures and order reconciliation errors.

Without monitoring, it becomes difficult to determine whether a poor result came from the strategy, market conditions, or an implementation bug.

6. The Main Trading Loop

At a high level, the bot repeatedly performs the following operations:

        +--------------------+
        | Read Market Data   |
        +--------------------+
                  |
                  v
        +--------------------+
        | Validate Data      |
        +--------------------+
                  |
                  v
        +--------------------+
        | Calculate Quotes   |
        +--------------------+
                  |
                  v
        +--------------------+
        | Check Risk Limits  |
        +--------------------+
                  |
                  v
        +--------------------+
        | Manage Orders      |
        +--------------------+
                  |
                  v
        +--------------------+
        | Reconcile Fills    |
        +--------------------+
                  |
                  v
        +--------------------+
        | Record Performance |
        +--------------------+
                  |
                  +----> Repeat

Each stage has a specific responsibility.

The strategy determines what orders would be desirable. Risk management determines whether those orders are acceptable. Order management handles execution, and reconciliation ensures the bot understands its actual positions.

Keeping these responsibilities separate makes the code easier to test and maintain.

7. Common Mistakes When Building a Market Maker

Mistake 1: Assuming every spread is profitable

A wide spread can indicate risk rather than opportunity.

The bot might get filled just before the market price moves against its position.

Mistake 2: Ignoring inventory

If buy orders fill repeatedly while sell orders remain open, the bot may accumulate more exposure than intended.

Inventory limits and position-aware quoting help control this problem.

Mistake 3: Replacing orders too frequently

Constant cancellation and replacement can create unnecessary API traffic, race conditions, and execution uncertainty.

The strategy needs a sensible policy for deciding when a quote has become stale enough to replace.

Mistake 4: Ignoring partial fills

An order may execute only partially. If the bot assumes the entire order filled, its internal inventory calculation can become incorrect.

Execution updates and periodic reconciliation are essential.

Mistake 5: Treating successful execution as proof of profitability

A bot can submit orders correctly and still lose money.

Software correctness and trading performance are separate problems. Both require testing.

Mistake 6: Going live too early

Start with unit tests, historical market-data replay, simulation, and paper trading.

Only consider live trading after the system's behavior, failure handling, and risk controls have been thoroughly evaluated.

8. Our Seven-Day Development Roadmap

This article is Day 1 of a seven-part series about understanding and building a Polymarket market maker bot.

Day	Topic	Main Goal
1	Market-Making Fundamentals	Understand liquidity, spreads, and inventory risk
2	Polymarket Order Book	Learn how bids, asks, and outcome tokens work
3	Python Project Setup	Connect to market data and organize the codebase
4	Trading Strategy	Calculate quotes and manage inventory
5	Order Management	Track, cancel, and replace orders reliably
6	Risk and Paper Trading	Test the strategy and control exposure
7	Complete Bot	Integrate components and monitor performance

The goal isn't just to copy a trading script. It's to understand the architecture, the reasoning behind the strategy, and the risks that must be controlled.

Conclusion

Building a Polymarket market maker bot is a practical way to explore Python, real-time market data, automated execution, and risk management.

The most important lesson is simple:

Market making isn't just about capturing the spread. It's about managing the risks involved in trying to capture it.

A reliable bot needs fresh data, sensible quoting logic, robust order management, accurate inventory tracking, and meaningful performance metrics.

In Day 2, we'll explore how the Polymarket order book works and how to interpret bids, asks, liquidity, and token prices before implementing the trading strategy.

Explore the Project

GitHub:

Benj4minCup / Polymarket-Trading-Bot-python

polymarket trading bot polymarket twap bot polymarket arbitrage bot polymarket bot polymarket trading bot polymarket twap bot polymarket arbitrage bot polymarket bot polymarket trading bot polymarket twap bot polymarket arbitrage bot polymarket bot polymarket trading bot polymarket twap bot polymarket arbitrage bot polymarket bot polymarket trading

Polymarket Trading bot system

An open-source and Strong Strategy collection of Polymarket trading bot and Polymarket arbitrage bot and Polymarket TWAP trading bot in Python for high-performance automated trading on polymarket crypto 5min and 15min markets.

This repository is primarily intended for educational and research purposes. It includes strategy concepts, implementation approaches, and selected performance screenshots to help developers understand how different automated trading strategies can be designed and tested.

The repository does not provide a complete production-ready trading bot source code. Instead, it provides strategy descriptions and research materials that you can use as a foundation for developing your own system.

If you are interested in building a Polymarket Trading Bot, you can follow my tutorials and use the concepts in this repository to develop your own implementation.

For users who prefer a ready-to-deploy solution or require custom strategy development, commercial bot development and customization are also available.

Features
…

View on GitHub
YouTube Video:

src="https://www.youtube.com/embed/UCF7MA1Kekk"
width="710"
height="399"
style="width: 100%; height: auto; aspect-ratio: 16 / 9;"
allowfullscreen
loading="lazy">
Discussion: https://telegram.me/BenjaminCup

If you're interested in Python, algorithmic trading, prediction markets, or building reliable automated systems, follow along as we develop the concepts step by step.

python #trading #beginners #opensource #polymarket #trading #bot

Polymarket Trading Bot in Python: BTC Spot Price vs. TWAP-60s

Benjamin-Cup — Sat, 17 Oct 2026 13:25:49 +0000

How can you analyze short-term Bitcoin prediction markets using live BTC prices and Polymarket order book data?

This Polymarket trading bot in Python explores the relationship between three important signals: the external Bitcoin spot price, the TWAP-60s price reference, and the probability implied by Polymarket's live order book.

The goal is to identify potential pricing discrepancies and understand whether they represent meaningful trading opportunities.

Project links:

💻 GitHub:

Benj4minCup / Polymarket-Trading-Bot-python

polymarket trading bot polymarket twap bot polymarket arbitrage bot polymarket bot polymarket trading bot polymarket twap bot polymarket arbitrage bot polymarket bot polymarket trading bot polymarket twap bot polymarket arbitrage bot polymarket bot polymarket trading bot polymarket twap bot polymarket arbitrage bot polymarket bot polymarket trading

Polymarket Trading bot system

An open-source and Strong Strategy collection of Polymarket trading bot and Polymarket arbitrage bot and Polymarket TWAP trading bot in Python for high-performance automated trading on polymarket crypto 5min and 15min markets.

This repository is primarily intended for educational and research purposes. It includes strategy concepts, implementation approaches, and selected performance screenshots to help developers understand how different automated trading strategies can be designed and tested.

The repository does not provide a complete production-ready trading bot source code. Instead, it provides strategy descriptions and research materials that you can use as a foundation for developing your own system.

If you are interested in building a Polymarket Trading Bot, you can follow my tutorials and use the concepts in this repository to develop your own implementation.

For users who prefer a ready-to-deploy solution or require custom strategy development, commercial bot development and customization are also available.

Features
…

View on GitHub
🎥 YouTube demo:
📩 Telegram: https://telegram.me/BenjaminCup

What Is a Polymarket Trading Bot?

A Polymarket trading bot is a program that interacts with prediction markets to analyze prices, monitor market conditions, generate signals, or execute trades, depending on its implementation.

In Bitcoin prediction markets, traders may speculate on whether BTC will cross a price threshold or finish above or below a specified level.

The challenge is that the current Bitcoin spot price does not tell the whole story. The market's resolution rules, remaining time, liquidity, and order book prices also matter.

This project focuses on comparing those signals to better understand short-term BTC prediction markets.

1. Live Bitcoin Spot Price

The live BTC spot price represents Bitcoin's current trading price on an external cryptocurrency exchange.

A trading bot can use this price to monitor market movements and compare the underlying asset with Polymarket's current pricing.

For example, if BTC is trading at $100,050, that tells us where Bitcoin is trading on the selected exchange at that moment.

However, different exchanges can report slightly different prices due to liquidity and market conditions.

The external spot price is useful information, but it should not automatically be treated as the official resolution price for a Polymarket contract.

2. TWAP-60s: Understanding the Price Reference

TWAP stands for Time-Weighted Average Price.

A TWAP-60s calculation represents an average price over a 60-second window, based on the specific calculation method used.

Unlike a single spot-price observation, it incorporates price information over a period of time.

This can be important in short-duration Bitcoin prediction markets because BTC prices can move rapidly. The latest spot price and a time-averaged price may differ.

For example:

Current BTC spot price: $100,050
Example 60-second reference: $100,000

The difference between these values provides context for analyzing the market.

Important: Always verify the resolution rules for the specific Polymarket contract. Do not assume that a TWAP-60s value is the official settlement reference unless the market rules specify it.

3. Polymarket Order Book and Implied Probability

The Polymarket order book displays bids and asks for outcome tokens.

For example, imagine a hypothetical YES market with the following prices:

Order book metric	Example
Best YES bid	$0.56
Best YES ask	$0.60
Midpoint	$0.58
Indicative midpoint probability	58%

A YES token priced at $0.58 can be interpreted as an indicative 58% market-implied probability, assuming the token pays $1 if YES resolves successfully and $0 otherwise.

However, the midpoint is not necessarily an executable trading price.

A buyer seeking immediate execution generally needs to consider the ask price, available liquidity, fees, and slippage.

The order book reflects traders' expectations, market liquidity, uncertainty, and the time remaining until resolution.

These figures are illustrative examples, not live Polymarket prices.

4. How the Polymarket BTC Trading Bot Works

The analysis process follows a simple workflow.

Retrieve the external BTC spot price.
Calculate or retrieve the relevant TWAP-60s value.
Read the current Polymarket order book.
Compare the price data with the contract's threshold and resolution rules.
Examine the market-implied probability.
Evaluate potential discrepancies, liquidity, and execution costs.

The important idea is to compare the underlying Bitcoin market with the price of the prediction market outcome.

A difference between the signals may justify further investigation, but it does not automatically indicate a profitable trade.

5. Why Can BTC Prices and Polymarket Probabilities Differ?

Several factors can explain apparent discrepancies.

Different price sources

The BTC price on an external exchange may not match the price source used to resolve the Polymarket contract.

Market update delays

Bitcoin can move quickly, while prediction-market quotes may update at a different pace.

Time until resolution

If BTC is currently above a threshold, the probability of finishing above it still depends on how much time remains and how volatile the market is.

Order book liquidity

A displayed price may be available for only a small number of tokens. Larger orders can receive worse execution prices.

Trading costs

Fees, bid-ask spreads, slippage, and latency can eliminate an apparent pricing advantage.

A useful Polymarket trading strategy must consider these factors rather than relying on a simple comparison between two prices.

6. Why Order Book Analysis Matters

Consider a YES token with a bid of $0.56 and an ask of $0.60.

The four-cent spread represents the difference between the best displayed buying and selling prices.

If a bot calculates probability using only the midpoint, it may overlook the cost of entering or exiting a position.

A more realistic analysis considers:

Best bid and ask.
Available liquidity at each price level.
Expected execution price for the intended order size.
Trading fees and slippage.
Data freshness and timing.
The contract's actual resolution conditions.

These checks help distinguish a theoretical pricing discrepancy from a potentially executable opportunity.

7. Explore the Python Polymarket Trading Bot

You can inspect the project source code and watch the demonstration using the links below.

GitHub repository

Polymarket Trading Bot — Python

Explore the source code, project structure, and implementation:

https://github.com/Benj4minCup/Polymarket-Trading-Bot-python

YouTube demo

Watch the project demonstration:

https://www.youtube.com/watch?v=UCF7MA1Kekk

Connect on Telegram

Have questions or want to discuss prediction markets, Python automation, or trading-bot development?

https://telegram.me/BenjaminCup

Conclusion

A Polymarket trading bot can analyze more than the current Bitcoin price.

Comparing the external BTC spot price, a TWAP-60s reference, and the live Polymarket order book provides a framework for studying short-term prediction markets.

Each signal serves a different purpose:

BTC spot price: Shows where Bitcoin is trading now.
TWAP-60s: Represents price behavior across a selected time window.
Order book: Shows the prices traders currently offer for prediction-market outcomes.

The main challenge is determining whether an apparent probability discrepancy remains meaningful after accounting for resolution rules, time to expiry, liquidity, and trading costs.

If you are interested in building a Polymarket trading bot with Python, exploring order book data, or studying Bitcoin prediction markets, check out the repository and demo above.

Disclaimer: This project is presented for educational and research purposes. Trading involves risk, and no strategy guarantees profit.

Polymarket Trading Bot: The Most Profitable Trading Bots on Polymarket Right Now

Benjamin-Cup — Fri, 16 Oct 2026 21:02:54 +0000

Using Claude, I analyzed every trade made by some of the most profitable trading systems on Polymarket and reconstructed their logic inside each market to understand how they consistently grow their capital and have already reached the 6 and 7-figure range.

Below, I will break down the strategy behind each trading bot, where its edge comes from, and why these systems continue to generate positive PnL while many of their competitors are no longer profitable.

Bonereaper (Directional Rotation with Dynamic Hedge) Bonereaper operates as a directional system. The algorithm forms a view on the current direction of the underlying asset, builds a position in the corresponding outcome, and then continues recalculating fair probability as the market moves. If the signal changes, the bot usually does not close the old position. Instead, it starts accumulating the opposite outcome.

Its cycle looks roughly like this:

Model detects an edge in Up -> Bot starts buying Up -> The underlying asset reverses -> Fair probability shifts in favor of Down -> Bot starts buying Down -> The original Up remains part of the total position, while the opposite side acts as a dynamic hedge.

This is especially visible in 5m markets. Bonereaper accumulated both sides in roughly 55% of these markets, while the median delay between the first entry on one side and the first entry on the opposite side was only around 26 seconds. At the same time, positions usually remained unbalanced: the smaller side was only around 45% of the larger side on a median basis.

The combined average price of Up and Down in two-sided 5m positions was around $1.08. This means it is not complete-set arbitrage. The bot pays for the hedge to reduce directional exposure after the signal changes.

Where the edge comes from:

The main objective of the algorithm is to recalculate the probability of Up and Down faster than Polymarket after the price of the underlying asset changes. To do this, the model takes into account external spot prices, order book depth, short-term momentum, movement speed, distance from the opening price, and the time remaining until resolution.

If fair probability has already changed while the contract price has not yet adjusted, a short-term pricing gap appears.

Bonereaper tries to capture that gap with the first side of the position. If the market continues moving in the expected direction, the bot can increase exposure. If the signal breaks, the opposite outcome limits the impact of the original entry.

Instead of a single binary position, the result is a position that is constantly being rebuilt.

0xb55… (Asynchronous Complete-Set Accumulator) The second bot has a completely different structure. Both sides of the position appear much more systematically. It buys both Up and Down in roughly 75% of all markets. On 15m markets, this rises to 79%, on 1h to 87%, and on 4h to 100%.

But this is not classic arbitrage where Up and Down are purchased at the same time. On 5m markets, the median gap between the first entry on one side and the first entry on the opposite side was around 52 seconds. On 15m markets, it was already close to three minutes. This means the algorithm uses price movement across time.

For example:

Up temporarily becomes cheap -> Bot accumulates Up -> Some time later, the underlying asset reverses -> Down becomes cheaper -> Bot starts accumulating Down -> Part of the two positions becomes a complete set

The economics then look like this:

Complete-set cost = VWAP(Up) + VWAP(Down)

If the final cost is below $1, the matched part of the position has a positive structural edge regardless of which outcome finishes higher at settlement.

This effect becomes especially visible on longer timeframes. On 1h markets, the median combined price of both sides was around $0.93, while on 4h markets it was around $0.91. This looks similar to temporal arbitrage.

Where the edge comes from:

Up and Down are constantly repriced as the underlying asset moves. The algorithm does not need to see the following prices at the same time:

Up = $0.42 Down = $0.55

It can buy Up now and buy Down several minutes later, after the entire pricing structure has changed. The longer a market remains open, the more opportunities the bot has to acquire both sides during different phases of the move.

This is why 1h and 4h markets are particularly suitable for this model. During a single window, the underlying asset can move up and down several times, creating attractive levels first for one outcome and then for the other. Part of the inventory becomes neutral, while the unmatched remainder keeps directional exposure.

Account: 0xb55fa1296e6ec55d0ce53d93b9237389f11764d4

mo-money (Multi-Timeframe Hybrid Bot) What makes mo-money interesting is that it does not use the same model across every timeframe. On shorter markets, it looks primarily directional. On longer markets, its behavior gradually shifts toward two-sided inventory management.

On 5m markets, both sides appeared in only around 32% of markets. On 1h markets, this increased to 67%, and on 4h markets to roughly 85%. Both the hedge frequency and the structure of the position change.

In two-sided 5m markets, the smaller side was only around 43% of the larger side on a median basis, while the average cost of the complete set was around $1.07. This means the bot keeps a clear directional bias on shorter timeframes.

On 1h markets, the sizes of Up and Down in two-sided positions were almost identical, while the median sum of their VWAPs was around $0.91. In practice, the same bot switches between two different modes:

On shorter timeframes

Identify the current bias -> Buy the primary outcome -> Add to the position while the signal remains valid -> Use the opposite side only when necessary -> Keep a noticeable directional remainder

On longer timeframes:

Start with one side -> Wait for a new price range -> Accumulate the opposite outcome -> Match a large portion of the contract quantities -> End up with nearly neutral inventory
Different timeframes have different market microstructure.

On 5m markets, there is very little time. It is more efficient for the algorithm to react quickly to a short-term signal than to wait for the perfect entry on the second side.

On 1h or 4h markets, the situation changes. The underlying asset has enough time to move through several local swings, allowing the bot to use volatility to improve the average price of both sides.

Account: mo-money

almach (Buy-Side Inventory Builder) almach uses another variation of a buy-only model. Its algorithm continuously places buy orders at different price levels and allows the market to gradually fill its inventory.

The logic behind almach becomes especially clear on longer timeframes. On 5m markets, both sides were present in only around 23% of markets. On 1h markets, this increased to 72%. On 4h markets, it reached 96%.

When both sides were built, the inventory was also significantly more balanced than Bonereaper’s.

On 1h markets, the smaller side was around 96% of the larger side on a median basis, while the combined average price of Up and Down was around $0.97. On 4h markets, the balance was around 92%, with a combined cost of roughly $0.99.

This strongly resembles a system designed not to buy a complete set immediately, but to build it gradually through passive BUY orders during different phases of the market.

How the algorithm works:

Place BUY liquidity on one or both sides -> Receive fills when price reaches the target levels -> Start accumulating the second side during the next move -> Match equal quantities of Up and Down into a neutral component -> Keep unmatched inventory only where the price justifies it

Where the edge comes from:

The main advantage here is execution quality. Instead of crossing the current ask and immediately paying for the full size of the position, the algorithm waits for the market to move toward its own levels.

For example, the bot gradually gets:

Up at an average entry of $0.46 Down at an average entry of $0.51

The total cost of the matched portion is $0.97

Those $0.97 prices did not need to exist in the order book at the same time. One side could have been filled much earlier than the other. The longer the market remains open, the more time the system has to wait for attractive prices on both sides. This explains why the share of two-sided positions for almach increases sharply on 1h and 4h markets.

Account: almach

Not every trading bot makes money in the same way. Even when several bots trade the same Polymarket Up/Down markets, their strategies can be completely different.

Let’s break down four interesting trading approaches:

🔹 Bonereaper — Directional Trading + Hedging

This bot looks for signals that suggest the market will move up or down. It takes a position based on that signal, then uses hedging to manage risk and adjust its exposure as the market changes.

🔹 0xb55… — Buying Opposite Outcomes

This strategy buys opposite outcomes at different prices or stages of a market move. The goal may be to combine them into a complete set, where one outcome pays $1 in total, potentially creating a profit if the combined purchase cost is below $1.

🔹 mo-money — Adaptive Trading

This approach changes its strategy depending on the market timeframe. Shorter markets may favor directional trading, while longer markets may call for more balanced inventory management.

🔹 almach — Execution-Focused Trading

Instead of buying a large position all at once, this approach gradually builds positions through buy orders. The goal is to manage entry prices, liquidity, and execution costs more carefully.

🚀 What Does This Mean for My Trading Bot?
My project explores the world of automated Polymarket trading:

💻 GitHub:

Benj4minCup / Polymarket-Trading-Bot-python

polymarket trading bot polymarket twap bot polymarket arbitrage bot polymarket bot polymarket trading bot polymarket twap bot polymarket arbitrage bot polymarket bot polymarket trading bot polymarket twap bot polymarket arbitrage bot polymarket bot polymarket trading bot polymarket twap bot polymarket arbitrage bot polymarket bot polymarket trading

Polymarket Trading bot system

If you are interested in building a Polymarket Trading Bot, you can follow my tutorials and use the concepts in this repository to develop your own implementation.

For users who prefer a ready-to-deploy solution or require custom strategy development, commercial bot development and customization are also available.

Features

…

View on GitHub

🎥 YouTube:

📩 Telegram: https://telegram.me/BenjaminCup

The key lesson is that a trading bot is more than a collection of BUY orders. Its real strategy depends on why it enters a position, when it exits, how it manages risk, how it balances inventory, and how it handles execution.

Two bots can produce similar transaction histories while following completely different strategies.

The real challenge is understanding the logic behind every trade and building a system that can manage risk in changing market conditions.

Trading involves risk. These strategies do not guarantee profits, and a complete set is profitable only when its total cost and fees are below its eventual payout.

Polymarket #TradingBot #AlgorithmicTrading #CryptoTrading #AutomatedTrading #Python #TradingStrategies #QuantTrading #PredictionMarkets #MarketMaking #RiskManagement #OpenSource #AITrading

DEV Community: Benjamin-Cup

Building Polymarket Trading Bot: From Backtesting to Live Trading(Market Maker)

1. Understand the Three Stages of Trading

Stage 1: Backtesting

Stage 2: Paper Trading

Stage 3: Live Trading

2. Design a Production Architecture

3. Separate Strategy from Execution

4. Build a Safe Order Lifecycle Manager

Recommended internal order states

5. Handle API Errors and Network Failures

Use an uncertain-order state

6. Implement Risk Management

Maximum order size

Maximum inventory

Maximum capital allocation

Stale market data protection

Emergency stop

Consider open-order exposure

7. Monitor Your Bot in Production

8. Build a Production Dashboard

9. Preserve Trading State with a Database

10. Recover Safely After a Restart

11. Deploy the Bot on a VPS

Basic deployment steps

12. Protect API Credentials

13. Follow a Gradual Live-Trading Plan

14. Production Readiness Checklist

Strategy

Execution

Portfolio

Risk

Infrastructure

Conclusion

Continue Building Your Polymarket Trading Bot

Coming Next — Day 11

polymarket #trading #bot #tutorial #python

Polymarket Trading Bot :Market Maker - How to Backtest Strategies and Optimize Trading Parameters

Introduction

1. What Is Backtesting?

Backtesting vs. Paper Trading vs. Live Trading

2. Understand the Backtesting Architecture

3. Collect Historical Market Data

Why Is Order Book Depth Important?

Snapshots vs. Event-Level Data

4. Calculate Market Metrics and Quotes

5. Simulate Realistic Order Execution

Important Execution Scenarios

6. Track Order States and Inventory

7. Calculate P&L and Performance Metrics

Important Performance Metrics

8. Optimize Trading Parameters

9. Avoid Overfitting

Walk-Forward Testing

10. Account for Realistic Trading Conditions

11. Organize the Python Project

12. Common Backtesting Mistakes

Conclusion

What's Next? Day 10

Follow the Project

Benj4minCup / Polymarket-Trading-Bot-python

polymarket Twap Bot polymarket Arbitrage Bot polymarket bot

Polymarket Trading bot system

Features

Advanced Polymarket Market Making Strategy: Dynamic Spreads, Volatility, and Market Conditions in Python

1. Why Fixed-Spread Market Making Has Limitations

2. Understand Market Volatility

A simple example

3. Calculate Short-Term Volatility in Python

4. Use Volatility to Adjust the Spread

5. Implement Dynamic Spread Calculation

6. Adjust Order Size Based on Liquidity

A basic liquidity ratio

7. Create a Basic Adaptive Order Size Function

8. Combine Dynamic Spreads With Inventory Skew

9. Detect Market Regimes

10. Know When Not to Make a Market

11. Build a Simple Adaptive Quote Engine

12. How Do You Know Dynamic Quoting Is Better?

Run controlled experiments