Polymarket has started rolling out Protocol V2, a rebuilt smart-contract system that replaces the framework it has run on since 2019, with new markets tentatively moving to the new infrastructure on November 2. A handful of live canary markets are already trading on the new contracts through October 30 as a testing phase.
The platform’s existing base, the Conditional Tokens Framework, is built on code Gnosis wrote in 2019 for general-purpose use. Each market type Polymarket later shipped required another contract added in front of it: separate adapters for collateral, wrapped tokens for neg-risk markets, and a second exchange for a second market type. Rajath Alex, the company’s head of protocol, described the rebuild as a system designed, in his words, “from the position token up.”
What changes
Protocol V2 consolidates the stack into one ERC-1155 position-token contract, one collateral token, one exchange and one router. Every position ID now encodes the market’s type, identity and outcome directly, so the protocol can read that information without separate storage lookups. Four market types are live at launch: binary, atomic neg-risk, incremental neg-risk and combinatorial.
Collateral is Polymarket USD, or pUSD, a token the platform introduced in April, backed one-to-one by Circle’s USDC held in a dedicated vault. Resolution moves through a new OracleAggregator with plug-in modules for different oracle sources, including UMA and Chainlink, instead of a single fixed resolution path.
Upgradeable UUPS proxies allow the contracts to be changed through a governance process described by Polymarket as a secure process, without redeploying the whole system. That reduces the maintenance cost of adding new features later, a recurring problem in a stack where every market type had required its own additional contract. Cross-chain movement of positions, collateral and resolution data is built into the codebase using a bridge based on Chainlink CCIP, although Polymarket has not announced when that feature activates or which networks beyond Polygon it will support. Combinatorial positions will need to be rebuilt on a target chain rather than transferred directly.
| Element | Old system | Protocol V2 |
|---|---|---|
| Positions contract | Conditional Tokens Framework (2019) | Single ERC-1155 PositionManager |
| Collateral | USDC through adapters | pUSD, backed 1:1 by USDC |
| Exchanges | Separate per market type | One exchange, all market types |
| Resolution | UMA | OracleAggregator, pluggable modules |
| Cross-chain | None | Chainlink CCIP bridge, activation pending |
Existing bets stay where they are
The rollout does not convert anything automatically. Migration guides warn that positions held under the older Conditional Tokens Framework remain on the old ledger, and moving them to the new PositionManager requires a separate, registered migration that Polymarket must initiate first. App and website users do not need technical steps, although they may be asked to approve new contracts when trading.
For trading integrations the work is heavier. Bots and third-party interfaces must keep supporting CTF holdings while adding a separate system for V2 positions: new position identifiers, different signing-domain versions, and separate buy-and-sell permissions for the new exchange contract. Polymarket tells developers to verify purchases, sales and balance reads on both a V2 market and a CTF market before trusting their own code against the switch.
Polymarket has published a migration guide and Data API V2, a Rust service built on an in-house on-chain indexer, to standardize response formats for integrators. CLOB V2, the new order-matching engine, went live in April, so this month’s change is the contract layer rather than the exchange software itself.
Audits and bug bounty
The rebuilt contracts went through audits by Cantina, Certora, Quantstamp, Sigma Prime, Zellic and Pashov Audit Group, with formal verification from Certora. Polymarket is offering a bug bounty of up to $5 million for critical findings, scaled to the severity of any issue reported.
Prediction market platforms carry a particular operational risk when contract code changes: an error in position handling can misprice or misresolve a market whose settlement depends on a real-world event. Polymarket’s monthly volume, now above $10 billion, has turned reliable settlement into a public accounting that draws close scrutiny, which raises the stakes of a contract rebuild done casually.
“Polymarket would run a few live test markets, known as canary markets, from Oct. 5 through Oct. 30,” Rajath Alex wrote in the October 5 announcement, describing November 2 as a tentative switch for newly created markets rather than a deadline for converting every existing bet.
Why the timing matters
Polymarket and its competitors are running into a regulatory landscape that is still in motion. Coinbase launched its own short-duration crypto prediction markets through Kalshi earlier this month. Regulators have not settled how event contracts are treated across the CFTC’s jurisdiction, with the White House weighing new rules for event contracts amid a broader power struggle over which agency watches prediction markets. Congressional committees have pressed Polymarket competitors on identity checks and suspicious trades.
A cleaner contract layer positions Polymarket to plug into whatever framework eventually emerges, whether that means new market types, partner integrations, or, eventually, cross-chain venues outside Polygon. Platforms that cannot move when the rules move end up rebuilding under pressure, which is a worse position than rebuilding ahead of it.
For market makers the change is mostly invisible during canary phase but becomes material on November 2, when newly created markets only exist on the new contracts. Withdrawals and deposits run through permission approvals that differ between the two systems, so any platform integrating Polymarket needs to handle the switch explicitly rather than assuming the old permissions carry over.
Whether the November 2 date holds depends on the canary phase. Polymarket has not published what failure would look like, but the codebase already includes a dedicated mechanism to migrate legacy positions, so the more likely fallback is a slower rollout rather than a hard fork.