private/order params your agent proposes, get a verdict, and sign only on ALLOW: the verdict becomes a physical gate, because an unsigned order is inert and a signed one needs no further permission.
What gets recognized
Both bare params and the JSON-RPC envelope ({ "method": "private/order", "params": { … } }) are accepted:
Instrument names are self-describing and parsed deterministically —
ETH-PERP, ETH-20260828-2600-P (put, strike $2,600, expiring 2026-08-28), ETH-USDC — so the judge reasons over:
Derive ORDER: SELL 10 ETH-20260828-2600-P (put, strike 1,450 premium, max fee 1000 USDC/contract, subaccount 30769with the notes that catch what the raw JSON hides: selling an option without
reduce_only writes short-option exposure far beyond the premium collected; max_fee is bound into the signature and the venue may charge up to it (max_fee × amount is real worst-case money); limit_price is required even for market orders and is the true slippage bound; a signature_expiry_sec at MAX_INT32 is a never-expiring authorization; and a payload that arrives pre-signed is already authorized — the verdict can gate submission, but no longer gates signing. When the classifier can reach Derive’s public ticker, it fail-soft enriches the summary with the live mark, tick/step/minimum conformance, and flags limit prices that deviate more than 20% from mark.
Use it from your bot
Verify the unsigned params, then sign and submit:venue is optional — perp and option instrument names auto-detect (spot pairs like ETH-USDC additionally need the signing-envelope fields, since BASE-QUOTE alone is too generic). The legacy name still works: venue: "lyra" routes here.
Use it from Claude or ChatGPT
Add the hosted connector (https://harness.chance.cc/api/mcp, see Connectors) and give your agent one standing instruction:
Before signing or submitting any Derive action — orders, withdrawals, transfers, session keys — callThere is no official Derive MCP server, so agents typically drive the REST/WebSocket API directly — the standing instruction gates whatever client they use.verify_intentwith my rules as the intent and the exact API params as the action, withvenue: "derive". Only proceed on ALLOW; on BLOCK or ESCALATE, stop and tell me why.
How the harness knows Derive
The judge works from a versioned snapshot of Derive’s own documentation — order placement and the cancel/replace family, instrument naming and live specs, the two-layer auth model and exactly what the EIP-712 action signature commits to (module addresses, domain separators, 1e18 scaling), session-key scopes including the granular trade-only grants the REST docs understate, withdrawals/deposits/transfers with their dual-signed shapes, margin (standard vs portfolio) and price-banding rejection rules — plus a curated brief of the venue’s footguns (signature-boundmax_fee, premium-vs-notional readings, short options, never-expiring signatures, the 1 TPS matching rate limit). Docs are never fetched at verdict time: the snapshot is reviewed like code, its version is hashed into every transcript, and each page the judge consults is chained with its content hash. See Architecture.
What the receipt adds for Derive
On top of the standard proof bundle (transcript root, judge signature, onchain anchor), venue-aware verdicts carryvenue: "derive", the actionFamily, the venue actionType (order, replace, cancel-all, withdraw, session-key, rfq-execute, …), mode: "structured", and the knowledge-snapshot version — all inside the hash-chained transcript. For orders, the transcript records the exact instrument, side, size, limit price, fee cap and subaccount the verdict was issued against.
Eligibility is yours to check: Derive’s Terms of Use restrict several jurisdictions, including United States persons. A Chance verdict verifies an order against your mandate — it never confers eligibility to trade on the venue.
