Cannot place CLOB orders programmatically with an email/Magic deposit-wallet account (POLY_1271) — API key L1 auth binds to EOA, not the deposit wallet

[andreaardenti]

Hi Polymarket team,

I'm building a trading bot on the CLOB and I'm blocked by what appears to be a known SDK/server bug affecting email/Magic deposit-wallet accounts (smart accounts using signature type POLY_1271 / type 3).

Account details

Deposit wallet (funder, holds the pUSD collateral): 0xedbD0485157A8dFE1cF6CDcbae4b80476D2c464D
Signing EOA (owner of the deposit wallet): 0x589E014f451cB5F0278851CCBeF170CF70a048f9
Signature type: 3 (POLY_1271)
SDK: @polymarket/clob-client-v2@1.0.8
What works

getBalanceAllowance correctly returns my collateral balance and allowances (with signature type 3).
Order creation/signing succeeds and reaches the API (EIP-1271 order signing is correct — order.signer = the deposit wallet).
The problem
Every order is rejected with:

"the order signer address has to be the address of the API KEY" (HTTP 400)
Root cause (confirmed empirically)
The API key is bound to the EOA (0x589E…), while for POLY_1271 the order signer is the deposit wallet (0xedbD…) — so they never match. I verified this both ways:

With POLY_ADDRESS = EOA → auth succeeds, but the order is rejected (signer ≠ API key).
With POLY_ADDRESS = deposit wallet → auth fails with "Unauthorized/Invalid api key" (401), because no API key exists for the deposit wallet.
The createApiKey / createOrDeriveApiKey L1 auth sends a plain ECDSA signature (not EIP-1271-wrapped), so the CLOB registers the key to the EOA and there's no way to obtain a key bound to the deposit wallet. This matches the open issue: #64

What I've already tried (all fail the same way)

Programmatic key derivation via the SDK (createOrDeriveApiKey).
Static API credentials generated from the web UI, placed in env.
Overriding the request POLY_ADDRESS header to the deposit wallet.
My question
How can an email/Magic deposit-wallet account obtain a CLOB API key that is bound to the deposit wallet (funder), so that POLY_1271 orders are accepted? Is there a supported workaround today (e.g., a specific endpoint, a UI flow, or a beta build), or is there an ETA for the EIP-1271-wrapped L1 auth fix?

Thanks a lot for your help.

[CrisisAlpha]

Data points from a production integration that trades via signature type 3 (relayer-deployed deposit wallet, live fills since mid-July), I spent some time in exactly this failure mode.

What works for us as of July (stock @polymarket/clob-client-v2@1.0.8):

• signatureType: 3, funderAddress: <deposit wallet>, signer = the owner EOA.
• L2 creds derived via L1 ClobAuth signed by the owner EOA (POLY_ADDRESS = EOA). The API key stays bound to the EOA; the order signer is the deposit wallet, and since roughly 2026-07-01 the venue accepts that pairing when the EOA is the wallet's owner (same server-side change reported in POLY_1271 (sig type 3) order placement fails: L1 auth always binds API key to EOA, never the deposit wallet py-clob-client-v2#70).

So "key bound to EOA" is no longer fatal by itself. Given yours still fails, two checks that give ground truth instead of guessing:

1. Is your signing EOA actually the wallet's owner?
   eth_call owner() (selector 0x8da5cb5b) on the deposit wallet. For email/Magic accounts the wallet's owner key is not always the key you exported — if owner() != your EOA, no client-side configuration can fix it.
2. Does the deployed wallet accept your order signature at all?
   eth_call isValidSignature(bytes32 digest, bytes sig) on the deposit wallet with the EIP-712 order digest and the SDK-produced signature. 0x1626ba7e = valid, 0xffffffff = invalid. On our (relayer-deployed, ERC-1967 beacon proxy) wallets, the SDK's plain EIP-712 owner signature is accepted — no ERC-7739 wrapping needed or wanted. If your wallet returns 0xffffffff, your wallet type validates differently (some UI-created ones are EIP-7702 delegated EOAs, per the report in py-clob-client-v2#70) and that's worth putting in this issue.

Two smaller gotchas that cost us time:

• POST /auth/api-key returns an empty body when a key already exists for that address — you must then GET /auth/derive-api-key with the same L1 headers to retrieve it.
• If your creds were created before the early-July server change, delete and re-derive them fresh before concluding anything.

If you just need to unblock: several people in py-clob-client-v2#70 confirmed the unified polymarket-client SDK (AsyncSecureClient.create(private_key=..., wallet=<deposit wallet>)) handles the binding in one step for email/Magic accounts.

[osr21]

Good diagnostics from @CrisisAlpha. A few concrete additions for the wallet-subtype leg of that check.

Pinning the wallet subtype before trusting isValidSignature

The deposit wallet selectors (owner(), isValidSignature) behave the same on both beacon and UUPS proxies, but knowing the subtype matters when the code check is inconclusive:

// Read EIP-1967 storage slots directly (Polygon JSON-RPC)
const IMPL_SLOT   = "0x360894a13ba1a3210667c828492db98dca3e2076cc3735a920a3ca505d382bbc";
const BEACON_SLOT = "0xa3f0ad74e5423aebfd80d3ef4346578335a9a72aeaee59ff6cb3588b35133d50";

const [impl, beacon] = await Promise.all([
  provider.getStorageAt(depositWallet, IMPL_SLOT),
  provider.getStorageAt(depositWallet, BEACON_SLOT),
]);

// impl   != "0x000…0"  → UUPS proxy   (impl slot points to implementation contract)
// beacon != "0x000…0"  → beacon proxy  (beacon slot points to UpgradeableBeacon)
// eth_getCode starts with 0xef0100  → EIP-7702 delegated EOA — different validation path

On beacon proxies (which is what the Polymarket relayer deploys, as CrisisAlpha notes), plain EIP-712 owner signatures work. On EIP-7702 delegated EOAs the signing scheme differs, so the subtype determines whether isValidSignature returns 0x1626ba7e without additional wrapping.

Getting the EIP-712 digest for the isValidSignature probe

Since computing the digest by hand is error-prone, the SDK exposes it after signing:

const order = await client.createOrder({ tokenId, price, size, side });
const digest = (order as any)._sig?.hash;   // raw EIP-712 message hash
// eth_call isValidSignature(digest, sdkSignature) on the deposit wallet
// 0x1626ba7e → valid  ✓     0xffffffff → invalid ✗

If this returns valid, the signing side is correct end-to-end — any rejection at that point is a credentials or header issue, not a signature issue.

API key re-derivation sequence (avoiding the stale-key trap)

// 1. Remove any existing key for the EOA address
await client.deleteApiKey();             // DELETE /auth/api-key, L1 auth with EOA

// 2. Re-derive (deterministic, idempotent):
const creds = await client.deriveApiKey();   // GET /auth/derive-api-key with same L1 headers
//    Note: POST /auth/api-key returns an empty body when a key already exists;
//    GET /auth/derive-api-key is the safe re-fetch path.

deriveApiKey() is safer than createApiKey() for deposit wallet accounts — it is deterministic and survives repeated calls. Despite L1 auth still being EOA-scoped on the SDK side, the July server-side change means the EOA-bound key + deposit-wallet-signer pairing is accepted as long as the EOA is the wallet's owner(). The full root-cause trace is in #63 if useful.