Learn how to build a Polymarket expected value trading bot using probability estimates, fair price, execution costs, risk controls, and position sizing.
A prediction-market bot does not make money simply because its probability estimate is “better.”
The trade exists only when the estimated probability creates enough expected value after price, fees, slippage, execution uncertainty, and model error.
That distinction is where a useful Polymarket EV strategy starts.
By Bo$onaX
Polymarket trading bots • Quantitative trading • Rust • Web3 infrastructure
GitHub: https://github.com/n9xdev/poly-alpha-lab
Telegram: https://t.me/bosonax
YouTube: https://youtube.com/@bosonax
X: https://x.com/xxniiinxx
Polymarket: https://polymarket.com/@bosona
The EV calculation is deceptively simple
Suppose a YES contract trades at 0.42.
Your model estimates the probability of YES at 0.55.
For a binary contract paying $1 at resolution:
EV = P(win) × payout - entry price
= 0.55 × $1.00 - $0.42
= $0.13
That looks attractive.
But a production Polymarket trading bot should not trade on this number alone.
The actual decision should look closer to:
net_edge =
model_probability
- market_price
- fees
- expected_slippage
- execution_cost
- uncertainty_buffer
The last term is particularly important. A model saying 55% does not mean the true probability is exactly 55%.
Fair price is a distribution, not a magic number
For a binary market, the estimated fair price can be represented as:
fair_price = P(outcome = YES)
The difficult part is estimating that probability.
A useful EV engine might combine:
- current market price
- order-book imbalance
- recent price movement
- external information
- time remaining
- historical conditional outcomes
- volatility
- liquidity
- correlated markets
The bot then compares its probability estimate against executable prices rather than simply comparing it against the displayed midpoint.
For example:
model probability: 0.57
best executable ask: 0.51
estimated total cost: 0.02
effective edge: 0.04
The trade is interesting because the net difference survives the expected costs.
Why probability calibration matters more than confidence
Consider two models.
Model A:
Predicted: 70%
Actual frequency: 56%
Model B:
Predicted: 60%
Actual frequency: 61%
Model B may be much more useful for EV trading even though it produces less dramatic predictions.
This is a calibration problem.
A bot should therefore record predictions and eventual outcomes and continuously evaluate whether probabilities such as 0.55, 0.65, and 0.80 actually behave like those probabilities.
Without calibration, an EV strategy can systematically manufacture fake edge.
The order book changes the decision
A market price is not necessarily the price your bot can trade.
Suppose:
Best bid: 0.48
Best ask: 0.53
Model: 0.56
Buying at 0.53 is very different from assuming the market is priced at 0.48 or 0.50.
A serious bot should therefore calculate EV from the intended execution price.
For larger orders, this becomes even more important because available liquidity may exist at multiple price levels.
Conceptually:
expected_entry =
Σ(price_level × quantity_filled) / total_quantity
The EV engine should receive an executable price estimate from the order-book layer rather than a stale market snapshot.
Position sizing is a separate problem
Positive EV does not tell you how much to trade.
A strategy might estimate:
fair probability = 0.58
entry price = 0.50
and still choose a small position because:
- probability uncertainty is high
- liquidity is thin
- the market is close to resolution
- the model has little historical evidence
- correlated positions already consume risk budget
A practical architecture separates signal generation from capital allocation.
Market Data
↓
Probability Model
↓
Fair Price
↓
EV Calculation
↓
Risk Filter
↓
Position Sizing
↓
Execution
That separation makes the system much easier to test.
A useful EV bot should reject trades
One of the easiest mistakes is designing a bot whose only job is to find positive numbers.
Instead, make rejection explicit.
For example:
if edge < minimum_edge {
return Decision::Skip;
}
if liquidity < minimum_liquidity {
return Decision::Skip;
}
if probability_confidence < minimum_confidence {
return Decision::Skip;
}
Decision::Trade
The thresholds should come from research and testing rather than arbitrary optimism.
A good EV engine should frequently say nothing to do.
Resolution risk belongs in the model
Prediction markets have another unusual property: the final payoff depends on the market's resolution rules, not merely on whether a headline appears favorable.
A bot therefore needs to understand the actual market rules before treating an outcome as a clean binary payoff.
This matters especially for ambiguous wording, edge cases, and markets where the resolution source has specific requirements.
Production architecture
For a low-latency implementation, I would keep the EV calculation lightweight and deterministic:
┌──────────────┐
│ Market Feed │
└──────┬───────┘
↓
┌──────────────┐
│ Order Book │
└──────┬───────┘
↓
┌──────────────┐
│ Probability │
│ Model │
└──────┬───────┘
↓
┌──────────────┐
│ EV Engine │
└──────┬───────┘
↓
┌──────────────┐
│ Risk Engine │
└──────┬───────┘
↓
┌──────────────┐
│ Execution │
└──────────────┘
The important design decision is not the number of services. It is keeping the boundary between prediction, valuation, risk, and execution explicit.
That lets you replay historical market data and ask a much more useful question:
Would the bot still have had positive EV at the price it could actually have obtained?
That is a much stronger test than simply asking whether the model predicted the winner.
The real objective
A Polymarket expected value strategy is fundamentally a probability-estimation problem wrapped inside an execution system.
The formula is easy.
The engineering is not.
You need calibrated probabilities, realistic executable prices, transaction costs, liquidity constraints, position limits, and protection against model uncertainty. Positive theoretical EV that disappears after execution is not an edge.
The strongest EV bots are therefore not machines that trade whenever fair_price > market_price.
They are systems designed to determine when that difference is large enough, reliable enough, and executable enough to justify risking capital.
Trading involves substantial risk. Expected value is a statistical framework, not a guarantee of profitability. Real-world results can differ because of model error, liquidity, execution, fees, market conditions, and resolution risk.
