Beyond Price: Building a Probability-Driven Trading System for Polymarket
Why combining external BTC/ETH market data with probability modeling and adaptive TWAP can create a more intelligent execution strategy
Short-duration prediction markets look deceptively simple.
A BTC Up/Down market appears to give you everything you need:
BTC Up
BTC Down
Current price
Time remaining
But there is a deeper problem.
Is the price on Polymarket actually reflecting the information available in the underlying BTC or ETH market?
That question changes the entire way we can design a trading bot.
Instead of building a system that simply reacts to Polymarket price movements, we can build a system that estimates its own probability, compares that probability with the market, and then uses TWAP to execute only when a meaningful difference exists.
The architecture becomes:
External BTC/ETH Data
↓
Feature Extraction
↓
Probability Model
↓
Fair Value
↓
Polymarket Price
↓
Edge
↓
Adaptive TWAP
↓
Continuous Re-evaluation
This is the difference between a price-following bot and a probability-driven trading system.
The Important Shift: Price Is Not the Signal
Consider a simple example.
A Polymarket BTC Up contract is trading at:
UP = $0.56
A reasonable first interpretation is that the market is pricing approximately a 56% probability of the outcome.
But suppose our model, using external BTC market information, estimates:
P(UP) = 0.64
Now we have:
Market probability: 56%
Model probability: 64%
Potential edge: 8%
The strategy isn't saying:
"BTC is going up, therefore buy UP."
Instead, it says:
"My estimated probability is materially higher than the current market price."
That distinction is fundamental.
The Polymarket price becomes one input into the trading decision, rather than the entire trading signal.
Where the Additional Information Comes From
For a short-duration BTC or ETH market, the underlying crypto market provides information that may not be fully represented in the prediction-market price at every moment.
A trading system can monitor:
- BTC/USDT price
- ETH/USDT price
- Short-term momentum
- Realized volatility
- Trading volume
- Exchange order-book imbalance
- Distance from the strike
- Time remaining
- Recent price acceleration
For example:
BTC Strike: $100,000
BTC Price: $100,250
Time Remaining: 3 minutes
Polymarket UP: $0.55
If BTC has strong short-term momentum and the model estimates a 63% probability of finishing above the strike, the $0.55 market price deserves further investigation.
The important point is that no individual feature needs to be perfect.
The goal is to combine multiple weak signals into a more useful probability estimate.
A Probability Model Doesn't Need to Be Complicated
The first version of the model can be surprisingly simple.
Conceptually:
P(UP) =
Momentum
+ Volatility
+ Order-Book Imbalance
+ Strike Distance
+ Time Remaining
A simple Python implementation could look like:
def estimate_probability(
momentum,
volatility,
imbalance,
distance,
time_remaining
):
score = (
0.30 * momentum +
0.15 * volatility +
0.20 * imbalance +
0.25 * distance +
0.10 * time_remaining
)
probability = 0.50 + score
return max(0.01, min(0.99, probability))
The weights above are illustrative rather than statistically validated.
That's important.
A production system should learn or optimize these parameters from historical data and then validate them on unseen data.
The purpose of this first model is to establish the architecture:
Market Data
↓
Features
↓
Probability
rather than attempting to build the perfect model immediately.
Why Strike Distance Alone Isn't Enough
One of the most interesting variables in a binary crypto market is the distance between the current asset price and the strike.
For example:
distance = (btc_price - strike) / strike
If:
BTC = $100,250
Strike = $100,000
then:
distance = 0.0025
But the number itself isn't enough.
Imagine two identical situations:
Scenario A
BTC = $100,250
Strike = $100,000
Time remaining = 10 seconds
Scenario B
BTC = $100,250
Strike = $100,000
Time remaining = 10 minutes
The probability of finishing above the strike can be dramatically different.
This is why price distance, volatility, and time remaining need to be interpreted together.
A normalized representation can be:
import math
def normalized_distance(
price,
strike,
volatility,
seconds_left
):
if volatility <= 0 or seconds_left <= 0:
return 0.0
return (
(price - strike) / strike
) / (
volatility * math.sqrt(seconds_left)
)
This turns a raw price difference into something closer to a volatility-adjusted signal.
Order-Book Imbalance Adds Another Dimension
Price tells us where the market is.
The order book can provide information about how participants are positioning around that price.
Suppose:
Bid volume = 850 BTC
Ask volume = 500 BTC
A basic imbalance calculation is:
def order_book_imbalance(
bid_volume,
ask_volume
):
total = bid_volume + ask_volume
if total == 0:
return 0.0
return (
bid_volume - ask_volume
) / total
This produces a value approximately between:
-1 → selling pressure
0 → balanced
+1 → buying pressure
It can then become another input to the probability model.
But this is where market microstructure becomes important.
Order-book imbalance isn't magic.
Liquidity can disappear.
Orders can be canceled.
Short-term order books can contain noise or misleading signals.
Therefore, imbalance should be treated as evidence, not certainty.
The Real Signal Is the Edge
Once we have a probability estimate, we can compare it against the Polymarket price.
def calculate_edge(
model_probability,
market_price
):
return model_probability - market_price
For example:
Model probability = 0.64
Market price = 0.56
Edge = 0.08
But an important mistake would be:
edge > 0 → trade
That's too simplistic.
Instead, define a minimum threshold:
MIN_EDGE = 0.05
if edge > MIN_EDGE:
print("Potential opportunity")
Why?
Because the theoretical edge can disappear after:
- Fees
- Slippage
- Latency
- Spread
- Partial fills
- Model error
- Execution costs
The strategy therefore needs a minimum economic edge, not merely a positive mathematical difference.
TWAP Solves a Different Problem
At this point, we have identified a potential opportunity.
But we still haven't solved execution.
Suppose:
Model probability = 0.65
Polymarket price = 0.55
Edge = 0.10
And we want to invest:
$1,000
A single large order can consume liquidity:
Large order
↓
Liquidity consumed
↓
Average price increases
↓
Expected edge decreases
This is where TWAP becomes useful.
Instead of:
$1,000 immediately
we can execute:
$1,000
12 slices
120 seconds
≈ $83 per slice
For example:
00s → $83
10s → $83
20s → $83
30s → $83
...
110s → $83
The key insight is:
The probability model decides whether to trade. TWAP decides how to execute the trade.
This separation is extremely useful when designing automated trading systems.
The Better Version: Adaptive TWAP
Fixed TWAP is useful, but markets don't remain static for two minutes.
Suppose the edge changes:
0.04
↓
0.07
↓
0.11
↓
0.05
↓
0.02
Why should the bot execute the same amount at every step?
It shouldn't.
Instead, the execution engine can react to the current edge.
For example:
Edge Execution
-------------------------
< 0.03 Stop
0.03–0.05 Small
0.05–0.08 Normal
0.08–0.12 Larger
> 0.12 Maximum
A simple implementation:
def calculate_order_size(edge, base_size):
if edge < 0.03:
return 0
multiplier = min(edge / 0.05, 2.0)
return base_size * multiplier
This transforms TWAP from a static schedule into an adaptive execution strategy.
The Most Important Feature: Stop Trading
This may be more important than the entry logic.
Imagine the bot starts with:
Model probability = 0.64
Market price = 0.56
Edge = 0.08
The trade begins.
Thirty seconds later:
Model probability = 0.57
Market price = 0.56
Edge = 0.01
The original edge has disappeared.
The bot should stop.
if edge < MIN_EDGE:
cancel_remaining_orders()
stop_twap()
This creates a feedback loop:
Prediction
↓
Execution
↓
Re-evaluation
↓
Prediction
↓
Execution
↓
...
The bot is no longer saying:
"I decided to buy, so I must finish the order."
Instead:
"I will continue buying only while the original trading thesis remains valid."
That is a much more robust way to think about automated execution.
Architecture Matters More Than the Formula
A production implementation should separate responsibilities.
I would structure it roughly like this:
BTC / ETH Exchange
│
▼
WebSocket Collector
│
▼
MarketData
│
▼
FeatureEngine
│
▼
ProbabilityModel
│
▼
SignalEngine
│
├────── Polymarket Price
│
▼
Edge Engine
│
▼
TWAP Executor
│
▼
Risk Manager
│
▼
Order Execution
The corresponding code architecture could be:
MarketData
↓
FeatureEngine
↓
ProbabilityModel
↓
SignalEngine
↓
TWAPExecutor
↓
RiskManager
This separation makes the system easier to test, optimize, and replace.
For example, you could improve the probability model without rewriting the execution engine.
A Practical 5-Minute BTC Example
Let's consider a realistic example.
Strike: $100,000
Current BTC: $100,180
Time remaining: 92 seconds
Polymarket UP: $0.54
Model probability: $0.63
Therefore:
Edge = 0.63 - 0.54
= 0.09
Suppose the minimum acceptable edge is:
0.05
The trade qualifies.
The bot wants:
Position = $600
Duration = 90 seconds
Rather than entering the entire position immediately, it starts a TWAP schedule.
Then the model changes:
Model probability = 0.58
Market price = 0.56
Edge = 0.02
Since:
0.02 < 0.05
the bot stops the remaining execution.
This illustrates the central concept:
The position is conditional on the edge remaining valid.
The Hardest Problem Isn't TWAP
It is tempting to think the difficult part is implementing TWAP.
It isn't.
The difficult part is answering:
How accurate is my probability estimate?
Imagine your model constantly predicts:
P(UP) = 0.65
But historical results show the actual probability is closer to:
P(UP) = 0.55
The bot will systematically believe it has an edge when no edge exists.
This is a model-calibration problem.
Before deploying capital, you should measure:
- Probability calibration
- Expected value
- Drawdown
- Slippage
- Fill rate
- Time-to-fill
- Data latency
- Fees
- Volatility regimes
- Strike-distance regimes
And most importantly:
Use out-of-sample testing.
Stop Predicting Direction. Start Estimating Probability.
There is a major difference between:
"BTC is going up, so buy UP."
and:
"Given BTC's current price, volatility, order flow, distance from the strike, and time remaining, I estimate a 63% probability of finishing UP."
The second statement is much more useful for systematic trading.
It gives us something measurable:
Estimated Probability
vs
Market Probability
And therefore:
Fair Value
↓
Market Price
↓
Potential Edge
This is the conceptual shift from directional trading to probability-driven trading.
Final Takeaway
TWAP itself isn't the strategy.
It's the execution layer.
The more interesting system is:
External BTC/ETH Data
↓
Feature Extraction
↓
Probability Model
↓
Fair Value
↓
Polymarket Price
↓
Edge
↓
Adaptive TWAP
↓
Continuous Re-evaluation
The objective is to build a bot that can:
estimate probability → identify potential mispricing → execute efficiently → continuously reassess → stop when the edge disappears.
That is a much more interesting engineering problem than simply building a bot that buys when BTC moves upward.
The combination of external market data, probability modeling, market microstructure, and adaptive execution provides a strong foundation for experimenting with systematic strategies in short-duration prediction markets.
And the most important lesson is simple:
Don't ask only where the market is trading. Ask what the market should be worth—and how confident you are in that estimate.
This is a strategy-development framework, not a guarantee of profitability. Real deployment requires calibrated models, realistic execution assumptions, strict position limits, and extensive out-of-sample testing.
