Skip to main content
The DelegatedOrderService enables partners with the delegated_signing scope to place and cancel orders on behalf of their sub-accounts. The server signs orders using the sub-account’s managed Privy wallet. No private key management is needed on the partner side.
Delegated signing requires a sub-account created with createServerWallet: true. EOA sub-accounts sign their own orders.
Recommended setup: Store your HMAC credentials (tokenId / secret) on your backend. Use this SDK server-side to sign partner-authenticated requests. Expose only your own app-specific endpoints to the frontend. Never expose HMAC secrets in browser bundles or client-side storage.

Access

Create a GTC delegated order

Builds an unsigned GTC (Good-Til-Cancelled) limit order locally and submits it to POST /orders with the onBehalfOf profile ID. The server signs the order via the sub-account’s managed wallet. GTC orders remain on the orderbook until filled or explicitly cancelled.
Use postOnly: true in the args to ensure the order only rests on the book and is never filled immediately as a taker:

Create a FAK delegated order

FAK (Fill-And-Kill) orders use the same price and size inputs as GTC, but they only consume immediately available liquidity and cancel any unmatched remainder. postOnly is not supported for FAK orders.

Create a FOK delegated order

FOK (Fill-or-Kill) orders execute immediately at the best available price or are cancelled entirely. There are no partial fills. Instead of price and size, FOK orders use makerAmount:
  • BUY: makerAmount is the USDC amount to spend (e.g., 50 = spend $50 USDC)
  • SELL: makerAmount is the number of shares to sell (e.g., 18.64 = sell 18.64 shares)

Parameters

GTC order args

FAK order args

FOK order args

Cancel an order

Cancel an order placed by the partner or on behalf of a sub-account.

Cancel on behalf of a sub-account

Cancel all orders in a market

Cancel all on behalf of a sub-account

How it works

  1. The SDK builds an unsigned order locally using OrderBuilder with a zero verifying address
  2. For GTC and FAK orders, price and size are used; for FOK orders, makerAmount is used (with takerAmount always set to 1)
  3. The order is posted to POST /orders with onBehalfOf and ownerId set to the sub-account’s profile ID
  4. The server detects the delegated_signing scope and missing signature
  5. The server looks up the sub-account’s server wallet, builds EIP-712 typed data, and signs via Privy
  6. The signed order is submitted to the CLOB engine. GTC orders can rest on the book, FAK orders cancel unmatched remainder, and FOK orders either fully fill or cancel