auth: sign_api_key_auth uses signer.address for ClobAuth, ignoring POLY_1271 deposit wallet shape

[Nexory]

sign_api_key_auth in src/polymarket/_internal/l1_auth.py:55-77 signs the ClobAuth EIP-712 payload using signer.address (the EOA) for every wallet type, and _resolve_api_credentials in src/polymarket/clients/async_secure.py:2360-2363 calls it without passing wallet_type or any deposit-wallet context. The resulting API key is registered against the EOA, which is incompatible with how the SDK later signs orders for WalletType.DEPOSIT_WALLET (SignatureType.POLY_1271 = 3).

Current flow

# _internal/l1_auth.py:55-77
def sign_api_key_auth(
    signer: LocalAccount,
    *,
    chain_id: int,
    timestamp: int,
    nonce: int = 0,
) -> ApiKeyAuthSignature:
    typed_data = build_api_key_auth_typed_data(
        address=signer.address,        # ← EOA, regardless of wallet_type
        chain_id=chain_id,
        timestamp=timestamp,
        nonce=nonce,
    )
    try:
        signed = signer.sign_typed_data(full_message=typed_data)  # ← raw ECDSA, no 1271 wrap
    except Exception as error:
        raise SigningError(...) from error
    return ApiKeyAuthSignature(
        address=signer.address,        # ← POLY_ADDRESS header = EOA
        nonce=nonce,
        signature="0x" + signed.signature.hex(),
        timestamp=timestamp,
    )

# clients/async_secure.py:2360-2363
signature = sign_api_key_auth(
    signer, chain_id=environment.chain_id, timestamp=int(time.time()), nonce=nonce
)
return await _auth_actions.create_or_derive_api_key(clob, signature)

The caller does not consult wallet_type (despite _ctx.wallet_type being available elsewhere, e.g. async_secure.py:1928, 1953, 1988, 2014).

Asymmetry with the order path

The order path already implements the POLY_1271 wrap correctly:

• src/polymarket/_internal/actions/orders/orders.py:20 — signer = wallet if signature_type == _POLY_1271_SIGNATURE_TYPE else draft.signer
• src/polymarket/_internal/actions/orders/typed_data.py:65-90 — build_order_typed_data wraps the order in TypedDataSign with the DepositWallet domain (_DEPOSIT_WALLET_DOMAIN_NAME = "DepositWallet", verifyingContract: order.signer, salt: BYTES32_ZERO) for _POLY_1271_SIGNATURE_TYPE.
• src/polymarket/_internal/actions/orders/typed_data.py:93-108 — build_order_signature builds the ERC-7739 trailer (appDomainSep + contentsHash + CONTENTS_TYPE hex + length_BE2).

So orders authored by a deposit wallet sign via ERC-7739 wrapping with the wallet as signer/maker; authentication still signs with the EOA. The auth path was simply not updated when the order path picked up POLY_1271 support.

Server-side consequence (matches clob-client-v2 cluster)

The API key is registered with POLY_ADDRESS = <EOA>. Later orders carry maker = ctx.wallet (deposit wallet) and the signer field set to the wallet (per orders.py:20). The CLOB's acceptance check ties the order's signer to the api-key holder, which now mismatch — same shape reported repeatedly on the V2 transitional client:

• Polymarket/clob-client-v2#64, #65, #66 (root cause: createApiKey() doesn't EIP-1271-wrap L1 auth)
• Polymarket/clob-client-v2#67, #69, #73, #75 (deposit wallet orders rejected with "the order signer address has to be the address of the API KEY")

Same root cause, different code organization.

What's needed to fix

Two pieces, mirroring build_order_typed_data / build_order_signature:

1. ApiKeyAuthSignature.address and the address field in the ClobAuth typed-data message must be the deposit wallet when wallet_type == "DEPOSIT_WALLET", not signer.address. Pass wallet / wallet_type from _resolve_api_credentials into sign_api_key_auth.
2. The signature must be ERC-7739 TypedDataSign-wrapped so the CLOB server's isValidSignature call on the deposit wallet contract validates. The wrap pattern already exists in typed_data.py:65-108 and can be ported to a _build_api_key_auth_typed_data deposit-wallet variant + _build_api_key_auth_signature trailer builder.

The blocker is two server-side constants the SDK can't infer alone:

• The app domain separator the CLOB server uses when calling isValidSignature on the deposit wallet for the L1-auth flow (analogous to _app_domain_separator(order) for orders, which derives from the CTF Exchange V2 domain).
• The CONTENTS_TYPE string for ClobAuth (analogous to _ORDER_TYPE_STRING).

Once those two are confirmed by Polymarket, the py-sdk implementation is mechanical — the existing typed_data.py infrastructure can be parametrized over the contents-type.

Impact

Every user with a V2 deposit wallet hits this on first authentication. The ApiKeyCreds returned looks valid, but the first order submission fails server-side with the "signer address has to be the address of the API KEY" error.

Cross-SDK

Same bug in ts-sdk: Polymarket/ts-sdk#73 (beginAuthentication in packages/client/src/clients.ts:418-432 signs ClobAuth with signerAddress regardless of identity.walletType, with no wrap).

Happy to send a PR once the two server-side constants are confirmed.

[Nexory]

Cross-validation update — @Vanlee-S has independently reproduced this same bug across four SDKs and confirmed it in Polymarket/clob-client-v2#66 (comment from 2026-05-28T17:12). Their dedicated reproduction issue with full traces is Polymarket/clob-client-v2#75.

Reproduction matrix:

• @polymarket/clob-client-v2 ✓
• py_clob_client_v2 ✓
• Rust polymarket_client_sdk_v2 ✓
• Across multiple API-key nonces, delete/recreate, EOA fallback — none bind to the deposit wallet

Their conclusion mirrors the analysis in this issue:

all API keys created/derived through the current L1 auth flow still behave as EOA-bound keys ... The L1 auth signature itself likely needs the same ERC-1271 / ERC-7739-style wrapped signature approach used by the V2 order signature path.

They also explicitly request the same two server-side constants flagged here:

1. the appDomainSep used by the CLOB server for ClobAuth L1 auth validation
2. the exact CONTENTS_TYPE string for ClobAuth

So the bug shape is now confirmed across the v2-transitional SDKs (TS, Python, Rust) + the new unified SDKs (Polymarket/ts-sdk#73 + this issue). Same root cause, same fix-blocker. Once those two constants are published, the new-SDK fix is mechanical.

[cesarenaldi]

Polymarket/ts-sdk#73 (comment)

[Nexory]

Mirroring the response from ts-sdk#73 since the same shape applies here — the empirical reproduction from @Vanlee-S at clob-client-v2#75 hits the same backend rejection:

ApiError: the order signer address has to be the address of the API KEY
status: 400

with EOA-bound API key (owner = session signer EOA) and POLY_1271 order signed by the deposit wallet (maker = signer = funder = 0x12e9478965fb198c90198fa2369b2e831718bc89). pUSD funded (11.557746), allowances set to max_uint256 on CTF Exchange + Neg Risk Adapter + Neg Risk CTF Exchange, builder code present.

So either the order-acceptance invariant needs to relax to order.maker → api_key.owner (with POLY_1271 resolution), or the SDK auth path here needs the same walletType branch on beginAuthentication so POLY_1271 wallets register the API key under the deposit wallet's address. Right now the SDK signs and registers as EOA regardless of identity.walletType, which is the contradiction we filed.

Cross-tracked at ts-sdk#73. Happy to align on either fix direction once you've confirmed which side of the invariant should move.

[Nexory]

Closing as resolved — same analysis as Polymarket/ts-sdk#73.

sign_api_key_auth in _internal/l1_auth.py:55-77 always uses signer.address (EOA) for both the ClobAuth typed-data payload and the POLY_ADDRESS header. This is by design: L1 auth is EOA-bound, the deposit wallet address only drives order signature type (POLY_1271) and gasless routing. The unified SDK auto-classifies wallet type via classify_wallet_type() (_internal/wallet.py:136-160), so the wrong-sigType failure mode in the older v2-transitional clients does not apply here.

@cesarenaldi confirmed the L1=EOA / L2=deposit-wallet split as the current backend model on Polymarket/ts-sdk#73. Apologies for the noise.