Backrunning Polymarket Resolutions: MEV on Prediction Markets

Backrunning Polymarket resolutions is one of the cleaner MEV opportunities in prediction markets: the settlement transaction is public, the affected books are identifiable in advance, and the mispricing you are chasing is mechanical rather than probabilistic. But "cleaner" does not mean easy. The window is measured in seconds, Polygon's gas market is non-trivial to navigate, and the competition from other searchers is real. Here is how the opportunity works, what the stack looks like in practice, and where capture rate bleeds away.

How Polymarket Settlement Creates a Backrunnable Event

Polymarket runs on Polygon PoS. When UMA's Optimistic Oracle finalises an assertion, a resolver calls the CTF Exchange or the Neg-Risk Exchange contract to settle the relevant condition. That transaction sets the winning outcome token to redeemable at $1.00 and worthless tokens to $0. The transaction is submitted to the public Polygon mempool before it mines.

Two things happen simultaneously once the tx confirms:

1. Related markets misprice. If "Will the Fed cut in September?" resolves YES, every correlated market — "Will there be two cuts before year-end?", "Will the 10Y yield drop below 4%?" — may still be quoted at stale odds. The book does not auto-reprice; individual market-makers have to pull and reprice their own quotes.

2. Redemption arbitrage opens. Anyone holding the losing-side token bought below zero (i.e., at a non-zero price because the book had not yet digested the outcome) can now redeem the winning token they flipped into from a complementary-outcome arb, locking the payout.

The backrun target is the second tx in the block after the resolution, or the first tx in the next block if your submission arrives late.

The Dependency Graph You Need to Pre-Build

Reactive scanning after a resolution confirms is too slow. The profitable approach is to pre-map every market's resolution dependencies before you need them.

The data work happens off the hot path:

• Pull the full market catalogue from Polymarket's CLOB API and gamma endpoint daily.
• Parse the question and description fields to cluster markets by underlying event, asset, and condition type.
• For each cluster, compute a directional sensitivity vector: if market A resolves YES, does market B's fair value move up or down and by how much?
• Persist this graph so that at resolution time you can do a single key lookup — market ID → list of (market, direction, estimated delta) — rather than reasoning from scratch.

The graph is also where you encode correlated-outcome structures: a multi-outcome market (e.g., "Final rate: 4.25% / 4.50% / 4.75%") where resolving one leg immediately prices the others. These are often the tightest edges because the relationship is exact, not estimated.

Latency Requirements on Polygon

Polygon PoS blocks target 2 seconds. The resolution transaction mines, and the next block is 2 seconds away. In that 2-second window you need to:

1. Detect the resolution tx in the new block (subscribe via newHeads + eth_getBlockByNumber with full tx objects, or use a logs subscription on the CTF Exchange address).
2. Evaluate your pre-built graph for affected markets.
3. Fetch current CLOB quotes for each affected market (cached from a continuous subscription, not a fresh HTTP call).
4. Compute order sizes respecting fee-adjusted break-evens.
5. Sign and submit your CLOB API orders.

The CLOB layer is off-chain (a centralised order book with on-chain settlement), so you do not need to construct an on-chain bundle for the order placement step — you submit REST calls. This is both a gift and a constraint: you cannot atomically bundle the entire sequence, and the CLOB can reject or queue your order. What you can bundle on-chain is a direct CTF redemption transaction if you already hold the winning token, or a proxy contract call for more complex settlement paths.

Realistic end-to-end latency budget: 200–400 ms from block mining to order landed in the CLOB. Beyond ~600 ms you are filling into a book that faster participants have already repriced.

Polygon Gas Dynamics and Priority

For any on-chain component of your strategy (redemptions, direct contract calls, keeper transactions), Polygon's EIP-1559 gas market sets the cost floor. A few specifics matter:

• Base fee volatility. Polygon's base fee can spike 10–20x in a single block during congestion. Keep a rolling estimate of the 90th-percentile base fee and use it as your floor rather than the current base fee.
• maxPriorityFeePerGas sizing. On Polygon, validator tips are smaller relative to Ethereum mainnet, but they still matter for ordering within a block. A 30–50 Gwei tip is typically sufficient to land in the first quartile of a block. During busy settlement events, raise this to 80–100 Gwei.
• Gas limit. If your on-chain path involves CTF redemptions, benchmark the gas cost per token type in advance. Over-estimating costs you in tip calculation; under-estimating causes reverts.

Because the CLOB itself is off-chain, the gas cost of on-chain settlement is separate from the cost of winning the order queue. Do not conflate them. The CLOB race is won by HTTP latency; the on-chain race is won by fee calibration.

Sizing the Edge and Where It Leaks

The gross edge on a correlated-market backrun is typically 1–5 cents per dollar of notional on the most liquid correlated markets — larger on thin books. But several factors compress the net:

• Taker fees. Polymarket's CLOB charges taker fees. A 3c gross edge on a 2c taker fee gives you 1c. Know your fee tier; fee tiers change with volume.
• Market-maker reaction. Good market-makers pull their quotes on a resolution event within 1–3 seconds. If your order lands at second 2.5, you may fill a stale quote. If it lands at second 4, the book has already repriced and your "edge" is gone or reversed.
• Partial fill risk. Thin books may not have enough size at the mispriced level to fill your full order. Sizing into illiquid markets against a stale quote is the fastest way to manufacture a loss.
• Correlation estimation error. Your pre-built sensitivity vectors are estimates. A resolution that carries unexpected information (e.g., a ruling that implies something your model did not anticipate) can move prices in surprising directions. Keep position limits per cluster.

In practice, the reliably profitable path is the exact correlated-outcome arbitrage — where one leg's resolution mathematically constrains another — rather than soft correlation plays. The edge is smaller but near-certain; the soft plays require better models than most participants have.

What a Working Stack Looks Like

The production architecture for this strategy has five components:

• Resolution monitor. A persistent WebSocket subscription to the CTF Exchange and Neg-Risk Exchange contracts on Polygon. Parses ConditionResolution and equivalent events in real time, no polling.
• Market graph store. A Redis hash keyed by market condition ID, updated nightly from the Polymarket API. Lookup is O(1).
• Quote cache. A background process subscribed to CLOB WebSocket feeds for all markets in the graph. Keeps the last mid, best bid, best ask and timestamp in memory. Stale quotes (> 5 s old) are flagged and skipped.
• Execution engine. Takes the resolution event, pulls affected markets from the graph, checks quote freshness, computes fee-adjusted sizes, and fires REST orders concurrently via Promise.all. Total compute: < 50 ms.
• On-chain settler. Optional — only active if the strategy holds winning tokens that need redemption. Submits via a private RPC endpoint with pre-calibrated gas parameters.

For teams already running a Polymarket arbitrage or market-making bot, the resolution-backrun layer fits as an additional strategy module, not a standalone system. The quote cache and market catalogue are shared infrastructure.

---

If you want to ship a Polymarket resolution-backrun strategy in production — graph pre-building, CLOB execution and on-chain settlement included — get in touch. The first conversation is always a technical scoping call, not a sales pitch.