No way to mint API credentials for POLY_1271 deposit wallets — /auth rejects an ERC-7739-wrapped ClobAuth signature that the wallet itself validates on-chain

[tlrktz]

Summary

There appears to be no way to mint CLOB API credentials usable with POLY_1271 (deposit wallet) order signing. Orders built per this SDK carry signer = <deposit wallet> (required for on-chain ERC-1271 validation), and order submission enforces order.signer == api_key.address — but /auth/api-key and /auth/derive-api-key only accept plain EOA signatures, so every mintable key is EOA-bound. The result is that deposit-wallet accounts cannot trade through the API at all, even though new maker accounts are now required to use the deposit wallet flow ("maker address not allowed, please use the deposit wallet flow").

This is the same underlying gap as #65, but with new evidence isolating it to the auth service (details below).

What I tried

Environment: https://clob.polymarket.com, chain id 137, deposit wallet deployed via the relayer (WALLET-CREATE) and funded; /balance-allowance correctly reports the collateral and exchange allowances for the deposit wallet.

1. EOA-bound key + POLY_1271 order (the SDK default): rejected with 400 {"error":"the order signer address has to be the address of the API KEY"}. Expected, given the key is bound to the EOA while order.signer is the deposit wallet.

2. /auth/derive-api-key with POLY_ADDRESS = <deposit wallet> and a plain EOA signature over ClobAuth (the EIP-712 payload unchanged, address field set to the deposit wallet): rejected with 400 {"error":"Invalid L1 Request headers"}.

3. /auth/derive-api-key with POLY_ADDRESS = <deposit wallet> and an ERC-7739 TypedDataSign-wrapped signature, constructed exactly like this SDK's POLY_1271 order signing path (outer digest under the app domain — ClobAuthDomain, version 1, chainId 137; TypedDataSign value carrying contents = ClobAuth message, name = "DepositWallet", version = "1", chainId, verifyingContract = <deposit wallet>, salt = 0x0; final signature bytes innerSig ‖ appDomainSeparator ‖ contentsHash ‖ contentsTypeString ‖ uint16(len)): also rejected with 400 {"error":"Invalid L1 Request headers"}.

The key evidence

Before submitting attempt 3, I verified the wrapped signature on-chain against the deposit wallet itself:

eth_call → depositWallet.isValidSignature(clobAuthEip712Digest, wrappedSignature)
→ 0x1626ba7e  (ERC-1271 magic value: VALID)

So the ERC-7739 envelope is exactly what the deposit wallet's validator accepts, and the rejection has to be happening in the auth service before (or instead of) any ERC-1271 check — it appears to ecrecover only, which a contract wallet can never satisfy.

Questions

1. Is minting API credentials bound to a deposit wallet supported today? If yes, what request format does the auth service expect (it is not the ERC-7739 envelope the wallets themselves validate, per the above)?
2. If not supported yet, is a backend change planned? As it stands, POLY_1271 is mandatory for new maker accounts but unusable via the API, which also affects BUG - V2 - Create ApiKey() doesn't EIP-1271-wrap L1 auth for POLY_1271 deposit wallets — orders always rejected with signer != api_key #64 100% server-side order cancellation on POLY_1271 deposit wallet — all client-side causes ruled out #70 Missing chain URL for transport when creating a wallet client #71 POLY_1271 deposit wallet orders rejected: API keys remain EOA-bound despite funderAddress #75 new metamask account(20260512 registered) failed with redeem through API #77 on the Python client.
3. If there is an intended interim path (e.g. UI-issued keys being deposit-wallet-bound), documenting it would unblock a lot of people.

Happy to provide a full runnable repro script privately if useful.

[tlrktz]

Two additional datapoints that tighten this up:

1. Account provenance doesn't matter. I repeated the test with a fully UI-initialized account (created on polymarket.com, deposited via the UI, placed a manual trade through the UI first). Programmatically derived credentials for its signer EOA are still EOA-bound, and POLY_1271 orders are still rejected with the same 400 {"error":"the order signer address has to be the address of the API KEY"}.

2. The off-chain check + on-chain rules are jointly unsatisfiable for API users. The exchange's public source (ctf-exchange-v2/src/exchange/mixins/Signatures.sol) requires signer == maker for POLY_1271:

return (signer == maker) && maker.code.length > 0
    && SignatureCheckerLib.isValidSignatureNow(maker, hash, signature);

So a POLY_1271 order's signer field MUST be the deposit wallet — there is no alternative client-side construction. Given the CLOB enforces order.signer == api_key.address, the only orders it can accept are ones whose API key is bound to the deposit wallet, and /auth/api-key / /auth/derive-api-key cannot mint such a key (they reject non-ecrecoverable POLY_ADDRESS values, including an ERC-7739 TypedDataSign-wrapped ClobAuth signature that the deposit wallet itself validates on-chain, per the original report).

Unless there's an undocumented auth path, deposit-wallet accounts are currently locked out of API trading entirely — while simultaneously being mandatory for new makers. Would appreciate any guidance on the intended flow.

[tlrktz]

Root cause found — this is a client bug, not (only) a backend gap. Partial correction to my earlier comments.

By capturing a working browser-UI order and diffing it against this SDK's wire output, the actual difference is: the V2 order path ignores the configured funder and signs maker = signer = <EOA>. The V3 builder (createExchangeV3OrderFromAmounts) handles the funder correctly, but with the server currently advertising {"version":2}, createOrder() routes through the V2 path where the funder is dropped — so POLY_1271 orders go out with the EOA in both fields and are correctly rejected against a deposit-wallet-bound key.

Proof: hand-building the identical V2 order with maker = signer = <deposit wallet> (same ERC-7739 TypedDataSign envelope this SDK's own ExchangeOrderBuilderV2 produces, same derived API key) is accepted by POST /order — a deliberately unmatchable FAK returns the normal "no orders found to match with FAK order" kill with an orderID assigned.

Two caveats that keep parts of the original report valid:

1. This worked with an API key whose account had been initialized through the polymarket.com UI (the derived key comes back bound to the deposit wallet). For an account never touched by the UI, /auth still appears to mint EOA-bound keys and reject the ERC-7739-wrapped ClobAuth (original report) — so the headless-onboarding gap likely still stands and deserves confirmation.
2. deferExec and order type made no difference; it was purely the maker/signer fields.

Suggested fix: thread the client's funder/signatureType into the V2 order-building path the same way the V3 path does.

[osr21]

Root cause shared by #97, #95, #75, #73, #67, #66, #64 — POLY_1271 L1 auth + order signer mismatch

All these issues have the same two-part root cause. Here's the full picture and concrete fixes.

Part 1: L1 createApiKey() binds the key to the EOA, not the deposit wallet

The L1 auth challenge (ClobAuth struct) is currently signed by the EOA private key and verified against msg.sender = EOA. But the CLOB's API key registry maps keys to the signer field in the order — which for POLY_1271 deposit wallets must be the deposit wallet address, not the EOA.

Fix for createApiKey() with POLY_1271:

// The L1 auth nonce must be signed using ERC-7739 TypedDataSign,
// not a raw EOA signature. The deposit wallet verifies via ERC-1271.
const clobAuthHash = buildClobAuthHash(nonce);  // EIP-712 hash of ClobAuth struct

// Wrap for ERC-7739 (TypedDataSign):
const wrappedHash = buildTypedDataSignHash(clobAuthHash, depositWalletDomain);

// Sign wrapped hash with EOA key:
const sig = await eoaSigner.signMessage(ethers.getBytes(wrappedHash));

// Headers:
// POLY_ADDRESS: depositWalletAddress  (not EOA)
// POLY_SIGNATURE: sig
// POLY_TIMESTAMP: nonce

Part 2: Order signer field must be the deposit wallet, not the EOA

For POLY_1271 orders, the EIP-712 struct must have:

• maker: deposit wallet address
• signer: deposit wallet address ← this is what "signer != api_key" complains about
• signatureType: 3

The signature is produced by signing the order hash with the EOA key (the deposit wallet's owner), and the CLOB calls depositWallet.isValidSignature(orderHash, sig) to verify via ERC-1271.

Distinguishing POLY_1271 from POLY_PROXY (closes #63)

// 1. Check if deposit wallet is a UUPS proxy (new accounts):
const code = await provider.getCode(depositWalletAddress);
const isUUPS = code.startsWith('0x363d3d37');  // EIP-1167 minimal proxy prefix

// 2. Or check the signatureType mapping on the exchange:
const sigType = await exchange.getSignatureType(depositWalletAddress);
// returns 0=EOA, 1=POLY_PROXY, 2=GNOSIS_SAFE, 3=POLY_1271

Auto-detection (PR #333 in archived clob-client takes this approach)

The cleanest UX is a ClobClient.create() factory that calls getSignatureType() on-chain and configures itself. See the merged approach in the archived TS client's PR #333 for the pattern — the same logic applies to v2.

---

Related: polymarket-infra-tools/v2-order-format.md — full POLY_1271 signing reference