A Polymarket account does not trade from the key you sign with. It trades from a smart contract wallet that the signing key controls. Which contract you get depends on when and how the account was created: a Deposit Wallet for every account wallet deployed on or after May 4, 2026, a legacy Proxy Wallet for accounts made through Magic Link or Google sign-in, and a legacy Safe Wallet for accounts made with an external signer such as MetaMask or Rabby. That one distinction explains most of the confusion people hit when they try to read, fund, or follow a Polymarket address.
The three wallet types, and the date that separates them
Polymarket's own documentation is unusually direct about this. There is one current wallet type and two legacy ones, and the rule is chronological rather than a setting you choose:
| Wallet type | When it applies | Signer |
|---|---|---|
| Deposit Wallet | Every account wallet deployed on or after May 4, 2026. The current default. | Account signer, plus optional session-key signers |
| Proxy Wallet | Legacy. Created through Magic Link or Google authentication on polymarket.com. | Embedded wallet key held behind the login |
| Safe Wallet | Legacy. Created with an external signer such as MetaMask or Rabby. | Your own externally owned account |
In all three cases the same split holds: the signer authorises, the smart wallet owns. Your collateral sits in the smart wallet. Your outcome tokens sit in the smart wallet. The orders are signed by a key that holds none of it. That is why Polymarket tells users to fund the account wallet address shown in the profile menu and not the address their browser extension displays.
Why Polymarket is built this way
Three reasons, all of them practical rather than ideological.
- Gasless trading. A smart wallet can be driven by a relayer. The user signs a message; the relayer pays the gas and submits the transaction. Without the contract in the middle, every single order, approval, split, merge, and redemption would need the user to hold the chain's native gas token and click through a wallet prompt.
- One approval surface. Trading on Polymarket needs ERC-20 and ERC-1155 approvals to several protocol contracts. Doing that once inside a smart wallet is cleaner and safer than asking a retail user to approve repeatedly from an externally owned account.
- Separable authority. A contract can distinguish between the owner and whoever is currently allowed to trade. That is what makes session keys possible, and it is the single most important detail for anyone reading a wallet's activity from outside.
How a Deposit Wallet address is derived
Deposit Wallet addresses are deterministic. You can compute one from the signer address before the contract exists on chain, because the factory deploys with CREATE2 and a salt derived from the signer:
factory = 0x00000000000Fb5C9ADea0298D729A0CB3823Cc07 beacon = 0x7A18EDfe055488A3128f01F563e5B479D92ffc3a walletId = bytes32(signer) args = abi.encode(factory, walletId) salt = keccak256(args) depositWallet = CREATE2(factory, salt, initCodeHashERC1967BeaconProxy(beacon, args))
Two consequences follow from that snippet, and both matter if you are doing any kind of wallet analysis.
First, the mapping from signer to wallet is one-to-one and computable offline. Give a signer address to the derivation and you get exactly one Deposit Wallet address, whether or not it has ever been deployed. Second, the implementation has changed once already: Deposit Wallets deployed before the June 29, 2026 upgrade use a UUPS proxy, and wallets deployed after it use a beacon proxy. If you are deriving addresses for older accounts, the algorithm above will give you the wrong answer, and a wrong answer here looks exactly like an empty wallet rather than like an error.
Session keys: the reason the signer may not be the owner
A Deposit Wallet owner can authorise a separate signer with scoped, time-limited trading access. The practical effect is that the key placing orders can be a short-lived delegate rather than the account owner. This is a good design — it is how an owner can let a bot or a mobile session trade without handing over the account — but it quietly breaks a common assumption in wallet tracking.
If you were inferring identity from the signing key, you were inferring the identity of a session, not a person. Any methodology that treats "same signer" as "same trader" will misread a wallet that rotates session keys, and will also misread two different wallets a single operator drives from one machine. We cover the broader version of this problem in our notes on how to evaluate a Polymarket wallet.
What about trading straight from an externally owned account?
It is possible, with two caveats. The externally owned account has to be allowlisted for trading, and once it is, every on-chain action comes directly from that account: token approvals, transfers, splits, merges, and redemptions. That also means the account pays its own gas in the chain's native token, so the gasless path disappears. For a human trader this is usually a downgrade. For an infrastructure operator who wants no contract in the path, it is sometimes the right trade. Our write-up on Polymarket gas fees goes through what that actually costs in practice.
Six things this changes if you track or copy a wallet
This is where the architecture stops being trivia. Every item below is a mistake we have seen people make, including in public dashboards.
- The public address is the smart wallet. The address in a profile URL, on a leaderboard, or in an API response is the account wallet. Searching a block explorer for the owner's externally owned account will show you funding movements and almost no trading.
- A transfer in is not a trade. Collateral arriving at the smart wallet from an exchange or from the owner's own key is a deposit. Scoring it as position-taking inflates volume and distorts any return calculation built on cash flows.
- One operator can hold several wallets. Derivation is per signer. A single person with several signers has several unrelated-looking account wallets, and nothing on chain announces that they belong together.
- Session keys decouple signer from owner. A change in who signs does not imply a change in who decides. Treating a key rotation as a new trader produces phantom wallets on a leaderboard.
- There are two position ledgers. Polymarket markets use either the PositionManager ledger for Protocol V2 markets or Conditional Tokens for CTF markets. Both express Yes and No as ERC-1155 balances with the same economic meaning, but the identifiers differ, so a tracker that only understands one of them will show a wallet as holding nothing while it is fully invested.
- Wallet type gates what you can read. Legacy Proxy and Safe wallets behave differently from Deposit Wallets at the integration layer. Resolving the type is step one, not a detail to sort out later.
If your tracker cannot tell a deposit from a buy, nothing downstream of it is worth reading. Address resolution is not plumbing; it is the first thing that decides whether a number means anything.
How to tell which wallet type an address is
You do not need a special tool for a quick answer. Work through these in order:
- Check deployment date. The contract's creation transaction places it before or after May 4, 2026, which settles Deposit Wallet versus legacy immediately.
- Check whether it is a contract at all. An address with no code is an externally owned account, which on Polymarket means either a signer or an allowlisted direct trader.
- Try the derivation. If you have a candidate signer, derive the Deposit Wallet address from it. A match confirms the relationship without needing any private data.
- Read the proxy pattern. A UUPS proxy and a beacon proxy expose different storage and different upgrade paths, which separates pre- and post-June 29, 2026 Deposit Wallets.
How Poly Syncer handles it
Our mirroring path resolves the wallet type before it does anything else, because the cost of getting this wrong is not a cosmetic error. Mirroring a deposit as if it were a buy would put real collateral into a market the source wallet never expressed a view on. Classifying a session-key rotation as a new trader would silently reset the sample a score is built from. The order is: resolve the address, classify the event, decide whether it is a position change, and only then consider mirroring it. The scoring side of that is documented in our wallet scoring methodology, and the live view sits in the dashboard.
Frequently asked questions
Why is my Polymarket address different from my MetaMask address?
Because MetaMask is the signer and Polymarket trades from a smart contract wallet that your MetaMask key controls. The address Polymarket shows in the profile menu is the account wallet, and that is the one that holds your collateral and your positions.
Where should I send a deposit?
To the account wallet address shown in your Polymarket profile menu, not to the address your browser extension displays. Funds sent to the signer sit with the signer and are not available for trading.
What is the difference between a Proxy Wallet and a Safe Wallet?
Both are legacy smart wallets. A Proxy Wallet was created through Magic Link or Google authentication on polymarket.com. A Safe Wallet was created with an external signer such as MetaMask or Rabby. Accounts deployed on or after May 4, 2026 use a Deposit Wallet instead.
Can I work out someone's Polymarket wallet from their signer address?
For a Deposit Wallet, yes. The address is derived deterministically from the signer with CREATE2, so the derivation is public and reproducible. Note that wallets deployed before the June 29, 2026 upgrade use a different proxy pattern, so the current algorithm will not reproduce their addresses.
Does the signer on a trade identify the trader?
Not reliably. A Deposit Wallet owner can grant a separate signer scoped, time-limited trading access, so the signing key may belong to a delegated session rather than to the account owner.
Sources
The wallet types, the May 4, 2026 cutoff, the derivation algorithm, the June 29, 2026 proxy change, session keys, and the two position ledgers in this article come from Polymarket's own developer documentation: Wallets and Authentication and Positions & Tokens. Dates and contract addresses are reproduced as published there and can change; check the source before relying on them in code.