Polymarket Proxy Wallet: Find It and Use It via API

Why does Polymarket separate the signer from the wallet?

Because most Polymarket accounts are smart contract wallets rather than plain externally owned accounts.

When you sign up with an email, Polymarket provisions a smart wallet for you. Your key authorizes actions; the smart wallet holds the collateral and the positions. That arrangement is what makes email signup possible without handing a user a seed phrase, and it is why a naive integration that only knows about one address fails. To analyze other wallets rather than your own, see Predictefy vs Predicts.guru.

The symptom is nearly always the same. You query positions for the address your private key derives, get an empty array, and conclude the account is empty. It is not. You asked the wrong address.

Which wallet type do you have?

This matters for reading older material. Most of what is written about Polymarket "proxy wallets" predates the Deposit Wallet and describes the legacy path. The underlying idea did not change, only the naming and the API surface.

How do you find your account wallet address?

The profile menu on polymarket.com shows it directly. That string, not the address your signing key derives, is the one that holds funds and positions.

Two checks worth doing before you write any code. Confirm the address you copied has a balance you recognize, and confirm it is different from your signer address. If they match, you have an externally owned account and none of the rest of this applies to you.

How do you connect with the current SDK?

The unified client takes the two addresses as separate arguments, which makes the distinction impossible to miss.

import { createSecureClient, relayerApiKey } from "@polymarket/client";
import { privateKey } from "@polymarket/client/viem";

const client = await createSecureClient({
  wallet: process.env.POLYMARKET_WALLET_ADDRESS,
  signer: privateKey(process.env.SIGNER_PRIVATE_KEY),
  apiKey: relayerApiKey({
    key: process.env.RELAYER_API_KEY,
    address: process.env.RELAYER_API_KEY_ADDRESS,
  }),
});

How did older clients express this?

If you are maintaining an integration built on py-clob-client, the same concept appears as two parameters rather than one object.

client = ClobClient(
    host,
    key=PRIVATE_KEY,
    chain_id=137,
    signature_type=1,
    funder=FUNDER_ADDRESS,
)

Getting signature_type wrong produces an authentication failure rather than a helpful message, so it is worth confirming against your actual wallet type rather than copying a value from an example.

What about giving a bot its own key?

A Deposit Wallet owner can authorize a separate signer with scoped, time-limited trading access through session keys. That is the sanctioned way to run automation without putting the account's main key on a server, and it is materially safer than the alternative of copying your primary private key into a deployment environment.

Where does the key actually live?

Whatever wallet type you have, the signing key is yours and should stay in your own process. That is worth stating plainly because it is the property that bounds your risk: an integration layer that reads your data should never be an integration layer that could move it.

Predictefy is built that way. Orders are constructed server side, signed in your process, and relayed back, so key custody never moves. The read surface covers Polymarket as one of 16 venues on a single normalized schema:

curl -s "https://data.predictefy.com/api/polymarket/fetchMarkets?sort=volume&limit=10" \
  -H "Authorization: Bearer pk_live_YOUR_KEY"

Frequently Asked Questions