# Deposit wallet

Also written signature type 3, sigtype 3.

*https://predictionmarkets.tools/glossary/deposit-wallet · next to Trading Clients, SDKs & Bots*

**Definition:** On Polymarket, a smart-contract wallet owned by your signing key, deployed for you by the venue's relayer, which holds your collateral and positions and signs orders under signature type 3. Its address is computed from your key before it exists. On a centralised exchange the same words usually mean an address the exchange controls and credits to your account, which is close to the opposite arrangement.

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](https://predictionmarkets.tools/tools/polymarket-alpha-bot) 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](https://predictionmarkets.tools/tools/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](https://predictionmarkets.tools/compare/polymarket-python-clients).

**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](https://predictionmarkets.tools/guides/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](https://predictionmarkets.tools/guides/where-your-key-lives).

## Where you will meet this

- [Alphapoly (polymarket-alpha-bot)](https://predictionmarkets.tools/tools/polymarket-alpha-bot.md)
- [polymarket-client](https://predictionmarkets.tools/tools/polymarket-client.md)

## Sources

1. [src/polymarket/_internal/wallet.py](https://github.com/Polymarket/py-sdk/blob/main/src/polymarket/_internal/wallet.py) — Polymarket, read 2026-09-27
2. [CHANGELOG, release 0.1.0-b4](https://github.com/Polymarket/py-sdk/blob/main/CHANGELOG.md) — Polymarket, 2026-06-08
3. [README](https://github.com/chainstacklabs/polymarket-alpha-bot) — Chainstack Labs, read 2026-09-27
4. [Generating new deposit addresses](https://support.kraken.com/articles/360001093023-generating-new-deposit-addresses) — Kraken, 2025-08-08

*Last updated 2026-09-27. A reference page, corrected in place — not a dated post.*