Polymarket Spread Bots: Locking the YES+NO Mispricing

Prediction markets run on a simple constraint: for any binary outcome, the price of YES plus the price of NO must equal $1.00. On Polymarket, both sides trade as ERC-1155 tokens against a USDC CLOB, and in a perfectly liquid market that sum never strays. In practice it strays constantly — during news spikes, when one side runs thin on the order book, or when retail flow piles into one leg faster than market makers can hedge. A polymarket spread bot exists to exploit exactly those moments: buy the cheaper leg, buy the more expensive leg simultaneously, and lock in the difference as riskless (or near-riskless) profit regardless of which way the event resolves.

Why the YES+NO Sum Drifts

Polymarket's CLOB processes each side independently. A sudden event — a breaking court ruling, a surprise poll — can sweep the YES asks in milliseconds while NO bids sit untouched. The sum briefly reads 0.97 or 1.05 instead of 1.00. Three cents on a $50,000 notional position is $1,500 captured in a single fill. The window is typically 50–400 ms before competing bots close it.

The structural mispricings that last longer (seconds rather than milliseconds) come from inventory skew. A market maker who is long YES after a large retail buy may widen the NO spread to reduce risk, leaving the combined mid above par. Your bot benefits from that skew without needing to guess direction.

A third, slower class of mispricing appears near resolution: markets that should already be settled at $0.00 or $1.00 can trade off fair value for minutes after the oracle posts its answer, because not all participants monitor the resolution feed in real time.

Core Architecture of a Spread Bot

Data layer. Subscribe to Polymarket's WebSocket order-book feed for both legs simultaneously. You need co-located, low-latency connections — even a 20 ms lag in the YES feed means you might fill YES at a price that has already moved by the time the NO order lands. Many production bots also tap a geyser-style event stream for on-chain fills to detect when large orders have cleared the book before the WebSocket update propagates.

Signal logic. At each tick, compute best_ask_YES + best_ask_NO. If the sum is below a configurable threshold (e.g., 0.994 to account for 0.3% taker fees per leg), flag a buy-both opportunity. Conversely, if best_bid_YES + best_bid_NO exceeds 1.006, flag a sell-both opportunity. The threshold is not a fixed number — it must account for:

• Taker fee on each leg (currently 0.2–0.5% depending on volume tier)
• Estimated gas or priority fee for the on-chain settlement
• Slippage from partial fills if the desired size exceeds the top-of-book liquidity

Execution. Both legs must be submitted as close to simultaneously as possible. A common pattern is to optimistically submit both limit orders at the ask and monitor for partial fills. Because Polymarket settles via the Polygon network, priority fees matter: underprice gas and your order sits in the mempool while a competing bot fills ahead of you. Some implementations batch both legs into a single multicall transaction to reduce execution risk.

Inventory management. A leg that fills without its counterpart is not riskless — it is a directional position. Your bot needs a position reconciliation loop that runs every 100–500 ms and either places a corrective order on the unfilled leg or cancels both. Hard inventory limits (e.g., max $500 net exposure per market) and a kill-switch that halts all activity if net exposure exceeds a threshold are non-negotiable in production.

Risk Factors You Cannot Ignore

• Resolution risk near expiry. If a market is seconds from resolving, filling both legs locks your capital until the contract settles. Avoid markets with fewer than five minutes to resolution unless you have explicit handling for that case.
• Fee creep. Gas spikes on Polygon can turn a profitable signal into a net-negative fill. Simulate the full round-trip cost — including the USDC withdrawal from the CLOB — before sizing any order.
• Anti-rug / simulation. Before going live, replay historical order-book snapshots against your signal logic to verify it does not trigger on stale data or self-generated fills. Production bots should also run a shadow mode that logs signals without executing, so you can audit fill rates and false positives.
• Correlated markets. Some Polymarket events are economically linked (e.g., two candidates in the same election). Capturing a spread in one market while holding inventory from a correlated market can create hidden directional risk that your per-market exposure limits will not catch.

For a worked example of how these principles apply across venues, see the cross-venue arbitrage case study, which covers order-book synchronization and latency budget allocation in detail.

Our trading-bot services cover the full stack from signal design to on-chain execution, including custom priority-fee tuning and position reconciliation loops built for Polymarket's specific settlement mechanics.

---

If you want a production-grade polymarket spread bot — or need an existing prototype stress-tested against real order-book data — start a project with TierZero. We scope and ship fast.