Order placement returns 400 "maker address not allowed, please use the deposit wallet flow" for Magic.link proxy wallets (py-clob-client-v2 1.0.0 + 1.0.1)

[malyshrus]

Order placement returns 400 "maker address not allowed, please use the deposit wallet flow" for Magic.link proxy wallets

Bug confirmed in py-clob-client-v2 versions 1.0.0 and 1.0.1.
Affects every account whose primary wallet was created via Magic.link (the default
sign-up flow on polymarket.com).

Summary

create_and_post_order consistently returns HTTP 400 with the error message "maker address not allowed, please use the deposit wallet flow" when placing an order signed by a Magic.link-derived EOA on behalf of its corresponding proxy wallet (signature_type=1, POLY_PROXY).

The order is rejected at the API gateway layer before any matching-engine logic runs. The same wallet can deposit, withdraw, and trade through the official Polymarket UI without issue — the rejection is specific to programmatic CLOB access.

This blocks all programmatic order placement for Magic.link-onboarded accounts.

---

Environment

Field	Value
py-clob-client-v2	tested on 1.0.0 and 1.0.1 — both fail identically
Python	3.11
Endpoint	https://clob.polymarket.com/order
Account type	Magic.link (signed up via Polymarket web UI)
Signer EOA	<MAGIC_LINK_DERIVED_EOA>
Funder / proxy wallet	<MAGIC_LINK_PROXY_WALLET>
Signature type	1 (POLY_PROXY) — also tested 3 (POLY_1271), same error
Funded asset	pUSD (0xC011a7E1...), confirmed non-zero balance
Network egress	Tested both direct and via residential proxy — same result

---

Steps to reproduce

import os
from py_clob_client_v2.client import ClobClient
from py_clob_client_v2.clob_types import OrderArgs
from py_clob_client_v2.order_builder.constants import BUY

client = ClobClient(
    host="https://clob.polymarket.com",
    chain_id=137,                          # Polygon mainnet
    key=os.environ["SIGNING_KEY"],         # Magic.link EOA private key
    funder=os.environ["FUNDER_ADDRESS"],   # Magic.link proxy wallet
    signature_type=1,                      # POLY_PROXY
)
client.set_api_creds(client.create_or_derive_api_creds())

# Any liquid market's YES token works — same error on every market.
order_args = OrderArgs(
    token_id="<LIQUID_MARKET_YES_TOKEN_ID>",
    price=0.01,    # far below market — guaranteed NOT to fill
    size=100.0,
    side=BUY,
)

placed = client.create_and_post_order(order_args)   # <-- raises here

---

Expected behavior

Order is accepted and posted to the orderbook, or rejected with a meaningful business-logic error (e.g. insufficient balance, minimum size violation, market closed). The "deposit wallet flow" is a UI funding workflow — it is not a valid order-placement constraint.

Actual behavior

[py_clob_client_v2] request error status=400
url=https://clob.polymarket.com/order
body={"error":"maker address not allowed, please use the deposit wallet flow"}

PolyApiException:
  status_code=400
  error_message={'error': 'maker address not allowed, please use the deposit wallet flow'}

The error is identical regardless of:

• signature_type (tried both 1 POLY_PROXY and 3 POLY_1271)
• Order direction (BUY / SELL), price, or size
• Network egress (direct vs residential proxy)
• SDK version (1.0.0 and 1.0.1)
• Whether the call is create_and_post_order or create_order + post_order separately

---

What we have verified ✅

1. Wallet is funded and active. get_balance_allowance returns the correct non-zero pUSD balance.
2. API credentials are valid. derive_api_credentials succeeds; subsequent reads (orderbook, balances) work fine.
3. EIP-712 signature is well-formed. The order hash matches what OrderBuilder produces, and the recovered signer matches the Magic.link EOA.
4. Same wallet works via UI. Placing the same order through polymarket.com succeeds with no warning.
5. Bug persists on 1.0.1. Upgraded recently, no change in behavior.

---

Hypothesis

The Polymarket order-routing API appears to maintain a server-side allowlist of "approved maker addresses" that excludes Magic.link-managed proxy wallets — despite these wallets being the default wallet type for accounts created via the public web flow.

The error message ("please use the deposit wallet flow") suggests the API is steering users into a UI funding path rather than acknowledging the order placement. This is either:

(a) A deliberate restriction — in which case CLOB API access requires a separate self-managed wallet (e.g. user-imported MetaMask). The docs should make this explicit, and py-clob-client-v2 should surface a clearer pre-flight error (e.g. on derive_api_credentials) rather than letting the user reach create_and_post_order only to fail with this opaque 400.

(b) A bug — the maker-address allowlist needs to include Magic.link proxy wallets, since they are the wallet type the platform itself provisions for new users.

Either way the current behavior is broken from the user's perspective: the SDK accepts the wallet, signs the order, posts it — and the server rejects with a message that makes no sense in the order-placement context.

---

Impact

Blocks every Magic.link-onboarded user from any programmatic CLOB activity:

• 烙 Algorithmic / quant trading
•  Dispute monitoring and automated position closing
•  Dashboard tools that need to place or cancel orders
•  Integrations (e.g. portfolio rebalancers, API connectors)

The only workaround currently is to import a separate EOA into MetaMask, fund it manually, and trade from that — bypassing Magic.link entirely. This contradicts the official onboarding flow.

---

Suggested fix

Either:

1. Allowlist Magic.link proxy wallets at the order-routing API.
2. Document the restriction clearly:
   • In the SDK README under a prominent Wallet requirements section.
   • In derive_api_credentials — return / raise an error before the user signs anything.
   • In the Polymarket developer docs.
3. Replace the error message. "Use the deposit wallet flow" implies a UI action that doesn't exist for API users. A clearer message would be:
   "Magic.link-managed wallets cannot place orders via the CLOB API. Please use a self-custody wallet (e.g. MetaMask)."

---

Reproducer

I'm happy to share full request/response traces (with Authorization headers redacted), order hashes, and the exact OrderArgs construction code in a sanitized form if helpful for reproduction. Just let me know what would be useful.

---

Related

• Originally observed with py-clob-client-v2 1.0.0
• No change after upgrade to 1.0.1
• Multiple existing issues against Polymarket/py-clob-client and Polymarket/py-clob-client-v2 describing the same symptom — but no fix has been merged or root-caused publicly.

---

_{Filed by @malyshrus — an active Polymarket trader running an automated quant pipeline. Please prioritize — this is a hard-block on a fundamental SDK use case.}

[christianGRogers]

Are you certain about the hypothesis. I seem to be getting the same issue using a self managed wallet (Meta Mask). What was the the reproduce conditions you used to bypass this error using a self managed wallet?

[dragonflyuk]

I also can't get this to work, stange thing is it worked a couple of days ago, but now I can't get it to work on, either my deposit wallet or a metamask wallet.

[christianGRogers]

Does Polymarket hire any real engineers or is all of their stuff just made with agents? I feel like v2 has been nothing but broken ai slop. They must have forgotten to say make no mistakes.

[malyshrus]

@christianGRogers @dragonflyuk Update — confirmed working with MetaMask (self-managed) after switching to signature_type=3 (POLY_1271, EIP-1271 smart-contract wallet). The hypothesis was on the right track but the V1/V2 detail matters.

Symptoms (silent failure)

• get_balance_allowance() returns {"balance": "0", "allowances": {...: "0"}} even though the wallet holds real USDC.e/pUSD.
• Order placement either fails the funding check, or — worse — sometimes places on Polymarket but the position never shows in the SDK view.
• No exception is raised. That's why it's hard to find.

What's actually happening

The "Builder address — API use only, do not send funds" label in the Polymarket profile page is misleading. That same address IS your V2 trading proxy: an ERC1967 minimal proxy that gets deployed on first deposit, with your EOA baked into the trailing bytecode. With sig_type=0/1/2 the L2 API silently returns zero data; only sig_type=3 (EIP-1271 / POLY_1271) makes it report real balances and allowances.

Reproduction

1. Connect MetaMask, deposit funds via the Polymarket UI deposit flow.
2. Find your funder address on https://polymarket.com/profile/<EOA> — the HTML embeds proxyAddress, proxyWallet, baseAddress, all pointing to the same smart-contract proxy.
3. SDK init that works:

from py_clob_client_v2.client import ClobClient
from py_clob_client_v2.clob_types import ApiCreds, BalanceAllowanceParams, AssetType
from py_clob_client_v2.constants import POLYGON

cli = ClobClient(
    host="https://clob.polymarket.com",
    key=PRIVATE_KEY,            # your EOA private key
    chain_id=POLYGON,
    creds=ApiCreds(api_key=..., api_secret=..., api_passphrase=...),
    signature_type=3,           # ← POLY_1271 (EIP-1271)
    funder=PROXY_ADDRESS,       # the 0xB04... style proxy from /profile
)
print(cli.get_balance_allowance(
    params=BalanceAllowanceParams(asset_type=AssetType.COLLATERAL),
))
# balance > 0, allowances at max uint

Things I tried that returned zero

sig_type	meaning	result
0	EOA	balance 0 (silent)
1	POLY_PROXY (legacy)	balance 0 (silent)
2	POLY_GNOSIS_SAFE	balance 0 (silent)
3	POLY_1271 (V2 deposit wallet)	works ✅

@dragonflyuk on "it worked a couple of days ago"

Sounds like Polymarket migrated your account from the old POLY_PROXY (sig 1) into the new V2 deposit-wallet flow on the server side, and the old sig type stopped returning real data. Quick sanity check:

from web3 import Web3
w3 = Web3(Web3.HTTPProvider("https://polygon-rpc.com"))
code = w3.eth.get_code(YOUR_FUNDER_ADDRESS)
print(len(code))  # > 0 means it's now a smart-contract proxy → need sig_type=3

If len(code) > 0 and the trailing 20 bytes equal your EOA — you're on the V2 deposit-wallet path and need signature_type=3.

If signature_type=3 still doesn't work for you

• Make sure your api_key/api_secret/api_passphrase come from cli.create_or_derive_api_key() against the same EOA, not from the Polymarket dashboard "Create API Key" UI (those are sometimes scoped to a different builder-id).
• Verify the L1 signing key (PRIVATE_KEY) matches the EOA that owns the proxy (the EOA whose 20 bytes are baked into the proxy bytecode).

[dragonflyuk]

I'll be quite honest, I'm completely confused. I've tried a couple of ways to setup a new account, and got nowhere. Can anyone give me a step by step of how to setup with MetaMask, with which key/wallet address I use for every stage. I'll write off the $20-30 that is lost in there somewhere, if I can get a working system.

…

On Wed, May 13, 2026 at 7:00 PM malyshrus ***@***.***> wrote: *malyshrus* left a comment (Polymarket/py-clob-client-v2#56) <#56 (comment)> @christianGRogers <https://github.com/christianGRogers> @dragonflyuk <https://github.com/dragonflyuk> Update — confirmed working with MetaMask (self-managed) after switching to *signature_type=3 (POLY_1271, EIP-1271 smart-contract wallet)*. The hypothesis was on the right track but the V1/V2 detail matters. Symptoms (silent failure) - get_balance_allowance() returns {"balance": "0", "allowances": {...: "0"}} even though the wallet holds real USDC.e/pUSD. - Order placement either fails the funding check, or — worse — sometimes places on Polymarket but the position never shows in the SDK view. - No exception is raised. That's why it's hard to find. What's actually happening The "Builder address — API use only, do not send funds" label in the Polymarket profile page is *misleading*. That same address IS your V2 trading proxy: an ERC1967 minimal proxy that gets deployed on first deposit, with your EOA baked into the trailing bytecode. With sig_type=0/1/2 the L2 API silently returns zero data; only sig_type=3 (EIP-1271 / POLY_1271) makes it report real balances and allowances. Reproduction 1. Connect MetaMask, deposit funds via the Polymarket UI deposit flow. 2. Find your funder address on https://polymarket.com/profile/<EOA> — the HTML embeds proxyAddress, proxyWallet, baseAddress, all pointing to the same smart-contract proxy. 3. SDK init that works: from py_clob_client_v2.client import ClobClientfrom py_clob_client_v2.clob_types import ApiCreds, BalanceAllowanceParams, AssetTypefrom py_clob_client_v2.constants import POLYGON cli = ClobClient( host="https://clob.polymarket.com", key=PRIVATE_KEY, # your EOA private key chain_id=POLYGON, creds=ApiCreds(api_key=..., api_secret=..., api_passphrase=...), signature_type=3, # ← POLY_1271 (EIP-1271) funder=PROXY_ADDRESS, # the 0xB04... style proxy from /profile )print(cli.get_balance_allowance( params=BalanceAllowanceParams(asset_type=AssetType.COLLATERAL), ))# balance > 0, allowances at max uint Things I tried that returned zero sig_type meaning result 0 EOA balance 0 (silent) 1 POLY_PROXY (legacy) balance 0 (silent) 2 POLY_GNOSIS_SAFE balance 0 (silent) *3* *POLY_1271 (V2 deposit wallet)* *works* ✅ @dragonflyuk <https://github.com/dragonflyuk> on "it worked a couple of days ago" Sounds like Polymarket migrated your account from the old POLY_PROXY (sig 1) into the new V2 deposit-wallet flow on the server side, and the old sig type stopped returning real data. Quick sanity check: from web3 import Web3w3 = Web3(Web3.HTTPProvider("https://polygon-rpc.com"))code = w3.eth.get_code(YOUR_FUNDER_ADDRESS)print(len(code)) # > 0 means it's now a smart-contract proxy → need sig_type=3 If len(code) > 0 and the trailing 20 bytes equal your EOA — you're on the V2 deposit-wallet path and need signature_type=3. If signature_type=3 still doesn't work for you - Make sure your api_key/api_secret/api_passphrase come from cli.create_or_derive_api_key() against the *same* EOA, not from the Polymarket dashboard "Create API Key" UI (those are sometimes scoped to a different builder-id). - Verify the L1 signing key (PRIVATE_KEY) matches the EOA that owns the proxy (the EOA whose 20 bytes are baked into the proxy bytecode). — Reply to this email directly, view it on GitHub <#56 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AHZT3Q7TTNABVMFKFL357SL42SZ2FAVCNFSM6AAAAACYYFUSBCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHM2DINBTHA3DQMJQGY> . Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>. You are receiving this because you were mentioned.Message ID: ***@***.***>

[gpmn]

我也是新注册的邮箱账号, 使用ProxyAddress/Magic.link/私钥/signatureType=1来访问API.
无法查询资金,一直是0
无法下单,一直报告"maker address not allowed, please use the deposit wallet flow"
和你的现象几乎完全一样.