该用户的聊天记录定位。
will the maintenance update solve the issue with new authentication type=3 wallets being able to 3rd party trade, nothing i have been able to do will allow the new polymarket wallet sig type to run trades yet
will the maintenance update solve the issue with new authentication type=3 wallets being able to 3rd party trade, nothing i have been able to do will allow the new polymarket wallet sig type to run trades yet
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...
<@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.
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.
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.
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.
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.
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
still waiting for a proper dev response here, its like talking to a wall, then the wall tells you to speak to the other wall 😤
still waiting for a proper dev response here, its like talking to a wall, then the wall tells you to speak to the other wall 😤
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
Polymarket