order_version_mismatch recurrence on order submissions — polymarket-cli v0.1.5 (~25 days after #69 fix)

[16bitapex]

Filing as recurrence of #69 (closed 2026-04-29 "seems to be solved now" — no CLI release between filing and fix). Same symptom returned on 2026-05-23.

Error

POST /order → 400 Bad Request
{"error": "order_version_mismatch"}

Surfaced by polymarket clob create-order CLI exit 1.

Environment

• CLI: polymarket-cli v0.1.5 (latest GitHub release, published 2026-03-10)
• Binary path: /usr/local/bin/polymarket (single binary, no node deps)
• Signature types tested: BOTH proxy AND eoa — both fail with identical error (confirmed via SIGNATURE_TYPE=proxy then redeploy with SIGNATURE_TYPE=eoa)
• Order types tested: GTC limit order via clob create-order
• Chain: Polygon (137)
• Read endpoints: all OK (clob ok, clob book, clob price, clob market, wallet show)
• Order endpoints: ALL fail with order_version_mismatch

Reproducer

polymarket clob create-order \n  --token <real-mlb-totals-token-id> \n  --side buy --price 0.50 --size 1 \n  --signature-type proxy --output json

Returns:

{"error":"Status: error(400 Bad Request) making POST call to /order with {\"error\":\"order_version_mismatch\"}"}

Identical when --signature-type eoa substituted.

Hypothesis (per closed #69)

Issue #69 was resolved server-side at the CLOB API without a CLI release. Today's recurrence suggests the schema/version drift has returned. Either:

1. CLOB API expects a new order schema version that v0.1.5 doesn't construct
2. EIP-712 typed-data domain version bumped on the protocol side
3. Required field added to order struct that v0.1.5 doesn't populate

Differential vs #69

• 25 days elapsed since order_version_mismatch on all order submissions since April 28 — polymarket-cli v0.1.4 / v0.1.5 #69 was fixed
• Same CLI version (v0.1.5 — no release in between)
• Same symptom across all signature types (matches order_version_mismatch on all order submissions since April 28 — polymarket-cli v0.1.4 / v0.1.5 #69)
• Read endpoints all healthy (matches order_version_mismatch on all order submissions since April 28 — polymarket-cli v0.1.4 / v0.1.5 #69)

Request

1. Confirm whether CLOB API is currently in a schema-drift state similar to April 28-29
2. If yes — same server-side rollback path as last time, or new CLI release needed?
3. Any flag / env var to control the order version manually for forward-compat?

Linking #69 for prior occurrence.

[alt-barta]

Root cause identified

After diffing the SDK releases, this is a protocol version mismatch between the CLI's pinned SDK and what the CLOB API now requires.

What's happening

polymarket-cli (both v0.1.4 and v0.1.5) is pinned to polymarket_client_sdk_v2 = "0.5.1" in Cargo.toml. SDK 0.5.1 only knows about the V1 protocol:

• Host: https://clob.polymarket.com
• EIP-712 domain version: "1"
• Order fields: taker, nonce, feeRateBps

On 2026-05-01, polymarket_client_sdk_v2 = "0.6.0-canary.1" was published. This canary adds full V2 protocol support:

• Host: https://clob-v2.polymarket.com
• EIP-712 domain version: "2"
• New order fields: timestamp, metadata, builder
• Auto-detects V1 vs V2 on first order build

The CLOB API is now rejecting V1-signed orders with order_version_mismatch. SDK 0.5.1 constructs and signs with the old V1 schema; the server expects V2. Same mechanism as #69 (fixed server-side on April 29 without a CLI release), now recurring because the API has moved to V2 permanently.

Why the CLI didn't get the fix

Cargo.toml uses version = "0.5.1" which under semver resolves to ^0.5.1 — it will never pick up 0.6.0-canary.1 automatically. The canary is also a pre-release, so it requires an explicit opt-in.

Fix

The CLI needs to bump its SDK dependency:

# Cargo.toml
polymarket_client_sdk_v2 = { version = "0.6.0-canary.1", features = ["gamma", "data", "bridge", "clob", "ctf"] }

This should restore order placement without any other code changes since the 0.6.0 SDK auto-detects the protocol version.

Workaround (build from source)

For anyone blocked right now who has Rust installed:

git clone https://github.com/Polymarket/polymarket-cli
cd polymarket-cli
# Edit Cargo.toml: change version = "0.5.1" to version = "0.6.0-canary.1"
cargo build --release
# Binary at ./target/release/polymarket

Happy to submit a PR for the version bump if that would help move it forward.

[fridayyi]

Adding another reproduction from macOS/Homebrew today (2026-06-01), same order_version_mismatch symptom.

Environment

• macOS arm64 (Homebrew install)
• Formula: polymarket/polymarket-cli/polymarket stable 0.1.4
• Installed path: /opt/homebrew/bin/polymarket -> ../Cellar/polymarket/0.1.4/bin/polymarket
• polymarket --version prints polymarket 0.1.0 despite the Cellar/formula being 0.1.4
• CLOB /version returns {"version":2}

Reproduction

A normal CLOB limit order on an active, non-neg-risk market fails before any order is accepted:

{"error":"Status: error(400 Bad Request) making POST call to /order with {\"error\":\"order_version_mismatch\"}"}

Read endpoints (book/balance/metadata) work; order submission fails.

Local diagnostics

After uninstall/untap/retap/reinstall, the binary still reports 0.1.0:

brew uninstall polymarket
brew untap polymarket/polymarket-cli
brew tap Polymarket/polymarket-cli https://github.com/Polymarket/polymarket-cli
brew install polymarket
which polymarket
# /opt/homebrew/bin/polymarket
polymarket --version
# polymarket 0.1.0

The installed binary does not appear to contain obvious V2 markers:

strings $(which polymarket) | grep -E "VERSION_V|exchange_v2|0xE111180000d2663C0091e4f400237545B87B996B"
# no output

A broader strings scan finds Polymarket CTF Exchange, but not the V2 exchange addresses (0xE111...996B, 0xe222...0F59) or exchange_v2.

Cross-check with Python SDK V2

Using py-clob-client-v2==1.0.1 in a dry-run (no POST), the generated typed data aligns with CLOB V2:

{
  "domain": {
    "name": "Polymarket CTF Exchange",
    "version": "2",
    "chainId": 137,
    "verifyingContract": "0xE111180000d2663C0091e4f400237545B87B996B"
  },
  "order_fields": [
    "salt:uint256",
    "maker:address",
    "signer:address",
    "tokenId:uint256",
    "makerAmount:uint256",
    "takerAmount:uint256",
    "side:uint8",
    "signatureType:uint8",
    "timestamp:uint256",
    "metadata:bytes32",
    "builder:bytes32"
  ]
}

So this looks CLI/binary-artifact specific: Homebrew/formula says 0.1.4, but the shipped binary reports 0.1.0 and appears not to include the V2 exchange schema/address, while the server is now /version: 2.

[johnsonice]

same problem here

[osr21]

This error recurs because the V2 order format requirements are stricter than V1 in two ways that can get out of sync at runtime:

**Root causes observed:**

1. **EIP-712 domain version mismatch** — V2 orders must use `version: "2"` in the EIP-712 domain. If any cached signing config still uses `version: "1"` (from a saved API key or stale session), the signed hash won't match what the CLOB reconstructs server-side, producing `order_version_mismatch`.

2. **Missing V2 struct fields** — V2 adds `feeRateBps` and `nonce` (a timestamp-based uint256) to the signed struct. If the struct was serialised without these fields (e.g. using an old order-utils library), the domain separator is correct but the type hash differs.

**Diagnostic step:** Log the raw order payload before signing and confirm it contains:
```json
{
"salt": "<random>",
"maker": "<proxyWallet>",
"signer": "<eoaOrApiKey>",
"taker": "0x0000000000000000000000000000000000000000",
"tokenId": "<clobTokenId>",
"makerAmount": "<uint256>",
"takerAmount": "<uint256>",
"expiration": "0",
"nonce": "0",
"feeRateBps": "0",
"side": 0,
"signatureType": 0
}
```

**Why it recurs after a "fix":** The issue typically resurfaces when the binary is rebuilt against a new version of the signing library without updating the EIP-712 type string to include `feeRateBps` and `nonce`. Adding a version-checked assertion at startup against the CLOB `/auth/info` response would make this deterministic rather than runtime-discovered.