1
1 Comment

Building Alpha Models from Prediction Market Order Flow

I've been experimenting with different Polymarket Trading bot strategies, and one thing keeps becoming more interesting:

Price isn't the whole story.

Most trading bots look at the current YES/NO price, compare it with a probability estimate, and decide whether there is an edge.

That's a good starting point.

But underneath that price, something else is happening.

Traders are placing orders. Liquidity is moving. Buyers are consuming asks. Sellers are hitting bids. Spreads are changing.

That's order flow.

And I think it can become a useful additional signal for prediction-market bots.


The Idea

Imagine a Polymarket contract moves:

$0.50 → $0.55

A normal price-based strategy sees a +$0.05 move.

But there are different ways that move could happen.

Scenario A

Aggressive buying
+ Ask liquidity consumed
+ Buy volume increasing

Scenario B

Low volume
+ Liquidity disappearing
+ No meaningful buying

Same price movement.

Completely different market behavior.

That's the reason I'm interested in order flow.

Instead of asking only:

"Where is the price going?"

we can also ask:

"What is happening inside the market that is causing the price to move?"


From Order Flow to Alpha

The architecture I'm interested in looks roughly like this:

Polymarket Market Data
          ↓
     Order Flow
          ↓
   Feature Engineering
          ↓
      Alpha Model
          ↓
 Probability Forecast
          ↓
   Expected Edge
          ↓
    Risk Manager
          ↓
      Execution

The important part is that order flow isn't automatically a BUY/SELL signal.

It's a source of information.

The model needs to determine whether that information actually improves forecasting.


What Data Would I Track?

I wouldn't start with 500 indicators.

I'd start with a small set of features.

Order Book

Bid depth
Ask depth
Spread
Bid/ask imbalance
Multi-level depth

Trades

Buy volume
Sell volume
Trade count
Average trade size
Large trade frequency

Price

Short-term momentum
Price acceleration
Returns
Volatility

Market Context

Time remaining
Liquidity
Underlying asset movement
Market regime

The goal isn't to collect everything.

The goal is to find a few features that provide incremental information.


A Simple Order-Book Feature

One simple feature is order-book imbalance:

                 Bid Depth - Ask Depth
Imbalance = -------------------------------
                 Bid Depth + Ask Depth

For example:

Bid Depth = 30,000
Ask Depth = 10,000

Imbalance = 0.50

That tells us there is considerably more displayed liquidity on the bid side.

But this does not mean:

Imbalance = 0.50
       ↓
BUY

Orders can be canceled.

Displayed liquidity isn't the same as executed trading.

So I treat imbalance as a feature, not a prediction.


Combining Order Flow With Probability

This is where it gets more interesting.

Suppose my probability model says:

P(YES) = 61%

Then the order-flow model detects:

Strong buying pressure
+
Increasing buy volume
+
Ask liquidity being consumed

The combined system could potentially update the forecast:

P(YES) = 66%

Conceptually:

Probability Model
       +
Order Flow Model
       ↓
Combined Forecast

Now we're not simply following price.

We're trying to determine whether market behavior provides information that should change our probability estimate.


Add Volatility

Order flow doesn't exist in a vacuum.

The same signal can behave very differently depending on market conditions.

For example:

Strong buying pressure
        ↓

Low volatility
→ potentially more stable signal

Extreme volatility
→ potentially less reliable signal

So my preferred model architecture is becoming:

Probability
     +
Order Flow
     +
Volatility
     ↓
Expected Edge

Then:

Expected Edge
     ↓
Execution Costs
     ↓
Risk
     ↓
Trade / Don't Trade

The Important Part: Incremental Alpha

This is probably the most important concept in the whole idea.

Suppose I already have a momentum model.

Then I add:

Order-book imbalance

If the model performs better out-of-sample, that's interesting.

But if I add another 20 order-flow indicators and performance doesn't improve, those features probably aren't adding much.

So the question isn't:

"How many features can I add?"

It's:

"Does this feature provide information my model doesn't already have?"

That's incremental alpha.

More data doesn't automatically mean more edge.


Execution Can Destroy the Edge

This is another lesson that becomes obvious once you start building real bots.

Imagine:

Model fair value = $0.65
Market ask       = $0.61

Raw edge = $0.04

Looks great.

But then:

Spread
+
Slippage
+
Fees
+
Market impact
+
Latency

reduce the actual opportunity.

The real pipeline is:

Signal
   ↓
Expected Edge
   ↓
Execution Costs
   ↓
Net Edge
   ↓
Trade / Don't Trade

A strategy that looks profitable before execution costs can become unprofitable in production.

This is why I think execution should be part of the strategy model, not something added at the end.


How I'd Build It

If I were starting this project from zero, I'd keep it simple.

1. Collect market data

Price
Trades
Volume
Order book
Spread
Time remaining

2. Build basic features

Order-book imbalance
Buy/sell imbalance
Momentum
Volatility
Liquidity changes

3. Define a prediction target

For example:

Will price move higher over the next 30 seconds?

or:

Will the model probability change over the next minute?

4. Backtest

Use:

Out-of-sample testing
Walk-forward testing
Different market regimes

5. Add realistic costs

Include:

Fees
Slippage
Latency
Market impact

6. Only then add complexity

Once the basic model works, experiment with machine learning.

I think this is much better than starting with a complicated model and trying to figure out afterward why it works.


My Polymarket Trading Bot Architecture

The system I'm interested in building looks roughly like this:

                 POLYMARKET
                     │
                     ▼
                Market Data
                     │
          ┌──────────┴──────────┐
          ▼                     ▼
    Probability            Order Flow
       Model                  Model
          │                     │
          └──────────┬──────────┘
                     ▼
                 Alpha Model
                     │
                     ▼
                  Volatility
                     │
                     ▼
               Expected Edge
                     │
                     ▼
                Risk Manager
                     │
                     ▼
                 Execution
                     │
                     ▼
                Performance
                     │
                     ▼
                 Feedback

The nice thing about this architecture is that each part can be improved independently.

You can swap the probability model without rebuilding execution.

You can improve the order-flow model without changing risk management.

You can add new strategies without rewriting the entire system.

That's how I prefer building trading infrastructure: modular first, complicated later.


Open-Source Polymarket Experiments

I've been experimenting with different automated Polymarket strategies, including short-duration crypto markets, arbitrage, momentum, liquidity monitoring, and execution.

I've put some of the work here:

Polymarket Trading Bot — GitHub

If you're building your own bot, the official Polymarket developer documentation is also the place I'd start for understanding the market and trading infrastructure.

I've also written a more general guide on building automated Polymarket strategies:

Building a Professional Polymarket Trading System

And a more hands-on tutorial:

How to Build a Polymarket Trading Bot


What I'm Most Interested in Testing

The interesting question isn't:

"Can order flow predict the market?"

It's:

"Does order flow provide information that my existing model doesn't already know?"

That's a much harder question.

And that's exactly what makes it interesting.

I'd like to test:

Order Flow
     +
Probability
     +
Volatility
     +
Liquidity
     +
Execution

and see whether the combination produces better risk-adjusted, out-of-sample results than using price or probability alone.


A Few Lessons So Far

If you're building a prediction-market bot, I'd keep these principles in mind:

1. Don't confuse activity with information.

A large trade doesn't automatically mean someone knows the outcome.

2. Don't overfit order flow.

There are endless features you can create from an order book.

Most won't be useful.

3. Always test incremental value.

A feature is interesting only if it improves the model beyond what you already have.

4. Model execution realistically.

A theoretical edge isn't the same as a tradable edge.

5. Keep the system modular.

Separate data, signals, risk, and execution.

It makes experimentation much faster.


Final Thoughts

I'm increasingly convinced that the next generation of Polymarket Trading bots won't simply look at price.

They'll combine several layers:

Order Flow
     ↓
Alpha Model
     ↓
Probability
     ↓
Volatility
     ↓
Expected Net Edge
     ↓
Risk
     ↓
Execution

The goal isn't to predict every market correctly.

It's to find situations where the information available to the system creates a repeatable edge after costs and risk.

That's the part I'm interested in building.

And honestly, that's what makes prediction markets fun to work on as an indie hacker:

You can start with a simple idea, build the data pipeline, test the hypothesis, automate the execution, and gradually turn it into a complete quantitative system.

Contact Info
Telegram
https://t.me/BenjaminCup

on August 5, 2026
  1. 1

    Treating order flow as a feature rather than a signal is the right frame, the failure mode with most retail strategies is skipping straight from imbalance to a directional call without ever testing if it adds information on top of what price already tells you. The incremental alpha framing you end on is the part that actually matters, plenty of order flow indicators correlate with price after the fact without ever predicting it beforehand. Curious how you plan to test for that distinction out of sample before trusting any single feature.