POLY_GNOSIS_SAFE signature always rejected for migrated V1 Safe/proxy accounts

[peternginpan]

Environment

• Package: @polymarket/clob-client-v2 v1.0.5
• Account type: V1 Gnosis Safe proxy, migrated to V2 (not a new deposit-wallet account)
• Signer: viem createWalletClient + privateKeyToAccount

Steps to reproduce

1. Construct signer via viem:

   const account = privateKeyToAccount(privateKey);
   const signer = createWalletClient({ account, chain: polygon, transport: http(rpcUrl) });
   

const client = new ClobClient({ host, chain: 137, signer, signatureType: 2, funderAddress });
const creds = await client.createOrDeriveApiKey(); // succeeds

const info = await client.getClobMarketInfo(conditionId); // succeeds

const resp = await client.createAndPostOrder(
{ tokenID, price, side: Side.BUY, size },
{ tickSize, negRisk },
OrderType.GTC
);

Expected

Order submits successfully (this account trades fine manually via the Polymarket web UI — funds, permissions, and market access are all confirmed working).

Actual

{ "error": "invalid POLY_GNOSIS_SAFE signature", "status": 400 }

Order is created and signed client-side without any error — the rejection happens server-side on the final POST.

Additional data point

Also tried omitting signatureType entirely (to let the SDK auto-detect):

{ "error": "invalid EOA signature: signer and maker do not match for EOA sig", "status": 400 }

This confirms the SDK falls back to type-0 (pure EOA) signing when signatureType is unset — which is incorrect for a Safe-funded order, and produces a different (also wrong) error.

Per docs, signatureType: 2 (POLY_GNOSIS_SAFE) should be correct for an existing V1 Safe/proxy account post-V2-migration (type 3 / POLY_1271 is documented as being for new deposit-wallet accounts only). Every variation of client construction with type 2 fails with the same signature error, which points to an issue in the Gnosis Safe signing path itself — possibly related to the EIP-712 domain version bump between V1 (version “1”) and V2 (version “2”), or an incorrect verifyingContract in the Safe signature construction.

Happy to provide more detail or test a patch if useful.

KNOWN ISSUES v2.zip

[CrisisAlpha]

Triage steps from having fought the type-2 path (we ultimately ship type 3, so data points, not a definitive fix):

1. Verify the funder is the factory-derived proxy of the signing EOA. The venue only accepts funderAddress == computeProxyAddress(signerEOA) per the Polymarket proxy factory (0xaacfeea03eb1561c4e67d661e40682bd20e3541b, CREATE2 salt = keccak256(signerEOA)). If you sign with any key other than the one the Safe was derived from (delegate, session key, second owner), the Safe check fails even though the UI — which uses the original key — works fine.

2. Ground-truth the signature on-chain instead of guessing at domains: eth_call isValidSignature(orderDigest, sig) on the Safe. 0x1626ba7e = your signature is fine and the problem is server-side; 0xffffffff = the signature really doesn't verify for that Safe.

3. Check you're signing the V2 struct against the V2 domain. V2 changed both the domain version ("1" → "2") and the Order struct (v1's taker/expiration/nonce/feeRateBps are gone; timestamp/metadata/builder are new) — and the standard vs neg-risk exchanges share the same domain name/version, differing only in verifyingContract. A neg-risk token signed against the standard exchange (or vice versa) fails validation. GET /neg-risk?token_id=<id> tells you which exchange the token belongs to; make sure negRisk in your order options matches.

Your EIP-712-domain-bump hypothesis is plausible but (2) will tell you definitively whether to chase the client or the server.