Using token momentum, market structure, and TWAP timing to detect potential entries

Polymarket's move toward TWAP-based resolution changes how short-duration crypto markets can be analyzed.

Instead of simply asking:

"Is YES trading at $0.70?"

a trading system can ask:

Why did YES move to $0.70, and does the underlying market support that movement?

This is the idea behind a TWAP Momentum Price-Field Bot.

The Strategy

The bot continuously maintains a real-time state for each active market:

YES / NO price
Price momentum
Price velocity
Order-book depth
Bid/ask imbalance
Underlying price
TWAP state
Time remaining
Spread
Liquidity

The goal is to detect a directional price field where multiple signals align.

For example:

YES

0.58 → 0.61 → 0.65 → 0.68 → 0.71

Underlying:      UP
TWAP state:       UP
Order book:       Buyer-supported
Momentum:         Strong
Time remaining:   35s

Rather than buying simply because YES crossed 0.65, the bot evaluates whether the movement is supported by the broader market state.

Momentum Calculation

A basic momentum calculation can be:

momentum = current_price - price_n_seconds_ago

Velocity adds the time dimension:

velocity = (
    current_price - previous_price
) / time_difference

The system can also measure momentum persistence.

For example:

0.56
0.59
0.62
0.65
0.68
0.70

is a very different signal from:

0.61
0.66
0.62
0.67
0.63
0.65

The first sequence shows more consistent directional movement.

Example Signal

A simplified signal engine might look like:

def momentum_signal(market):

    if market.token_price < 0.65:
        return False

    if market.momentum < MIN_MOMENTUM:
        return False

    if market.momentum_duration < MIN_DURATION:
        return False

    if not market.underlying_confirms:
        return False

    if not market.twap_confirms:
        return False

    if market.spread > MAX_SPREAD:
        return False

    if market.liquidity < MIN_LIQUIDITY:
        return False

    return True

The 0.65 level is only a filter. The actual signal comes from the combination of momentum, underlying data, TWAP state, order-book conditions, and timing.

Price Field Architecture

A practical implementation can separate the system into several services:

Polymarket WebSocket
        ↓
Market State Engine
        ↓
Momentum Calculator
        ↓
TWAP / Underlying Data
        ↓
Signal Engine
        ↓
Risk Manager
        ↓
Execution Engine

The market-state engine maintains the latest information for each active slug, while the signal engine evaluates whether the current state satisfies the trading conditions.

This separation also makes backtesting and debugging easier.

Why Time Matters

The same token price can represent very different situations depending on the remaining time.

YES = 0.70

4 minutes remaining
        vs
20 seconds remaining

A momentum strategy therefore needs to include time remaining as part of the signal.

The appropriate time windows and thresholds should come from historical testing rather than being hard-coded from assumptions.

Order-Book Confirmation

Token momentum becomes more useful when combined with market structure.

The bot can monitor:

Bid volume
Ask volume
Order-book imbalance
Depth near mid-price
Spread
Recent fills
Liquidity

For example:

YES = 0.69

Bids:
0.69 → 120
0.68 → 180
0.67 → 240

Asks:
0.70 → 30
0.71 → 45
0.72 → 60

A relatively thin ask side can allow aggressive buying to move the token quickly through several price levels.

However, the bot still needs to account for slippage and the possibility that the visible book changes before execution.

Risk Management

Momentum can reverse quickly, so execution should be separated from risk management.

Important controls include:

Maximum position size
Maximum market exposure
Maximum slippage
Maximum spread
Daily loss limit
Stale-data detection
WebSocket disconnect protection
Execution timeout
Price-reversal detection

Stale-data protection is especially important. If the underlying feed stops updating while the Polymarket order book continues changing, the system should stop treating the signal as valid.

Backtesting

For each historical market, I would record:

Timestamp
YES / NO price
Underlying price
TWAP
Order book
Momentum
Time remaining
Signal
Entry price
Settlement result
Slippage
PnL

Then test different thresholds and market regimes.

The objective is not to find a perfect number such as:

YES > 0.673
Momentum > 0.084

The objective is to determine whether the signal remains robust outside the dataset used to develop it.

A useful development process is:

Historical backtest
        ↓
Market replay
        ↓
Paper trading
        ↓
Small live test
        ↓
Execution analysis
        ↓
Iteration

The Core Idea

The TWAP Momentum Price-Field Bot combines several layers of market information:

Token Momentum
      +
Underlying Price
      +
TWAP State
      +
Order-Book Structure
      +
Time Remaining
      +
Execution Quality
      +
Risk Management

The goal is not to predict every market correctly.

It is to systematically identify situations where the market is repricing quickly and determine whether that movement is supported by the underlying data and market structure.

That makes the strategy a useful framework for researching short-duration TWAP markets and building systematic trading infrastructure around them.

Explore the Code

I also maintain a Polymarket trading-bot repository for educational and development reference:

GitHub:

For development, collaboration, or technical discussion:

Telegram:
https://t.me/BenjaminCup