Polymarket's V2 upgrade leaves existing bets where they are. Users and developers now have to manage both legacy and V2 positions, each with its own permissions and identifiers.
Polymarket's long-awaited Protocol V2 is now live. But if you have bets under the old Conditional Tokens Framework (CTF), nothing moves by itself. The upgrade does not shift your positions to the new system. Legacy holdings stay put unless you or an integration decide to move them. This means users and developers now deal with two separate systems, each with its own rules, permissions, and quirks.
Old bets stay where they are
If you have open bets or positions on Polymarket's app or website, the upgrade does not force you to move anything. Your CTF holdings remain untouched. You do not have to move funds or positions unless you want to. For most users, the only thing you might see is a prompt in the app asking for new approvals. According to Polymarket's documentation, migration only happens if you or an integration choose to start it. Even then, Polymarket must register the relevant condition or event before any transfer can go through.
Polymarket V2 replaces the legacy architecture with a unified ERC-1155 PositionManager, encoding market type, condition, and outcome directly into position IDs.
For developers and trading integrations, things get more complicated. They have to keep supporting CTF-based positions and also add support for V2's new PositionManager contract. Balances are tracked separately. Integrations must handle both legacy and V2 identifiers, permissions, and trading logic. The migration guide says CTF identifiers must stay in place for older markets. Permissions for spending collateral or shares do not work across both systems.
New permissions and trading steps
V2 brings in new permissions and identifiers for trading. To buy in a V2 market, your account must let the new ExchangeV3 contract spend enough pUSD to cover your purchase and fees. Selling needs a separate permission for ExchangeV3 to use your PositionManager shares. These permissions are not the same as those in the CTF system. Old CTF approvals do not carry over.
Trading software now has to pick the right share identifier for each market version. Both CTF and V2 identifier fields can show up in API responses. Orders in V2 use position IDs and a new signing-domain version. CTF orders keep their old format. This difference matters for integrations that process trades, combine or redeem positions, or read balances and payouts from contracts. In V2, the Router contract handles creating, combining, and redeeming positions. Each step needs its own approval.
The only collateral asset in Polymarket V2 is pUSD, an ERC-20 token fully backed 1:1 by USDC and USDC.e in an external vault, with reserves always matching or exceeding circulating supply.
Timeline and integration needs
Polymarket started testing V2 with live "canary markets" on October 5. The plan was to switch new markets to V2 on November 2. But this is not a hard deadline for moving all old bets. Legacy positions can stay under CTF as long as users or integrations want. The documentation stresses that trading integrations must support both systems at the same time, checking purchases, sales, and balances on both V2 and CTF markets.
If you are a developer already using pUSD and the CTFExchangeV2 order format, your core setup-collateral, wallets, endpoints-does not change. But things get more complex. Now you have to manage two sets of balances, permissions, and trading logic. This kind of dual support is not unique to Polymarket. Other platforms have faced similar issues during big protocol upgrades, as seen with tokenized stock trading rules.
What this means for users and developers
For most app and website users, the move to V2 is invisible unless you choose to migrate positions or use new markets. The main risk is confusion. You need to watch for approval prompts and know that permissions for CTF do not work for V2, and vice versa. Developers and trading integrations have more work. They must update their software to handle new contract addresses, identifiers, and permission flows. If they do not, trades can fail, balances can be wrong, or payouts can be missed.
Polymarket's changelog shows that other upgrades-like CLOB V2 and Data API v2-went live earlier in 2026. But the October Protocol V2 rollout is about the new position management system. The documentation also points out the difference between Polygon-based onchain trading and Polymarket US, which has its own guides and requirements.
The V2 upgrade does not change the pUSD collateral, wallet setup, or endpoint URLs for existing integrations. The main change is that users and developers now have to track and manage two separate systems for positions and permissions. As of October, everyone must pay close attention to whether they are dealing with CTF or V2 markets, especially when handling approvals, trades, and balance checks.
Polymarket's migration plan shows a common reality in decentralized finance. Protocol upgrades rarely make things seamless for legacy users and integrations. By making migration explicit and keeping both systems running, Polymarket avoids forced conversions that could disrupt user positions or break integrations. But this also means more complexity and a higher risk of mistakes. For U.S. users and developers, the message is simple: protocol upgrades may bring new features, but they also require careful handling of permissions, identifiers, and migration steps to avoid costly errors.
The Conditional Tokens Framework (CTF) and PositionManager contracts are two different ways to manage prediction market positions on Polymarket. CTF, the old system, uses its own ledger and identifiers. V2's PositionManager brings a new contract and permission model. This split lets users and developers migrate gradually, but it also adds more work. Knowing the difference between these systems is key for anyone trading, integrating, or building on Polymarket. Permissions, identifiers, and contract actions do not work the same way between the two frameworks.
