Skip to main content
The SDK trading modules provide a common workflow for wallet setup, CLOB credentials, approvals, order placement, cancellation, and position operations. Polymarket V2 is the default in every current PolyNode SDK.
Trading methods sign messages and can place orders or submit on-chain transactions. Start with a dedicated test wallet, confirm the token ID, price, size, and funder address, and never commit private keys or CLOB credentials.

Install

Store credentials outside source control:

Current V2 behavior

You do not need to opt into V2. These are the defaults: V2 uses PolyUSD collateral and applies Polymarket protocol fees when an eligible taker order matches. V2 signed orders do not include the legacy feeRateBps, nonce, or taker fields. The SDK omits those fields from the V2 signature and wire payload. The explicit V1 compatibility mode is different: its signed order includes the market fee rate. When V1 is selected, the SDK fetches the current fee and refuses to sign if fee, tick-size, or negative-risk metadata cannot be resolved safely.
Do not copy V1 fields into a V2 order. If you do not have a deliberate legacy requirement, keep the V2 default.

Set up a wallet

ensureReady / ensure_ready is idempotent. It discovers the wallet type, creates or loads CLOB credentials, and completes required setup. For a new wallet it can deploy contracts or submit approvals, so treat it as a state-changing operation.
Fund the returned funderAddress / funder_address, not an address guessed from the signing key. The correct funding flow depends on the wallet type. See Deposit wallets, V2 details, and PolyUSD.

Place an order

The following snippets place a real order when run. Replace every placeholder and validate the market first.
Supported time-in-force values are GTC, GTD, FOK, and FAK. A V2 GTD expiration must include the required safety buffer; the SDK rejects an invalid value before submission.

Cancel and inspect orders

Each SDK supports:
  • canceling one order;
  • canceling all active orders;
  • canceling active orders for a market;
  • listing open orders;
  • checking balances and approvals;
  • reading the local order-attempt history.

Three different fee concepts

Keep these separate in your product and accounting: Builder attribution does not by itself charge the user an application fee. An application fee is enabled only when you explicitly configure it. See Fee escrow before enabling application fees.

Builder attribution

Current V2 orders use a public bytes32 builder code. The SDK supplies PolyNode’s public code by default. You can provide your own code at trader level, override it for one order, or disable the default attribution.
Generate and manage builder credentials in your Polymarket builder settings. Builder credentials are secrets; the public builder code is not.

Position operations

The trading modules also expose split, merge, and negative-risk conversion builders or helpers. These are on-chain operations and are distinct from placing a CLOB order. Review Position management before signing or submitting one.

Cleanup

Close the trader to flush and release its local storage:

Next steps

Find a token with V3

Discover markets and token IDs before constructing an order.

Stream a verified book

Use PN1 integrity before making price-sensitive decisions.

V2 migration details

Understand the current exchange and payload differences.

Trading errors

Handle rejected orders and transport failures explicitly.