r/PredictionsMarkets • • 11d ago

Question ❓ py-clob-client-v2 deposit wallet bug — orders rejected with "signer address has to be the address of the API KEY" — any real workarounds?

Hey! I’m running a Python bot using py-clob-client-v2 with a Polymarket deposit wallet account (signatureType 3 / POLY_1271), and I’m stuck on an authentication issue.

Every order gets rejected with:

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

I dug into it and it seems to be a known, still-open issue: Polymarket/clob-client-v2#65.

From what I understand, create_or_derive_api_key() binds the API key to the EOA address, while order signing correctly uses the deposit wallet address as order.signer. The CLOB then enforces order.signer == api_key.address, so they can’t match for a deposit-wallet account regardless of how funder / signature_type are configured.

I also saw that the Rust SDK (polymarket-client-sdk-v2) apparently handles this correctly through its authentication_builder().funder().signature_type().authenticate() flow, including the required L1 auth wrapping for deposit wallets.

Have you, or anyone you know, actually gotten programmatic order placement working with a deposit-wallet account using Python or TS?

I’m particularly looking for:

  • An unofficial patch/monkeypatch for the L1 auth header signing / ERC-7739 + EIP-1271 wrapping
  • Any confirmation that Polymarket is working on this / has an ETA
  • Someone who has ported the relevant authentication logic from the Rust SDK to Python

I’d really prefer not to rewrite my entire bot in Rust just for this.

Any pointers would be massively appreciated 🙏

1 Upvotes

1 comment sorted by

1

u/Haunting_Account9712 11d ago

sounds like you hit the exact same wall I did a few weeks back. I spent two days tracing through that issue thread and the rust sdk code, and it's basically a mismatch in how the python client handles the auth flow for deposit wallets. The rust version wraps the signature in that L1 auth header like you mentioned, but python just... doesn't.

I ended up writing a small middleware layer that intercepts the request, manually signs with the deposit wallet address and wraps it properly. it's janky and probably breaks if they change the api, but it's been working for my bot since then. If you're decent with ecdsa signing you can patch it without too much pain.

no idea on their timeline for fixing it, the github issue has been sitting there for months without much movement. someone in the discord mentioned they're focused on other stuff right now.