CLOB V2 and pUSD: What Changed on Polymarket
Update · 4 min read · published 2026-04-20 · updated 2026-07-25
On 22 April 2026 Polymarket shipped the largest infrastructure change in its history: new exchange contracts, a rewritten central limit order book, and a new collateral token called pUSD. The cutover is long done, but its consequences show up every day - in the token your balance is denominated in, in the contracts your redeem transaction talks to, and in the fee data attached to every market. This is the reference.
What the upgrade replaced
- New exchange contracts. Orders now match against a new set of contracts. Open orders from before the cutover did not roll over, and allowances granted to the old exchange no longer mean anything.
- A rewritten CLOB backend. New API surface, renamed endpoints, changed authentication signatures. V1 API keys stopped working.
- pUSD collateral. USDC.e is no longer the settlement asset. pUSD wraps it one-for-one and is what every balance, position and payout is denominated in.
- Builder API V2. Every third-party integration that routes orders - Polynter's trade panel included - had to move to the V2 SDK.
pUSD in practice
pUSD is a wrapper, not a new currency. One pUSD is one dollar-equivalent of the underlying stablecoin, with the same six decimals, and it converts back one-for-one. For a trader the practical effects are narrow but real:
- Your balance, your position sizes and your realised PnL are all quoted in pUSD.
- Redeeming a winning market returns pUSD, not USDC.e. Getting to USDC.e is a separate unwrap or bridge step.
- Approvals are granted to pUSD-aware contracts. An allowance you signed for the old collateral does nothing for the new one.
Full mechanics of moving value in and out are in how to deposit and withdraw.
The part that still bites: adapters
This is the most common source of failed transactions months after the cutover, and it is worth understanding even if you never touch a contract directly.
Redeeming, merging and splitting positions do not talk to the conditional-token contract directly any more. They go through collateral adapters that handle the pUSD wrapping on your behalf - one adapter for ordinary binary markets, a separate one for neg-risk markets (the multi-outcome questions where exactly one candidate can win).
Two things follow. First, each adapter needs its own setApprovalForAll on the conditional-token contract before it can move your outcome tokens; approving one does not approve the other. Second, any tool, script or bookmarked contract call still pointing at the retired V1 neg-risk adapter will fail - that address stopped accepting relayed calls on 17 July 2026.
If a redeem or merge reverts with no obvious reason, a missing adapter approval is the first thing to check.
What the upgrade did not change
- Historical resolutions and price history were preserved in full.
- The conditional-token framework itself - the YES/NO share model, splitting, merging, redeeming - works the same way conceptually.
- Market slugs, IDs and event metadata stayed stable, so links and bookmarks survived.
- The read-only data APIs that power analytics were unaffected throughout.
Notes for integrators
- Pin the client SDKs to versions that agree with each other. Mismatched builder-signing and relayer clients produce confusing type conflicts rather than clean errors.
- Re-derive API credentials; V1 keys are dead.
- Handle the pUSD token address in every balance read and fee calculation - the old collateral address will silently return zero.
- Read fee parameters from the market itself rather than a hardcoded table. Fee coefficients differ by category and have been adjusted more than once since the upgrade.
- Websocket consumers needed to point at the new socket URL; old channels do not fail loudly, they simply go quiet.
- Route redeem, merge and split through the correct adapter for the market type, and check the approval state before signing.
Why the upgrade happened
The V1 stack was built for a smaller platform. Matching latency, the cost of settlement, and the difficulty of shipping fee logic without redeploying contracts were all constraints. V2 moved fee parameters into per-market data, separated collateral handling into adapters, and replaced the matching backend - which is what made the current fee structure, the maker rebate programme and short-dated crypto markets that settle within the hour practical to run at all.
In other words, most of what looks like a product change over the past few months is downstream of this infrastructure change.
How Polynter handles it
Our read-only analytics never depended on the exchange contracts, so leaderboards, the 99%+ screener, holding rewards and the tickers ran through the cutover untouched. The trade panel moved to the V2 SDK, and redeem, merge and split now route through the current collateral adapters with the approvals handled in the flow. Fee estimates are read per market rather than assumed.
Related reading: Polymarket fees explained and what Polymarket is.