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 create_server_wallet=True. EOA sub-accounts sign their own orders.
Recommended setup: Store your HMAC credentials (token_id / 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 and submits it to POST /orders with the on_behalf_of 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 post_only=True 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. post_only 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 maker_amount:
  • BUY: maker_amount is the USDC amount to spend (e.g., 50.0 = spend $50 USDC)
  • SELL: maker_amount is the number of shares to sell (e.g., 18.64 = sell 18.64 shares)

Parameters

GTC order parameters

FAK order parameters

FOK order parameters

Cancel an order

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 with a zero verifying address
  2. GTC and FAK orders use price and size; FOK orders use maker_amount (with taker_amount always set to 1)
  3. The SDK posts the order to POST /orders with on_behalf_of and owner_id 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 server submits the signed order to the CLOB engine. GTC orders can rest on the book, FAK orders cancel unmatched remainder, and FOK orders either fully fill or cancel