Two different “V2”s. Polymarket has used the name “V2” for two separate upgrades. This page is about the second one.
In these docs, Polymarket Protocol V2 is always written out in full.
What it is
Polymarket Protocol V2 is Polymarket’s new on-chain system for markets. Polymarket introduced it to run every market type (yes/no, multi-outcome and combos) on one position system and one exchange:- positions live in a new position ledger, PositionManager, instead of Conditional Tokens;
- every market type trades on one exchange, ExchangeV3;
- split, merge and redeem go through Polymarket’s Router;
- each market and outcome gets a new id, and results are reported as shares of 1,000,000.
v1 and markets on the new system as version v2, hence Protocol V2. The April 2026 upgrade was also called “V2” because it replaced the original exchange contracts. They are different layers: April changed the exchange and kept every market and token id, while Protocol V2 changes the position system for new markets.
What does not change. Markets that exist today stay on the current system and keep their ids. Existing holdings are not converted. Collateral is still pUSD.
Polymarket’s own description is in its guide Migrate to Polymarket Protocol V2. This page covers what it means for polynode.
Dates
These are Polymarket’s dates.
polynode handles Protocol V2 markets whenever they appear, so if Polymarket moves a date, there is nothing extra for you to do.
Do I need to do anything?
SDK versions with Polymarket Protocol V2 support:
How to recognise a Protocol V2 market
REST rows and WebSocket events for a Protocol V2 market carry two extra fields. They are absent on every other market.
Use these fields, not the shape or length of an id, to tell markets apart. The SDKs also provide
getMarketProtocol(id) (TypeScript) and get_market_protocol(id) (Python, Rust), which return "v1" or "v2".
Ids
- Outcome ids (
token_idand similar fields) are decimal strings, as today. Protocol V2 ids are usually larger numbers, up to 78 digits. Never parse them as JavaScript numbers or floats. - Condition ids are 66 characters (
0xplus 64 hex characters), as today. Polymarket’s contracts and some Polymarket APIs show a Protocol V2 condition id in a shorter 31-byte form (0xplus 62 hex characters); the 66-character form is the same value followed by00. polynode routes and WebSocket filters that take a condition id accept either form. - The combo stream and combo routes keep their existing 31-byte combo condition ids.
REST API
Protocol V2 markets appear in the same routes as every other market, with the same fields and units. Rows for a Protocol V2 market add:condition_id equals structural_condition_id, with one exception. Polymarket lets a holder move a position from a current market into Protocol V2. Such a position keeps the current market’s condition_id, so its old and new rows group under one market, and structural_condition_id shows its Protocol V2 id.
Results keep today’s form in payout_numerators and payout_denominator. For example, [1, 0] with 1 means the first outcome won, and [1, 1] with 2 is a 50/50 result. payouts_ppm carries the same result exactly.
While Polymarket’s test markets run, they appear in wallet, trade and market-id routes, but not in market listings or search. Their slugs start with polyv2.
WebSocket
Protocol V2 markets arrive on the same streams as the same event types. Events for a Protocol V2 market add:exchange keeps its two existing values (ctf_exchange for yes/no markets and neg_risk_ctf_exchange for multi-outcome markets), so typed decoders, including older SDK versions, keep working.
Protocol V2 results arrive as oracle events with oracle_type: "condition_resolution". payouts uses today’s form ([1, 0], [0, 1], or [1, 1] for a 50/50 result). On these events question_id carries the condition id and adapter_address the market’s Polymarket module contract.
The order book stream keeps its message format and adds Protocol V2 markets as Polymarket lists them.
Trading with the SDK
After upgrading, place orders with the same calls as before. The SDK checks each market’s protocol (once, then cached) and signs Protocol V2 orders for ExchangeV3 with EIP-712 domain version"3". The order fields are unchanged. If the SDK cannot tell which protocol a market uses, it refuses to sign and returns a retryable error, so no order is sent.
Older SDK versions keep working on current markets. Polymarket rejects their orders on Protocol V2 markets, and no funds move.
Approvals
Protocol V2 markets use new approval targets. The first order on a Protocol V2 market sets up what it needs, once. This is gasless for Safe and deposit wallets; an EOA pays a small amount of POL gas. To set them up ahead of time, calltrader.ensureReady(signer, { protocolV2: true }) (TypeScript), trader.ensure_ready(signer, protocol_v2=True) (Python) or trader.ensure_protocol_v2_ready() (Rust). Existing approvals are not changed or revoked.
Split, merge and redeem
On Protocol V2 markets, split, merge and redeem go through Polymarket’s Router; the SDK picks the right path for each market. For redeem, outcome index0 is the first outcome (Yes, or Up) and 1 is the second. Converting negative-risk positions is not available for Protocol V2 markets; the SDK returns a clear error instead. See Position management.
Contract addresses (Polygon)
FAQ
Is this the same as the V2 migration in April?
Is this the same as the V2 migration in April?
No. April’s upgrade replaced the exchange and moved collateral to pUSD for every market. Polymarket Protocol V2 replaces the position system for newly created markets. See the table at the top of this page.
Do my existing positions change?
Do my existing positions change?
No. Current markets keep their ids and stay on the current system. If a holder chooses to move a position into Protocol V2, polynode shows it as a Protocol V2 row for the same market (see the REST API section above).
My order on a new market fails with an older SDK
My order on a new market fails with an older SDK
Upgrade to the versions above. Older versions sign for the April exchange, which Protocol V2 markets do not use. Polymarket rejects those orders and no funds move.
Why does a condition id sometimes have 64 characters?
Why does a condition id sometimes have 64 characters?
That is the 31-byte form Polymarket’s contracts use. polynode returns the 66-character form and accepts both. Combo condition ids keep their existing 31-byte form.