derive_proxy_wallet returns wrong address — no way to override actual proxy wallet

[Portisclawbot]

Description

polymarket wallet show derives the proxy wallet address locally via derive_proxy_wallet() (CREATE2), but the derived address does not match the actual proxy wallet assigned by Polymarket's backend.

Steps to Reproduce

1. Import a private key that was used to register on Polymarket web UI:

   polymarket wallet import <key> --force
   

2. Check wallet info:

   polymarket wallet show -o json
   

   Returns proxy_address: 0x938C... (locally derived)

3. Query the actual profile from Polymarket API:

   polymarket profiles get <address> -o json
   

   Returns proxyWallet: 0x943F... (server-assigned, different)

4. Check balance:

   polymarket clob balance --asset-type collateral -o json
   

   Returns balance: "0" — because it queries the wrong proxy address.

5. Meanwhile, querying positions with the correct proxy address works:

   polymarket data positions 0x943F... -o json
   

   Returns actual open positions with correct values.

Root Cause

The CLI uses derive_proxy_wallet(address, chain_id) from the SDK to compute the proxy address via CREATE2. However, accounts created through the Polymarket web UI (e.g., via Magic Link / social login) may have a different proxy wallet assigned by the backend. The locally derived address and the server-assigned address diverge.

Impact

• clob balance always returns 0 (queries wrong proxy)
• clob create-order / market-order may fail or operate on wrong proxy
• Any authenticated CLOB command that relies on the derived proxy is broken for these accounts

Suggested Fix

1. Query the actual proxy from the API: Use the profiles get endpoint to fetch the real proxyWallet and cache it, instead of relying solely on local derivation.
2. Allow config override: Add a proxy_wallet field to config.json so users can manually specify their actual proxy address.
3. Add a CLI flag: e.g., --proxy-wallet <address> as a global option.

Environment

• CLI version: v0.1.4
• OS: macOS (arm64)
• Signature type: proxy
• Chain: Polygon (137)

[d5c5ceb0]

I suspect that the integrated contracts are all in a test environment, and the bridged USDC doesn't resolve to USDC.e after swapping.

[mentholmike]

yeah i'm running into this issue. I can't remove the funds from the proxy wallet it generated from the key I imported

[pck101001]

I ran into the same issue and lost ~3 USDC by depositing to the incorrectly derived EIP-1167 proxy address. After digging into the root cause, I have both a fix and a recovery tool for anyone who sent funds to the wrong address.

Root Cause

The CLI uses derive_proxy_wallet() (EIP-1167 minimal proxy, factory 0xaB45...) but Polymarket deploys Gnosis Safe wallets (factory 0xaacF...) for browser wallet users. The two methods use different salt encoding, factory addresses, and init code hashes, producing completely different addresses for the same EOA.

Fix

PR submitted: #22 — changes the default to derive_safe_wallet() with signature_type = "gnosis-safe". Users can still pass --signature-type proxy for Magic Link accounts.

Recovery Tool

If you deposited funds to the EIP-1167 address shown by the old CLI, they are recoverable. The Polymarket Proxy Wallet Factory's proxy() function is permissionless — it atomically deploys the EIP-1167 proxy via CREATE2 and executes arbitrary calls through it in a single transaction.

I wrote a recovery tool and verified it on-chain: recovery tx

Features:

• Auto-scans for Native USDC and USDC.e balances by default
• Supports any ERC20 token via --token <address> (repeatable)
• Supports native POL recovery via --native
• Batches multiple token recoveries into one transaction

How to use:

git clone https://github.com/pck101001/polymarket-cli.git
cd polymarket-cli
git checkout tool/recover-usdc
PRIVATE_KEY=0xYOUR_KEY cargo run --release --bin recover_usdc

Your EOA needs a small amount of POL for gas (~$0.01).

Why this works: ERC20 balances are stored in the token contract's mapping(address => uint256), independent of whether the target address has deployed code. The CREATE2 address is deterministic — deploying the proxy there later gives it control over pre-existing balances. The factory's proxy() function handles deployment + call routing atomically.

@mentholmike This should help you recover your funds.