Polymarket’s Protocol V2 rollout does not automatically move existing bets held under its older Conditional Tokens Framework, or CTF, onto new contracts. Its migration guidance tells trading integrations to retain support for those holdings while adding a separate system for V2 positions and new trading permissions.

In his Oct. 5 announcement , Rajath Alex said Polymarket would run a few live test markets, known as canary markets, from Oct. 5 through Oct. 30. He described Nov. 2 as a tentative switch for newly created markets, rather than a deadline for converting every existing bet.

For people using Polymarket’s app or website, no technical migration is required. Users should complete any approval prompts shown in the app. The guides address Polygon-based onchain trading; Polymarket’s main documentation directs users of Polymarket US to separate documentation.

A separate mechanism does allow holders to move CTF positions into V2. Polymarket’s contract registry says the relevant condition or event must be registered by Polymarket first. Its indexing reference describes events connecting the old CTF balance to the new PositionManager balance. That is a distinct operation from updating trading software.

For developers, the change starts with where shares are recorded. Legacy CTF positions remain on the older ledger, while V2 balances sit in a separate contract called PositionManager. The contract migration guide requires integrations to handle the appropriate balances and retain CTF identifiers for older markets.

Permissions also stay separate. Under the 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 do not grant either approval.

Trading software must select the correct share identifier from each market’s version, even if both generations’ identifier fields appear in the response. 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. Balance requests also distinguish V2 shares from CTF shares.

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