Polymarket's Protocol V2 rollout does not automatically move existing bets held under its older Conditional Tokens Framework (CTF) onto new contracts. The prediction market operator's own migration guidance instructs trading integrations to retain support for those legacy holdings while adding a separate system for V2 positions and new trading permissions — meaning developers, not the protocol, carry the migration burden.

In an Oct. 5 announcement, Rajath Alex said Polymarket would run a series of live test markets, known as canary markets, from Oct. 5 through Oct. 30. He described Nov. 2 as a tentative switch date for newly created markets, not a deadline for converting every existing bet. That distinction frames the entire upgrade: new markets move to V2, while old positions stay where they are unless someone moves them.

For users of Polymarket's app or website, no technical migration is required. Users only need to complete any approval prompts shown in the app. The documentation covers Polygon-based on-chain trading; Polymarket's main docs direct users of Polymarket US to separate documentation, reflecting the platform's split regulatory posture between its international and US-facing operations.

Can holders move old positions to V2?

A separate mechanism does allow holders to move CTF positions into V2, but it is a distinct operation from updating trading software. Polymarket's contract registry states that the relevant condition or event must be registered by Polymarket first. The platform's indexing reference describes events connecting the old CTF balance to the new PositionManager balance.

The operational core of the change sits with developers, and it starts with where shares are recorded:

• Legacy CTF positions remain on the older ledger.
• V2 balances sit in a separate contract called PositionManager.
• The contract migration guide requires integrations to handle both balances and retain CTF identifiers for older markets.

What do integrations have to rebuild?

Permissions also stay separate. Under Polymarket's API migration guide, the account holding a V2 buyer's assets must authorize ExchangeV3 — the new trading contract — to spend enough pUSD, Polymarket's trading collateral, to cover purchases and fees. Selling requires permission for ExchangeV3 to operate on the seller's PositionManager shares. Existing CTF permissions grant neither approval.

Trading software must also select the correct share identifier from each market's version, even when response payloads contain identifier fields for both generations. V2 orders use position IDs and signing-domain version 3; CTF orders retain their exchange and signing-domain version 2. Those signing versions distinguish the two trading paths, and balance requests likewise separate V2 shares from CTF shares.

For integrations that create, combine or redeem positions directly through contracts, V2 uses a Router contract. Creating positions requires approval for Router to spend pUSD; combining or redeeming them requires Router operator permission on PositionManager. Integrations must also update their balance handling and payout reads.

How does V2 relate to earlier upgrades?

The similar version labels refer to different upgrades, a point Polymarket's changelog makes explicit. CLOB V2 went live on April 28, 2026, and Data API v2 launched on Sept. 4, 2026. The October Protocol V2 rollout adds the separate position system on top of those changes.

For integrations already using pUSD and the CTFExchangeV2 order format, the transition surface is narrower: collateral, wallets, order-book credentials and endpoints stay the same. Polymarket nevertheless tells developers to verify purchases, sales and balances on both a V2 market and a CTF market before relying on either path.

The practical consequence is a period of dual-ledger operation. Until legacy CTF markets resolve or holders migrate positions through the registration-dependent mechanism, integrations serving Polymarket traffic must maintain two permission sets, two signing domains and two balance sources. The canary-market window through Oct. 30 and the tentative Nov. 2 cutover for new markets give developers roughly a month to complete that work before V2 becomes the default for fresh liquidity.