Polymarket Trading Bot Position Sizing
A profitable signal is not enough. A Polymarket trading bot also needs to decide how much capital to risk.
Position sizing is one of the most important—and most underestimated—parts of Polymarket algorithmic trading. A bot with a good signal can still perform badly if it repeatedly overcommits capital, ignores liquidity, or treats correlated markets as independent opportunities.
This guide shows how to build a practical Python position-sizing engine for a Polymarket bot using estimated probability, market price, fractional Kelly sizing, liquidity caps, and portfolio-level risk controls.
Polymarket provides developer resources for programmatic market interaction, including market data and trading infrastructure. Builders should verify implementation details against the current official documentation before connecting production capital.
About the Author
Bo$onaX
I write about Polymarket trading bots, prediction-market infrastructure, algorithmic trading, Python automation, Web3 development, and quantitative strategies.
Contact:
X: https://x.com/xxniiinxx
Telegram: https://t.me/bosonax
Youtube: https://youtu.be/fbtzTnPiRW0?si=alLrul9Rw75m2fVf
What You’ll Learn
- How to convert a probability model into a position size
- Why market price alone should not determine size
- How to calculate binary-contract Kelly sizing
- Why fractional Kelly is usually safer for uncertain models
- How to cap positions using portfolio and liquidity constraints
- How to implement the logic in Python
- How to monitor and test a production sizing engine
The Core Position-Sizing Problem
Suppose your model estimates:
Probability of YES: 62%
Market price: 55¢
Enter fullscreen mode Exit fullscreen mode
Your estimated edge is:
edge = 0.62 - 0.55 = 0.07
Enter fullscreen mode Exit fullscreen mode
The obvious conclusion is to buy YES. But how much?
A fixed strategy might buy $100 every time. That ignores an important distinction:
62% model vs 55¢ market
52% model vs 45¢ market
Enter fullscreen mode Exit fullscreen mode
Both have a 7 percentage-point difference, but the payout structure and model confidence may differ.
A robust Polymarket trading strategy should separate:
- Signal generation
- Probability estimation
- Position sizing
- Execution
- Portfolio risk management
flowchart LR
A[Market Data] --> B[Probability Model]
B --> C[Estimated Edge]
C --> D[Position Sizing Engine]
D --> E[Risk & Liquidity Caps]
E --> F[Polymarket Order Book]
F --> G[Execution]
G --> H[Portfolio State]
H --> D
Enter fullscreen mode Exit fullscreen mode
The sizing engine should never assume that a signal is automatically worth the maximum possible trade.
Step 1: Calculate Edge
For a YES contract:
edge = estimated_probability - market_price
Enter fullscreen mode Exit fullscreen mode
Example:
estimated_probability = 0.62
market_price = 0.55
edge = estimated_probability - market_price
print(edge) # 0.07
Enter fullscreen mode Exit fullscreen mode
This is only the beginning. Before sizing the trade, your bot should account for execution costs, spread, potential slippage, and model uncertainty.
A practical approximation is:
net_edge = model_probability - entry_price - cost_buffer
Enter fullscreen mode Exit fullscreen mode
The cost_buffer is strategy-specific. Do not hard-code a universal Polymarket fee or slippage value without checking the current market and official documentation.
Step 2: Use Kelly Criterion
For a binary position, a simplified Kelly calculation can be expressed as:
f = (p × b - q) / b
Enter fullscreen mode Exit fullscreen mode
Where:
-
p= estimated probability of winning -
q=1 - p -
b= potential profit relative to the amount risked -
f= fraction of bankroll to allocate
For a YES contract purchased at price c, the theoretical profit multiple at resolution is approximately:
b = (1 - c) / c
Enter fullscreen mode Exit fullscreen mode
Python implementation:
def kelly_fraction(probability: float, price: float) -> float:
if not 0 < probability < 1:
raise ValueError("Probability must be between 0 and 1")
if not 0 < price < 1:
raise ValueError("Price must be between 0 and 1")
b = (1 - price) / price
q = 1 - probability
fraction = (probability * b - q) / b
return max(0.0, fraction)
Enter fullscreen mode Exit fullscreen mode
Example
p = 0.62
price = 0.55
kelly = kelly_fraction(p, price)
print(f"Kelly fraction: {kelly:.4f}")
Enter fullscreen mode Exit fullscreen mode
The output is a theoretical fraction of bankroll.
But full Kelly can be dangerous when your probability estimate is imperfect—which, in real trading, it almost always is.
Step 3: Use Fractional Kelly
A more conservative approach is:
fractional_kelly = kelly * 0.25
Enter fullscreen mode Exit fullscreen mode
For example:
KELLY_MULTIPLIER = 0.25
def fractional_kelly_size(
bankroll: float,
probability: float,
price: float,
multiplier: float = KELLY_MULTIPLIER,
) -> float:
fraction = kelly_fraction(probability, price)
fraction *= multiplier
return bankroll * fraction
Enter fullscreen mode Exit fullscreen mode
The exact multiplier is a strategy parameter, not a universal rule. A smaller multiplier may be appropriate when:
- the probability model is poorly calibrated
- historical data is limited
- markets are highly correlated
- execution costs are uncertain
- liquidity is thin
Step 4: Add Hard Risk Caps
Kelly alone should not control your Polymarket bot.
A production sizing engine should apply multiple limits.
from dataclasses import dataclass
@dataclass
class RiskLimits:
max_position_pct: float = 0.05
max_portfolio_exposure_pct: float = 0.40
max_market_liquidity_pct: float = 0.10
def calculate_position_size(
bankroll: float,
probability: float,
price: float,
available_liquidity: float,
limits: RiskLimits,
kelly_multiplier: float = 0.25,
) -> float:
raw_size = fractional_kelly_size(
bankroll=bankroll,
probability=probability,
price=price,
multiplier=kelly_multiplier,
)
position_cap = bankroll * limits.max_position_pct
liquidity_cap = available_liquidity * limits.max_market_liquidity_pct
final_size = min(
raw_size,
position_cap,
liquidity_cap,
)
return max(0.0, final_size)
Enter fullscreen mode Exit fullscreen mode
The result is not simply:
model edge → maximum capital
Enter fullscreen mode Exit fullscreen mode
Instead:
model edge
↓
Kelly estimate
↓
fractional Kelly
↓
portfolio cap
↓
liquidity cap
↓
final position size
Enter fullscreen mode Exit fullscreen mode
Position Sizing and the Polymarket Order Book
Your model may recommend a $2,000 position, but the visible Polymarket order book may not support a $2,000 trade at your expected price.
That creates execution risk.
Before sending an order, a production Polymarket API Python client should estimate:
- available size at target prices
- average fill price
- spread
- potential slippage
- whether the trade itself moves the market
A simple position-size formula can therefore become:
final_size =
min(
model_size,
portfolio_cap,
liquidity_cap,
slippage_cap
)
Enter fullscreen mode Exit fullscreen mode
For active strategies, live market data can be monitored through the relevant Polymarket data infrastructure and websocket interfaces described in the current developer documentation.
Production Architecture
A clean Polymarket trading bot Python architecture should keep sizing independent from execution.
strategy/
signal.py
probability_model.py
risk/
position_sizing.py
exposure.py
correlation.py
execution/
orderbook.py
orders.py
fills.py
monitoring/
metrics.py
alerts.py
Enter fullscreen mode Exit fullscreen mode
This separation is important because your signal model may change while your risk engine should remain conservative.
Retry Carefully
Do not blindly retry an order because a request failed. First determine whether the order may have been accepted.
Use exponential backoff for safe retryable network operations:
import time
import logging
logger = logging.getLogger(__name__)
def retry(operation, attempts=3):
for attempt in range(attempts):
try:
return operation()
except Exception as exc:
logger.warning(
"Operation failed on attempt %d: %s",
attempt + 1,
exc,
)
if attempt == attempts - 1:
raise
time.sleep(2 ** attempt)
Enter fullscreen mode Exit fullscreen mode
Order submission requires idempotency and order-state reconciliation. Network failure does not necessarily mean that an order was rejected.
Common Failure Modes
1. Full Kelly with an overconfident model
A small probability-estimation error can dramatically affect recommended size.
Use conservative sizing until calibration has been validated.
2. Ignoring correlated exposure
Five positions may look diversified but actually depend on the same event or price movement.
Portfolio-level exposure matters more than the number of open trades.
3. Sizing from the last traded price
Your actual fill may occur at a worse price.
Size from executable order-book liquidity, not an outdated snapshot.
4. Treating paper trading as live trading
Paper systems often fail to model partial fills, queue position, slippage, and adverse selection accurately.
5. No maximum loss controls
Every automated system should have hard limits independent of the strategy model.
Testing and Monitoring
Test the sizing engine independently from the Polymarket market making bot or execution layer.
At minimum:
def test_no_positive_edge_returns_zero():
size = fractional_kelly_size(
bankroll=10_000,
probability=0.50,
price=0.55,
)
assert size == 0
Enter fullscreen mode Exit fullscreen mode
Monitor:
- bankroll
- open exposure
- gross and net exposure
- largest position
- position size as percentage of equity
- estimated versus realized fill price
- model probability versus market probability
- rejected orders
- partial fills
- daily drawdown
The current Polymarket exchange stack has undergone recent upgrades, including changes described by Polymarket to exchange contracts and order-book behavior, so production bots should be maintained against the latest official migration and developer documentation rather than relying on old SDK assumptions.
Practical Example
Assume:
Bankroll: $10,000
Model probability: 0.62
YES entry price: 0.55
Fractional Kelly: 25%
Maximum position: 5% bankroll
Enter fullscreen mode Exit fullscreen mode
Your sizing engine calculates a theoretical Kelly amount, reduces it using the fractional Kelly multiplier, and then checks the hard position limit.
Even if the model recommends more, the final position cannot exceed:
$10,000 × 5% = $500
Enter fullscreen mode Exit fullscreen mode
If order-book liquidity or expected slippage requires an even smaller amount, the bot should reduce the position further.
That is the central principle:
The best position size is not the largest mathematically possible position. It is the largest position your strategy, liquidity, execution system, and portfolio risk limits can realistically support.
Advanced Improvements
More advanced Polymarket automated trading systems can add:
- probability calibration curves
- confidence-weighted Kelly sizing
- correlation-aware portfolio sizing
- dynamic exposure limits
- volatility-aware capital allocation
- strategy-level capital budgets
- real-time fill-quality feedback
- model-specific risk multipliers
A useful next step is to make the sizing multiplier dynamic:
final_kelly_multiplier =
base_multiplier
× model_confidence
× liquidity_quality
× portfolio_risk_factor
Enter fullscreen mode Exit fullscreen mode
This allows a Polymarket arbitrage bot or directional strategy to reduce capital automatically when execution quality deteriorates.
Frequently Asked Questions
How much should a Polymarket trading bot risk per trade?
There is no universal number. Use estimated edge, model confidence, available liquidity, portfolio exposure, and a hard maximum position cap.
Is Kelly Criterion good for a Polymarket bot?
It can be useful, but full Kelly assumes accurate probabilities. Fractional Kelly and hard risk caps are generally more robust for uncertain real-world models.
Should a Polymarket arbitrage bot use position sizing?
Yes. Arbitrage still has execution risk, partial-fill risk, capital constraints, and settlement or inventory considerations.
Should I size trades from the best bid or ask?
Use realistic executable prices and enough order-book depth to estimate the actual average fill price.
Can a Polymarket websocket improve position sizing?
Yes. Real-time market data can help update liquidity and pricing inputs, but the final implementation should follow the current official Polymarket developer documentation.
Useful Resources
- Polymarket Official Website — Market access and platform information.
- Official Polymarket Documentation — Primary technical authority for API and trading implementation.
- — Official starting point for developers looking for programmatic resources.
- — Useful for developers building applications and infrastructure around Polymarket.
- Polymarket Official X Account — Official announcements and platform updates.
Third-party Medium, DEV.to, and YouTube resources were not included here because a current, directly relevant resource could not be verified confidently enough for this technical article.
Conclusion
Position sizing is the bridge between a Polymarket trading strategy and actual capital risk.
A production system should not simply ask:
“Is this trade profitable?”
It should ask:
“How much should we risk after accounting for edge, model uncertainty, liquidity, execution quality, and existing exposure?”
For most systems, a strong starting architecture is:
Probability model
→ Net edge
→ Fractional Kelly
→ Position cap
→ Liquidity cap
→ Portfolio risk check
→ Order execution
→ Fill reconciliation
Enter fullscreen mode Exit fullscreen mode
That framework works for directional strategies, Polymarket arbitrage, market making, and more complex algorithmic systems.
Educational and trading-risk disclaimer: This article is for educational and software-development purposes only. Prediction-market trading involves substantial risk. No position-sizing formula guarantees profit or prevents losses. Test thoroughly and independently verify current platform behavior before deploying capital.
Related Articles
How Polymarket CLOB Works
Anchor text: “Polymarket CLOB architecture”
Why: Helps readers understand how orders interact with the exchange.Polymarket Order Book Explained
Anchor text: “Polymarket order book liquidity”
Why: Essential for liquidity-aware position sizing.How to Handle Slippage in a Polymarket Bot
Anchor text: “slippage-aware position sizing”
Why: Connects sizing decisions with realistic execution costs.How to Build a Polymarket Trading Bot
Anchor text: “build a Polymarket trading bot”
Why: Broad pillar article for implementation architecture.Polymarket WebSocket Guide
Anchor text: “real-time Polymarket market data”
Why: Supports live price and liquidity updates.Polymarket Arbitrage Bot Development
Anchor text: “Polymarket arbitrage bot”
Why: Explains sizing in multi-leg strategies.Polymarket TWAP Trading Bot
Anchor text: “Polymarket TWAP strategy”
Why: Connects position sizing with time-sensitive market strategies.