2026-11-11 / mechanisms / 8 min read

Polymarket Protocol V2 Explained: What Changes Under the Hood

Polymarket Protocol V2 replaces Gnosis's Conditional Tokens for new markets with one upgradeable ERC-1155 PositionManager, pUSD collateral, three market modules and an OracleAggregator. New markets move in phases on November 23, November 24 and December 1, 2026. Our view is that V2 lowers integration and capital costs while concentrating settlement trust in Polymarket's own keys.

Our thesis is that Protocol V2 makes Polymarket cheaper to integrate and more capital-efficient, and pays for it by moving final authority over positions, collateral and resolution from Gnosis's ownerless contract to upgradeable contracts that a single owner address can change, so the risk a trader carries on a V2 market is mostly operator risk.

What is Protocol V2?

Polymarket's protocol lead Rajath Alex announced V2 on October 5, 2026. The Block reported the design the next day: a single ERC-1155 positions contract in place of the 2019-era Gnosis Conditional Tokens Framework (CTF), pUSD collateral, a router, four initial market types (binary, atomic neg-risk, incremental neg-risk and combinatorial), and an OracleAggregator that "can plug into UMA, Chainlink, and other data sources." Six firms audited the code, and the bug bounty pays up to $5 million.

The dates moved. On October 6 the switch for new markets was tentatively November 2. Polymarket's migration guide, read on November 11, now lists three phases, all in Eastern Time:

• Monday, November 23, 8:30 AM: BNB, DOGE, HYPE, SOL, XRP and ZEC Up/Down at 5 and 15 minutes, plus three temperature markets (NYC, Warsaw, Munich).
• Tuesday, November 24: BTC and ETH Up/Down at 5 minutes, 15 minutes and 4 hours, other crypto, remaining weather, commodities, finance and minor sports.
• Tuesday, December 1: soccer, NFL and college football, basketball, tennis, esports and social count.

The guide says later phases depend on "successful trading and settlement, correct reward scoring, and sufficient liquidity in the preceding phase." Thanksgiving-week football stays on CTF. Existing CTF markets keep their contracts, and "existing CTF holdings are not converted."

What changes, before and after?

Two upgrades are easy to conflate. The first, CLOB V2, went live on April 28, 2026: new exchange contracts, a rewritten matching backend, and pUSD in place of USDC.e as trading collateral, per Polymarket's CLOB V2 guide. Protocol V2 replaces the position layer underneath. The table compares the CTF system as it runs today with V2, from Polymarket's contracts page and the V2 repository.

What backs pUSD?

Polymarket's pUSD page calls it an ERC-20 "backed by USDC" with "no algorithmic peg, no fractional reserve." The repository's collateral doc is more specific: pUSD wraps "USDC and USDCe 1:1 via an external vault," and the invariant is that the vault's combined balance is at least total supply.

We read the contracts directly at Polygon block 97,154,154, at 22:38 UTC on November 11, 2026. pUSD's total supply was 504.98 million. Its vault held 508.29 million USDC.e and 313 native USDC. The invariant held with about $3.3 million to spare. The backing is almost entirely USDC.e, which Circle describes as the "Ethereum-bridged form of USDC" that arrives through the Polygon PoS Bridge. Polymarket and Circle said on February 5, 2026 that native USDC would replace USDC.e in "coming months." On our read, that has not happened at the vault yet.

The token's owner holds rescue, which can move any ERC-20 balance held by the token contract, and controls upgrades; the onramp and offramp can each be paused per asset by an admin.

How does the oracle aggregator resolve a market?

The aggregator separates "who reports, who disputes, and who arbitrates," per the repository's oracle doc. Reporter modules vote; a result reaches proposal when reporterThreshold distinct modules agree; a liveness window opens for disputer modules; enough disputes escalate to an arbitrator. Three reporter modules are live on Polygon: UMA's optimistic oracle (OOReporterModule), Chainlink (ChainlinkReporterModule), and an EOAReporterModule for "authorized EOA addresses." The doc also says an admin "can call resolveResult() at any non-Resolved stage to force-finalize a condition," and that the operator role is "a fully trusted role."

We decoded the aggregator's event logs for the 10,000 blocks from 18:28 to 22:38 UTC on November 11. That window held 835 new resolution requests, all from the canary period:

• 433 used the UMA reporter alone, with a 300-second aggregator liveness window.
• 402 used the Chainlink reporter alone, with a liveness window of zero, which the doc says makes a proposal "finalizable in the same block and cannot be disputed."
• All 835 set the reporter threshold to 1, and every one registered 0x000000000000000000000000000000000000dEaD as both disputer module and arbitrator.

Across the wider window from 04:58 UTC on November 10 (10,873 requests), every request still used a threshold of 1. For UMA markets this changes less than it looks, since disputes still happen inside UMA's own process before its result reaches the aggregator, under the rules on Polymarket's resolution page: a bond of typically $750, a two-hour challenge period, and a token-holder vote on a second dispute. For Chainlink markets it matters more. The repository says the Chainlink module's offchain priceSource writer "is fully trusted," that the module does not verify Chainlink report signatures onchain, and recommends "reporterThreshold >= 2" in production. The canary configuration used one.

What about cross-chain positions?

The code ships a hub-and-spoke bridge on Chainlink CCIP that can move binary and neg-risk positions, pUSD and results. Polygon is the only chain that can resolve a condition; results flow outward one hop. Combinatorial positions cannot be bridged at all. Polymarket says it will activate the bridge when it expands beyond its current network, according to The Block, and neither the repository's deployed-address list nor the docs list a bridge contract as of November 11.

What does V2 mean for liquidity and market makers?

Each V2 market starts on a fresh book with new position IDs, and CTF markets keep trading until they resolve, so makers run two integrations for as long as CTF markets stay open, which for the 2028 presidential contracts means years. The contract and API guides list the work: new approvals on ExchangeV3 and PositionManager ("existing CTF approvals do not carry over"), a CONDITIONAL-V2 balance type, and choosing IDs by each market's version field. Collateral does not split, because pUSD serves both systems.

The starting point is thin. At 22:40 UTC on November 11, the 100 highest-volume open V2 markets in Polymarket's gamma API had traded $182.73 between them. The largest closed V2 market we found, a Central Park temperature contract for October 16, traded $1,158. The later phases carry the flow: sports events, split between Phase 2 (minor sports) and Phase 3, produced 48.7% of the 24-hour volume across the 1,000 open events we pulled. Our liquidity essay found that much of Polymarket's depth is paid for, which makes "correct reward scoring" the gate we would watch; the live liquidity page will show whether V2 books fill.

Combos are the clearest capital gain. Makers quote multi-leg positions through RFQ with a 400-millisecond quote window and an optional one-second last look, per the Combos docs, and a collateral-return flow merges offsetting legs back into pUSD before resolution. A leg that resolves 50/50 stays in the product, so a YES combo with one 50/50 leg pays $0.50.

What does it mean for composability?

Inside Polymarket, integration gets simpler. A position ID now encodes its module, so routing is one lookup, and split, merge and redeem go through one Router call. Neg-risk conversion moves from the Neg Risk Adapter to the Router and NegRiskModule, per the negative-risk page.

Outside Polymarket, three things narrow it. Contracts that hold positions must handle the warning that "protocol mints and unsafe transfers do not invoke ERC-1155 receiver callbacks." The owner() of PositionManager, OracleAggregator and pUSD returned the same contract address on November 11, so a protocol building on V2 positions inherits one upgrade key. And the license is BUSL-1.1 with "Additional Use Grant: None" until March 27, 2030, so no one else can run the code in production before then. Gnosis's CTF is LGPL-3.0 and has no owner.

What is the strongest case against our view?

The strongest objection is that Polymarket always held the override. The UMA CTF Adapter lets an admin flag a question and resolveManually after a one-hour safety period, and the exchange, fee and collateral layers were already Polymarket's own contracts after April. On that reading V2 makes existing trust explicit and adds structure (thresholds, per-event rules history, recorded changes) that can be tightened later without touching positions. Canary settings on markets with a few hundred dollars of volume say little about December.

We accept most of this. Our point is about where the residual guarantee sits. Under CTF, the token ledger and payout math were Gnosis code nobody could change, so even an admin-resolved market paid out under fixed rules, and the override came with a public one-hour flag. Under V2, the ledger, the payout logic, the collateral and the oracle are all upgradeable behind one owner, and the force-resolve has no delay. That is a reasonable design for a venue that wants to move fast and answer to regulators. It is a different product from a neutral settlement layer, and readers who price oracle risk should price this instead.

What would change our mind

• Production V2 events using two or more independent reporters, or a live disputer and arbitrator in place of the 0x...dEaD placeholder, once Phase 3 runs.
• A timelock or published multisig threshold on the owner address of PositionManager, OracleAggregator and pUSD, with upgrade delays long enough for holders to exit.
• The pUSD vault moving to native USDC, removing PoS-bridge exposure from the backing.
• An Additional Use Grant on the BUSL license that lets other teams build production markets on V2 positions.