Learn how to design a Polymarket probability arbitrage bot using fair probability, expected value, order-book pricing, fees, liquidity, execution risk, and Rust architecture.
A Polymarket probability arbitrage bot should not begin with the question, “Which market is wrong?”
The better question is: what probability do I believe, what price can I actually trade, and does the difference survive execution costs?
That distinction turns a simple probability comparison into a real quantitative trading system.
By Bo$onaX
Polymarket trading bots • Quantitative trading • Rust • Web3 infrastructure
The number 0.50 is not automatically “fair”
Polymarket outcomes trade between $0 and $1. A $0.50 YES price can be interpreted as roughly 50% implied probability, but the displayed probability is derived from market pricing rather than being an objective estimate of reality. Polymarket currently explains that displayed prices generally use the midpoint of the bid-ask spread, with last trade used when the spread exceeds $0.10. :chatgpt-content-reference{index=”6″}
That creates the basic signal:
Edge = P_{model} - P_{market}
Enter fullscreen mode Exit fullscreen mode
Suppose a model estimates a 63% probability while executable YES liquidity is available around $0.57.
The raw probability difference is:
0.63 - 0.57 = 0.06
Enter fullscreen mode Exit fullscreen mode
Six percentage points looks attractive.
It is not yet a trade.
The bot still has to account for spread, fees, slippage, liquidity, stale information, model error, and the possibility that the quoted price disappears before the order reaches the book.
Where the arbitrage signal actually comes from
A useful probability arbitrage system can combine several independent probability sources:
- external market prices
- statistical models
- event-specific data
- related Polymarket markets
- historical price distributions
- derivatives-implied probabilities
- cross-market consistency relationships
Polymarket itself exposes separate interfaces for market discovery, pricing, historical data, and trading. Its research documentation describes Gamma as useful for discovering markets and implied probabilities, while the CLOB provides pricing, spreads, depth, and price history. :chatgpt-content-reference{index=”7″}
The architecture therefore becomes something like:
Market Discovery
↓
Probability Sources
↓
Fair-Value Engine
↓
Edge Calculation
↓
Cost / Liquidity Filter
↓
Execution Engine
↓
Position + Risk Manager
↓
Monitoring / Reconciliation
Enter fullscreen mode Exit fullscreen mode
The important part is the middle.
A probability model without an execution-aware filter produces signals that may look excellent in a spreadsheet and disappear in production.
Fair probability versus executable probability
Consider:
- model probability: 64%
- best YES ask: 59%
- expected slippage: 1%
- transaction cost: 0.5%
- model uncertainty buffer: 2%
The naive edge is 5 percentage points.
After accounting for execution and uncertainty, the usable edge becomes dramatically smaller.
A production bot should therefore maintain at least two values:
model_probability
executable_probability
Enter fullscreen mode Exit fullscreen mode
The second should incorporate the actual side of the book the strategy intends to trade.
This is particularly important because Polymarket’s current fee system is market-dependent. Eligible markets can charge taker fees, while makers are not charged maker fees; fee parameters vary by category, and maker rebates are funded from collected taker fees. :chatgpt-content-reference{index=”8″}
So a strategy that blindly compares “fair probability” against the displayed midpoint can systematically overestimate its opportunity.
The arbitrage bot should think in expected value
For a binary share purchased at price (p), with estimated probability (q), the simplified expected value before additional costs can be represented as:
EV = q(1-p) - (1-q)p
Enter fullscreen mode Exit fullscreen mode
which simplifies to:
EV = q-p
Enter fullscreen mode Exit fullscreen mode
For a $0.57 purchase with (q=0.63):
EV = 0.06
Enter fullscreen mode Exit fullscreen mode
But the real strategy should use:
EV_{net}=EV-fees-slippage-risk\_buffer
Enter fullscreen mode Exit fullscreen mode
Only when the resulting value exceeds a configurable threshold should the execution engine consider sending an order.
That threshold should not be static across every market. Thin books, fast-moving events, and uncertain resolution conditions deserve larger safety margins.
Rust implementation: separate the model from execution
A clean implementation should prevent the probability engine from directly submitting orders.
For example:
struct Signal {
token_id: String,
model_probability: f64,
executable_price: f64,
expected_edge: f64,
confidence: f64,
}
fn tradable(signal: &Signal, min_edge: f64) -> bool {
signal.expected_edge >= min_edge
&& signal.confidence >= 0.8
}
Enter fullscreen mode Exit fullscreen mode
This is intentionally simplified. In production, probability uncertainty should be modeled explicitly rather than represented by a hard-coded confidence number.
The execution layer should separately handle:
- order-book state
- order sizing
- order submission
- cancellations
- fills
- retries
- reconciliation
That separation makes it possible to replay historical market data against the same strategy logic without placing live orders.
The failure mode most probability bots miss
The dangerous bug is not necessarily a bad probability model.
It is acting on stale information.
Suppose an external data source moves your model from 52% to 66%. Your bot detects a large edge and submits a BUY order.
During those milliseconds, another trader may have already repriced the Polymarket book.
The strategy then buys at a price that no longer represents the original opportunity.
This is why a serious Polymarket probability arbitrage bot needs timestamps attached to both:
probability_observed_at
book_observed_at
order_submitted_at
fill_received_at
Enter fullscreen mode Exit fullscreen mode
Without those timestamps, diagnosing adverse selection becomes unnecessarily difficult.
What to test before using real capital
A useful test suite should replay historical order-book states and evaluate:
- signal generation
- probability calibration
- minimum-edge thresholds
- position sizing
- partial fills
- stale quotes
- sudden probability changes
- empty liquidity
- rejected orders
- network failures
- duplicate execution
- resolution and settlement handling
Do not judge the strategy only by theoretical edge.
Measure whether the edge remains after simulated execution.
Final perspective
A Polymarket probability arbitrage bot is ultimately a probability-to-execution pipeline, not a simple “buy when probability is cheap” script.
The difficult engineering work lives between the model and the order.
A useful system continuously asks three questions:
What is the fair probability?
What price can I actually obtain?
Is the remaining edge large enough to justify the risks?
That is where Polymarket probability arbitrage becomes quantitative trading rather than simple price watching.
Trading-risk disclaimer: This is an educational discussion, not financial advice. Probability estimates can be wrong, liquidity can disappear, execution can fail, and trading strategies can lose capital. No profitability or performance is guaranteed.