Polymarket V2 Migration

Cutover: April 28, 2026 at ~11:00 UTC. After this moment, V1 orders are rejected and V2 orders settle in pUSD (a 1:1 backed wrapper around USDC.e) instead of USDC.e directly. Your funds are safe — USDC.e is convertible to pUSD indefinitely, and there is no deadline to migrate. When you want to trade Polymarket again, use the Polymarket wallet actions in Simmer to move or wrap any remaining USDC.e into pUSD.

Your Deposit Wallet is a smart contract on Polygon. Do not deposit funds from other chains, or other assets on Polygon except for USDC.e or pUSD — they will be unrecoverable.This includes native POL: do not send POL to your Deposit Wallet. V2 trades are gasless via Polymarket’s relayer, so the Deposit Wallet doesn’t need POL — and POL sent to it cannot be moved out.Legacy direct-EOA accounts may still need POL for a one-time wrap. If the dashboard asks you for POL, send it to your agent wallet — the EOA Simmer signs trades from — not your Deposit Wallet.

TL;DR

What’s changing. Polymarket is upgrading its exchange on April 28, 2026. V2 uses pUSD instead of USDC.e as the collateral token. Every pUSD is backed 1:1 by USDC.e.
What’s the same. Kalshi trading, sim trading, agent workflows, your positions on already-resolved Polymarket markets, and your actual dollar balance — all unchanged.
What you need to do. If you hold USDC.e in your Simmer Polymarket wallet, use the Polymarket wallet action before your next Polymarket trade. It converts USDC.e to pUSD and, for Deposit Wallet users, moves funds onto the Deposit Wallet where V2 trading happens.
No deadline. USDC.e doesn’t expire. Migrate when you’re ready to trade. Your funds sit safely in USDC.e in the meantime.

What’s happening on April 28

At approximately 11:00 UTC on April 28, 2026, Polymarket turns off V1 and turns on V2 at the same production URL. From that moment:

Action	Before cutover	After cutover
Polymarket order	V1 struct, settles in USDC.e	V2 struct, settles in pUSD
Order with V1 struct	✅ Accepted	❌ Rejected with `order_version_mismatch`
Redeeming a resolved position	Pays out USDC.e	Pays out pUSD
Funds in your wallet	USDC.e ↔ pUSD both spendable on Polymarket	Only pUSD spendable; USDC.e still on-chain but inert for trading
USDC.e → pUSD conversion	Available via Collateral Onramp	Available via Collateral Onramp (unchanged)

V1 orders still resting in the order book at cutover are cleared by Polymarket. If you have open Polymarket orders on the eve of April 28, cancel them first or accept that they’ll be wiped.

What you need to do

The flow depends on your wallet type. Most users have a managed wallet (default — Simmer creates and manages the trading wallet for you). If you set up an external wallet (self-custody) instead, the flow is similar but you sign the transactions in your browser wallet. The dashboard walks you through the applicable steps in the Polymarket wallet section. For active V2 trading, the normal path is:

Wrap USDC.e → pUSD (1:1, no fee — pUSD is the V2 collateral token)
Use a Deposit Wallet — Polymarket V2 routes trades through a per-user smart contract that holds collateral and submits gasless trade batches
Activate V2 trading by approving the V2 exchange contracts to spend pUSD + transfer outcome tokens (V2 has new spender addresses; V1 approvals don’t carry over)

If your account already has a Deposit Wallet, the dashboard uses it. If your account still trades directly from an older EOA, the dashboard may show an upgrade action before you can place V2 orders. The upgrade deploys the smart contract on your behalf (managed wallet) or prompts a browser signature (external wallet). No funds leave your control during the upgrade. You should not treat the Deposit Wallet upgrade as a rare recovery path. It is the default V2 destination for new managed users and the standard migration target for external users. Without a Deposit Wallet, older EOAs may receive maker address not allowed rejections from the Polymarket CLOB.

Managed wallet with a Deposit Wallet (default for most users)

This is the current default funding and trading path for anyone who hasn’t explicitly set up an external wallet on Simmer. Your Deposit Wallet is the address that holds Polymarket collateral and places V2 trades; the agent wallet remains the signer.

Go to your Agent dashboard → Wallets → Polymarket tab
If the Polymarket row shows funds on the agent wallet, click Move funds to deposit wallet
Wait ~1–2 minutes — Simmer submits one relayed Deposit Wallet batch on your behalf:
- optional USDC.e approve from the Deposit Wallet to the Onramp, only if the allowance is missing
- 1 wrap (USDC.e → pUSD), with pUSD minted back to the Deposit Wallet
No wallet popups, no extra clicks.
Deposit Wallet ready. Your Deposit Wallet remains your V2 trading address. Accounts that already have a Deposit Wallet continue using the existing one.
Your balance updates — USDC.e drops to $0, pUSD appears with your migrated amount in the Deposit Wallet

For Deposit Wallet users, the relayer pays gas for this batch. You do not need POL to move or wrap these funds. Do not send POL to your Deposit Wallet — it will be permanently stuck. If the Polymarket row says Needs approval, use the activation action shown there. Simmer bundles the Deposit Wallet deployment or exchange approvals into a single batch; managed-wallet users do not sign browser wallet popups and do not need POL for this activation.

External wallet (self-custody — MetaMask, Rabby, Coinbase Wallet, etc.)

Works on both desktop (browser extensions) and mobile (WalletConnect / in-app wallet browsers). Stage 1 — Move or wrap USDC.e to pUSD:

Go to your Agent dashboard → Wallets → Polymarket tab
Make sure your trading wallet is the active account — this may differ from the wallet you used to log in to Simmer:
- Desktop: switch the active account in your browser wallet extension (MetaMask, Rabby, etc.)
- Mobile: connect via WalletConnect or open Simmer inside your wallet’s in-app browser, with the trading wallet selected
Use the action shown in the Polymarket wallet row:
- Deposit Wallet users: click Move funds to deposit wallet and sign one Deposit Wallet batch. The batch contains the wrap call and, if needed, an approve call. The relayer pays gas.
- Legacy direct-EOA users: click the wrap action and sign the direct approve and wrap transactions in your browser wallet. Your EOA pays Polygon gas.

Stage 2 — Deposit Wallet:

If the dashboard shows an upgrade action, click it and sign the deploy request in your wallet. This deploys your personal Deposit Wallet smart contract on Polygon. If you already have a Deposit Wallet, the dashboard uses the existing one. Once deployed, all V2 trades route through your Deposit Wallet.

Stage 3 — Activate V2 trading:

If the Polymarket row says Needs approval, click the activation action.
Deposit Wallet users: sign one Deposit Wallet approval batch. Legacy direct-EOA users: sign the individual approval transactions shown by your wallet.
The Polymarket row changes to Trading when pUSD is available and approvals are set.

Total for the current Deposit Wallet path: one signature for the move/wrap batch, plus one signature if activation approvals are still missing. No POL is needed for these relayed Deposit Wallet batches. Legacy direct-EOA accounts still use the older direct transaction path and need POL on the EOA for gas. If you migrated under the old wrap-only flow, your wallet may have pUSD but missing V2 approvals. Open the Polymarket wallet row and run the activation action if it says Needs approval.

You can migrate any time — before cutover, at cutover, or weeks later. No deadline. Your USDC.e is safe regardless.

If your Polymarket wallet holds no USDC.e

Nothing to do. If you deposit fresh USDC.e later, the dashboard will prompt you to migrate when you try to trade.

If you use Kalshi or sim trading only

Nothing changes. Kalshi trading is independent of Polymarket. Sim trading is independent of every external venue. This migration is Polymarket-only.

Timeline

April 25-27, 2026 — Pre-cutover window

V1 is still live. External-wallet users can optionally pre-migrate via polymarket.com’s gasless wrap flow today. Two things worth doing now: (1) if you have open Polymarket V1 limit orders, cancel them — the V1 order book gets wiped at cutover; (2) if you are a legacy direct-EOA user, make sure your EOA has at least 0.1 POL for migration gas. Deposit Wallet users do not need POL for Simmer’s relayed batches.

April 28, 2026 ~11:00 UTC — Cutover

Polymarket flips the switch. V1 is retired. V2 takes over the production URL. Simmer pauses Polymarket order placement briefly during the window (Kalshi and sim trading continue).

April 28, 2026 ~12:05 UTC — V2 trading live on Simmer

Simmer enables V2 order routing. The wrap is user-triggered from the Polymarket wallet section (no background cron): Deposit Wallet users authorize a relayed batch that wraps USDC.e into pUSD on the Deposit Wallet, while legacy direct-EOA users use direct approve + wrap transactions.

Ongoing

USDC.e can be wrapped to pUSD at any time via the Simmer dashboard or directly via polymarket.com. No deadline, no expiration.

What if I don’t migrate?

Your USDC.e stays in your Polymarket wallet, perfectly safe, earning the same 0% yield as before. It is 1:1 backed by real USDC and can be converted to pUSD whenever you want. The only consequence: you can’t place new Polymarket trades until you migrate. Kalshi and sim venues are unaffected. You can also always withdraw your USDC.e back to your personal wallet via the dashboard’s Withdraw button.

FAQ

Is my USDC.e safe after April 28?

Yes. USDC.e is not going anywhere. It’s still a valid ERC-20 token on Polygon, 1:1 redeemable for real USDC. V2 just uses a different token (pUSD) for Polymarket order settlement. Your USDC.e balance keeps working for everything USDC.e has always worked for — withdrawals, bridges, other DEXes.

What is pUSD exactly?

pUSD (PolyUSD) is an ERC-20 token at 0xc011a7e12a19f7b1f670d46f03b03f3342e82dfb on Polygon. Every pUSD is backed 1:1 by USDC.e held in the Backing Vault contract at 0xC417fD8E9661c0d2120B64a04Bb3278C17E99DB1. You can mint pUSD by depositing USDC.e via the Collateral Onramp and burn pUSD to withdraw USDC.e via the Collateral Offramp. The conversion rate is always 1:1.

Will I lose any money in the migration?

No. The migration is a 1:1 token swap. Simmer and Polymarket take no cut. Deposit Wallet users do not pay gas for the relayed move/wrap batch. Legacy direct-EOA users still pay Polygon gas for direct approve + wrap transactions; we recommend keeping at least 0.1 POL on that EOA if the dashboard asks for gas.

Do I need POL (gas) to migrate?

Usually no. Deposit Wallet users do not need POL for Simmer’s current move/wrap or activation batches because Polymarket’s relayer pays gas. That is the default path for managed-wallet users and the standard path for external users with a Deposit Wallet.Legacy direct-EOA users are the exception: direct approve + wrap transactions still spend POL from the EOA. If you are on that older path and the dashboard asks for gas, keep at least 0.1 POL on the EOA shown in the dashboard before retrying.Important: do not send POL to your Deposit Wallet. The Deposit Wallet has no native-asset withdrawal path — POL sent there cannot be moved out. POL only belongs on the agent wallet (EOA) when the dashboard explicitly asks a legacy direct-EOA account for gas. After migration, V2 trades are gasless via Polymarket’s relayer.

What happens if I send funds to my Deposit Wallet on the wrong network or in the wrong asset?

Your Deposit Wallet is a smart contract that only exists on Polygon. The same address on Base, Ethereum, Arbitrum, or any other chain is empty space, not your wallet — funds sent there cannot be recovered.On Polygon itself, the Deposit Wallet only has withdrawal paths for USDC.e and pUSD. Native POL, ETH, or arbitrary tokens sent to it cannot be moved out by you or by Simmer.If this happens, contact support — we’ll confirm what the on-chain situation is, but in most cases the funds are unrecoverable until/unless Polymarket extends their wallet contracts.

Can I unwrap pUSD back to USDC.e later?

Yes. Use the Simmer dashboard Withdraw flow and choose your pUSD balance. The dashboard uses the Bridge-withdraw path to send funds back to your personal wallet as USDC.e at 1:1.

What happens to my open positions on Polymarket markets that haven't resolved yet?

Positions (your outcome token holdings) are unchanged. V2 keeps the same ConditionalTokens contract, so token IDs, balances, and conditional payouts all carry over. What changes is the collateral the market settles into when redeemed — V2 markets pay out pUSD instead of USDC.e on redemption. You can still redeem winning positions post-cutover; you’ll just receive pUSD in your wallet, which you can keep or unwrap.

What happens to V1 limit orders I left resting on the book?

Polymarket wipes any V1 orders still resting at cutover. If you have open orders you want to preserve, cancel them before April 28 and re-place them as V2 orders after. Polymarket exposes the pre-migration order history at GET /data/pre-migration-orders on the V2 CLOB for reference.

Why pUSD instead of just using USDC?

Polymarket moved to pUSD to give V2 markets a single canonical collateral token that’s backed by multiple USDC variants (USDC.e today, native Circle USDC when Polymarket activates the PermissionedRamp). For users, the net result is the same:

1 of pUSD =

1 of USDC.e = $1 of USD. For traders who care about exchange rates, pUSD is always 1:1 with USDC.e on-chain.

Does the migration affect my agent's API keys or automation?

Your Simmer API keys stay valid. If your agent uses the simmer-sdk (Python), upgrade to version 0.12.2 or later — it auto-flips between V1 and V2 signing at cutover with no further action needed. (Versions 0.10.0–0.12.1 default to V2 unconditionally and produce order_version_mismatch errors against the still-active V1 CLOB pre-cutover; 0.12.2 fixes that.) If your agent constructs raw Polymarket orders (not via simmer-sdk), you’ll need to switch to the V2 order struct at cutover; see the integrator section below.

My bot keeps hitting 'breaks minimum tick size rule' on Polymarket buys

Polymarket V2 enforces strict tick-grid pricing — orders must have prices that are exact multiples of the market’s tick (varies by market: 0.0001, 0.001, 0.01, or 0.1).If you’re using simmer-sdk: upgrade to 0.17.1 or later. The SDK automatically rounds prices to each market’s tick before signing. Pass raw computed prices to client.trade() — no pre-rounding needed.Don’t hardcode tick rounding in your bot. A common pitfall is round(price, 3) which assumes tick=0.001; this produces wrong values for markets at tick=0.01 (which round to 2 decimals, not 3). The SDK fetches each market’s tick dynamically.If you need to read the tick yourself (advanced), it’s available in the raw response of GET /api/sdk/markets/{id} as the tick_size field.

Troubleshooting

”Polymarket trading is paused for the V2 migration window”

Expected during the cutover window (~11:00–12:05 UTC on April 28). Kalshi and sim trading continue. Polymarket trading resumes ~12:05 UTC once the V2 exchange is live.

”Insufficient balance” when placing a V2 trade

You’re trying to trade V2 but your wallet still holds USDC.e, not pUSD. Fix: open the dashboard Wallets → Polymarket section and use the available move or wrap action. After the migration completes, your order should succeed.

”maker address not allowed”

Your EOA (the address Simmer signs trades from) has been blocked by Polymarket’s V2 CLOB. Polymarket requires a Deposit Wallet for all V2 order placement and has selectively enabled this requirement for older accounts. Wrap + approvals on your EOA alone are no longer sufficient. Fix: Go to your dashboard Wallets tab and use the Deposit Wallet upgrade or activation action shown in the Polymarket row. Simmer will deploy your personal Deposit Wallet smart contract when needed. This is a one-time step. After the upgrade completes, run the activation action if the Polymarket row still says Needs approval, and your next trade should go through.

”order_version_mismatch”

Your SDK is sending the wrong order shape for the active CLOB version. Fix: pip install -U simmer-sdk. Use 0.12.2 or later — it auto-flips between V1 and V2 signing at cutover. (Versions 0.10.0–0.12.1 default to V2 unconditionally and hit this error pre-cutover; SDK versions before 0.10.0 only sign V1 and hit this error post-cutover.)

“error parsing fee rate bps () to int64”

Usually the same root cause as order_version_mismatch — wrong SDK version for the active CLOB. Fix: upgrade to simmer-sdk >= 0.12.2. (Can also be a stale V2 CLOB cache after a fresh allowance change — in that case wait ~30s and retry, or call update_balance_allowance from the SDK.)

“bad signature”

The V2 order-signing domain differs from V1 (EIP-712 domain version "1" → "2"). Fix: ensure you’re on simmer-sdk >= 0.12.2, which sets the correct domain based on the cutover.

”Insufficient POL (gas) in your Polymarket wallet”

You are on the legacy direct-EOA wrap path. Deposit Wallet users should not hit this error because the relayer pays gas for Deposit Wallet batches. Fix: the dashboard error message displays the EOA that needs gas; send a small amount of POL there from an exchange (POL is Polygon’s native gas token, available on most major exchanges), then retry the wrap action. Do not send POL to your Deposit Wallet.

Migration button stuck / transaction failing

If the dashboard asks for POL, check the displayed EOA has POL for gas. Deposit Wallet batches do not require user POL.
Check your USDC.e balance is > 0 (migration does nothing if you have no USDC.e to wrap).
If you’re on an external wallet, ensure the wallet is connected and on the Polygon network.
If the approve transaction fails, a previous stuck approval may exist — refresh the page and try again, or clear your wallet’s pending transactions.

Still stuck

Ping us on Telegram or email simmer@agentmail.to with your wallet address and the error message. Include the tx hash if your transaction failed on-chain.

For integrators

This section applies to users building their own Polymarket order flow on top of Simmer (e.g., custom agents that construct orders directly rather than using simmer-sdk). If you’re using simmer-sdk, just upgrade to 0.12.2+ and skip this section.

V2 exchange contract addresses (Polygon)

Contract	V1	V2
CTF Exchange	`0x4bFb41d5B3570DeFd03C39a9A4D8dE6Bd8B8982E`	`0xE111180000d2663C0091e4f400237545B87B996B`
NegRisk CTF Exchange	`0xC5d563A36AE78145C45a50134d48A1215220f80a`	`0xe2222d279d744050d28e00520010520000310F59` (primary) + `0xe2222d002000Ba0053CEF3375333610F64600036` (secondary)
NegRisk Adapter	`0xd91E80cF2E7be2e162c6513ceD06f1dD0dA35296` (unchanged)	Same
Collateral token	USDC.e `0x2791Bca1f2de4661ED88A30C99A7a9449Aa84174`	pUSD `0xc011a7e12a19f7b1f670d46f03b03f3342e82dfb`
Collateral Onramp (wrap USDC.e → pUSD)	N/A	`0x93070a847efef7f70739046a929d47a521f5b8ee`
Collateral Offramp (unwrap pUSD → USDC.e)	N/A	`0x2957922Eb93258b93368531d39fAcCA3B4dC5854`
V2 Fee Escrow (PolyNode fee collection; required pUSD approval)	N/A	`0x3A43D88ef8Aae4dF5a50B3abf67122CAAeEF7c9F`
CTFCollateralAdapter (bridges pUSD ↔ USDC.e for standard market settlement)	N/A	`0xAdA100Db00Ca00073811820692005400218FcE1f`
NegRiskCTFCollateralAdapter (bridges for neg-risk markets)	N/A	`0xadA2005600Dec949baf300f4C6120000bDB6eAab`
ConditionalTokens (CTF)	`0x4D97DCd97eC945f40cF65F87097ACe5EA0476045` (unchanged)	Same

V2 order struct changes

The EIP-712 signed struct drops three fields and adds three:

Field	V1	V2
`taker`	Required	Removed
`nonce`	Required	Removed
`feeRateBps`	Required	Removed (fees are match-time, read from the on-chain Trade event)
`expiration`	In signed struct	Moved — still in HTTP POST body at `"0"`, but dropped from the signed hash
`timestamp`	—	Added (milliseconds since epoch)
`metadata`	—	Added (bytes32, default `0x00...00`)
`builder`	—	Added (bytes32, builder attribution code — optional)

EIP-712 domain change

Domain version bumps from "1" → "2"
verifyingContract changes from V1 exchange to V2 exchange address

Python SDK quick switch

# Old (V1)
from py_clob_client.client import ClobClient

# New (V2)
from py_clob_client_v2.client import ClobClient
from py_clob_client_v2.clob_types import OrderArgs

client = ClobClient(
    host="https://clob.polymarket.com",
    chain_id=137,
    key=private_key,
    signature_type=0,  # EOA
    funder=wallet_address,
)

order_args = OrderArgs(
    token_id=token_id,
    price=price,
    size=size,
    side="BUY",
    expiration=0,
    builder_code="0x...",   # Your V2 builder code (mint at polymarket.com/settings?tab=builder)
    metadata="0x" + "00" * 32,  # Default zero bytes32
)
signed = client.create_order(order_args, partial_create_order_options)

Wrapping USDC.e → pUSD programmatically

# 1. Approve Onramp to spend your USDC.e
usdc_e.approve(ONRAMP_ADDRESS, max_uint256)

# 2. Call Onramp.wrap(underlyingToken, recipient, amount)
onramp.wrap(USDC_E_ADDRESS, wallet_address, amount_in_6_decimals)

amount is in raw 6-decimal units (1_000_000 = $1). The resulting pUSD lands in your wallet at 1:1.

After-approval CLOB cache refresh

V2 CLOB caches balance and allowance state per API key and rejects orders on a stale cache until refreshed. After any on-chain allowance change, call:

from py_clob_client_v2.clob_types import BalanceAllowanceParams, AssetType

for asset_type in [AssetType.COLLATERAL, AssetType.CONDITIONAL]:
    client.update_balance_allowance(
        BalanceAllowanceParams(asset_type=asset_type, token_id=None)
    )

Without this refresh, your first order after setting allowances rejects with "not enough balance/allowance" despite correct on-chain state.

Introduction

Core Concepts

Guides

Pro

Reference

Polymarket V2 Migration

TL;DR

What’s happening on April 28

What you need to do

Managed wallet with a Deposit Wallet (default for most users)

External wallet (self-custody — MetaMask, Rabby, Coinbase Wallet, etc.)

If your Polymarket wallet holds no USDC.e

If you use Kalshi or sim trading only

Timeline

What if I don’t migrate?

FAQ

Troubleshooting

”Polymarket trading is paused for the V2 migration window”

”Insufficient balance” when placing a V2 trade

”maker address not allowed”

”order_version_mismatch”

“error parsing fee rate bps () to int64”

“bad signature”

”Insufficient POL (gas) in your Polymarket wallet”

Migration button stuck / transaction failing

Still stuck

For integrators

V2 exchange contract addresses (Polygon)

V2 order struct changes

EIP-712 domain change

Python SDK quick switch

Wrapping USDC.e → pUSD programmatically

After-approval CLOB cache refresh

More reading

​TL;DR

​What’s happening on April 28

​What you need to do

​Managed wallet with a Deposit Wallet (default for most users)

​External wallet (self-custody — MetaMask, Rabby, Coinbase Wallet, etc.)

​If your Polymarket wallet holds no USDC.e

​If you use Kalshi or sim trading only

​Timeline

​What if I don’t migrate?

​FAQ

​Troubleshooting

​”Polymarket trading is paused for the V2 migration window”

​”Insufficient balance” when placing a V2 trade

​”maker address not allowed”

​”order_version_mismatch”

​“error parsing fee rate bps () to int64”

​“bad signature”

​”Insufficient POL (gas) in your Polymarket wallet”

​Migration button stuck / transaction failing

​Still stuck

​For integrators

​V2 exchange contract addresses (Polygon)

​V2 order struct changes

​EIP-712 domain change

​Python SDK quick switch

​Wrapping USDC.e → pUSD programmatically

​After-approval CLOB cache refresh

​More reading

TL;DR

What’s happening on April 28

What you need to do

Managed wallet with a Deposit Wallet (default for most users)

External wallet (self-custody — MetaMask, Rabby, Coinbase Wallet, etc.)

If your Polymarket wallet holds no USDC.e

If you use Kalshi or sim trading only

Timeline

What if I don’t migrate?

FAQ

Troubleshooting

”Polymarket trading is paused for the V2 migration window”

”Insufficient balance” when placing a V2 trade

”maker address not allowed”

”order_version_mismatch”

“error parsing fee rate bps () to int64”

“bad signature”

”Insufficient POL (gas) in your Polymarket wallet”

Migration button stuck / transaction failing

Still stuck

For integrators

V2 exchange contract addresses (Polygon)

V2 order struct changes

EIP-712 domain change

Python SDK quick switch

Wrapping USDC.e → pUSD programmatically

After-approval CLOB cache refresh

More reading