Polymarket pUSD and Protocol V2 Explained

Two upgrades with similar names are easy to mix up. CLOB V2 changed the exchange, the order backend and the collateral token. Protocol V2 added a second way of holding outcome positions. This guide explains both from Polymarket's own documentation, keeps the developer detail short and says where the pages are silent or disagree. A dated timeline of the changelog entries is a separate post.

What is pUSD?

Polymarket's documentation describes pUSD as the collateral token for all trading on Polymarket. Technically it is an ERC-20 token on Polygon that USDC backs. ERC-20 is a token standard, and the documentation calls pUSD a wrapper that represents a claim on USDC. The smart contract enforces the backing, and the page states there is no algorithmic peg and no fractional reserve. A complete pair of Yes and No tokens in a market is backed by 1 pUSD of value.

pUSD can be transferred like any other ERC-20 token, but it is built to work inside Polymarket: the documentation says there are no plans at present to list it on outside exchanges. Polymarket Perps use the same token, since the Perps collateral is pUSD (see the Perps guide).

Why did Polymarket introduce it?

The documentation gives a short reason: settlement in native USDC, which it describes as a standard that is more capital efficient, more scalable and better aligned with institutions as the platform grows. The collateral before pUSD was USDC.e, the bridged form of USDC, and pUSD replaced it. The pages do not compare the two tokens or say more about the decision.

How do you get pUSD?

It depends on how you use Polymarket.

• On polymarket.com. The frontend wraps your funds automatically after a one-time approval. After that you simply see a balance and trade.
• By depositing. The bridge handles the conversion: assets from other chains are converted to pUSD on Polygon automatically. You can send native USDC or bridged USDC.e.
• Through the contracts. The documentation names two groups that wrap by hand, power users and API-only traders, who wrap USDC.e into pUSD through the Collateral Onramp contract. It does not describe other interfaces.

Going the other way, a withdrawal unwraps pUSD through the Collateral Offramp, and you can also withdraw pUSD itself, though some exchanges no longer accept pUSD deposits directly. On fees, the Fees page says Polymarket charges no fee to deposit or withdraw USDC, and the Withdraw page says it does not charge withdrawal fees; a service you use along the way may charge its own.

Which wallet type does an account use?

The Wallets page says a Deposit Wallet is the default and that all account wallets deployed on or after May 4, 2026 use one, with Proxy and Safe wallets as legacy types. Polymarket 101 words it more narrowly: new API users use deposit wallets, and Safe and Proxy wallets stay supported for people and integrations that already use them. The Contracts page adds that pUSD and Polymarket account wallets work with both position systems, which are covered below.

What did CLOB V2 change?

CLOB V2 is the upgrade that introduced pUSD. Polymarket's changelog describes it as a coordinated upgrade made of new exchange contracts, a rebuilt CLOB backend and pUSD as the new collateral token. It went live on April 28, 2026 at about 11:00 UTC, and trading was paused for about 1 hour. For traders, the visible effects were these:

• Open orders were wiped, so anything resting before the cutover had to be placed again.
• Fees are set by the protocol at match time instead of being part of the signed order. The fees guide covers the rates.
• Builder attribution now runs through an optional builder code field on the order. The migration guide says builder codes enable attribution and revenue sharing for integrators.

What is Protocol V2?

Protocol V2 is a different change from CLOB V2, and its migration pages start from integrations that already use pUSD and the CTF Exchange V2 order format. The documentation says it introduces new position tokens, plus new contracts for trading, for position operations and for resolution. One naming wrinkle: the Contracts page puts the same Poly v2 badge on the pUSD token and its Onramp and Offramp contracts as on PositionManager, while the changelog and the migration guide tie pUSD to the CLOB V2 go-live, which is the reading this guide follows.

The core of Protocol V2 is a second ledger for outcome positions. Markets on the Conditional Tokens Framework (CTF) hold their Yes and No balances in the Conditional Tokens contract. Protocol V2 markets hold them in a contract called PositionManager, which passes each operation to a module: BinaryModule for a plain Yes/No market, NegRiskModule for multi-outcome events and CombinatorialModule for positions built from a set of legs. Combinatorial positions, which combine several existing outcomes into one new Yes and No pair, use Protocol V2 rather than the Conditional Tokens Framework. Orders for V2 positions settle through a separate exchange contract, ExchangeV3, and splits, merges and redemptions go through a contract called the Router.

Protocol V2 also reaches resolution. Polymarket 101 says V2 markets can also use other resolution mechanisms. The Contracts page shows the path: results go from reporter modules through an OracleAggregator to the module that owns the condition, with reporter modules named OO, Chainlink and EOA. The resolution data names a reporter for each resolved condition: UMA_OO, CHAINLINK or EOA. The pages do not expand "OO" or "EOA" or say which markets use which reporter. The resolution guide covers the UMA path in full.

How do the two position systems relate?

The two position systems on Polymarket. Source: docs.polymarket.com/trading/positions/how-positions-work, checked Oct 19, 2026.

Both systems hold Yes and No outcomes as ERC-1155 tokens (the standard the 101 page names for outcome shares), and the documentation says those balances mean the same thing economically for a trader. Splitting pUSD into a Yes and No pair, merging a pair back and redeeming after resolution exist in both, through different contracts. The How Positions Work page warns that a CTF token ID must not be sent to PositionManager, nor a Position ID to Conditional Tokens; it says market discovery provides the identifiers each workflow needs.

What happens to what you already hold? The overview says existing CTF holdings are not converted, and the contract migration page adds that updating an integration does not convert existing CTF balances. The Contracts page also describes a migration path from CTF positions into PositionManager, but Polymarket has to register the condition or event first, and the pages do not say who can use it or when. For Polymarket app and website users, the overview says no technical migration is required beyond completing any approval prompts that appear.

What changed for traders, and what did not

What changed

• The collateral is pUSD instead of USDC.e, so balances, order costs and payouts are in pUSD.
• Some markets keep their positions on the Protocol V2 ledger, and the Polymarket app may show approval prompts.

What stayed the same

• Polymarket's pUSD page puts it this way: day to day, nothing changes. You still deposit, check a balance, trade and withdraw.
• A winning share still redeems for $1.00 each and a losing share becomes worthless, whichever system holds it.
• The Prices & Orderbook page says the order book is shared across markets, while the settlement route depends on which system holds the tokens.
• For integrations already on pUSD, the overview says the collateral, the wallets, the CLOB credentials and the endpoints are unchanged under Protocol V2.

What to check on a market page

• The resolution rules. They define how the market resolves, and some markets can use mechanisms other than UMA. See the resolution guide.
• The unit. Balances, order costs and payouts are in pUSD, not USDC.e, while a limit order is placed with a price and a number of shares.
• Approval prompts. The overview tells Polymarket app and website users to complete any approval prompts that appear. The pages do not say what those prompts approve.
• The version, if you read data. Market data from the Gamma API carries a version, "v1" for CTF markets and "v2" for Protocol V2 markets. The documentation's advice is to read the market's version field, because the presence of an ID field does not tell you. The pages used for this guide do not say that the Polymarket app displays it.
• Official notices. The changelog and the status page announce changes and incidents; the timeline post lists the dated changelog entries.

For developers

Developers had more to do. For CLOB V2, production no longer supports legacy V1 SDKs and V1-signed orders, and the order structure and signing domain changed; the guide Migrating to CLOB V2 has the details. For Protocol V2, Polymarket publishes migration pages for SDK, API and smart-contract integrations, all reached from the overview. In short, you pick identifiers by the market's version, grant fresh approvals because existing CTF permissions do not carry over to V2, sign V2 orders against the V2 exchange and keep CTF support for CTF markets. This guide stops here on purpose.

PolyTerminal is an independent interface for Polymarket and is not operated or endorsed by Polymarket. Orders placed through PolyTerminal carry PolyTerminal’s Polymarket builder code, and PolyTerminal may charge a builder fee on top of Polymarket’s own fees. This page is educational and is not investment advice. Rules were compared with the official documentation on Oct 19, 2026; check the source before you act on a number.