Polymarket negRisk Adapter Explained: Multi-Outcome Markets

{"excerpt":"Polymarket negRisk explained: how the NegRiskAdapter contract links binary CTF conditions so multi-candidate markets can't double-pay or leave every outcome resolved NO.","tags":["Polymarket","negRisk","Smart Contracts","Prediction Markets","Solidity"],"cover":"nodes","content":"A Polymarket market with five candidates isn't one contract with five outcomes. It's five separate binary conditions, each minting its own YES and NO tokens, wired together by a piece of infrastructure most traders never look at: the NegRiskAdapter. If you're building anything that touches multi-outcome markets — a market maker, an arb bot, a settlement watcher — you need to understand this contract, because it's the thing standing between "exactly one winner" and a market that can silently pay out twice.\n\n## The primitive underneath everything: Gnosis CTF\n\nPolymarket is built on the Gnosis Conditional Tokens Framework (CTF). A "condition" is identified by conditionId = keccak256(oracle, questionId, outcomeSlotCount). For a simple yes/no market, outcomeSlotCount is 2, and an oracle address (Polymarket's UMA-backed resolver) eventually calls reportPayouts([1,0]) or [0,1] to settle it. Collateral gets split into outcome tokens with splitPosition and merged back with mergePosition; winners redeem 1:1 against USDC.\n\nThis works cleanly for a binary question like "Will the Fed cut rates in September?" It does not work cleanly for "Who wins the Republican primary?" with eight candidates, because CTF's native multi-outcome support means one condition with eight slots, one oracle report, and — critically — a market structure that doesn't compose well with Polymarket's per-outcome order books and per-outcome liquidity.\n\n## Why N independent binary markets isn't a shortcut\n\nThe naive fix is to spin up eight separate binary conditions — "Will candidate A win: yes/no", "Will candidate B win: yes/no", and so on — each with its own oracle resolution. That gets you separate order books per candidate, which is what you actually want for UX and liquidity. But it breaks the invariant that makes the market meaningful: nothing at the contract level stops two of those conditions from both resolving YES, or all eight resolving NO. Independent UMA resolutions have no awareness of each other. A data dispute, a stale price feed, or just a sloppy resolver call on one leg can produce a state where the sum of "the field" doesn't equal exactly one winner. In a market handling real settlement volume, that's not a rounding-error problem — it's a double-payout or a stuck-collateral problem, and it's the kind of bug you generally only find in production, at the worst possible time. For background on how those individual resolutions get finalized in the first place, see our breakdown of how the UMA optimistic oracle resolves Polymarket markets.\n\n## What the NegRiskAdapter actually does\n\nThe NegRiskAdapter sits between the individual CTF conditions and UMA. Instead of UMA reporting payouts directly to each condition, it reports to the adapter, and the adapter is registered as the oracle on every condition in the group (grouped by a shared negRiskMarketId). That indirection is the whole trick:\n\n- Each candidate still gets its own conditionId, its own YES/NO position pair, and its own order book.\n- When UMA settles one outcome as the winner, the adapter doesn't just report that single condition — it also drives every other condition in the same group to NO, in the same logical resolution path.\n- The mutual-exclusivity guarantee moves from "traders and arbitrageurs enforce this via trading" to "the contract enforces this structurally." That's the actual meaning of the name: it removes (negates) the tail risk of the field paying out inconsistently.\n\nThis is also why negRisk markets can't add or remove candidates mid-market — questionCount and the outcome set are fixed at group creation, because the adapter's resolution fan-out logic depends on knowing the full set upfront.\n\n## The other half: converting NO sets into YES without touching the oracle\n\nHere's the part that matters for anyone trading these markets programmatically. In a mutually exclusive, exhaustive market, holding NO on every outcome except one is economically identical to holding YES on that remaining one — exactly one candidate wins, so "everyone but E loses" and "E wins" are the same statement. The adapter exposes this directly: convertPositions lets you hand over a complete set of NO tokens (all outcomes but one) and receive YES tokens for the remaining outcome, 1:1, in a single transaction, with no oracle call and no waiting for market resolution.\n\nWorked example. A five-candidate market — A, B, C, D, E — is trading with NO prices roughly at $0.85, $0.90, $0.92, $0.88 for A–D (meaning the market thinks each is fairly unlikely to win) and YES_E around $0.30. Suppose you can buy NO_A, NO_B, NO_C, NO_D for a combined cost under $1.00 — say $0.92 average blended, roughly $3.68 for the four-leg basket. Converting that basket yields one YES_E token:\n\n\n// pseudo-code, actual call takes conditionId array + amount\nnegRiskAdapter.convertPositions(\n negRiskMarketId,\n indexSetExcluding(E), // NO_A, NO_B, NO_C, NO_D\n amount\n);\n// returns YES_E tokens 1:1, no redemption wait\n\n\nIf YES_E is trading above what your NO basket cost you, converting and selling YES_E is a same-block arbitrage with no directional risk on the outcome itself — you're arbitraging internal consistency, not predicting the winner. This is precisely the kind of mechanical edge that a well-built Polymarket arbitrage bot is designed to catch continuously across every negRisk group on the platform, since the mispricing windows are usually seconds, not minutes.\n\n## Where this meets the order book\n\nNegRisk markets trade through a variant exchange contract (the CLOB matching engine integrates directly with the adapter) rather than the plain CTFExchange used for simple binary markets, because order matching sometimes needs to mint or convert inventory on the fly to fill a taker order without every maker holding a full NO basket. If you're not already familiar with how Polymarket's central limit order book differs from AMM-style prediction markets, that's worth reading before you go further — see our comparison of CLOB versus AMM designs for prediction markets. For market makers specifically, this changes inventory management: quoting five correlated order books means your hedge isn't just "buy the opposite side," it's managing a basket position that can be converted, which is exactly the kind of logic we build into custom Polymarket market maker systems rather than leaving it to manual spreadsheet tracking.\n\n## The tradeoffs that don't make it into the docs\n\nA few things worth knowing before you build against this:\n\n- Centralization of trust moves, it doesn't disappear. The adapter is now the oracle of record for every leg in the group. A bug or compromised resolution path in the adapter is a group-wide failure, not a single-market failure — worse blast radius than isolated binary markets, even though the everyday trading experience is safer.\n- Fixed outcome sets. You can't add a late-entry candidate after the group is created. Real-world events that add participants (a new candidate entering a race) need a fresh market or a reserved "field/other" slot from day one.\n- Gas cost scales with N. Converting or splitting a full basket touches every outcome's position, so an eight-candidate group costs meaningfully more gas per conversion than a two-outcome market. Bots doing this at volume need to budget for that, and it's one more reason execution speed and gas efficiency matter more here than in a simple Polymarket spread bot running on a single binary market.\n\nIf you're evaluating whether to build execution infrastructure against Polymarket's multi-outcome markets versus a fixed-payout venue like Kalshi, the mechanics above are a big part of that decision — we cover the practical differences in Polymarket versus Kalshi for algorithmic traders.\n\nUnderstanding convertPositions and the adapter's resolution fan-out isn't optional if you're trading negRisk markets at any size — it's the difference between a bot that catches basket mispricings in one transaction and one that's still redeeming legs one at a time after the opportunity's gone. If you want that logic built and battle-tested rather than reverse-engineered from a block explorer, our team builds exactly this class of Polymarket arbitrage bot."}