Deposit Wallets

Polymarket is rolling out deposit wallets as a new account type alongside the existing Gnosis Safe proxy wallets. This guide explains what changed, whether you need to do anything, and how to handle both wallet types in your integration.

What are deposit wallets?

Deposit wallets are Polymarket’s new smart contract wallet type for new accounts. They replace the Gnosis Safe proxy that existing accounts use. Heard the term “beacon wallet”? It’s the same thing. Newer deposit wallets are built so Polymarket can upgrade all of them at once — that upgradeable variant is what gets called a beacon wallet. There’s also an earlier standalone variant from before that change. Both behave identically, and everything on this page (and the /resolve endpoint) handles both — you never need to tell them apart. From your perspective as a builder, the key differences are:

	Safe proxy (existing)	Deposit wallet (new)
Signature type	`2` (POLY_GNOSIS_SAFE)	`3` (POLY_1271)
How addresses are derived	CREATE2 from Safe factory	CREATE2 from deposit wallet factory
Order signing	Standard EIP-712	EIP-712 with ERC-7739 TypedDataSign wrapper
Approvals	Gasless via Safe multisend	Gasless via WALLET batch
V1 support	Yes	No (V2 only)

The good news: if you use the polynode SDK, all of this is handled automatically. ensureReady() detects the wallet type, order() signs correctly, and the /resolve endpoint resolves both wallet types.

Do I need to change anything?

If you use the polynode SDK for trading: update to the latest version. Everything else is automatic.

# Minimum versions for deposit wallet support
cargo add polynode@0.13.3        # Rust
npm install polynode-sdk@0.10.6  # TypeScript
pip install polynode==0.10.3     # Python

If you only read data (positions, trades, /resolve): existing fields are unchanged. /resolve still returns safe, eoa, username, and type exactly as before. It also returns the deployed-only wallets object and a wallet_details list with plain wallet_type, deployed, and current status for each relevant address. If you call the Polymarket CLOB directly (without our SDK): you need to implement ERC-7739 TypedDataSign wrapping for signatureType: 3 orders. See the signing details below.

How to detect wallet type

For trading, the SDK auto-detects wallet type when you call ensureReady() or detectWalletType(). Detection checks on-chain in this order:

Safe deployed? -> POLY_GNOSIS_SAFE (type 2)
Proxy deployed? -> POLY_PROXY (type 1)
Deposit wallet deployed? -> POLY_1271 (type 3)
Nothing deployed -> defaults to POLY_GNOSIS_SAFE (new Safe will be created)

This controls how the SDK signs orders. The /resolve identity endpoint uses a different rule for compatibility with Polymarket’s deposit-wallet migration: if a resolved EOA has a deployed deposit wallet, /resolve returns that deposit wallet in safe.

import { PolyNodeTrader } from 'polynode-sdk';

const trader = new PolyNodeTrader({ polynodeKey: 'pn_live_...' });
const status = await trader.ensureReady(privateKey);

console.log(status.signatureType);
// 2 = Safe (existing user)
// 3 = Deposit wallet (new user)

// Either way, order() works the same:
await trader.order({ tokenId: '...', side: 'BUY', price: 0.55, size: 100 });

How to handle mixed user bases

If your platform has existing Safe users and new deposit wallet users, no special handling is needed. The SDK stores each user’s wallet type in the local database and uses the correct signing method automatically.

// User A: existing Safe wallet
await trader.ensureReady(userA_privateKey);
// status.signatureType === 2, uses standard EIP-712

await trader.order({ tokenId: '...', side: 'BUY', price: 0.5, size: 50 });

// User B: new deposit wallet
await trader.ensureReady(userB_privateKey);
// status.signatureType === 3, uses ERC-7739 TypedDataSign wrapper

await trader.order({ tokenId: '...', side: 'BUY', price: 0.5, size: 50 });
// Same API, different signing under the hood

Wallet address derivation

You can derive any user’s deposit wallet address from their EOA without any network calls:

const { deriveDepositWalletAddress, deriveSafeAddress } = require('polynode-sdk');

const eoa = '0xA60601A4d903af91855C52BFB3814f6bA342f201';
const depositWallet = await deriveDepositWalletAddress(eoa);
const safe = await deriveSafeAddress(eoa);

// Both are deterministic — same EOA always produces the same addresses

from polynode.trading import derive_deposit_wallet_address, derive_safe_address

eoa = "0xA60601A4d903af91855C52BFB3814f6bA342f201"
deposit_wallet = derive_deposit_wallet_address(eoa)
safe = derive_safe_address(eoa)

use polynode::trading::onboarding::{derive_deposit_wallet_address, derive_safe_address};

let eoa = "0xA60601A4d903af91855C52BFB3814f6bA342f201".parse().unwrap();
let deposit_wallet = derive_deposit_wallet_address(eoa);
let safe = derive_safe_address(eoa);

The /resolve endpoint

The Resolve Wallet endpoint keeps the same fields and prioritizes deposit wallets in the existing safe field. The field name remains safe for backward compatibility.

curl "https://api.polynode.dev/v1/resolve/0x8b60bf0f650bf7a0d93f10d72375b37de18f8c40" \
  -H "x-api-key: YOUR_KEY"

{
  "safe": "0x8b60bf0f650bf7a0d93f10d72375b37de18f8c40",
  "eoa": "0xa60601a4d903af91855c52bfb3814f6ba342f201",
  "username": null,
  "type": "deposit_wallet",
  "wallets": {
    "deposit_wallet": "0x8b60bf0f650bf7a0d93f10d72375b37de18f8c40",
    "safe": null,
    "proxy_wallet": null
  },
  "wallet_details": [
    {
      "address": "0x8b60bf0f650bf7a0d93f10d72375b37de18f8c40",
      "wallet_type": "deposit_wallet",
      "deployed": true,
      "current": true
    }
  ]
}

The safe field contains the preferred trading wallet address. If the controlling EOA has a deployed deposit wallet, safe is the deposit wallet. Otherwise it is the existing Safe/proxy wallet. The type field tells you which kind of wallet was returned. deployed and current are separate booleans in wallet_details, so an address can still be identified as a deposit wallet before its contract is deployed.

`type` value	Description
`"safe"`	Gnosis Safe proxy (most existing accounts)
`"deposit_wallet"`	Deposit wallet (newer accounts)
`"proxy"`	Legacy proxy wallet

Both forward resolution (EOA -> wallet) and reverse resolution (wallet -> EOA) work for all wallet types. When both a Safe and deposit wallet exist, deposit wallet wins.

How POLY_1271 signing works

You only need this section if you’re implementing signing without the polynode SDK. If you use signV2Order() or trader.order(), this is handled automatically.

For deposit wallet users, V2 orders use signatureType: 3 (POLY_1271). The signing process wraps the standard Order EIP-712 hash in a Solady TypedDataSign struct:

Build the standard V2 Order struct (same fields as type 0/1/2)
Set maker and signer to the deposit wallet address (not the EOA)
Sign using TypedDataSign as the EIP-712 primary type under the exchange domain, with the deposit wallet parameters as struct fields
Wrap the resulting signature: innerSig (65 bytes) + appDomainSeparator (32 bytes) + contentsHash (32 bytes) + orderTypeString (186 bytes) + typeStringLength (2 bytes)

The final wrapped signature is 317 bytes (634 hex chars + “0x” prefix = 636 total). The TypedDataSign struct includes the deposit wallet’s identity:

name: "DepositWallet"
version: "1"
verifyingContract: the deposit wallet address
salt: bytes32(0)

FAQ

Do existing Safe wallet users need to change anything?

No. Safe wallets continue to work exactly as before. The SDK detects your wallet type automatically. All existing integrations are backward compatible.

Will my /resolve API responses break?

No. No existing field was renamed or removed. The endpoint still returns safe, eoa, username, type, and wallets; wallet_details is additive.

Can I still create new Safe wallets?

Yes. The SDK defaults to creating Safe wallets for new users when no wallet is detected on-chain. Deposit wallets are created through Polymarket’s frontend or relayer, not through the polynode SDK’s default flow.

What SDK version do I need?

Deposit wallet address derivation and detection: >= 0.10.0. POLY_1271 order signing: >= 0.10.5. Full onboarding flow (deploy + approve): >= 0.10.6. Latest recommended: Rust 0.13.3, TypeScript 0.10.6, Python 0.10.3.

What if a user has both a Safe and a deposit wallet?

For /resolve, the deposit wallet is returned in safe when it is deployed. The field name stays safe so existing clients do not need to parse a new field. wallet_details lists both addresses and shows which one is current and whether each is deployed.

Do deposit wallets work with V1 orders?

No. POLY_1271 (signature type 3) is V2 only. V1 orders only support types 0 (EOA), 1 (POLY_PROXY), and 2 (POLY_GNOSIS_SAFE). Since Polymarket’s V2 exchange is now live, all new activity uses V2.

How do I know which wallet type to use for copy trading?

Register followers with their actual sig_type (2 for Safe, 3 for deposit wallet). The copy trading engine automatically generates the correct typed data for each follower’s wallet type. Your signing code should use signV2Order() from the SDK, which handles both types transparently.

Is there a performance difference?

Deposit wallet signatures are larger (317 bytes vs 65 bytes) due to the ERC-7739 wrapping, but this has no meaningful impact on order submission speed or gas costs. The CLOB processes both types identically.

Getting Started

Guides

What are deposit wallets?

Do I need to change anything?

How to detect wallet type

How to handle mixed user bases

Wallet address derivation

The /resolve endpoint

How POLY_1271 signing works

FAQ

​What are deposit wallets?

​Do I need to change anything?

​How to detect wallet type

​How to handle mixed user bases

​Wallet address derivation

​The /resolve endpoint

​How POLY_1271 signing works

​FAQ

What are deposit wallets?

Do I need to change anything?

How to detect wallet type

How to handle mixed user bases

Wallet address derivation

The /resolve endpoint

How POLY_1271 signing works

FAQ