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. For GTC and FAK orders, price and size are used; for FOK orders, maker_amount is used (with taker_amount always set to 1)
  3. The order is posted 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 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