Complementary-Outcome Arbitrage on Polymarket Explained
How to identify and execute risk-free arbitrage when the sum of YES prices across all complementary outcomes in a Polymarket binary event falls below $1.00, including slippage and gas cost calculations.
Polymarket runs on a CLOB (Central Limit Order Book) settled in USDC on Polygon. Because each binary outcome market is independent — its own order book, its own liquidity — prices across complementary outcomes within the same event regularly drift out of alignment, and the sum of all YES prices can fall measurably below $1.00. When it does, you can buy every outcome simultaneously and lock in a guaranteed profit regardless of what resolves. The catch is execution: the edge is real but thin, and slippage plus gas will eat it alive if you are not precise.
The Core Mechanic
Take a categorical event with three mutually exclusive and exhaustive outcomes: Candidate A wins, Candidate B wins, Candidate C wins. In a perfectly efficient market, the sum of their YES prices equals exactly $1.00 because exactly one must resolve YES. In practice, you might observe:
- Candidate A YES: $0.51
- Candidate B YES: $0.31
- Candidate C YES: $0.14
Sum: $0.96. The gap — $0.04 per dollar of exposure — is your theoretical edge before costs. You buy $X of each outcome at those prices. One resolves to $1.00; the others go to $0.00. Your total outlay is $0.96X; your guaranteed return is $1.00X. That is a 4.17% return on capital deployed, risk-free on resolution — provided fills land at quoted prices.
Reading the Order Book Correctly
The quoted best-ask is not your fill price. You need to walk the order book to the depth required to fill your target size and compute a volume-weighted average price (VWAP) for each leg. If you are buying $500 of Candidate A YES at a best-ask of $0.51 but the book only has $120 sitting there and the next level is $0.535, your effective fill price shifts materially.
The corrected calculation:
edge = 1.00 - sum(VWAP_i * size_i) / total_size
Run this across all legs before committing. Any leg where liquidity is thin relative to your target size will compress or eliminate the edge. In my experience, the only markets where size matters less are major political events in the 24-48 hours post-announcement — volume spikes and depth improves transiently, but so does competition.
Gas and Protocol Costs
Polymarket on Polygon is cheap but not free. Each order submission is an on-chain transaction. For a three-leg arb:
- 3 approval transactions (if tokens are not pre-approved): negligible on Polygon at current gas, but non-zero
- 3 fill transactions: roughly 150,000-200,000 gas per conditional token trade at current contract versions
- Polygon gas at 30-60 gwei means each fill leg costs $0.01-0.04 at typical conditions
Total round-trip cost for a three-leg trade: call it $0.10-0.15 in gas at conservative estimates. On a $500 position with 4% theoretical edge, your $20 gross profit absorbs that comfortably. On a $50 position, it is already 0.2-0.3% of capital — start shrinking the edge to 1-2% and small size stops making sense.
The practical minimum edge threshold before touching a trade: 1.5% after estimated slippage, with a hard floor of 0.5% remaining after gas. Below that, execution variance will put you underwater on average.
Timing and Latency Constraints
These opportunities do not sit open waiting for you. The better ones close in under 60 seconds as other bots detect them. You need:
- A WebSocket subscription to Polymarket's order book feed — polling REST is too slow
- Pre-signed transactions ready to broadcast the moment conditions are met — signing on-the-fly adds 200-500ms you cannot afford
- A simulation step that re-checks VWAP on current book state immediately before broadcast, so you do not send a transaction into a market that moved
The simulation-before-broadcast step is non-negotiable. I have seen arb legs get lifted between detection and submission often enough that skipping this check leads to partial fills that leave you long a single outcome at a price that no longer makes sense.
Handling Partial Fills and Leg Risk
What happens when two legs fill and the third does not? You are now net long one or two outcomes at a known cost basis — no longer risk-free, now directional. Your system needs a fill-or-cancel (FOC) approach or a compensating hedge. Polymarket's native order types as of current contract versions do not give you true atomic execution across legs. You must implement your own session-level atomicity: if any leg fails or partially fills beyond your tolerance threshold, immediately submit a market-sell on the filled legs to flatten the position. Accept the small loss; do not hold directional exposure hoping to re-leg.
The trading bots we build at TierZero handle this with a state machine that tracks leg status, triggers the unwind logic automatically, and logs every partial fill with the realized P&L so the edge model can be calibrated over time.
Sizing and Capital Efficiency
Because one leg always pays out at $1.00 and the rest go to zero, your gross capital requirement is the sum of all leg notionals. For a $0.96-sum market, you deploy $0.96 to earn $1.00. Capital turnover is high if you are catching multiple events, but each individual trade ties up 100% of the position notional until resolution — which can be days or weeks on political markets.
The implication: prioritize short-resolution markets. A binary event resolving within 48 hours with a 2% edge is more capital-efficient than a 4% edge on a market resolving in three months. Annualized returns on the former can be an order of magnitude higher.
If you want this running in production — order book feed, pre-signed transactions, fill tracking, and automatic unwind logic — talk to the team.
Need a bot like this built?
We design, build and run trading bots on Solana, Hyperliquid and Polymarket.
Start a projectMore from the blog
Public vs Paid RPC: How to Run a Fair Benchmark
A fair comparison of public and paid RPC endpoints must account for quotas, workload, freshness and support guarantees.
Read articleRPC Benchmark Percentiles Explained: p50, p95 and p99
Why averages hide the latency spikes that break trading bots, wallets and production blockchain applications.
Read articleHyperliquid REST vs WebSocket Benchmark: What to Measure
A benchmark plan for Hyperliquid market data that separates request latency from streaming freshness and recovery.
Read article