Start by identifying the account’s wallet type. You can then connect an existing Polymarket account or create new accounts for your users.
Wallet Types
A Deposit Wallet is the default smart wallet for trading on Polymarket. Your wallet type depends on how and when the account wallet was created.
Connect Your Account
Connect an existing polymarket.com account to trade with its funds and positions. Copy the account wallet address from the profile menu:
Create a Relayer API key under polymarket.com → Settings → API Keys → Relayer API Keys:
This key authorizes gasless wallet operations for the account. Copy the Signer Address and API Key shown after creation.
With the wallet address and Relayer API key ready, connect the account with
createSecureClient.Create a Secure Client
First, provide the signer and account wallet. Include the Relayer API
key to authorize gasless wallet operations.This example uses Viem with a private key. See Wallet
Integrations to connect a
signer from another supported wallet library. Inspect the Account
Then, inspect the resolved account identity and wallet type.client.account contains the signer, account wallet, and wallet type for the session. That’s it—you have connected your account. With the wallet address and Relayer API key ready, connect the account with
AsyncSecureClient.create (SecureClient.create is available for
synchronous workflows).Create a Secure Client
First, create an AsyncSecureClient or SecureClient with the private
key and account wallet.
Include the Relayer API key to authorize gasless wallet operations. Inspect the Account
Then, inspect the resolved account wallet and wallet type.client.wallet and client.wallet_type contain the resolved account wallet and wallet type for the session. That’s it—you have connected your account. Authenticate with the CLOB and create L2 credentials.Create an L1 Signature
First, create an L1 signature to attest to ownership of the signer
address. See API Authentication
for the complete signing flow.Sign clobAuthTypedData with the signer that controls
<signer_address>. The returned signature is <clob_l1_signature>. Create L2 Credentials
Then, create L2 credentials by sending the signer address, timestamp,
nonce, and L1 signature to the CLOB.Store the returned L2 credentials for authenticating private requests,
including requests that place orders: That’s it—you have connected your account.
Create New Accounts
Create a polymarket.com account to serve as your builder account. It represents your integration and owns the builder profile and API credentials used to create Deposit Wallets for your users. Each wallet remains controlled by its signer.
In the builder account, open polymarket.com → Settings → Builders and create an API key:
Copy the API Key, Secret, and Passphrase shown after creation.
Builder API credentials are secrets. Keep them on your server, and never
expose or share them.
With the Builder API key ready, create the new account with
createSecureClient.Create a Deposit Wallet
First, create a SecureClient with the signer and Builder API key. The SDK
derives the signer’s Deposit Wallet address and deploys the wallet
automatically.This example uses Viem with a private key. See Wallet
Integrations to connect a
signer from another supported wallet library. Inspect the Account
Then, inspect the resolved account identity and wallet type.client.account contains the signer, account wallet, and wallet type for the session. That’s it—you have created the new account. With the Builder API key ready, create the new account with
AsyncSecureClient.create (SecureClient.create is available for
synchronous workflows).Create a Deposit Wallet
First, create an AsyncSecureClient or SecureClient with the private
key and Builder API key.
The SDK derives the signer’s Deposit Wallet address and deploys the
wallet automatically. Inspect the Account
Then, inspect the resolved account wallet and wallet type.client.wallet and client.wallet_type contain the resolved account wallet and wallet type for the session. That’s it—you have created the new account. With the Builder API key ready, deploy a Deposit Wallet for each new signer
through the Relayer.Prepare the Deployment Request
First, prepare a WALLET-CREATE request for each new signer.Create a Unix timestamp in seconds, then sign the exact serialized request body with the Builder API key secret. Deploy the Deposit Wallet
Then, submit the signed request to the Relayer.The response includes the Relayer transaction ID. Confirm the Deployment
Then, poll the Relayer transaction until it reaches STATE_CONFIRMED.The confirmed transaction includes the new Deposit Wallet address as proxyAddress.Treat STATE_FAILED and STATE_INVALID as terminal failures. Create an L1 Signature
Then, create an L1 signature to attest to ownership of the signer
address. See API Authentication
for the complete signing flow.Sign clobAuthTypedData with the signer that controls <signer_address>. The returned signature is <clob_l1_signature>. Create L2 Credentials
Finally, create L2 credentials by sending the signer address,
timestamp, nonce, and L1 signature to the CLOB.Store the returned L2 credentials for authenticated requests and order placement. That’s it—you have created the new account.
Execute Gasless Transactions
Approve token spending, transfer funds, and manage positions from the account
wallet without paying gas.
SecureClient provides named methods for supported wallet actions. Each
method returns a TransactionHandle; call .wait() to wait for the action
to settle.Create a SecureClient with either a Relayer or Builder API key:Use the method that matches the wallet action you want to perform:Approve ERC-20 spendingSet an allowance for a contract to spend an ERC-20 token from the account
wallet. Pass "max" to approve the maximum amount.Approve an ERC-1155 operatorAllow an operator to manage every ERC-1155 token held by the account wallet.
Set approved to false to revoke access.Transfer ERC-20 tokensTransfer an ERC-20 token from the account wallet. amount is expressed in the
token’s base units.AsyncSecureClient provides named methods for supported wallet actions.
Each method returns a transaction handle; call await handle.wait() to
wait for the action to settle. The same methods are available on the
synchronous SecureClient.Create an AsyncSecureClient with either a Relayer or Builder API key:Use the method that matches the wallet action you want to perform:Approve ERC-20 spendingSet an allowance for a contract to spend an ERC-20 token from the account
wallet. Pass "max" to approve the maximum amount.Approve an ERC-1155 operatorAllow an operator to manage every ERC-1155 token held by the account wallet.
Set approved to False to revoke access.Transfer ERC-20 tokensTransfer an ERC-20 token from the account wallet. amount is expressed in the
token’s base units.A Deposit Wallet executes one or more contract calls as an ordered batch.
The signer authorizes the complete batch, and the Relayer submits it
gaslessly.The following steps show the Deposit Wallet path. For Safe or Proxy Wallet
flows, use an SDK that handles the wallet-specific payloads.
Build the Call List
First, encode each contract call and add it to the batch in execution order.target is the contract to call, value is the amount of native POL to send in
wei, and data is the ABI-encoded function call. Use "0" for value when the
call does not transfer POL. Fetch the Wallet Nonce
Then, fetch a fresh WALLET nonce for the signer using the API key for your
integration.For Builder API keys, create builder_signature from the request timestamp,
method, and path. See Create New Accounts for the
complete signing flow. Create the Batch Typed Data
Build a Deposit Wallet Batch containing the wallet address, fresh nonce,
future deadline, and call list. Sign the Batch
Sign the typed data with the signer that controls the Deposit Wallet. The
example below uses Viem. Submit the Batch
Submit the signed batch using the same call list and API key for your
integration.For Builder API keys, sign the request timestamp, method, path, and exact
serialized body as described in Create New Accounts.The response includes the transaction ID used in the next step. Confirm the Transaction
Poll the transaction until it reaches STATE_CONFIRMED.Treat STATE_FAILED and STATE_INVALID as terminal failures.
Set Up Trading Approvals
Set up the ERC-20 and ERC-1155 approvals that allow Polymarket’s exchange
contracts to spend the account wallet’s pUSD and Conditional Tokens when
placing orders. For Deposit Wallets, Safe Wallets, and Proxy Wallets, these
approvals are submitted as a gasless transaction.
Create a SecureClient with either a Relayer or Builder API key:Call setupTradingApprovals() to configure the required allowances:The method checks existing approvals and submits only what is missing, so it is safe to call more than once.Order placement can recover from missing allowances automatically. Setting them up in advance keeps that work out of your first order. Create an AsyncSecureClient with either a Relayer or Builder API key (the
same workflow is available with the synchronous SecureClient):Call setup_trading_approvals() to configure the required allowances:The method checks existing approvals and submits only what is missing, so it is safe to call more than once.Order placement can recover from missing allowances automatically. Setting them up in advance keeps that work out of your first order. Configure both CLOB exchange contracts so a Deposit Wallet can buy and sell
in standard and neg-risk markets.The following steps show the Deposit Wallet path. For Safe or Proxy Wallet
flows, use an SDK that handles the wallet-specific payloads. For EOA trading,
see Set Up EOA Trading. Check the Required Approvals
First, check each allowance before building the transaction so the batch
contains only missing approvals.Read the current values with allowance(wallet, exchange) on pUSD and isApprovedForAll(wallet, exchange) on Conditional Tokens. Build the Approval Call List
Then, encode the missing ERC-20 and ERC-1155 approval calls.Build one call for each missing approval. This example includes all four. Execute the Approval Batch
Use the approval call list as the calls in Execute Gasless
Transactions. Fetch a fresh nonce, sign the
complete batch, submit it, and wait for STATE_CONFIRMED before continuing. Sync CLOB Allowances
Finally, update the CLOB allowance cache:Using the signer address and CLOB API credentials from API
Authentication, create a fresh
<clob_request_timestamp> and generate <clob_l2_signature> without a request
body. The query parameters are not part of the signed path:Refresh the conditional-token allowance for each token before its first sell order.
Advanced Options
Explore additional wallet and authentication patterns for advanced integrations.
Derive a Deposit Wallet Address
If you need to compute a Deposit Wallet address before deployment, use the
deterministic derivation algorithm below.
Deposit Wallets deployed before the June 29, 2026 upgrade use a UUPS proxy.
Deposit Wallets deployed after the upgrade use a beacon proxy. The following
algorithm derives the address for a new Deposit Wallet with a beacon proxy.
See Contract Addresses for the
current Deposit Wallet factory and beacon.
Set Up EOA Trading
If your EOA is allowlisted for trading, use it as the account wallet. Every
onchain action—including token approvals, ERC-20 transfers, splits, merges, and
redemptions—is submitted directly from the EOA and requires POL for gas.
Pass the signer address as wallet. The SDK identifies the account as an
EOA and skips Deposit Wallet deployment.Methods such as approveErc20(), approveErc1155ForAll(), transferErc20(),
and the position lifecycle methods submit transactions directly from the
signer. For example, set up every required trading approval: Pass the signer address as wallet. The SDK identifies the account as an
EOA and skips Deposit Wallet deployment.Methods such as approve_erc20(), approve_erc1155_for_all(),
transfer_erc20(), and the position lifecycle methods submit transactions
directly from the signer. For example, set up every required trading approval: Set Up Trading Approvals
First, approve both CLOB exchange contracts to spend pUSD and manage
Conditional Tokens. Submit each required approval transaction from the
EOA and pay gas with POL held at that address.See Set Up Trading Approvals for the required approvals and contract addresses. Create an L1 Signature
Then, create an L1 signature to attest to ownership of the EOA. See API
Authentication for the complete
signing flow.Sign clobAuthTypedData with the EOA. The returned signature is <clob_l1_signature>. Create L2 Credentials
Finally, create L2 credentials by sending the signer address,
timestamp, nonce, and L1 signature to the CLOB.Store the returned L2 credentials for authenticated requests and order placement. See Place a Limit Order for the
complete direct API order flow.
Remote Builder Signing
Remote Builder Signing keeps Builder API credentials on your server while a TypeScript client requests signed headers for Builder-authenticated actions.
Create a Signing Endpoint
Authenticate and authorize the caller on your server, then sign the request
details supplied by the client. Connect the Client
Pass the user’s signer and the signing endpoint to the client. Authenticate
signing requests with the application’s session credentials or custom
headers.The Builder API credentials remain on the server; the client receives only the headers for the request being authorized.
Opt Out of Beacon Upgrades
Deposit Wallets deployed after June 29, 2026 use an ERC-1967 beacon
proxy. This
proxy pattern resolves the implementation for multiple wallets through a shared
beacon, allowing Polymarket to send implementation upgrades without changing
their addresses. The wallet owner can instead pin the wallet to the
implementation that is current when it opts out. The owner-only calls below are
submitted directly and require POL for gas.
An opted-out wallet does not receive future security fixes, bug fixes, or
features delivered through beacon upgrades. Review the current implementation
and accept responsibility for maintaining the wallet before opting out.
Pause the Wallet
Send a direct onchain transaction from the wallet owner to call pause() on
the Deposit Wallet.
Wait for the Timelock
Read timelockDelay() from the Deposit Wallet factory and wait until that
interval has elapsed after the wallet was paused.
Opt Out
Send another transaction from the wallet owner to call optOut() on the
Deposit Wallet. This pins the wallet to the beacon implementation that is
current when the transaction executes.
Unpause the Wallet
Call unpause() from the wallet owner to clear the paused state.
To resume receiving beacon upgrades, repeat the pause and timelock steps, call
optIn(), and then unpause the wallet. Review the beacon’s current default
implementation before opting back in.