Skip to main content
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. Migration takes one click on your Simmer dashboard when you want to trade Polymarket again.

​
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, convert it to pUSD before your next Polymarket trade. One click on the dashboard, ~30 seconds.
  • 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:
ActionBefore cutoverAfter cutover
Polymarket orderV1 struct, settles in USDC.eV2 struct, settles in pUSD
Order with V1 struct✅ Accepted❌ Rejected with order_version_mismatch
Redeeming a resolved positionPays out USDC.ePays out pUSD
Funds in your walletUSDC.e ↔ pUSD both spendable on PolymarketOnly pUSD spendable; USDC.e still on-chain but inert for trading
USDC.e → pUSD conversionAvailable via Collateral OnrampAvailable 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

​
If your Polymarket wallet holds USDC.e (most users)

Log in to simmer.markets and click Migrate to V2 on the dashboard banner. Takes ~30 seconds. Your USDC.e balance becomes the same dollar amount in pUSD, and you can trade Polymarket V2 immediately.
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 an external wallet (self-custody — MetaMask, Rabby, Coinbase Wallet, etc.)

Same flow on the dashboard — you’ll sign the approve + wrap transactions in your connected browser wallet (MetaMask, Rabby, Coinbase Wallet, etc.). Your wallet needs a small amount of POL for gas. Alternatively, you can migrate directly at polymarket.com if you prefer their gasless flow.

​
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

1

April 25-27, 2026 — Pre-cutover window

V2 is already live in a test environment. Dashboard migration banner is active — you can wrap your USDC.e to pUSD now. Early migration means zero Polymarket trading interruption for you.
2

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).
3

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

Simmer enables V2 order routing. Users who have already migrated trade immediately. Users still holding USDC.e see the dashboard banner and migrate with one click.
4

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

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.
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.
No. The migration is a 1:1 token swap with no fees beyond the Polygon gas cost for the wrap transaction (~0.02 POL, roughly $0.01). Simmer and Polymarket take no cut.
Yes — the wrap transaction needs a small amount of POL to cover gas for approve + wrap. Most users who have traded Polymarket before already have POL in their wallet. If not, fund your Polymarket wallet address on Polygon before clicking Migrate.
Yes. The Collateral Offramp contract at 0x2957922Eb93258b93368531d39fAcCA3B4dC5854 converts pUSD back to USDC.e at 1:1. Simmer’s dashboard Withdraw flow routes through this when you withdraw a pUSD balance to your personal wallet.
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.
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.
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: 1ofpUSD=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.
Your Simmer API keys stay valid. If your agent uses the simmer-sdk (Python), upgrade to version 0.10.0 or later — it handles the V2 order shape automatically. If your agent constructs raw Polymarket orders (not via simmer-sdk), you’ll need to switch to the V2 order struct; see the integrator section below.

​
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: click Migrate to V2 on the dashboard banner. After the migration completes, your order should succeed.

​
”order_version_mismatch”

Your SDK is sending V1-formatted orders to the V2 exchange. Fix: upgrade simmer-sdk with pip install -U simmer-sdk. Version 0.10.0+ handles V2 automatically.

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

Same root cause as order_version_mismatch — SDK < 0.10.0 sending V1-shaped order to V2. Upgrade 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.10.0, which sets the correct domain based on the migration flag.

​
”No POL in your wallet for gas”

Your external wallet needs a small amount of POL (Polygon’s native token) to sign the approve + wrap transactions on migration. Fix: fund a small amount of POL to your wallet on Polygon, then retry the Migrate button. This only applies to external (self-custody) wallets — managed Simmer wallets handle gas automatically.

​
Migration button stuck / transaction failing

  • Check your Polygon wallet has POL for gas.
  • 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.10.0+ and skip this section.

​
V2 exchange contract addresses (Polygon)

ContractV1V2
CTF Exchange0x4bFb41d5B3570DeFd03C39a9A4D8dE6Bd8B8982E0xE111180000d2663C0091e4f400237545B87B996B
NegRisk CTF Exchange0xC5d563A36AE78145C45a50134d48A1215220f80a0xe2222d279d744050d28e00520010520000310F59 (primary) + 0xe2222d002000Ba0053CEF3375333610F64600036 (secondary)
NegRisk Adapter0xd91E80cF2E7be2e162c6513ceD06f1dD0dA35296 (unchanged)Same
Collateral tokenUSDC.e 0x2791Bca1f2de4661ED88A30C99A7a9449Aa84174pUSD 0xc011a7e12a19f7b1f670d46f03b03f3342e82dfb
Collateral Onramp (wrap USDC.e → pUSD)N/A0x93070a847efef7f70739046a929d47a521f5b8ee
Collateral Offramp (unwrap pUSD → USDC.e)N/A0x2957922Eb93258b93368531d39fAcCA3B4dC5854
CTFCollateralAdapter (bridges pUSD ↔ USDC.e for standard market settlement)N/A0xADa100874d00e3331D00F2007a9c336a65009718
NegRiskCTFCollateralAdapter (bridges for neg-risk markets)N/A0xAdA200001000ef00D07553cEE7006808F895c6F1
ConditionalTokens (CTF)0x4D97DCd97eC945f40cF65F87097ACe5EA0476045 (unchanged)Same

​
V2 order struct changes

The EIP-712 signed struct drops three fields and adds three:
FieldV1V2
takerRequiredRemoved
nonceRequiredRemoved
feeRateBpsRequiredRemoved (fees are match-time, read from the on-chain Trade event)
expirationIn signed structMoved — 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.

​
More reading