The introduction of Polymarket’s Protocol V2 does not automatically transfer existing wagers from the older Conditional Tokens Framework (CTF) to the updated contracts. Migration instructions instead advise trading integrations to maintain support for those legacy holdings while simultaneously incorporating a separate framework for V2 positions and new trading authorizations.
Rajath Alex stated in an Oct. 5 announcement that Polymarket would host a series of live test markets—referred to as canary markets—running from Oct. 5 through Oct. 30. He pointed to Nov. 2 as an estimated transition date for newly generated markets, rather than a hard deadline to convert every pre-existing bet.
Individuals utilizing Polymarket’s website or app do not need to perform a technical migration. Users simply need to follow any approval prompts that appear within the application. These guidelines apply to Polygon-based onchain trading, whereas Polymarket’s main documentation directs users of Polymarket US to distinct instructions.
Holders do have access to a separate mechanism that permits them to move CTF positions into V2. According to Polymarket’s contract registry, the relevant event or condition must initially be registered by the platform. Furthermore, its indexing reference outlines events that link legacy CTF balances with the new PositionManager balances, functioning as an operation completely separate from updating trading software.
Integrations must support both systems
For developers, the transition begins with how shares are tracked. While legacy CTF positions stay on the older ledger, V2 balances are housed in a distinct contract known as PositionManager. The contract migration instructions dictate that integrations must manage both sets of balances correctly and keep CTF identifiers intact for older markets.
Permissions also remain segmented. The API migration guide specifies that the account holding a V2 buyer’s assets must grant ExchangeV3—the new trading contract—enough authorization to spend pUSD, Polymarket’s trading collateral, to cover purchases and associated fees. Similarly, executing sales requires granting ExchangeV3 permission to interact with the seller’s PositionManager shares. Legacy CTF permissions do not automatically supply either approval.
Trading applications must select the correct share identifier corresponding to each market’s specific version, even if identifier fields for both generations appear in the API response. V2 orders utilize position IDs alongside signing-domain version 3, whereas CTF orders continue to rely on their exchange and signing-domain version 2. These signing versions serve to differentiate the two distinct trading paths, and balance requests likewise separate V2 shares from CTF shares.
Integrations that directly create, combine, or redeem positions via smart contracts must utilize the V2 Router. Generating positions demands approval for the Router to spend pUSD, while combining or redeeming them requires granting the Router operator permission on the PositionManager. Additionally, integrations must update their balance handling and payout read mechanisms.
Similar version names point to distinct updates. Polymarket’s changelog indicates that CLOB V2 went live on April 28, and Data API v2 launched on Sept. 4, both occurring in 2026. The October Protocol V2 rollout introduces the separate position architecture.
For integrations already utilizing pUSD and the CTFExchangeV2 order format, elements like collateral, wallets, order-book credentials, and endpoints remain unchanged. Even so, Polymarket advises developers to verify transactions, sales, and balances across both V2 and CTF markets.