POLY_1271 deposit wallet order rejected: "the order signer address has to be the address of the API KEY"

[Mattirr]

Hi Polymarket team,

I’m trying to use CLOB V2 programmatic order posting with a new deposit wallet account using POLY_1271 / signatureType=3.

The deposit wallet is funded and allowances are OK, but live order posting is rejected by the CLOB.

Observed:

• Owner EOA: 0x75a4...D6D6
• Deposit wallet / funder: 0xAC67...0910
• signatureType: 3 / POLY_1271
• CLOB collateral / pUSD balance in deposit wallet: 3.00
• pUSD allowance: OK for the CLOB contracts
• API credentials are valid for getApiKeys/getOpenOrders
• createAndPostOrder reaches CLOB
• Test order was a 0.10 USDC GTC limit order
• Market orders were OFF

Error returned by CLOB:

"the order signer address has to be the address of the API KEY"

My diagnosis:

The API key appears to be bound to the owner EOA, while the POLY_1271 order signer/maker is the deposit wallet. The CLOB enforces order.signer == api_key.address, so deposit-wallet orders cannot be accepted even when balance and allowances are correct.

Questions:

1. Is there currently a supported way to create/derive CLOB L2 API credentials bound to the deposit wallet for POLY_1271 accounts?

2. Does /auth/api-key support ERC-1271 / EIP-7739 style auth for deposit wallets?

3. If POLY_1271 deposit wallet API trading is currently blocked, is the recommended path to use an official Safe/Proxy/Builder flow with signatureType=1 or signatureType=2?

4. If there is a supported builder/relayer flow for posting CLOB orders from a deposit wallet, please point me to the correct documentation or required parameters.

Important: I am not sharing private keys or API secrets. I can provide sanitized logs if needed.

[crp4222]

This works now as of 2026-07-03 with the stock client, no fallback needed. On a genuine POLY_1271 deposit wallet: signature_type=3, funder = the deposit wallet, sign with your EOA key, then create_or_derive_api_key() returns valid creds (no 401) and get_balance_allowance(COLLATERAL) shows the deposit wallet's collateral. The May-era 401 on the derive path looks fixed server-side since.

On your diagnosis: the API key being bound to your EOA is actually correct and expected, not the blocker. For signature_type=3 the order signer is your EOA (that's what the api key ties to); the deposit wallet is the maker/funder, validated via ERC-1271 at the order layer, not at the api-key step. So you don't need creds "bound to the deposit wallet", and you don't need to drop to sig_type 1 or 2.

One gotcha I hit while testing: derive_api_key() succeeds under both sig_type=1 and =3, but only =3 reports the deposit wallet's balance; =1 derives a POLY_PROXY identity that holds nothing, so it returns 0. If your auth succeeds but collateral reads 0, that's the wrong signature_type, not the 1271 bug. Full repro in #70.