Learn how Polymarket order flow reveals trading pressure using order-book imbalance, executed trades, microstructure signals, and robust research methods.
Contacts
Nagi writes about Polymarket bots, algorithmic trading, quantitative strategies, Python automation, Web3, and prediction-market infrastructure.
Github: https://github.com/nagi777x/Polymarket-Trading-Bot
X: https://x.com/nagi__777__
Telegram: https://t.me/nagi_777x
Understanding Polymarket Order Flow
A Polymarket price is only the visible result of a much larger process.
Behind a move from 52¢ to 58¢ are orders entering the book, resting liquidity disappearing, trades executing at particular prices, and participants choosing whether to provide or consume liquidity.
That makes Polymarket order flow different from simply watching price.
The useful research question is:
Does the sequence of orders and executions contain information that is not already reflected in the current market price?
That question turns order flow into a market-microstructure problem rather than another trading-bot tutorial.
What We Are Analyzing
Polymarket uses a Central Limit Order Book (CLOB), where bids and asks represent available liquidity. Official market-data interfaces expose order-book snapshots, prices, spreads, historical prices, and trade data. The public market WebSocket also provides order-book snapshots, price-level changes, and last-trade events.
For research, the useful variables are:
- Best bid and ask
- Bid/ask depth
- Spread
- Executed trade price
- Executed trade size
- Trade side
- Order-book changes
- Midpoint changes
- Time between events
The central assumption is that liquidity and execution events contain information about short-term market pressure.
That is a hypothesis, not an established trading edge.
The Difference Between Price and Order Flow
Suppose a market moves from 45¢ to 50¢.
Price alone tells us that the market repriced.
Order flow asks how.
Consider two scenarios.
Scenario A: Several trades execute aggressively near the ask while offers are repeatedly consumed.
Scenario B: The ask moves upward because resting sell liquidity disappears, but very little trading occurs.
Both can produce the same price change.
Their microstructure is different.
This distinction is important because a price move caused by aggressive execution may have different persistence from one caused primarily by liquidity withdrawal.
Polymarket's WebSocket market channel explicitly distinguishes order-book updates from last_trade_price execution events, making this separation possible in a real-time research pipeline.
A Simple Order-Flow Framework
A basic starting point is order-book imbalance:
OI = \frac{B-A}{B+A}
where:
- (B) = selected bid-side volume
- (A) = selected ask-side volume
For example, suppose the first three bid levels contain 900 shares and the first three ask levels contain 600.
OI = \frac{900-600}{900+600}=0.20
The book therefore has positive imbalance.
But this should not automatically be interpreted as a bullish signal.
Resting orders can be cancelled.
Liquidity can be replenished.
A large visible order does not necessarily represent persistent trading intent.
The stronger framework is therefore to combine book state with executed flow.
The Flow-State Model
A useful research feature is to treat order flow as a state rather than a single number.
Define four components:
- Depth imbalance — where visible liquidity is concentrated.
- Execution pressure — which side is actually trading.
- Liquidity change — whether depth is being added or removed.
- Price response — how much the market moves after those events.
This creates a simple matrix:
| Order Flow | Price Response | Interpretation |
|---|---|---|
| Strong buying | Strong upward move | Possible aggressive demand |
| Strong buying | Little movement | Possible absorption |
| Weak trading | Strong move | Possible liquidity withdrawal |
| Balanced trading | Little movement | Stable microstructure |
The interesting case is often absorption.
If substantial buying occurs but price barely advances, sellers may be absorbing demand.
Conversely, if relatively little executed volume produces a large price movement, the book may simply be thin.
This is more informative than labeling every green move “buy pressure.”
A Better Signal: Flow × Price Impact
One practical feature is:
F_t = \frac{\Delta P_t}{V_t+\epsilon}
where:
- (\Delta P_t) = price movement over a window
- (V_t) = executed volume
- (\epsilon) = small constant preventing division by zero
The interpretation is unusual but useful.
High (V_t) with low (\Delta P_t) suggests strong activity with limited price impact.
Low (V_t) with high (\Delta P_t) suggests that relatively little trading produced substantial repricing.
Neither is automatically bullish or bearish.
Instead, they describe market sensitivity to order flow.
That can become a regime variable.
Python Experiment
The following synthetic example calculates order imbalance. It is deliberately not presented as real Polymarket data.
def order_imbalance(bid_volume, ask_volume):
total = bid_volume + ask_volume
return 0.0 if total == 0 else (bid_volume - ask_volume) / total
samples = [
{"bid": 900, "ask": 600},
{"bid": 500, "ask": 800},
{"bid": 700, "ask": 700},
]
for row in samples:
print(order_imbalance(row["bid"], row["ask"]))
A production research system should calculate the feature repeatedly over time rather than treating one snapshot as a signal.
The official WebSocket feed provides full book snapshots and incremental price-level changes, while trade events include execution price, size, and side.
What Can Go Wrong?
Order-flow research has several traps.
Look-ahead bias: A feature accidentally incorporates events that were unavailable when the decision would have been made.
Snapshot bias: Sampling the book periodically can miss rapid liquidity changes between observations.
Event duplication: Reconnecting to a stream without correct state reconciliation can produce duplicate observations.
Stale state: An apparently large bid may no longer exist when a strategy attempts to trade.
Selection bias: Studying only highly active markets can make the signal appear more universal than it is.
Spread effects: A price move may partly represent changing transaction costs rather than changing probability.
Resolution effects: Prediction markets can behave differently as the resolution event approaches.
Most importantly, order-book imbalance measures visible liquidity, not trader intent.
Testing the Hypothesis
A serious experiment should separate four layers:
Hypothesis: Order-flow imbalance contains short-horizon information about subsequent price movement.
Experiment: Calculate imbalance and executed-flow features over historical event streams.
Observed result: Measure subsequent midpoint or trade-price movement after predefined horizons.
Interpretation: Determine whether the relationship survives costs, different market types, and different volatility regimes.
Avoid optimizing the feature and evaluation window simultaneously.
A better methodology is walk-forward testing:
- Define the feature.
- Choose the prediction horizon.
- Train or calibrate on an earlier period.
- Test on unseen markets or later periods.
- Repeat across regimes.
- Compare against a price-only baseline.
The key benchmark is not whether order flow predicts price.
It is whether it predicts more information than price, spread, and recent returns already provide.
Practical Example
Consider a hypothetical BTC Up market trading around 56¢.
The best bid is 55¢ and ask is 57¢.
During the next minute:
- Bid depth increases.
- Several trades execute on the buy side.
- Ask liquidity repeatedly disappears.
- The midpoint rises to 59¢.
That sequence is more informative than simply observing “56¢ → 59¢.”
Now consider another market where the midpoint also reaches 59¢, but almost no trades occur and ask liquidity simply disappears.
The two observations should be stored as different market states.
That is the core idea behind order-flow analysis: classify the path, not just the destination.
Advanced Extensions
Experienced researchers can extend this framework with:
- Multi-level order-flow imbalance instead of top-of-book measurements.
- Event-time sampling instead of fixed clock intervals.
- Hidden-state or regime models.
- Cross-market flow features for related contracts.
- Machine-learning models predicting price impact rather than direction.
A particularly useful extension is predicting future price impact conditional on executed volume. This asks whether the market is becoming more or less sensitive to incoming flow.
Key Takeaways
- Order flow contains more information than the latest price alone.
- Resting liquidity and executed trades should be modeled separately.
- Imbalance is a feature, not automatically a trading signal.
- Price impact relative to executed volume can reveal liquidity regimes.
- The strongest research question is incremental information over price-based baselines.
- Historical replay and out-of-sample testing are essential before interpreting order flow as predictive.
FAQ
What is Polymarket order flow?
It is the sequence of order-book changes and executed trades occurring in a Polymarket CLOB market.
Is order-book imbalance a reliable trading signal?
Not by itself. It measures visible liquidity and should be tested against execution flow, price response, spread, and market regime.
What data is useful for Polymarket order-flow analysis?
Order-book snapshots, price-level changes, trade executions, trade size, trade side, midpoint, and spread are useful starting variables.
Can order flow predict Polymarket prices?
That is an empirical hypothesis. It should be evaluated using historical replay and out-of-sample tests rather than assumed.
What is the biggest mistake in order-flow research?
Treating displayed liquidity as equivalent to committed trading intent. Orders can change before they execute.
Conclusion
Polymarket order flow is best understood as a sequence of interactions between liquidity, execution, and price response.
The interesting research opportunity is not simply to calculate buy-versus-sell volume. It is to determine how much price movement a given amount of trading produces, and whether that relationship changes across market regimes.
For developers, the next step is therefore not immediately building a trading signal. Build a clean event-replay dataset first. Preserve book state, executions, timestamps, and market context. Then test whether order flow adds predictive information beyond what the price series already contains.
Disclaimer: This article is for educational and research purposes only. Trading prediction markets involves market, liquidity, execution, model, and capital risk. No strategy discussed here guarantees profit.
Top comments (0)