Skip to main content

Overview

The Rust SDK provides OrderClient for order creation, EIP-712 signing, and order management. It supports:
  • OrderType::Gtc for resting limit orders
  • OrderType::Fak for fill-and-kill limit orders
  • OrderType::Fok for fill-or-kill market orders

Prerequisites

Before placing orders, you need:
  • an authenticated Client
  • a private key for EIP-712 signing
  • market venue data (fetched via get_market() and cached automatically)
The OrderClient lazily fetches your profile on the first order to determine your owner_id and fee rate. CHAIN_ID defaults to 8453 (Base mainnet) unless you override it.
Wallet-mode preflight. Accepting the one-time “choose your trading wallet” prompt in the app enables 1-click (smart wallet) trading on your Limitless profile. Once that mode is set, self-signed orders are rejected with Signer does not match - you should use embedded address for smart wallet. Switch the profile to EOA trading mode first: see Trading wallet mode.

Token approvals

Before your first trade on a given venue, you must approve the exchange contracts to spend your tokens. This is a one-time on-chain setup per venue.
Approve USDC and Conditional Tokens to the exchange contract:
Approvals are on-chain transactions that cost gas. Use venue.exchange for both CLOB and NegRisk, and additionally venue.adapter for NegRisk markets.

GTC orders

GTC orders remain on the book until filled or explicitly cancelled.

Post-only GTC order

Use post_only: true to ensure the order never crosses the spread as a taker:

GtcOrderArgs

Self-trade prevention

Set stp_policy on CreateOrderParams to control what happens when your incoming order would match your own resting order on the same token. It is a top-level request field — not part of the EIP-712 signed order args — and applies to any order type. Leave it None to keep the server default, cancel_maker.
The create-order response carries an execution field with the outcome:
Self-trade prevention blocks same-profile matches on the same token only. Orders on a different token of the same profile are unaffected. The wire field is always stpPolicy, regardless of the SDK.

FAK orders

FAK orders use the same price + size inputs as GTC, but any unmatched remainder is cancelled immediately.
post_only is not supported for FAK orders.

FOK orders

FOK orders execute immediately and fully, or are cancelled entirely. Instead of price and size, you pass maker_amount.
For buys, maker_amount is the total USDC to spend:

FokOrderArgs

Build and sign separately

For advanced flows, build and sign orders without submitting them:
You can also override the signing config explicitly:

Cancelling orders

Cancel a single order:
Cancel all orders in a market:

Cancel and replace

cancel_replace cancels one open order and submits a replacement in the same request. Use it to reprice or resize a resting order in one round-trip instead of separate cancel and create calls. cancel_replace_batch runs several of these operations in a single call. The cancel and the replacement are not atomic: they report independent outcomes, and a successful cancel does not guarantee a successful replacement. Choose the failure mode with CancelReplaceMode: Identify the order to cancel with CancelTarget::OrderId or CancelTarget::ClientOrderId. The replacement uses the same OrderArgs fields as create_order.

Single cancel-replace

Batch cancel-replace

Each operation runs independently and its result is returned with the caller’s index:

Delegated cancel-replace

Partners with the delegated_signing scope call delegated_orders.cancel_replace and delegated_orders.cancel_replace_batch. The server signs the replacement using the sub-account’s managed wallet, so no signing key is required. Set on_behalf_of (the sub-account profile ID) and fee_rate_bps on every operation:
See POST /orders/cancel-replace and POST /orders/cancel-replace/batch for the full request and response shapes, per-status fields, and failure semantics.