Spec drift: polymarket — V2 exchange contracts and pUSD collateral token not reflected in spec (live April 28, 2026)

[realfishsam]

Exchange

polymarket

Drift Type

changed_params / auth_change

Severity

CRITICAL — V2 exchange contracts are entirely different from V1. Approvals and on-chain interactions targeting V1 addresses will fail. The collateral token changed, requiring a new wrap/approval flow.

Their Docs

New V2 contract addresses (live 2026-04-28):

• CTF Exchange: 0xE111180000d2663C0091e4f400237545B87B996B (was 0x4bFb41d5B3570DeFd03C39a9A4D8dE6Bd8B8982E)
• Neg Risk Exchange: 0xe2222d279d744050d28e00520010520000310F59 (was 0xC5d563A36AE78145C45a50134d48A1215220f80a)

New collateral token:

• Polymarket USD / pUSD: 0xC011a7E12a19f7B1f670d46F03B03f3342E82DFB (was USDC.e: 0x2791Bca1f2de4661ED88A30C99A7a9449Aa84174)
• API-only operators must call wrap() on the Collateral Onramp contract to convert USDC/USDC.e to pUSD; the UI handles this automatically

New API endpoint required for pUSD balance sync:

• GET /balance-allowance/update — must be called after wrapping pUSD to sync the exchange's cached balance state

Source: https://docs.polymarket.com/v2-migration

Our Cached Spec

The spec files do not document contract addresses. However, any hardcoded addresses in core/src/exchanges/polymarket/auth.ts or index.ts that reference V1 contract addresses will produce failed transactions. The GET /balance-allowance/update endpoint does not exist in core/specs/polymarket/PolymarketClobAPI.yaml.

File: core/specs/polymarket/PolymarketClobAPI.yaml, core/src/exchanges/polymarket/auth.ts

callApi() References at Risk

None specific — but any on-chain interaction (EIP-712 signing with old contract address as verifyingContract) uses the wrong domain.

Hardcoded URL Bypasses

• https://polygon-rpc.com at index.ts:674 — used for on-chain balance lookup

Impact

1. On-chain balance/allowance approvals granted to V1 contract addresses are not recognized by V2 contracts — trading blocked until re-approval.
2. USDC.e allowances don't transfer to pUSD — users need to wrap and re-approve.
3. Balance queries returning 0 are likely because the balance-allowance cache needs the new /balance-allowance/update endpoint to sync.

---

Found by automated spec drift audit

[peterxing]

I opened a focused PR for the actionable spec-drift slice here: #460

What it covers:

• adds GET /balance-allowance/update to the bundled Polymarket CLOB OpenAPI spec;
• exposes updateBalanceAllowance() through the implicit API descriptor;
• adds regression coverage that keeps the V2 pUSD balance path from drifting back to legacy USDC.e.

Verification I ran:

• npm test --workspace=pmxt-core -- polymarket-v2-spec.test.ts --runInBand
• node_modules\\.bin\\tsc.cmd -p core\\tsconfig.json --noEmit
• git diff --check (only existing Windows LF/CRLF warnings)

If helpful, Peter/OpenClaw can also package the remaining Polymarket V2 migration surface into a fixed A$390 readback: contract-address/signing-domain checklist, pUSD wrap/cache-sync flow, approval/trading failure matrix, and copy-paste regression checks against the current PMXT code paths. Contact: info@transhumanism.com.au. Settlement after scope confirmation can be invoice or USDC on Base/Polygon.