Signature Types and Proxy Wallets
signature_type=0 means EOA is the funder — simple. signature_type=1 means proxy wallet for magic/email logins. signature_type=2 means the Gnosis Safe proxy that browser-wallet web users get. When to use each, and the funder address trap that bites every new Polymarket integration.
Polymarket supports three main signature types. Two of them are for the proxy wallets that web users get — one flavor for email/magic-link logins, one for browser-wallet logins. One of them is for programmatic bots with direct private keys. Getting the wrong one produces signature errors that do not name the problem.
The Three Types
| Type | Signer | Funder | When to use |
|---|---|---|---|
| 0 | EOA (your private key) | Same EOA | Programmatic bots with direct keys |
| 1 | Signer EOA | Magic/email proxy wallet | Email/social login users |
| 2 | Signer EOA | Gnosis Safe proxy wallet | Browser-wallet (e.g. MetaMask) web users — the most common proxy type |
The signer is whose private key signs the order payload — an EOA (Externally Owned Account, a plain private-key wallet, as opposed to a smart-contract account). The funder is whose balance gets debited when the order fills. For type 0 they are the same address. For types 1 and 2 they are different — the signer controls a separate proxy smart contract that holds the actual USDC.e. Type 2 is the Gnosis Safe proxy that Polymarket auto-deploys when a user connects a browser wallet to polymarket.com, which makes it the most common type among web accounts. (Newer Polymarket web accounts also use a fourth type — signature_type=3, an EIP-1271 smart wallet for the newer deposit-wallet flow — but it follows the same signer-vs-funder logic and is irrelevant for direct-key bots.)
Inline Diagram — Signature Type Matrix
The Funder Address Trap
The classic mistake is to sign an order with signature_type=1 (proxy) but set the funder field to the signer EOA instead of the proxy wallet. Polymarket validates the signature against the signer, then checks the balance at the funder. If the funder is the signer EOA and the signer EOA has no USDC.e (because the funds are in the proxy), the order gets rejected as insufficient balance even though the account is technically "funded."
The reverse mistake is equally common: using signature_type=0 but providing a proxy address as the funder. Polymarket expects funder == signer for type 0; providing anything else produces an "invalid signature" error that does not identify the actual problem.
How to Know Which You Have
If you generated your key with Account.create() or imported a hex private key into Metamask and funded it directly — you have an EOA with type 0 semantics.
If you signed up to Polymarket via the website using email/magic link and never saw a private key — you have a proxy wallet with type 1 semantics. Your funds live in a smart contract proxy, not the signer EOA.
If you connected a browser wallet like MetaMask to polymarket.com — Polymarket auto-deployed a Gnosis Safe proxy for you, and that account has type 2 semantics. Same signer-vs-funder split as type 1, different proxy contract.
If you are a programmatic bot being integrated from scratch — always use type 0. It is the simplest path and avoids proxy-wallet footguns entirely. Agent Framework uses type 0.
The Rule
Type 0 for bots. Types 1 and 2 for web users. Funder matches signer for type 0. Any mismatch produces opaque errors that will eat hours. Know which type you are using before your first order ships.