Polymarket’s upgrade won’t automatically move existing bets to new contracts
Polymarket's Protocol V2 upgrade introduces new contracts for wagers without automatically transferring existing bets from the older Conditional Tokens Framework, requiring developers and integrations to manage both systems.
The introduction of Polymarket’s Protocol V2 does not automatically transfer existing wagers stored under the older Conditional Tokens Framework (CTF) over to the new contracts. Migration guidelines instruct trading integrations to maintain support for those legacy holdings while simultaneously incorporating a distinct infrastructure for V2 positions alongside new trading permissions.
Rajath Alex noted in an Oct. 5 announcement that Polymarket would roll out a limited number of live test markets—referred to as canary markets—running from Oct. 5 through Oct. 30. He pointed to Nov. 2 as a tentative switchover date specifically for newly generated markets, rather than a strict deadline to convert every pre-existing bet.
Individuals utilizing the official Polymarket website or app are not required to perform any technical migration steps. Instead, users simply need to finish any approval prompts that appear inside the application. These guidelines pertain specifically to Polygon-based onchain trading; separate documentation is maintained for users of Polymarket US according to the platform’s main documentation.
France blocked Polymarket after its transaction controls failed to stop 578,751 new French visitors
Holders do have access to a separate mechanism enabling them to transition CTF positions into V2. According to Polymarket’s contract registry, the corresponding event or condition must first be registered by Polymarket. Furthermore, its indexing reference outlines events that link the legacy CTF balance with the new PositionManager balance, representing an operation completely separate from updating trading software.
Integrations must support both systems
The transition begins for developers at the foundational level of where shares are tracked. While legacy CTF positions continue residing on the older ledger, V2 balances reside within a separate contract known as PositionManager. The contract migration guide dictates that integrations must appropriately manage these respective balances while preserving CTF identifiers for older markets.
Permission structures likewise remain distinct. Per the API migration guide, accounts holding V2 buyer assets must grant ExchangeV3—the new trading contract—authorization to spend sufficient pUSD (Polymarket’s trading collateral) to cover all purchases and associated fees. Similarly, executing sales requires granting permission for ExchangeV3 to manage the seller’s PositionManager shares. Legacy CTF permissions do not automatically supply either of these approvals.
Trading applications must carefully select the appropriate share identifier corresponding to each market version, even if identifier fields from both generations appear inside the response payload. V2 orders rely on position IDs and signing-domain version 3, whereas CTF orders maintain their legacy exchange and signing-domain version 2. These respective signing versions help separate the two distinct trading pathways, and balance requests similarly differentiate V2 shares from CTF shares.
For integrations that handle creating, combining, or redeeming positions directly via contracts, V2 utilizes a Router. Establishing positions requires granting the Router approval to spend pUSD, whereas combining or redeeming them necessitates Router operator permissions on the PositionManager. Integrations must also refresh how they handle balances and read payouts.
Hyperliquid challenges Polymarket with $32 million opening for prediction-market builders
It is worth noting that similarly named version labels refer to completely different updates. Polymarket’s changelog documents CLOB V2 launching on April 28 and Data API v2 going live on Sept. 4, both occurring in 2026. Meanwhile, the October Protocol V2 rollout introduces the separate position architecture.
Polymarket’s stablecoin launch looks bearish for USDC, but the real shift runs deeper
For integrations already utilizing pUSD and the CTFExchangeV2 order format, core components like collateral, wallets, order-book credentials, and endpoints remain unchanged. Even so, Polymarket advises developers to thoroughly verify purchases, sales, and balances across both CTF markets and V2 markets.
?Frequently Asked Questions
01Do I need to manually move my existing bets to Polymarket Protocol V2?
No. Polymarket’s Protocol V2 rollout does not automatically transfer existing bets held under the older Conditional Tokens Framework (CTF) to the new contracts. App and website users require no technical migration aside from completing on-app approval prompts.
02What happens to my legacy CTF positions?
Legacy CTF positions remain on the older ledger, and trading integrations are instructed to maintain support for those holdings alongside the new V2 system.
03Are existing trading permissions compatible with V2?
No. Existing CTF permissions do not grant approval for V2 trading. Separate permissions must be established for ExchangeV3 and the Router.



