Polymarket Launches Protocol V2, With New Markets Moving Over on November 2

Polymarket Launches Protocol V2, With New Markets Moving Over on November 2

Custom Image
Polymarket has begun rolling out Protocol V2, a major upgrade to the smart-contract infrastructure supporting its blockchain-based prediction markets. Announced on October 5, 2026, the new protocol introduces unified position tokens, redesigned trading contracts, and expanded oracle integration. The company is targeting November 2, 2026, for newly created markets to move to V2, following several weeks of live testing. The upgrade affects the infrastructure behind prediction-market trading, where participants buy and sell positions tied to real-world outcomes. While existing positions will remain on their current contracts, developers and market makers must prepare for changes to trading integrations, contract permissions, and market-data services.
 

Key Takeaways

  • Polymarket Protocol V2 launch: Polymarket introduced its upgraded prediction-market infrastructure on October 5, 2026, beginning limited live testing before a broader rollout targeting newly created markets.
  • November 2 migration target: Polymarket tentatively plans to move new markets to Protocol V2 on November 2, following canary testing scheduled through October 30. Existing markets will not automatically migrate.
  • Smart-contract upgrades: Protocol V2 introduces ERC-1155 position tokens, ExchangeV3, and modular contracts supporting four market formats, while maintaining pUSD collateral backed 1:1 by USDC.
  • Existing positions and developer requirements: Current CTF holdings remain supported without mandatory conversion. Developers must update affected integrations, including new position identifiers, contract approvals, and order-signing requirements.
  • October 24 API deadline: Polymarket plans to retire Data API V1 endpoints, with documented exceptions, before the broader V2 market transition. Developers relying on affected services need to migrate to Data API V2.
  • Security and future capabilities: Six security firms reviewed V2 contracts, while new oracle infrastructure supports UMA and Chainlink integrations. Cross-chain functionality remains a potential future capability rather than a confirmed general rollout.
 

Polymarket Protocol V2 Launch and November 2 Migration Timeline

Polymarket introduced Protocol V2 on October 5, 2026, beginning a phased upgrade of the smart contracts supporting its blockchain-based prediction markets. Announced by Rajath Alex, Polymarket's Head of Protocol, the update replaces key components of the platform's original architecture built on the Gnosis Conditional Tokens Framework (CTF). The rollout aims to simplify market infrastructure, support additional market formats, and improve flexibility for future development. November 2, 2026, is the tentative target for newly created markets to adopt V2, rather than a mandatory migration date for all existing markets. The phased approach allows Polymarket to evaluate the upgraded system before expanding its use, while maintaining support for markets operating on the existing infrastructure.
 

Why Polymarket Is Testing Protocol V2 With Canary Markets

Polymarket began testing Protocol V2 through a limited number of live canary markets instead of immediately transferring all market activity to the new infrastructure. These markets operate using V2 smart contracts and allow developers to assess trading operations, transaction processing, and interactions between protocol components under real conditions. By introducing the system gradually, Polymarket can examine how the new architecture handles market activity without requiring an immediate platform-wide transition.
 
The testing period is scheduled to continue through October 30, 2026, giving Polymarket time to identify potential technical or integration problems before expanding deployment. Canary testing can help reveal issues that controlled development environments may miss, although it cannot guarantee that the broader rollout will be free of vulnerabilities or operational disruptions. The results will be important in determining whether the protocol is ready for wider adoption and whether additional adjustments are needed before the planned November transition.
 

When Will Polymarket Markets Move to Protocol V2?

Polymarket's migration follows a staged schedule covering developer services, live testing, and new-market deployment. The transition also separates existing CTF positions from markets created under Protocol V2, meaning current holdings will not automatically convert to the new architecture. This distinction matters because the upgrade affects different parts of Polymarket's infrastructure at different times. According to Polymarket's published migration guidance, the main upcoming milestones are:
 
  • October 24, 2026: Polymarket plans to retire Data API V1 endpoints, with documented exceptions, requiring affected developers to transition to Data API V2.
  • October 30, 2026: The scheduled canary-testing period concludes, subject to the results of production testing.
  • November 2, 2026: Polymarket tentatively plans to begin creating new prediction markets using Protocol V2, while existing CTF markets remain separate.
 
The November 2 migration target remains conditional, and the final deployment schedule could change depending on testing results and technical readiness. Existing markets will not automatically move to V2 on that date, so the transition may involve both legacy and upgraded infrastructure operating alongside each other. Polymarket has not established November 2 as a universal deadline for converting all outstanding positions.
 

How Polymarket Protocol V2 Changes Smart Contracts, pUSD Collateral, and Oracle Integration

Polymarket Protocol V2 introduces a redesigned trading infrastructure that brings position management, market-specific logic, collateral handling, and resolution processes into a more unified system. The upgrade replaces several components of the older Conditional Tokens Framework (CTF) architecture with modular smart contracts designed to support different prediction-market formats. Its main technical changes involve ERC-1155 position tokens, pUSD collateral, ExchangeV3, and an OracleAggregator that connects multiple resolution mechanisms.
 

ERC-1155 Smart Contracts and Modular Prediction Markets

The new architecture uses a single PositionManager contract based on the ERC-1155 token standard to manage prediction-market positions. ERC-1155 allows multiple token types to exist within one smart contract, reducing the need for separate position-management structures. Trading is handled through ExchangeV3, while a Router contract coordinates operations such as splitting, merging, and redeeming positions. This arrangement separates token accounting from market-specific functions, making the underlying system easier to extend without redesigning its central position infrastructure.
 
Polymarket V2 initially supports four market formats: Binary, Atomic Neg-risk, Incremental Neg-risk, and Combinatorial. These operate through three documented modules: BinaryModule, NegRiskModule, and CombinatorialModule. Binary markets involve two possible outcomes, while negative-risk formats accommodate related outcomes within broader events. Combinatorial markets support positions tied to combinations of outcomes. Each position also receives a structured identifier that connects it to the appropriate module, allowing the system to determine which contract manages its operations.
 

How pUSD Collateral Works in Polymarket Protocol V2

Polymarket V2 uses Polymarket USD (pUSD) as its collateral token, maintaining a dollar-denominated trading system across different prediction-market formats. Unlike a newly issued speculative cryptocurrency, pUSD is an ERC-20 token on Polygon backed 1:1 by USDC, with its backing enforced through smart contracts. This arrangement follows the broader use of stablecoin collateral in cryptocurrency trading, where assets linked to more stable reference values support trading and settlement. Polymarket originally introduced pUSD during its April 28, 2026, exchange upgrade, meaning the October Protocol V2 release continues an existing collateral arrangement rather than introducing a new stablecoin.
 
The collateral infrastructure includes CollateralOnramp and CollateralOfframp contracts that handle conversions between supported collateral assets and pUSD. Polymarket's documentation also identifies adapters connecting pUSD with the collateral used by older CTF markets, allowing both position systems to operate within the broader trading infrastructure. This design provides a common collateral layer while maintaining compatibility between different market architectures. However, the use of USDC-backed collateral does not remove smart-contract, conversion, or underlying stablecoin risks.
 

OracleAggregator Connects UMA and Chainlink for Market Resolution

Protocol V2 introduces an OracleAggregator to coordinate how prediction markets determine their final outcomes. An oracle supplies external information that blockchain smart contracts cannot independently verify, such as election results, sporting outcomes, or asset prices. These decentralized blockchain oracles are important components of applications that rely on real-world information. Instead of relying on a single resolution mechanism for every market, the new architecture uses configurable modules that can connect different reporting sources. This gives Polymarket greater flexibility in matching a market's resolution process to the type of information required.
 
The documented oracle system includes several distinct components:
  • UMA integration: The OOReporterModule can relay settled results from UMA's Optimistic Oracle into Polymarket's resolution process, supporting markets that depend on externally verified outcomes.
  • Chainlink price data: The ChainlinkReporterModule supports price-based resolution using configured Chainlink Data Streams information, including comparisons between an asset's starting and ending prices.
  • Dispute and arbitration controls: OracleAggregator supports reporting thresholds, dispute windows, and arbitration procedures. These mechanisms allow reported outcomes to be challenged under configured rules before final settlement.
 
The modular system can accommodate additional resolution sources without requiring the entire position-management architecture to be replaced. Nevertheless, oracle reliability remains essential to prediction-market accuracy. Incorrect external data, configuration errors, or disputes over an event's outcome can still affect settlement, even when multiple reporting mechanisms are supported.
 

What Polymarket V2 Means for Existing Positions, Developers, and Future Prediction Markets

Polymarket's Protocol V2 upgrade introduces different requirements for everyday traders, developers, and market makers. While the platform aims to maintain a familiar trading experience for regular users, applications connected directly to its infrastructure must account for new position identifiers, contract permissions, and order-signing rules. The redesigned system also creates opportunities for additional prediction-market features, although several capabilities remain under development rather than available for general use.
 

What Happens to Existing Polymarket Positions and Wallets?

Existing Polymarket positions will continue to operate through their original Conditional Tokens Framework (CTF) contracts unless a separate migration takes place. According to Polymarket's migration guidance, website and mobile app users do not need to perform a technical migration or manually transfer their holdings to a different wallet. However, users may encounter new authorization requests when interacting with markets running on the upgraded infrastructure. These permissions allow the relevant smart contracts to access approved assets or positions for specific trading operations.
 
Several practical considerations are important for existing position holders:
  • Wallet approvals: Users may need to authorize new trading contracts before interacting with V2 markets. Existing permissions for older contracts do not automatically extend to the new system.
  • Position management: Legacy holdings remain associated with their original contracts, while V2 positions use a separate accounting system. Applications tracking portfolios must recognize both.
  • Optional migration: Polymarket's contract documentation describes mechanisms for converting certain eligible legacy positions into V2 positions, but the relevant conditions or events must first be registered. This is not an automatic platform-wide process.
 
For regular traders, the main consideration is whether a particular market operates under the older or upgraded infrastructure. Users should follow instructions provided through Polymarket's official interface and verify wallet approval requests before authorizing transactions. The protocol upgrade does not eliminate the financial risks associated with prediction markets, including potential losses when an event settles against a position.
 

How Developers and Market Makers Must Adapt to Polymarket V2

Developers operating trading bots, market-making systems, portfolio dashboards, or analytics platforms face more substantial integration changes. Polymarket's updated infrastructure requires applications to distinguish between legacy CTF assets and V2 positions when placing orders, checking balances, or processing market activity. Although existing order-book endpoints and authentication arrangements remain available for compatible integrations, V2 transactions require different identifiers, contract approvals, and signing rules.
 
The main technical requirements include:
  • Market identification: V2 integrations use positionIds, while legacy markets continue using clobTokenIds. Applications must identify the market version before selecting the appropriate asset identifier.
  • Order authentication: ExchangeV3 orders use EIP-712 signing domain version 3, whereas existing CTFExchangeV2 orders use version 2. Mixing these formats can result in rejected orders.
  • Trading permissions: Buying V2 positions requires sufficient pUSD approval for ExchangeV3, while selling requires operator permission over the relevant PositionManager tokens.
  • Data API integration: Data API V2 introduces cursor-based pagination, standardized response structures, and snake_case fields. The /v2/positions endpoint also supports filtering positions by status, including open, redeemable, mergeable, and closed holdings.
 
These changes are particularly relevant for automated trading systems that depend on accurate order execution and portfolio accounting. Developers need to test both legacy and V2 market operations, including balance retrieval, order submission, and position settlement. Market makers must also ensure their software selects the correct contract and permissions for each transaction, as an integration error could interrupt trading even when the underlying market remains operational.
 

Future Prediction Markets: Cross-Chain Trading and New Features

Beyond the immediate migration, Polymarket Protocol V2 provides infrastructure designed to support cross-chain position transfers and additional market functionality. Its documented bridging architecture uses Chainlink's Cross-Chain Interoperability Protocol (CCIP) to support the movement of eligible positions, collateral, and resolution results between supported networks. Under the proposed hub-and-spoke design, Polygon serves as the authoritative resolution network, while other networks could support compatible trading activity. However, general cross-chain trading has not been confirmed as active, and the documented bridging mechanism does not currently support every position format.
 
Polymarket has also identified potential features such as scalar resolution and directional collateral return, which could expand how future prediction markets represent outcomes and manage collateral. Scalar resolution could support markets involving numerical outcomes rather than only fixed categories, although its implementation and availability remain subject to further development. The modular architecture may make future additions easier to integrate, but it does not establish that trading costs will fall or liquidity will improve. Those outcomes will depend on actual deployment, market participation, and the performance of the upgraded infrastructure.
 

Conclusion

Polymarket Protocol V2 introduces significant changes to the platform's prediction-market infrastructure, including unified ERC-1155 positions, modular smart contracts, and additional oracle integrations. The upgrade is designed to simplify an increasingly complex trading architecture while creating room for future market formats and cross-chain functionality.
 
The immediate focus remains on the phased rollout. November 2, 2026, is a tentative transition date for newly created markets, while existing CTF positions will not automatically migrate. Developers also face an earlier Data API V1 retirement deadline on October 24. Although the architecture offers greater flexibility, its effects on trading performance, liquidity, and operating costs will become clearer only after broader deployment. For traders and developers, understanding these distinctions is more useful than assuming every market will change at once.
 

🔥 Beyond the Headlines: What KuCoin 5.0 Means for You

Market news moves fast — but where you act on it matters just as much. This October, KuCoin launches KuCoin 5.0, transforming KuCoin into a rebuilt platform. Here's what actually changes for you:
 
  • One account for everything. Older platforms split your money across separate "spot," "margin," and "futures" accounts and expected you to understand why. KuCoin 5.0's unified account removes that entirely — deposit once, and everything is simply there (only available to VIPs for now).
  • Stocks, indices, and commodities. KuCoin 5.0 expands beyond crypto into global markets. When crypto chops sideways and equities rally (or the reverse), you rotate in minutes instead of opening a brokerage account and waiting days for fiat rails.
  • Real-world assets (RWA). Tokenized exposure to traditional assets like commodities, right inside your crypto account. One of the fastest-growing segments in global finance is no longer reserved for institutions — you access it from the same balance you trade with.
  • Earn while you learn. Not ready to trade? KCUSD lets your stablecoins earn daily, auto-compounding interest. The lowest-stress way to put your idle deposit to work for 4% yield.
  • An AI assistant in plain language. Ask questions, get market context, understand what you're looking at — built into the platform, no jargon required.
  • An app that doesn't overwhelm. Faster, cleaner, and consistent — intuitive from the first tap, not after a tutorial.
  • Safety you can check, not just trust. A MiCAR-licensed EU entity, Proof of Reserves you can verify yourself, and internationally certified security (SOC 2 Type II, ISO 27001:2022).
 
Create your account in minutes — and start on the platform built for where crypto is going, not where it's been.
 

FAQs

Can Traders Sell Polymarket V2 Positions Before an Event Ends?

Yes. Traders can sell outcome tokens before market resolution, provided the market remains open and sufficient buying interest exists. The selling price depends on available orders and market conditions. Because prediction-market order execution depends on available liquidity, the final selling price may differ from the displayed market price. Exiting early may result in a profit or loss, regardless of how the event eventually resolves.

How Are Winning Positions Paid After a Polymarket V2 Market Resolves?

After resolution, winning outcome tokens can be redeemed for collateral according to the market's recorded payout. In a standard binary market, each winning share generally redeems for 1 pUSD, while losing shares have no redemption value. Some markets may use split payouts, depending on their resolution rules.

Where Can Users Verify Polymarket Protocol V2 Smart Contracts?

Users can verify deployed contract addresses through Polymarket's official developer documentation and inspect the corresponding transactions on PolygonScan. The contract registry identifies trading, collateral, position-management, and resolution contracts. When a contract uses a proxy, users should reference the documented proxy address rather than an implementation address or an unverified third-party link.

Has Polymarket Protocol V2 Undergone Security Audits?

Yes. Polymarket has published security reviews involving Cantina, Certora, Quantstamp, SigmaPrime, Zellic, and Pashov. Certora also conducted formal verification work, while a Cantina bug-bounty program offers rewards of up to $5 million for qualifying critical vulnerabilities. These measures strengthen security assessment but cannot guarantee that every vulnerability has been identified.
 
 

Disclaimer

The information provided on this page may originate from third-party sources and does not necessarily represent the views or opinions of KuCoin. This content is intended solely for general informational purposes and should not be considered financial, investment, or professional advice. KuCoin does not guarantee the accuracy, completeness, or reliability of the information, and is not responsible for any errors, omissions, or outcomes resulting from its use. Investing in digital assets carries inherent risks. Please carefully evaluate your risk tolerance and financial situation before making any investment decisions. For further details, please consult KuCoin’s Terms of Use and Risk Disclosure.