Skip to main content
BETA — SUBJECT TO CHANGE. This capability is in beta and may change without notice.
A participant’s buying power at Polymarket US is the cash in their trading account. Your funding entity manages that cash with two transfer reasons — DEPOSIT (partner funding account → participant account) and WITHDRAWAL (participant account → funding account) — mirroring what the participant does in their wallet: Why this beats bank rails: the participant’s fiat already sits with your funding entity. Allocating it to trading is one platform ledger transfer — seconds — instead of a bank transfer to the clearinghouse — hours to days. The time between “I want to trade with these funds” and “I can submit a trade with these funds” is one confirmed DEPOSIT transfer.

​
Deposits

Create a DEPOSIT transfer when the participant allocates wallet funds to trading:
  • Event-driven, typically 1:1. One transfer per wallet allocation event is the intended pattern. If wallet deposits and withdrawals are the only ways a participant’s allocation changes, mirroring them keeps on-platform buying power in lock-step with the wallet.
  • Latency-sensitive. A participant is typically waiting to trade behind a deposit. Give deposits priority over batch work (fee collections, scheduled withdrawals) in your transfer queue — see rate limits and smoothing.
  • Funded from the pool. A deposit is rejected if the partner funding account can’t cover it — size and top up the pool for peak allocation demand, per sizing the funding account.
  • Consider batching micro-events. If your product produces many small allocations per participant (e.g. round-ups), aggregate them into fewer, larger deposits rather than one transfer each — transfers scale with wallet events, and the budget is shared across your integration.

​
Withdrawals

Create a WITHDRAWAL transfer when the participant de-allocates funds from trading. The amount must be covered by the participant’s free cash:
  • Check before you initiate. Confirm free cash via your ledger projection (authoritative read: PositionAPI/GetAccountBalance — see Reconciliation). A withdrawal exceeding free cash is rejected.
  • Leave the fee earmark behind. Accrued, uncollected vendor fees are cash in the same account. Cap withdrawable amount at free cash − accrued uncollected vendor fees, or your fee collection becomes uncollectable — see Vendor Fees.
  • Open orders lock collateral. If the participant wants to withdraw more than their free cash, they (or you, on their behalf) must first cancel open orders or close positions to release collateral.
  • Trading proceeds are withdrawable. Settlement credits, realized profit, and released collateral accumulate in the account as free cash — a participant “cashing out winnings” is just a withdrawal like any other.

​
Keeping the mirror honest

Both legs of every confirmed transfer post to the balance ledger as typed entries (DEPOSIT / WITHDRAWAL), alongside trading events. Reconcile per account:
Your funding entity’s wallet ledger and the platform’s account ledger should agree on the allocation at all times; the Reconciliation page covers the stream-first pattern for maintaining that projection across your participant base.

Transfers

The API — request shape, idempotency, rate limits.

Partner Funding Overview

The model and the transfer budget.

Vendor Fees

The fee earmark that withdrawals must respect.

Reconciliation

Ledger projection and authoritative balance reads.