Polymarket Bot Order-Book Imbalance: How to Detect Real Market Pressure

Order-book imbalance looks simple.

Count the bids.

Count the asks.

Compare them.

If bids are much larger than asks, the market looks bullish.

If asks are much larger than bids, the market looks bearish.

But building a Polymarket bot around that assumption can be a serious mistake.

A large imbalance does not automatically mean the price will move.

Orders can disappear.

New liquidity can arrive.

Trades can consume one side of the book.

The spread can change.

And the imbalance that looked strong 200 milliseconds ago may no longer exist.

The real question is:

How can a Polymarket bot determine whether order-book imbalance represents meaningful market pressure or temporary noise?

That is where the engineering becomes interesting.

What Is Order-Book Imbalance?

For a simple order book, define:

Bid Volume = total size on the bid side

Ask Volume = total size on the ask side

A basic imbalance formula is:

Imbalance =
(Bid Volume - Ask Volume)
/
(Bid Volume + Ask Volume)

The result is between:

-1 and +1

For example:

Bid Volume = 800
Ask Volume = 200

Then:

(800 - 200) / (800 + 200)

= 600 / 1000

= 0.60

The result is:

+0.60

That means the displayed bid-side liquidity is significantly larger than the ask-side liquidity.

But this is only a snapshot.

It is not a trading decision.

Why a Single Imbalance Snapshot Is Dangerous

Imagine your Polymarket bot sees:

Imbalance = +0.70

The bot buys immediately.

Then:

100 ms later → +0.35
200 ms later → +0.10
300 ms later → -0.05

The original imbalance disappeared.

What happened?

Possibilities include:

• Large bids were cancelled

• New asks appeared

• Trades consumed the bids

• Price moved

• Liquidity migrated to another level

The bot wasn't necessarily wrong about the data.

The problem was treating a temporary observation as a persistent signal.

Persistence Matters

This is one of the first improvements I would make to a Polymarket bot.

Instead of asking:

What is the current imbalance?

Ask:

How long has the imbalance remained meaningful?

For example:

t0 → +0.68
t1 → +0.71
t2 → +0.69
t3 → +0.73
t4 → +0.66

This is more interesting than:

t0 → +0.70
t1 → +0.12
t2 → -0.10

Both examples contain:

+0.70

But they describe very different market conditions.

A Better Imbalance Signal

Instead of:

IF imbalance > threshold
    BUY

I prefer thinking in terms of:

Imbalance
+
Persistence
+
Price Movement
+
Trade Flow
+
Liquidity
+
Spread

Then the bot can decide whether the imbalance is strong enough to influence execution.

Which Levels Should You Measure?

Another important question is:

How much of the order book should be included?

Suppose the book is:

Bid

0.48 → 100
0.47 → 200
0.46 → 300
0.45 → 800
0.44 → 1500

and:

Ask

0.52 → 100
0.53 → 150
0.54 → 200
0.55 → 300
0.56 → 400

If you include every level, the distant 0.45 bid can dominate your calculation.

But that liquidity may have very little relevance to the immediate execution price.

So the bot needs to define an observation window.

For example:

Top 1 level
Top 3 levels
Top 5 levels
Price-distance window
Depth within X ticks

There isn't one universally correct choice.

It depends on the strategy and market.

Top-of-Book Imbalance

The simplest approach is to compare only the best bid and best ask sizes.

For example:

Best Bid Size = 500
Best Ask Size = 100

Then:

Imbalance = (500 - 100) / (500 + 100)

= 0.667

This is fast.

But it can also be fragile.

A single large order can make the imbalance look extreme.

If that order disappears, the signal disappears with it.

Multi-Level Imbalance

A more stable approach is to use several levels.

For example:

Bid:

0.50 → 200
0.49 → 150
0.48 → 100

Total = 450

and:

Ask:

0.51 → 100
0.52 → 100
0.53 → 100

Total = 300

Then:

Imbalance =
(450 - 300) / (450 + 300)

= 0.20

This gives a different picture from looking only at the best level.

The important engineering decision is to make the depth window configurable.

Weighting Distance From the Mid Price

Not all liquidity should necessarily have equal weight.

Liquidity close to the current market may matter more than liquidity far away.

So you can introduce weights.

Conceptually:

Weighted Imbalance =
Weighted Bid Depth
-
Weighted Ask Depth

where levels closer to the midpoint receive greater weight.

For example:

Level 1 → weight 1.00
Level 2 → weight 0.75
Level 3 → weight 0.50
Level 4 → weight 0.25

The exact weighting function is something I would test rather than hard-code permanently.

Imbalance vs Price Movement

This is where the signal becomes much more useful.

Suppose:

Imbalance = +0.65

but:

Price = unchanged

That is different from:

Imbalance = +0.65
Price = rising

And different again from:

Imbalance = +0.65
Price = falling

The same imbalance can have different meanings depending on what price is doing.

So a Polymarket bot should not necessarily interpret:

Imbalance = +0.65

in isolation.

Add Trade Flow

Displayed liquidity is not the same thing as executed liquidity.

This is an important distinction.

The order book tells you what traders are currently displaying.

Trades tell you what actually happened.

Imagine:

Bid imbalance = +0.60

but recent trades are repeatedly hitting the bids.

That could indicate that the displayed bid liquidity is being consumed.

Now consider:

Bid imbalance = +0.60

while aggressive buying is repeatedly lifting the asks.

That is a very different situation.

So I would track:

• Order-book imbalance

• Recent trade direction

• Trade volume

• Price movement

• Liquidity changes

Liquidity Appearance vs Liquidity Consumption

This distinction is extremely important.

Suppose a large bid appears:

BUY 1,000

The bot might interpret this as strong support.

But if the order disappears before any meaningful trading occurs, it may have provided little real support.

On the other hand:

BUY 1,000

appears and:

300 traded
400 traded
200 traded

Now the displayed liquidity has actually participated in execution.

This is why I would track both:

Displayed Liquidity

and:

Consumed Liquidity

The Imbalance Can Move Before Price

A useful feature for a Polymarket bot is to monitor the sequence of events.

For example:

1. Bid depth increases
2. Imbalance becomes positive
3. Ask depth decreases
4. Trades begin lifting the ask
5. Mid price moves

This sequence can be more informative than simply observing:

Imbalance = +0.70

The order of events matters.

That means the bot should store short-term market history rather than only the latest book snapshot.

Use a Rolling Window

For example, maintain:

last 100 ms
last 250 ms
last 500 ms
last 1 second

Then calculate:

Current Imbalance
Average Imbalance
Maximum Imbalance
Minimum Imbalance
Imbalance Duration
Imbalance Change

Now the strategy can distinguish:

Strong + persistent

from:

Strong + temporary

Imbalance Velocity

Another useful feature is how quickly imbalance changes.

For example:

t0 = 0.10
t1 = 0.30
t2 = 0.50
t3 = 0.70

The imbalance is increasing rapidly.

Compare that with:

t0 = 0.70
t1 = 0.69
t2 = 0.68
t3 = 0.67

The second case still has positive imbalance.

But the pressure is weakening.

So instead of only calculating:

imbalance

calculate:

imbalance_change

and potentially:

imbalance_velocity

Don't Let Imbalance Override the Strategy

This is one of the most important rules.

I would not build:

IF imbalance > 0.5
    BUY

as the complete strategy.

Instead:

Strategy Signal
+
Order-Book Imbalance
+
Trade Flow
+
Price Movement
+
Liquidity
+
Risk

should influence the final decision.

Imbalance should often be a feature.

Not the entire strategy.

Example: Two Different Markets

Consider Market A:

Imbalance = +0.70
Persistence = 50 ms
Price = falling
Trade flow = selling
Spread = widening

That doesn't look like a strong long setup.

Now Market B:

Imbalance = +0.65
Persistence = 800 ms
Price = rising
Trade flow = buying
Spread = stable
Liquidity = increasing

That is a much more interesting condition.

The numerical imbalance is similar.

The market context is completely different.

Imbalance and Execution

This is where the feature becomes useful for a Polymarket bot.

Suppose the strategy already wants to buy.

The execution engine sees:

Strong positive imbalance
+
Positive trade flow
+
Stable spread

It may decide that waiting for a lower passive price has a higher opportunity cost.

The bot could therefore become more aggressive.

Now consider:

Weakening imbalance
+
Negative trade flow
+
Widening spread

The execution engine may reduce size or wait.

This creates a better relationship between:

Signal

and:

Execution Policy.

Imbalance Can Also Tell the Bot When Not to Trade

This is often overlooked.

A good trading feature doesn't only answer:

"BUY?"

It can also answer:

"WAIT."

For example:

Strategy = BUY

Imbalance = unstable
Spread = widening
Liquidity = falling
Trade flow = conflicting

The best decision may be:

WAIT

The bot doesn't need to trade every time the strategy detects a theoretical opportunity.

A Practical Imbalance Score

You could create a composite score such as:

Score =
w1 × Imbalance
+
w2 × Persistence
+
w3 × TradeFlow
+
w4 × PriceMomentum
+
w5 × LiquidityChange
-
w6 × Spread

The weights should be determined through testing.

The important part is that the model combines multiple pieces of market information.

Then:

Score > Entry Threshold

could permit execution.

While:

Score < Entry Threshold

could result in:

WAIT

Avoid Hard-Coded Thresholds

A common mistake is:

imbalance > 0.50

forever.

Different markets can behave differently.

Liquidity can vary.

Time-to-resolution can vary.

Spread can vary.

Market participants can vary.

So thresholds should ideally be configurable and tested against historical data.

For example:

imbalanceThreshold
minimumPersistence
maxSpread
minimumDepth
minimumTradeVolume
maxSignalAge

These should be strategy parameters, not hidden constants throughout the codebase.

Signal Freshness Matters

Even a strong imbalance can become stale.

A simplified execution flow is:

ORDER BOOK UPDATE
        ↓
FEATURE CALCULATION
        ↓
SIGNAL
        ↓
VALIDATION
        ↓
EXECUTION

If the bot waits too long between those stages, the market state may have changed.

So I would associate each signal with:

signalTimestamp
bookTimestamp

and calculate:

signalAge

If:

signalAge > maximumAllowedAge

the bot should invalidate the signal and recalculate.

A Better Architecture

For a production-style Polymarket bot, I would separate the components:

Market Data
    ↓
Order Book
    ↓
Feature Engine
    ↓
Imbalance Calculator
    ↓
Signal Engine
    ↓
Risk Engine
    ↓
Execution Engine
    ↓
Order Manager
    ↓
Position Manager

The imbalance calculator shouldn't place orders.

The strategy shouldn't directly manipulate balances.

The execution engine shouldn't decide the market direction.

Each component should have a clear responsibility.

What I Would Log

When the bot trades because of an imbalance-related signal, I want to know exactly why.

For example:

SIGNAL

imbalance = 0.64
imbalance_duration = 620ms
trade_flow = +0.72
price_change = +0.004
spread = 0.01
depth = 840
signal_age = 18ms

DECISION

signal = BUY
confidence = HIGH
order_size = 100

EXECUTION

order_type = LIMIT
price = 0.54
filled = 82
remaining = 18

This makes the strategy testable.

Without this information, you may only see:

BUY
SELL
P&L

and have no idea why the bot made its decisions.

Backtesting the Feature

Before trusting order-book imbalance with real capital, I would test:

• Different depth windows

• Different imbalance thresholds

• Different persistence requirements

• Different market conditions

• Different time-to-resolution ranges

• Different liquidity levels

• Different spreads

• Different execution delays

The important metric isn't simply:

"Did price go up after positive imbalance?"

You also need to ask:

"Could the bot actually execute the trade at the assumed price?"

The Difference Between Prediction and Execution

This is the key lesson.

Suppose positive imbalance predicts that price will move higher.

That doesn't automatically mean the bot can profit from it.

The bot still needs:

Prediction
+
Entry Price
+
Execution Probability
+
Slippage
+
Position Size
+
Exit
+
Risk

A feature can be statistically useful and still be economically useless after execution costs.

The Rule I Would Use

I wouldn't build a Polymarket bot around:

Imbalance → Buy

I would build:

Imbalance
      +
Persistence
      +
Trade Flow
      +
Price
      +
Liquidity
      +
Spread
      +
Strategy
      +
Risk
      ↓
Execution Decision

That's a much more robust way to think about order-book imbalance.

Final Thoughts

Order-book imbalance is one of those features that looks extremely simple at first.

Calculate bid volume.

Calculate ask volume.

Compare them.

Done.

But real markets aren't static.

Liquidity changes.

Orders disappear.

Trades consume liquidity.

Prices move.

Spreads change.

Signals become stale.

That's why the useful question isn't:

"Is there an imbalance?"

The better question is:

"Is the imbalance persistent, meaningful, tradable, and consistent with the rest of the market state?"

That is the difference between adding an indicator to a bot and actually engineering an execution system.

What's Next?

I'm continuing this practical Polymarket bot engineering series.

The next problem I want to explore is:

Limit Orders vs Marketable Orders in a Polymarket Bot

When should the bot provide liquidity?

When should it take liquidity?

How much does execution probability matter?

And when is getting filled more important than getting the perfect price?

Source Code

I publish practical Polymarket bot development and experiments on GitHub.

My Polymarket TWAP trading bot:

https://github.com/ruudkoeyvoets/polymarket-trading-bot-twap

Follow the Development

I also share Polymarket bot development, execution experiments, and technical research on YouTube:

https://www.youtube.com/@std0d

---

This article is for educational and software-development purposes only and is not financial advice. Automated trading involves substantial risk. No strategy, bot, or execution technique guarantees profit.