Hey devs — need help with the POLY_1271 / deposit-wallet signing path on a new (post-Apr-28) account.
Everything's working on-chain (EIP-7702 deposit wallet deployed + funded, approvals set, CLOB sees balance/allowances). But order placement fails on all 3 SDKs incl. a Rust repro on sdk_v2 0.5.1:
sig_type=3 → 400 "the order signer address has to be the address of the API KEY".
Root cause: L1 auth binds the api-key to the EOA (POLY_ADDRESS=EOA) regardless of funder/sig_type, while POLY_1271 orders use signer=deposit wallet — so they never match (issues #64/#65/#70). And the deeper wall: the deposit wallet is a Privy embedded wallet (#344/#57), so the UI-exported key is only half a TSS share — client-side signing can't authorize it at all.
Three questions:
1. Can a new user get a non-Privy account (sig_type 0/1/2) for programmatic trading?
2. If not — is there a supported Privy server-signing / session-signer path?
3. ETA on the #70 L1-binding fix?
Funds safe, happy to share traces/repro. ud83dude4f
Hey devs — need help with the POLY_1271 / deposit-wallet signing path on a new (post-Apr-28) account.
Everything's working on-chain (EIP-7702 deposit wallet deployed + funded, approvals set, CLOB sees balance/allowances). But order placement fails on all 3 SDKs incl. a Rust repro on sdk_v2 0.5.1:
sig_type=3 → 400 "the order signer address has to be the address of the API KEY".
Root cause: L1 auth binds the api-key to the EOA (POLY_ADDRESS=EOA) regardless of funder/sig_type, while POLY_1271 orders use signer=deposit wallet — so they never match (issues #64/#65/#70). And the deeper wall: the deposit wallet is a Privy embedded wallet (#344/#57), so the UI-exported key is only half a TSS share — client-side signing can't authorize it at all.
Three questions:
1. Can a new user get a non-Privy account (sig_type 0/1/2) for programmatic trading?
2. If not — is there a supported Privy server-signing / session-signer path?
3. ETA on the #70 L1-binding fix?
Funds safe, happy to share traces/repro. ud83dude4f
check you're using:
- sig 3
- py clob v2 1.0.1
- poly address
- eoa pk
check you're using:
- sig 3
- py clob v2 1.0.1
- poly address
- eoa pk
Hey devs — need help with the POLY_1271 / deposit-wallet signing path on a new (post-Apr-28) account.
Everything's working on-chain (EIP-7702 deposit wallet deployed + funded, approvals set, CLOB sees balance/allowances). But order placement fails on all 3 SDKs incl. a Rust repro on sdk_v2 0.5.1:
sig_type=3 → 400 "the order signer address has to be the address of the API KEY".
Root cause: L1 auth binds the api-key to the EOA (POLY_ADDRESS=EOA) regardless of funder/sig_type, while POLY_1271 orders use signer=deposit wallet — so they never match (issues #64/#65/#70). And the deeper wall: the deposit wallet is a Privy embedded wallet (#344/#57), so the UI-exported key is only half a TSS share — client-side signing can't authorize it at all.
Three questions:
1. Can a new user get a non-Privy account (sig_type 0/1/2) for programmatic trading?
2. If not — is there a supported Privy server-signing / session-signer path?
3. ETA on the #70 L1-binding fix?
Funds safe, happy to share traces/repro. ud83dude4f
Hey devs — need help with the POLY_1271 / deposit-wallet signing path on a new (post-Apr-28) account.
Everything's working on-chain (EIP-7702 deposit wallet deployed + funded, approvals set, CLOB sees balance/allowances). But order placement fails on all 3 SDKs incl. a Rust repro on sdk_v2 0.5.1:
sig_type=3 → 400 "the order signer address has to be the address of the API KEY".
Root cause: L1 auth binds the api-key to the EOA (POLY_ADDRESS=EOA) regardless of funder/sig_type, while POLY_1271 orders use signer=deposit wallet — so they never match (issues #64/#65/#70). And the deeper wall: the deposit wallet is a Privy embedded wallet (#344/#57), so the UI-exported key is only half a TSS share — client-side signing can't authorize it at all.
Three questions:
1. Can a new user get a non-Privy account (sig_type 0/1/2) for programmatic trading?
2. If not — is there a supported Privy server-signing / session-signer path?
3. ETA on the #70 L1-binding fix?
Funds safe, happy to share traces/repro. ud83dude4f
Appreciate the snippet — I did exactly that, on your recommended version, and it still fails. Details so this can go to whoever owns the deposit-wallet auth:
- Upgraded to py-clob-client-v2 1.0.1 (confirmed, removed legacy V1).
- Ran your exact code: signature_type=3, funder=deposit wallet, create_or_derive_api_key(), then create_and_post_order().
- Deposit wallet is deployed (EIP-7702, impl 0xe6Cae83BdE06E4c305530e199D7217f42808555B), funded with pUSD, approvals set, CLOB sees balance + allowances.
Result:
- create_or_derive_api_key() returns an EOA-bound key (121457bb-...), not one bound to the deposit wallet.
- get_api_keys() shows only that EOA key.
- POST /auth/api-key → 400 "Could not create api key" (so it falls back to derive, which returns the EOA key).
- create_and_post_order → 400 "the order signer address has to be the address of the API KEY".
So the precondition you described — "the derived key only resolves to the deposit wallet when the wallet is deployed and your signing EOA is its registered signer" — is exactly the issue: the wallet is deployed, but the SDK's L1 auth signs as the EOA and registers the key under the EOA regardless of funder/signature_type. The key never resolves to the deposit wallet, so signer != api-key owner, every time.
Reproduced identically on Rust 0.5.1 too. Same as GitHub #83 (different dev, current SDK, same wall — they also note the api-key UUID is deterministic, so DELETE+CREATE returns the same EOA key).
My actual question: is my signing EOA (0xc101...) the registered signer on the deposit wallet, or is that wallet Privy-custodied (per #344/#57)? If the registered signer is a Privy address and not the exported key, then no client-side signing can ever resolve the key to the deposit wallet — which would mean this needs a server-signing path or a non-Privy account, not an SDK config change. That's the yes/no I need from engineering.
Happy to share full traces. Thanks.
Appreciate the snippet — I did exactly that, on your recommended version, and it still fails. Details so this can go to whoever owns the deposit-wallet auth:
- Upgraded to py-clob-client-v2 1.0.1 (confirmed, removed legacy V1).
- Ran your exact code: signature_type=3, funder=deposit wallet, create_or_derive_api_key(), then create_and_post_order().
- Deposit wallet is deployed (EIP-7702, impl 0xe6Cae83BdE06E4c305530e199D7217f42808555B), funded with pUSD, approvals set, CLOB sees balance + allowances.
Result:
- create_or_derive_api_key() returns an EOA-bound key (121457bb-...), not one bound to the deposit wallet.
- get_api_keys() shows only that EOA key.
- POST /auth/api-key → 400 "Could not create api key" (so it falls back to derive, which returns the EOA key).
- create_and_post_order → 400 "the order signer address has to be the address of the API KEY".
So the precondition you described — "the derived key only resolves to the deposit wallet when the wallet is deployed and your signing EOA is its registered signer" — is exactly the issue: the wallet is deployed, but the SDK's L1 auth signs as the EOA and registers the key under the EOA regardless of funder/signature_type. The key never resolves to the deposit wallet, so signer != api-key owner, every time.
Reproduced identically on Rust 0.5.1 too. Same as GitHub #83 (different dev, current SDK, same wall — they also note the api-key UUID is deterministic, so DELETE+CREATE returns the same EOA key).
My actual question: is my signing EOA (0xc101...) the registered signer on the deposit wallet, or is that wallet Privy-custodied (per #344/#57)? If the registered signer is a Privy address and not the exported key, then no client-side signing can ever resolve the key to the deposit wallet — which would mean this needs a server-signing path or a non-Privy account, not an SDK config change. That's the yes/no I need from engineering.
Happy to share full traces. Thanks.
You're using the wrong address
You're using the wrong address
Which address specifically? Here's exactly what I'm using so we're precise:
- key (signer EOA): 0xc101...EA11 — the exported PK from the account
- funder: 0x8D5Bc6a0...9Ec0 — this is the deposit address polymarket.com itself shows in the Deposit flow, and it's where my $10 deposit landed and deployed the wallet (EIP-7702, on-chain confirmed)
If the funder should be something other than the deposit address the UI gave me, what should it be? And if the signer EOA is wrong, what address should be signing — because that's the only private key the account's Export PK gave me.
I'm not trying to argue, I genuinely want the right values. If there's a different signer/funder pairing that makes create_or_derive_api_key() resolve the key to the deposit wallet, tell me the two addresses and I'll run it right now and report back.
Which address specifically? Here's exactly what I'm using so we're precise:
- key (signer EOA): 0xc101...EA11 — the exported PK from the account
- funder: 0x8D5Bc6a0...9Ec0 — this is the deposit address polymarket.com itself shows in the Deposit flow, and it's where my $10 deposit landed and deployed the wallet (EIP-7702, on-chain confirmed)
If the funder should be something other than the deposit address the UI gave me, what should it be? And if the signer EOA is wrong, what address should be signing — because that's the only private key the account's Export PK gave me.
I'm not trying to argue, I genuinely want the right values. If there's a different signer/funder pairing that makes create_or_derive_api_key() resolve the key to the deposit wallet, tell me the two addresses and I'll run it right now and report back.
funder is wrong
funder is wrong
Go to your profile and click the button beside the pencil
Go to your profile and click the button beside the pencil
Hi guys, I've been experiencing this error when trying to post orders via CLOB SDK even when using POLY_1271 + auth with funder
```Order failed: the order signer address has to be the address of the API KEY```
This is a new wallet created to trade programatically onto Polymarket, I signed all setup needed txs, I made a trade from UI just to check if trading works from it, tried creating a relayer api key, deposited funds from signer wallet but could not figure it out, does anyone have an idea of how to fix this or what could be the problem?
Hi guys, I've been experiencing this error when trying to post orders via CLOB SDK even when using POLY_1271 + auth with funder
```Order failed: the order signer address has to be the address of the API KEY```
This is a new wallet created to trade programatically onto Polymarket, I signed all setup needed txs, I made a trade from UI just to check if trading works from it, tried creating a relayer api key, deposited funds from signer wallet but could not figure it out, does anyone have an idea of how to fix this or what could be the problem?
Looks like you're using wrong combination of your main wallet and funder wallet (address in PM UI near your account icon).
Looks like you're using wrong combination of your main wallet and funder wallet (address in PM UI near your account icon).
I really checked it 20 times, using wallet address as polygon address and funder address as polymarket UI address, this really seems to be a bug from polymarket side :/
I really checked it 20 times, using wallet address as polygon address and funder address as polymarket UI address, this really seems to be a bug from polymarket side :/
Could be. I just saw exactly the same message myself when I used accidentally wrong funding address
Could be. I just saw exactly the same message myself when I used accidentally wrong funding address
Appreciate the snippet — I did exactly that, on your recommended version, and it still fails. Details so this can go to whoever owns the deposit-wallet auth:
Upgraded to py-clob-client-v2 1.0.1 (confirmed, removed legacy V1).
Ran your exact code: signature_type=3, funder=deposit wallet, create_or_derive_api_key(), then create_and_post_order().
Deposit wallet is deployed (EIP-7702, impl 0xe6Cae83BdE06E4c305530e199D7217f42808555B), funded with pUSD, approvals set, CLOB sees balance + allowances.
Result:
create_or_derive_api_key() returns an EOA-bound key (121457bb-...), not one bound to the deposit wallet.
get_api_keys() shows only that EOA key.
POST /auth/api-key → 400 "Could not create api key" (so it falls back to derive, which returns the EOA key).
create_and_post_order → 400 "the order signer address has to be the address of the API KEY".
So the precondition you described — "the derived key only resolves to the deposit wallet when the wallet is deployed and your signing EOA is its registered signer" — is exactly the issue: the wallet is deployed, but the SDK's L1 auth signs as the EOA and registers the key under the EOA regardless of funder/signature_type. The key never resolves to the deposit wallet, so signer != api-key owner, every time.
Reproduced identically on Rust 0.5.1 too. Same as GitHub #83 (different dev, current SDK, same wall — they also note the api-key UUID is deterministic, so DELETE+CREATE returns the same EOA key).
My actual question: is my signing EOA (0xc101...) the registered signer on the deposit wallet, or is that wallet Privy-custodied (per #344/#57)? If the registered signer is a Privy address and not the exported key, then no client-side signing can ever resolve the key to the deposit wallet — which would mean this needs a server-signing path or a non-Privy account, not an SDK config change. That's the yes/no I need from engineering.
Happy to share full traces. Thanks.
Appreciate the snippet — I did exactly that, on your recommended version, and it still fails. Details so this can go to whoever owns the deposit-wallet auth:
Upgraded to py-clob-client-v2 1.0.1 (confirmed, removed legacy V1).
Ran your exact code: signature_type=3, funder=deposit wallet, create_or_derive_api_key(), then create_and_post_order().
Deposit wallet is deployed (EIP-7702, impl 0xe6Cae83BdE06E4c305530e199D7217f42808555B), funded with pUSD, approvals set, CLOB sees balance + allowances.
Result:
create_or_derive_api_key() returns an EOA-bound key (121457bb-...), not one bound to the deposit wallet.
get_api_keys() shows only that EOA key.
POST /auth/api-key → 400 "Could not create api key" (so it falls back to derive, which returns the EOA key).
create_and_post_order → 400 "the order signer address has to be the address of the API KEY".
So the precondition you described — "the derived key only resolves to the deposit wallet when the wallet is deployed and your signing EOA is its registered signer" — is exactly the issue: the wallet is deployed, but the SDK's L1 auth signs as the EOA and registers the key under the EOA regardless of funder/signature_type. The key never resolves to the deposit wallet, so signer != api-key owner, every time.
Reproduced identically on Rust 0.5.1 too. Same as GitHub #83 (different dev, current SDK, same wall — they also note the api-key UUID is deterministic, so DELETE+CREATE returns the same EOA key).
My actual question: is my signing EOA (0xc101...) the registered signer on the deposit wallet, or is that wallet Privy-custodied (per #344/#57)? If the registered signer is a Privy address and not the exported key, then no client-side signing can ever resolve the key to the deposit wallet — which would mean this needs a server-signing path or a non-Privy account, not an SDK config change. That's the yes/no I need from engineering.
Happy to share full traces. Thanks.
Upgraded to py-clob-client-v2 1.0.1 (confirmed, removed legacy V1).
Ran your exact code: signature_type=3, funder=deposit wallet, create_or_derive_api_key(), then create_and_post_order().
Deposit wallet is deployed (EIP-7702, impl 0xe6Cae83BdE06E4c305530e199D7217f42808555B), funded with pUSD, approvals set, CLOB sees balance + allowances.
Result:
create_or_derive_api_key() returns an EOA-bound key (121457bb-...), not one bound to the deposit wallet.
get_api_keys() shows only that EOA key.
POST /auth/api-key → 400 "Could not create api key" (so it falls back to derive, which returns the EOA key).
create_and_post_order → 400 "the order signer address has to be the address of the API KEY".
So the precondition you described — "the derived key only resolves to the deposit wallet when the wallet is deployed and your signing EOA is its registered signer" — is exactly the issue: the wallet is deployed, but the SDK's L1 auth signs as the EOA and registers the key under the EOA regardless of funder/signature_type. The key never resolves to the deposit wallet, so signer != api-key owner, every time.
Reproduced identically on Rust 0.5.1 too. Same as GitHub #83 (different dev, current SDK, same wall — they also note the api-key UUID is deterministic, so DELETE+CREATE returns the same EOA key).
My actual question: is my signing EOA (0xc101...) the registered signer on the deposit wallet, or is that wallet Privy-custodied (per #344/#57)? If the registered signer is a Privy address and not the exported key, then no client-side signing can ever resolve the key to the deposit wallet — which would mean this needs a server-signing path or a non-Privy account, not an SDK config change. That's the yes/no I need from engineering.
Happy to share full traces. Thanks.
Upgraded to py-clob-client-v2 1.0.1 (confirmed, removed legacy V1).
Ran your exact code: signature_type=3, funder=deposit wallet, create_or_derive_api_key(), then create_and_post_order().
Deposit wallet is deployed (EIP-7702, impl 0xe6Cae83BdE06E4c305530e199D7217f42808555B), funded with pUSD, approvals set, CLOB sees balance + allowances.
Result:
create_or_derive_api_key() returns an EOA-bound key (121457bb-...), not one bound to the deposit wallet.
get_api_keys() shows only that EOA key.
POST /auth/api-key → 400 "Could not create api key" (so it falls back to derive, which returns the EOA key).
create_and_post_order → 400 "the order signer address has to be the address of the API KEY".
So the precondition you described — "the derived key only resolves to the deposit wallet when the wallet is deployed and your signing EOA is its registered signer" — is exactly the issue: the wallet is deployed, but the SDK's L1 auth signs as the EOA and registers the key under the EOA regardless of funder/signature_type. The key never resolves to the deposit wallet, so signer != api-key owner, every time.
Reproduced identically on Rust 0.5.1 too. Same as GitHub #83 (different dev, current SDK, same wall — they also note the api-key UUID is deterministic, so DELETE+CREATE returns the same EOA key).
My actual question: is my signing EOA (0xc101...) the registered signer on the deposit wallet, or is that wallet Privy-custodied (per #344/#57)? If the registered signer is a Privy address and not the exported key, then no client-side signing can ever resolve the key to the deposit wallet — which would mean this needs a server-signing path or a non-Privy account, not an SDK config change. That's the yes/no I need from engineering.
Happy to share full traces. Thanks.
<@1356604771208790198> why cant i get a straight answer here on how to proceed?
Upgraded to py-clob-client-v2 1.0.1 (confirmed, removed legacy V1).
Ran your exact code: signature_type=3, funder=deposit wallet, create_or_derive_api_key(), then create_and_post_order().
Deposit wallet is deployed (EIP-7702, impl 0xe6Cae83BdE06E4c305530e199D7217f42808555B), funded with pUSD, approvals set, CLOB sees balance + allowances.
Result:
create_or_derive_api_key() returns an EOA-bound key (121457bb-...), not one bound to the deposit wallet.
get_api_keys() shows only that EOA key.
POST /auth/api-key → 400 "Could not create api key" (so it falls back to derive, which returns the EOA key).
create_and_post_order → 400 "the order signer address has to be the address of the API KEY".
So the precondition you described — "the derived key only resolves to the deposit wallet when the wallet is deployed and your signing EOA is its registered signer" — is exactly the issue: the wallet is deployed, but the SDK's L1 auth signs as the EOA and registers the key under the EOA regardless of funder/signature_type. The key never resolves to the deposit wallet, so signer != api-key owner, every time.
Reproduced identically on Rust 0.5.1 too. Same as GitHub #83 (different dev, current SDK, same wall — they also note the api-key UUID is deterministic, so DELETE+CREATE returns the same EOA key).
My actual question: is my signing EOA (0xc101...) the registered signer on the deposit wallet, or is that wallet Privy-custodied (per #344/#57)? If the registered signer is a Privy address and not the exported key, then no client-side signing can ever resolve the key to the deposit wallet — which would mean this needs a server-signing path or a non-Privy account, not an SDK config change. That's the yes/no I need from engineering.
Happy to share full traces. Thanks.
<@1356604771208790198> why cant i get a straight answer here on how to proceed?
Upgraded to py-clob-client-v2 1.0.1 (confirmed, removed legacy V1).
Ran your exact code: signature_type=3, funder=deposit wallet, create_or_derive_api_key(), then create_and_post_order().
Deposit wallet is deployed (EIP-7702, impl 0xe6Cae83BdE06E4c305530e199D7217f42808555B), funded with pUSD, approvals set, CLOB sees balance + allowances.
Result:
create_or_derive_api_key() returns an EOA-bound key (121457bb-...), not one bound to the deposit wallet.
get_api_keys() shows only that EOA key.
POST /auth/api-key → 400 "Could not create api key" (so it falls back to derive, which returns the EOA key).
create_and_post_order → 400 "the order signer address has to be the address of the API KEY".
So the precondition you described — "the derived key only resolves to the deposit wallet when the wallet is deployed and your signing EOA is its registered signer" — is exactly the issue: the wallet is deployed, but the SDK's L1 auth signs as the EOA and registers the key under the EOA regardless of funder/signature_type. The key never resolves to the deposit wallet, so signer != api-key owner, every time.
Reproduced identically on Rust 0.5.1 too. Same as GitHub #83 (different dev, current SDK, same wall — they also note the api-key UUID is deterministic, so DELETE+CREATE returns the same EOA key).
My actual question: is my signing EOA (0xc101...) the registered signer on the deposit wallet, or is that wallet Privy-custodied (per #344/#57)? If the registered signer is a Privy address and not the exported key, then no client-side signing can ever resolve the key to the deposit wallet — which would mean this needs a server-signing path or a non-Privy account, not an SDK config change. That's the yes/no I need from engineering.
Happy to share full traces. Thanks.
can someone simply just answer why new accounts cant 3rd party confirm trades, and when/how this will be fixed? Ive asked repeatedly and tried everything...
can someone simply just answer why new accounts cant 3rd party confirm trades, and when/how this will be fixed? Ive asked repeatedly and tried everything...