Deposit wallet

Two readers arrive at this phrase from opposite directions. One has used a crypto exchange, where the deposit address is the place you send coins so that the exchange can credit them to you. The other is setting up a trading bot for Polymarket and has been told to "fund the deposit wallet". The words are the same and the question of who holds the money has opposite answers, so this page separates them before either reader sends anything anywhere.

How it works

On an exchange: an address somebody else controls

Kraken's support page describes the ordinary kind. You sign in, pick an asset and press "Generate deposit address"; what comes back is an address the exchange uses to credit deposits to your Kraken account. The exchange generated it, and the exchange manages its life: the page allows five per asset and says that generating more makes the older ones expire. What you send there becomes a balance on somebody else's books.

On Polymarket: a contract you own

Polymarket's own Python SDK recognises four kinds of account and maps each to the signature type an order carries: a plain externally owned address is type 0, a Polymarket proxy type 1, a Gnosis Safe type 2, and a deposit wallet type 3. The first is a key; the other three are smart contracts that a key controls. The deposit wallet is the current one — the SDK's changelog records secure clients switching to it by default in the 0.1.0-b4 release of June 2026, and session keys are authorised against it and nothing else.

Three properties come out of the SDK code and a README in this catalogue that walks through the setup:

• The address exists before the wallet does. The SDK derives it from your signer's address with CREATE2 against a known factory contract, so a client can compute where the wallet will live, and where to send funds, before it has been deployed.
• You do not pay to create it. The Alphapoly README asks for an ordinary signing key plus a Relayer API key from Polymarket's account settings; the app then deploys the wallet gaslessly, the relayer pays the gas, and you fund it with pUSD and need no POL at all.
• A bare key cannot trade on its own. The same README states that externally owned accounts are blocked by the allowlist on Polymarket's V2 order book, which is why the wallet is not an optional extra for a bot.

The ownership runs the other way from an exchange address. The signing key is yours, the contract answers to it, and the venue's relayer pays the gas on transactions the key has signed.

Why it matters here

Two addresses, and the funds go to only one of them. A deposit-wallet account has a signer address, which is the key you hold, and a wallet address, which is the contract that holds the pUSD and the positions. A tutorial that says "your address" means one or the other without saying which. Collateral sent to the signer sits beside the account rather than in it, and an order signed as type 0 from a key the order book will not accept is rejected rather than filled.

A client library has to guess which account you have. polymarket-client classifies the account from the key it is given and picks the signature type from that. The SDK's own code marks one branch as temporary: when it cannot derive the wallet from the signer, it assumes the key is a session key acting for a deposit wallet. That default is a reasonable one, and it is also the reason an error message can mention session keys to somebody who has never created one. How the clients differ on this is in the Polymarket Python clients comparison.

Wallet analytics can split one trader in two. On-chain, the trades belong to the contract, not to the person's key. A tracker that labels addresses without linking a deposit wallet to its signer shows the wallet's history under one address and anything the key did directly under another. What wallet tracking shows puts that on its list of questions to ask a vendor.

"Self-custodial" is true and incomplete. Nobody else holds the key, which is the part that matters most. But trading from the wallet depends on the venue's relayer and its order-book allowlist, so the practical ability to trade is still granted by the operator. The difference between holding the key and being able to use it is the subject of where your key lives.