Polymarket Neg-Risk Adapter: Split/Merge Arbitrage Mechanics

The neg-risk adapter is Polymarket's answer to a specific accounting problem: in a multi-outcome market like "Who wins the 2024 election?", the YES tokens across all candidates should sum to exactly $1, but the order books almost never enforce that. When they drift apart, a bot can mint or redeem a full set of outcome tokens for a guaranteed $1 and pocket the difference. This article walks through the exact contract calls that make that trade work, and the gas math on Polygon that decides whether the edge survives to settlement.

What the neg-risk adapter actually is

Polymarket binary markets sit on Gnosis's Conditional Tokens Framework (CTF). A single binary market is one conditionId with two outcome slots — YES and YES-complement. Splitting 1 USDC against that condition gives you 1 YES and 1 NO token, and merging them back returns your USDC. Clean, but it only covers one question.

Multi-outcome markets ("negative risk" markets) are a bundle of N independent binary conditions glued together by the NegRiskAdapter contract. Candidate A is its own conditionId, candidate B is another, and so on. The adapter's job is to let you treat "NO on A, NO on B, … NO on N" as economically equivalent to "YES on everybody else," and to guarantee that exactly one outcome resolves YES at settlement. That last guarantee is the whole point: it's what makes the sum-of-YES-equals-one invariant real rather than aspirational.

The adapter exposes three operations you care about: split, merge, and convert. Split and merge are the CTF primitives wrapped so they route USDC correctly. Convert is the neg-risk-specific one, and it's where most of the interesting arbitrage lives.

The three calls

Split. You send collateral, you get a full set of outcome tokens for one condition.

// via NegRiskAdapter — splits `amount` USDC on one marketId
// into complete YES/NO position for that outcome
negRiskAdapter.splitPosition(marketId, amount);
// you now hold `amount` of each of the 2 CTF tokens

Merge. The inverse. Hand back a complete set, get your USDC.

negRiskAdapter.mergePositions(marketId, amount);
// burns equal YES+NO, returns `amount` USDC

Convert. This is the multi-outcome trick. You hand the adapter NO tokens for a subset of the market's outcomes, and it returns YES tokens for every other outcome plus USDC change. If a market has 5 candidates and you deposit 1 NO token for candidate A, convertPositions gives you back 1 YES token for B, C, D, and E, because "A does not win" plus the neg-risk guarantee implies exactly one of the others does.

// indexSet is a bitmask of the outcomes you're converting NO on
negRiskAdapter.convertPositions(marketId, indexSet, amount);

The convert path is what lets you cross between the "buy NO on the favorite" book and the "buy YES on the field" book without ever touching a centralized matching engine.

Where the mispricing shows up

Sum-of-outcomes drift is the signal. Pull the best ask for YES on every outcome in the market. Add them. Three cases:

• Sum > $1.00. The YES side is collectively overpriced. Split 1 USDC into a complete set of NO tokens (buy the field cheaply through split/convert), then sell the YES legs into their books. The gap above par is your gross edge.
• Sum < $1.00. The field is underpriced. Buy one YES of each outcome for less than a dollar, hold to resolution, redeem the winning one for exactly $1. This is the patient version — no counterparty needed at exit, but you eat resolution latency.
• Sum ≈ $1.00. No trade. Move on.

The convert call collapses what would otherwise be N separate on-book fills into a single mint. That matters because every leg you'd otherwise sweep on-book carries its own slippage and its own signature. I've written before about why exit paths and position bookkeeping deserve as much attention as entry logic in a trading bot's order state machine — neg-risk arb is a textbook case, because a convert that lands while three of your five on-book sells are still pending leaves you with a half-formed position and no clean unwind.

A worked example

Say a 4-candidate market shows these best YES asks: A $0.46, B $0.30, C $0.18, D $0.10. Sum = $1.04. Four cents rich per complete set.

Your bot's move:

1. splitPosition 1,000 USDC on the market → you hold NO tokens across the structure.
2. Use convertPositions to shape the inventory into 1,000 YES of A, B, C, D.
3. Market-sell each YES leg into its book at the quoted asks.
4. Gross proceeds ≈ $1,040 on $1,000 in. Edge ≈ $40 before costs, before slippage.

Now subtract reality. Those asks have depth. Sweeping 1,000 units of D at $0.10 might clear the top three price levels and leave you filling the tail at $0.13. Half your edge can evaporate in the thin leg. The favorite leg is usually deep; the longshots are where you get hurt. A serious bot sizes each leg to available depth, not to a uniform notional — this is exactly the kind of constraint that belongs in the spec before a line of code gets written, which is why we push clients through a real scope-of-work process instead of coding to a vague "arb Polymarket" ask.

The gas math that decides the trade

On Polygon this arb is gas-bound at the margins, not gas-free. Rough per-op costs (they move with calldata and storage writes):

• splitPosition: ~150k–200k gas
• convertPositions: ~120k–250k gas, scaling with the number of outcomes in the index set
• each on-book fill: a CTF ERC1155 transfer plus exchange bookkeeping, ~80k–150k gas per leg

A 4-leg unwind can run 700k–900k gas end to end. At 100 gwei and MATIC around $0.50, that's on the order of $0.04–$0.05 total — trivial against a $40 edge. But Polygon gas is spiky. During congestion I've seen the priority fee needed to land in the next block spike 10–20x for minutes at a time. At 1,500 gwei your 800k-gas round trip is closer to $0.60, and if your edge was two cents on a small set instead of four cents on a thousand-unit set, the trade is now underwater before slippage.

Two rules I'd bake in:

• Price gas into the edge threshold, per block. Don't trade a fixed "2% gap" trigger. Trigger on gross_edge − (gas_units × current_base_fee × matic_usd) − expected_slippage > min_profit. Recompute current_base_fee every block; Polygon's base fee updates fast.
• Bundle where the contract allows it. Split-then-convert in one transaction beats two round trips on both gas and race exposure. Every extra transaction is another block where the books can move against you.

There's also the resolution-risk tail on the "sum < $1" patient trade. You're holding a full set to redemption, which means your capital is locked until the UMA oracle resolves and someone calls redeemPositions. If the market resolves ambiguously or gets disputed, that "guaranteed $1" is guaranteed eventually, not guaranteed soon. Size that trade against your cost of capital, not against the headline spread.

What actually makes this run in production

The mechanics are the easy 20%. The hard 80% is: a mempool watcher that recomputes the outcome sum every block, depth-aware leg sizing, a gas oracle wired into the trigger, and an execution layer that treats a partial fill as a first-class state rather than an exception. Multi-outcome markets on Polymarket are shallow enough that two bots chasing the same 3-cent gap will collapse it inside a block, so latency and clean partial-fill handling decide who actually books the edge. If you want the market-microstructure side handled well, the same discipline shows up in adjacent venues — the constraints we work through building a Polymarket spread bot and a Hyperliquid market maker are the same family of problems: quote off a fair value, size to depth, and never trust a fill until it's confirmed.

If you're scoping a neg-risk arb bot and want a straight read on whether your edge survives Polygon gas and thin longshot books, a strategy consultation is the cheapest way to find out before you build.