DEV Community

Cover image for Building a Polymarket TWAP Divergence Bot
Polymarket Trader & Web3 Dev
Polymarket Trader & Web3 Dev

Posted on

Building a Polymarket TWAP Divergence Bot

Explore how a Polymarket TWAP divergence bot measures price gaps, timing differences, liquidity, and potential market inefficiencies.

A Polymarket price can move before the underlying TWAP signal fully reflects the same information.

That sounds like an obvious trading opportunity. It isn't.

A difference between a Polymarket probability and a TWAP-derived reference value may represent delayed information, temporary liquidity imbalance, stale observations, or simply two measurements operating on different clocks.

That distinction is the foundation of a useful Polymarket TWAP divergence bot.


About the Author

Soulcrancerdev specializes in the engineering and quantitative research behind automated prediction-market trading.

Get in touch:
Github: https://github.com/thesoulcrancerdev/poly-trading-strategies
X: https://x.com/soulcrancerdev
Community: https://t.me/+SxEC7bVXYyphNzI5
Telegram: https://t.me/soulcrancerdev
Gmail: mailto:misssilverbeauty0927@gmail.com
Youtube: https://youtube.com/@soulcrancerdev


The Core Question

The real question is not:

“Is the Polymarket price different from the TWAP?”

It is:

“Does the observed divergence contain information about subsequent price behavior after accounting for timing, liquidity, and execution?”

That changes the entire engineering problem.

Divergence Is a Measurement Problem First

Suppose a Polymarket Up token trades around 0.58 while an external model estimates a materially different probability from a TWAP-derived signal.

The naive interpretation is:

TWAP says X → Polymarket is wrong → trade.

A better interpretation is:

Reference signal → divergence → market reaction → liquidity response → execution opportunity or no opportunity.

The difference itself is only an observation.

Polymarket's documentation exposes market-price information including token midpoint prices, where the midpoint is calculated from the best bid and best ask. ([Polymarket Documentation][1]) That makes the midpoint useful for research, but it should not automatically be treated as an executable trading price.

This is one of the easiest mistakes to make when building backtests.

A Better Divergence Model

Define:

D_t = P_market,t − P_reference,t
Enter fullscreen mode Exit fullscreen mode

where:

  • P_market = observed Polymarket probability proxy
  • P_reference = reference probability or model-derived value
  • D_t = divergence

But raw divergence is rarely enough.

A more useful signal is normalized divergence:

Z_t = (D_t − μ_D) / σ_D
Enter fullscreen mode Exit fullscreen mode

This asks whether today's divergence is unusual relative to the instrument's own recent behavior.

A 3-cent difference might be enormous in one regime and meaningless in another.

The Hidden Variable: Time Alignment

The most important engineering problem may not be price at all.

It is timestamp alignment.

A TWAP is intentionally smoothed over time. A market price can react immediately to new information. Comparing the two at identical timestamps can therefore produce a divergence that is completely expected.

Imagine:

  1. The underlying asset moves sharply.
  2. Traders update Polymarket prices.
  3. The TWAP changes gradually.
  4. The bot observes a large gap.
  5. The TWAP eventually moves toward the new market regime.

The bot could interpret step 4 as mispricing even though the difference is simply a consequence of the TWAP's construction.

Therefore, a serious system should store the raw observations rather than only the calculated signal.

At minimum:

timestamp
market_id
token_id
bid
ask
midpoint
reference_value
divergence
spread
liquidity/depth observations
signal_state
execution_state
Enter fullscreen mode Exit fullscreen mode

Polymarket's developer documentation provides APIs and WebSocket infrastructure for market data, making event-level collection possible without inventing undocumented interfaces. ([Polymarket Documentation][2])

The Divergence Bot Architecture

A useful architecture is:

flowchart LR
    REF[Reference / TWAP Data] --> SYNC[Time Alignment]
    PM[Polymarket Market Data] --> SYNC
    SYNC --> DIV[Divergence Engine]
    DIV --> FILTER[Liquidity + Spread Filters]
    FILTER --> SIGNAL[Signal State]
    SIGNAL --> EXEC[Execution Layer]
    EXEC --> MON[Monitoring]
    DIV --> STORE[Historical Dataset]

The key component is the Divergence Engine.

It should not simply produce BUY or SELL.

Instead, it should describe market state:

NORMAL
DIVERGING
EXTREME_DIVERGENCE
CONVERGING
INVALID
Enter fullscreen mode Exit fullscreen mode

This turns a noisy numerical difference into something that can be researched.

Hypothetical Example

Assume a hypothetical market has:

Polymarket midpoint: 0.61
Reference estimate:  0.55
Divergence:          +0.06
Enter fullscreen mode Exit fullscreen mode

The naive bot buys or sells immediately.

A research-oriented bot asks:

  • Is the reference signal fresh?
  • Has the divergence persisted?
  • Is the spread widening?
  • Is available liquidity changing?
  • Did the market just experience a large information shock?
  • Has this magnitude historically reverted?
  • Is the divergence increasing or decreasing?

A six-cent divergence that disappears in seconds is fundamentally different from one that persists for several minutes.

What Most Traders Get Wrong

1. Divergence does not equal mispricing

Two values can differ because they measure different things.

2. A midpoint is not guaranteed execution

A midpoint is a market-data statistic, not necessarily the price at which a meaningful order can be filled. ([Polymarket Documentation][1])

3. Bigger divergence is not automatically better

Large divergence may occur precisely when information risk and adverse selection are highest.

4. TWAP can create intentional lag

The smoothing mechanism that makes TWAP useful can also make naive comparisons misleading.

5. Backtests can manufacture alpha

If the reference value is calculated using information unavailable at the historical decision timestamp, the strategy contains look-ahead bias.

A Useful Research Experiment

Instead of immediately deploying the bot, collect historical synchronized observations and test:

divergence magnitude
→ subsequent market movement
→ convergence time
→ spread during divergence
→ available liquidity
Enter fullscreen mode Exit fullscreen mode

Then divide observations into divergence buckets.

For example:

|Z| < 1
1 ≤ |Z| < 2
2 ≤ |Z| < 3
|Z| ≥ 3
Enter fullscreen mode Exit fullscreen mode

The objective is not to prove profitability.

It is to discover whether divergence has measurable predictive information after conditioning on market state.

Failure Analysis

A TWAP divergence strategy can fail because:

  • the reference signal is stale;
  • timestamps are incorrectly synchronized;
  • liquidity disappears during the signal;
  • the market reprices faster than the bot can execute;
  • the apparent edge is entirely explained by spread;
  • the relationship changes between market regimes;
  • the backtest accidentally uses future information;
  • the signal is overfit to one market family.

The most dangerous failure is the last one: discovering a beautiful relationship that exists only inside the dataset used to discover it.

Advanced Insights

First: divergence velocity may matter more than divergence magnitude. A rapidly expanding gap describes a different market state from a stable gap.

Second: spread should be part of the signal. A theoretical six-cent edge can become meaningless if execution costs consume most of it.

Third: convergence itself contains information. Measuring how quickly divergence disappears may reveal whether the market reacts mechanically or through slower information absorption.

Fourth: market selection matters. Short-duration markets may behave differently from longer-duration markets because the relative importance of the reference window changes.

Fifth: the bot should record rejected signals. Studying signals that were filtered out can be as valuable as studying executed trades.

What This Means for Polymarket Developers

A robust Polymarket TWAP divergence bot should therefore be designed as a measurement system first and an execution system second.

Capture synchronized data. Preserve raw observations. Separate signal generation from execution. Measure spread and liquidity. Record why every signal was accepted or rejected.

The objective is not to find every difference between TWAP and Polymarket.

It is to determine which differences contain information that survives contact with the market.

Frequently Asked Questions

What is a Polymarket TWAP divergence bot?

A system that monitors differences between Polymarket market prices and a TWAP-based reference or model signal.

Is TWAP divergence automatically a trading opportunity?

No. Divergence can result from timing differences, liquidity, information shocks, or normal TWAP smoothing.

What should the bot measure?

At minimum: timestamps, market price, reference value, spread, divergence, liquidity observations, and subsequent price behavior.

Why is timestamp synchronization important?

Because comparing measurements from different effective time windows can create artificial divergence.

Should midpoint prices be used?

They can be useful for research, but midpoint should not automatically be treated as an executable price.

How should the strategy be validated?

Use historical synchronized observations and evaluate whether divergence predicts subsequent behavior after accounting for market conditions and execution assumptions.

Conclusion

The interesting part of TWAP divergence is not the gap itself.

It is the information contained inside the gap.

A serious research system asks whether divergence is temporary, persistent, accelerating, liquidity-driven, or simply an artifact of different measurement windows.

That is the difference between building another Polymarket trading bot and building a system capable of investigating a market inefficiency.

Practical next step: build the historical divergence dataset before adding automated execution.

Trading Disclaimer

Examples in this article are hypothetical and for research purposes. Past observations do not guarantee future results. Trading involves risk, and execution, liquidity, fees, model error, data quality, and changing market conditions can materially affect outcomes.

Top comments (0)