Backrunning Polymarket Resolution Events: Timing and Profitability

Resolution events are one of the few moments in prediction markets where the information advantage is zero and the execution advantage is everything. The outcome is public, deterministic, and propagates across dozens of correlated markets simultaneously — but liquidity adjusts unevenly, at different speeds, across Polymarket's own CLOB, Kalshi, on-chain USDC pools, and any structured product that references the same underlying event. That lag is the edge.

What "Backrunning" Means Here

The term is borrowed from Ethereum MEV, where a searcher appends their transaction immediately after a target transaction to capture the state change it produces. In the Polymarket context the mechanics differ but the logic is identical: you observe a resolution (or a resolution-in-progress signal) and atomically execute a sequence of trades that locks in the mispricing before the rest of the market catches up.

The canonical playbook looks like this:

• A market resolves YES. All YES tokens are now worth exactly $1.00 USDC.
• Correlated markets — "the same candidate wins the runoff," "the party holds the seat," any complement or derivative — have not yet repriced.
• You simultaneously redeem or sell the resolved market and take a position in the correlated market that the resolution now strongly implies.

The window for the correlated trade is typically 10–90 seconds in liquid markets, much longer in thin ones. Infrastructure determines which part of that window you can capture.

Resolution Signal Latency: Where the Race Starts

The naive assumption is that Polymarket's UMA-based resolution oracle is the starting gun. It is not. Resolution actually follows a sequence:

1. Dispute window close — UMA's optimistic oracle finalizes after a challenge period. For most markets this is the known timestamp.
2. Resolution transaction on-chain — a keeper calls resolve() on the CTF contract, minting or burning YES/NO tokens accordingly.
3. Gamma API update — Polymarket's indexer reflects the resolved state and updates REST/WebSocket feeds.
4. UI and downstream propagation — visible to humans.

A bot monitoring the on-chain resolution transaction directly — watching for the PositionSplit or PayoutRedemption events on Polygon — sees the resolution before the Gamma API update. That gap is usually 200–800 ms and can stretch to several seconds during Polygon network congestion. For liquid markets where the correlated trade opportunity closes fast, that is the entire edge.

Subscribe to Polygon logs filtered by the CTF Exchange contract address (0x4D97DCd97eC945f40cF65F87097ACe5EA0476045). Parse the ConditionResolution event, extract the condition ID, map it to your pre-built index of correlated markets, and fire.

The Correlated-Market Position: How to Size It

Not all correlations are equally exploitable. The useful ones share three properties:

• Causal dependency — the resolved event directly changes the probability of the correlated outcome (e.g., a primary result changes the general election probability).
• Sufficient liquidity — you need a book depth capable of absorbing your order without destroying the edge in slippage.
• Incomplete repricing — the correlated market has not yet updated. Thin markets are slow; this is where the edge is longest.

Sizing is straightforward in theory: you want to buy the correlated market up to the fair price implied by the resolution, accounting for taker fees (currently 2% of notional on winning fills on Polymarket) and expected price impact. In practice, the book moves as you trade it. A position sizing function that models price impact against the live order book snapshot — updated on every WebSocket tick — prevents you from oversizing into a market that's already moving.

For complement relationships (YES + NO = $1.00 implied), the math is exact. For probabilistic relationships, you need a calibrated model of how the resolved event updates the conditional probability. A simple Bayesian update applied to historical correlation data is usually enough; the bar is not high because you are trading against stale prices.

Atomic Execution: What It Buys You

On Polygon, true atomic cross-market execution requires a smart contract that batches the redemption of the resolved market and the buy in the correlated market into a single transaction. Without atomicity, you face execution risk: if the redemption succeeds but the correlated buy reverts (price moved, liquidity gone), you have unlocked capital but missed the trade. Worse, if you leg into a correlated short first and the redemption is delayed, you hold naked directional risk.

The contract architecture is straightforward:

function backrunResolution(
    bytes32 resolvedConditionId,
    bytes32 correlatedConditionId,
    uint256 outcomeIndex,
    uint256 maxPrice,
    uint256 size
) external {
    // 1. Redeem from resolved CTF position
    // 2. Assert minimum proceeds
    // 3. Execute limit buy on correlated market via CTF Exchange
    // revert atomically if any step fails
}

The maxPrice parameter is the kill-switch. If the correlated market has already repriced above your maximum by the time the transaction executes, the whole thing reverts — you pay gas and lose nothing else. This is non-negotiable; without it you are issuing a market order with unbounded slippage.

Gas optimization matters on Polygon because you want to be included in the earliest possible block after the resolution transaction. Dynamic gas pricing — reading the last 5 blocks' base fee and setting a priority fee 20–30% above the median — is enough for most resolution events. Polygon does not have Jito-style bundle auctions, so the lever is simply gas price and network co-location.

Infrastructure Requirements That Actually Matter

RPC latency to Polygon. Your listener and your broadcaster should connect to the same or geographically adjacent node. Alchemy and QuickNode both offer private endpoints with WebSocket support; a dedicated node co-located in the same datacenter as a major Polygon validator is the highest tier but meaningful only when you're within striking distance of the on-chain resolution event.

Pre-indexed market graph. You cannot build a correlation map in real time. Maintain an offline-computed graph of all live Polymarket markets with their dependency edges — updated nightly from the Gamma API catalog. At resolution time, a single lookup against this index returns the correlated markets and their implied fair prices in microseconds.

Order book snapshot freshness. Stale book data destroys edge. Your position sizing function should refuse to execute if the correlated market's book snapshot is more than 500 ms old. Force a fresh /book poll if the WebSocket feed has been quiet — thin markets often go minutes without a tick.

Simulation before broadcast. Run a local simulation of the full atomic transaction — redemption amount, expected proceeds, buy order fill at simulated impact — before broadcasting. A simulation that shows slippage eating all margin should abort the transaction, not submit and hope.

Realistic Profitability Numbers

On liquid correlated markets (5+ ETH in notional depth), the backrun edge per event typically falls in the 0.8–3.5¢ per share range after fees and gas, assuming you execute within the first 30 seconds of the on-chain resolution event. At $10k notional per event, that is $80–350 per resolution. High-profile events — US elections, major sports finals — may carry 10–20x that edge in the first minute, but the competition is also meaningfully thicker.

Thin markets are different. A correlated market with $500 of depth might lag by 60–180 seconds and offer 8–15¢ per share of edge, but absorbing even $1k of notional moves it 5+ cents. Profitability there is a function of how many markets you can cover simultaneously, not how much you put into each one.

Resolution frequency is the volume driver. Polymarket runs hundreds of concurrent markets; in a busy election cycle, multiple resolutions per day across correlated clusters are normal. A bot that covers all of them at moderate size beats a bot that sizes aggressively into a handful of high-profile events.

---

If you're building resolution-event infrastructure or want a production backrunner that covers Polymarket alongside your existing trading bot stack, get in touch — we've shipped these systems and can scope the build from on-chain listener to atomic contract in days, not months.