Starting August 7, 2026, 00:00 UTC, Polymarket's short-duration crypto up/down markets (5-min, 15-min, 4-hour) stop resolving on a single price snapshot at expiry and start resolving on a Time-Weighted Average Price (TWAP) - a 30–60 second window depending on market duration. This closes a real, quantified manipulation exploit and changes what "the right prediction" even means for anyone running a bot against these markets.
The problem: point-in-time resolution is a single point of failure
Polymarket's crypto up/down markets ask a simple binary question: will an asset's price be higher or lower at the end of a window than it was at the start?
Until now, the answer came from one price observation - whatever the oracle read at the exact expiry timestamp. That single number could decide a market with real money on both sides, which creates an obvious incentive: if you can influence the price at that one instant, you can influence the outcome, regardless of what the asset actually did for the rest of the window.
This is the same class of problem DeFi has dealt with for years with naive spot-price oracles - a single observation is trivially manipulable if you have enough capital to move it, even briefly. The 5-minute contracts alone did $4 billion in cumulative volume, with an estimated $7.6 million in losses attributable to exactly this kind of manipulation - a well-capitalized trader pushing the price in the final seconds, collecting the payout, and leaving other participants holding the loss.
The fix: TWAP resolution
Instead of:
resolution_price = price(T_expiry)
the contract now computes:
resolution_price = (1 / W) * Σ price(t_i) * Δt_i for t_i in [T_expiry - W, T_expiry]
where W is the averaging window and the sum is over sampled ticks weighted by how long each was valid - a standard discretized TWAP.
Window length scales with market duration, but not linearly:
| Market duration | TWAP window |
|---|---|
| 5 minutes | 30 seconds |
| 15 minutes | 60 seconds |
| 4 hours | 60 seconds |
The fact that a 4-hour market gets the same 60-second window as a 15-minute market is the tell: the window isn't sized proportionally to market length, it's sized to the minimum duration needed to make a manipulation attempt capital-inefficient. To move a TWAP over even 60 seconds on a liquid asset, you have to sustain a price deviation the whole time-during which arbitrageurs can (and will) trade against you - instead of just winning one lucky/paid-for tick.
Infrastructure behind it
The price feed itself comes from Chainlink Data Streams, delivered through Polymarket's own Real-Time Data Streaming (RTDS) layer. Testnet TWAP feeds are already live; mainnet feeds and RTDS delivery launch August 4 - three days before markets actually start resolving on it, giving integrators a short live-fire testing window before it's load-bearing.
Chainlink Data Streams is a pull-based, low-latency oracle product - distinct from Chainlink's older push-based Price Feeds - built for exactly this kind of high-frequency settlement use case. That's what makes sub-minute TWAP windows computationally practical for on-chain resolution.
Polymarket is also putting $1M in liquidity rewards across affected markets through August to keep spreads/depth healthy while market makers recalibrate their models - pricing a TWAP-resolved market means modeling the average price path into the close, not just the terminal price, which is a different risk than what they were quoting before.
Why build it this way
Three overlapping motivations:
- A quantified exploit, not a theoretical one - the losses were measurable.
2.Consistency with the platform's core value proposition. A prediction market's whole pitch is an honest, continuously updated price consensus. Resolving on one exploitable tick undermined that at the exact moment it mattered most - settlement.
3.Competitive pressure. Competitors like Kalshi have more robust settlement mechanisms, and the manipulation losses gave them a concrete talking point for institutional users.
What actually breaks in a trading bot
Strategy logic
Any edge that depended on influencing or predicting a single terminal tick is dead. The prediction target itself changes - from a point value (price(T_expiry)) to a path integral (mean(price(t)) over the window). This structurally favors:
Short-horizon momentum/mean-reversion models that output a distribution, not a point forecast
Volatility-aware sizing - variance of an average over W seconds is lower than variance of a single tick, so the "one random print decides everything" tail risk shrinks
Data ingestion
Last-trade price is no longer enough. You need the same input the resolution oracle uses: a continuous or high-frequency tick series over the TWAP window, from Chainlink Data Streams or Polymarket's RTDS WebSocket. Store raw ticks, not pre-averaged numbers - you'll want to reconcile your own computation against the published resolution price. Latency budget also tightens: with a 30-60s window, you need low-latency coverage of the whole window, not just a fresh final read.
Backtesting
Hard regime split required - tag every historical market pre-Aug-7 (snapshot) vs post-Aug-7 (TWAP) and never pool them. Pre-Aug-7 backtests will systematically overstate the value of last-second timing tactics that no longer work. Note also: historical TWAP can't be reconstructed retroactively unless you were independently logging tick data before the feed existed - Polymarket's old resolutions used the snapshot, full stop.
Execution/risk modeling
Don't calibrate long-term slippage assumptions on August data - the $1M rewards pool will temporarily tighten spreads/depth.
Since resolution is now a smoothed average, the tail risk of "the market flips on one random print" near expiry is reduced - worth revisiting position-sizing rules for the closing window specifically.
Model the closing window as a short-horizon stochastic process (a volatility model sized to the specific TWAP window), rather than treating expiry as a single random draw.
Monitoring
Reconcile your own tick-based TWAP calculation against Polymarket's published resolution price during the transition - first against testnet, then against mainnet from Aug 4–7 before it's load-bearing. Add explicit handling for feed gaps/stale ticks within the averaging window; these are new failure modes that simply didn't exist under single-tick resolution.
Closing thought
This is the same principle DeFi has used against flash-loan-style oracle manipulation, applied here to prediction-market settlement: average over a window instead of trusting an instant. It's a genuine integrity fix, and for anyone building against these markets, the honest response isn't to mourn a dead exploit - it's to rebuild the data pipeline and prediction target around what actually decides outcomes now.
The $7.6M loss figure and related characterizations come from crypto-news coverage of Polymarket's announcement, not a Polymarket-published number - treat it as a reported estimate.
Top comments (0)