desk-execution-protocol

Execution protocol

This is the only skill on the desk that ends with a request to Hyperliquid's /exchange endpoint, and only the Execution Trader uses it. The API mechanics live in hyperliquid-orders and hyperliquid-positions; this skill is the discipline around them.

Inputs

• The proposal file /workspace/trading-desk/proposals/<id>.md with a Risk Manager PASS and exact ticket fields.
• The user's approval line, by id, in chat, after the ticket was shown, inside the ticket's expiry.
• The desk computer configured per hyperliquid-setup: HYPERLIQUID_NETWORK, HYPERLIQUID_ACCOUNT_ADDRESS, and the API wallet key available to scripts from the environment (never printed).

Pre-send checklist

Run every item and write the result under ## execution before sending. Any failure: do not send, name the item, hand back to the Desk Lead.

1. Ticket integrity and gate. Id, PASS and approval refer to the same immutable ticket revision: action, account, network, market, side, size, entry, stop, take-profit, leverage, bounds and expiry. Append revisions; never overwrite the approved text. Any economic change needs a new suffixed ticket id, Risk PASS and user approval; the old approval cannot transfer. Confirm the native out-of-band approval gate covers this send path, including SDKs, scripts and HTTP. If coverage is unverified, do not send, even with chat approval or a written standing scope.
2. Network. HYPERLIQUID_NETWORK equals the ticket's network. Mainnet is never assumed.
3. Account and wallet. HYPERLIQUID_ACCOUNT_ADDRESS equals the ticket's account. Query userRole for the public API wallet address on this network: require role: agent and data.user equal to the ticket's account. Check its current approval and expiry with extraAgents for that account. An unsigned account read succeeding proves neither signing authority nor wallet scope. If the desk has never sent from this wallet on this network, rehearse through an approved testnet ticket first, not on mainnet.
4. Price still valid. Fresh mid from allMids is within the ticket's slippage tolerance of the ticket price. For a stop or take-profit ticket, the trigger price is on the correct side of the current mark.
5. Formatting. Asset index from live meta; price rounded to at most 5 significant figures and at most 6 - szDecimals decimals for perps (8 - szDecimals for spot); size rounded down to szDecimals; notional at least 10 USD; leverage on the account for that market already equals the ticket's leverage (set it first with a separate approved action if not).
6. cloid, nonce and expiry. Generate a fresh 16-byte client order id (0x + 32 hex chars), write it to the proposal file, and put it on the order. One cloid per order, never reused. Record the actual nonce chosen when constructing the signed request, its public API wallet signer and network before dispatch; a nearby send timestamp is not a substitute for the signed nonce. Set expiresAfter on the send, no later than the ticket's expiry and normally a minute out (hyperliquid-advanced), and write that deadline beside the cloid and nonce. The cloid identifies the order; the deadline closes its future acceptance window. Expiry does not cancel an order accepted earlier, so recovery still requires reconciliation.
7. One action. Entry plus its stop and take-profit go in one order action with grouping: normalTpsl (children sized to the entry, placed when it fills). Protection for an existing position is a standalone reduce-only trigger. Anything else in the ticket that is a different action type (leverage change, cancel) is a separate, separately approved step.
8. Capacity and recovery. Before any action that adds risk or removes protection, no unreconciled send may remain, regardless of its age; complete any restart/feed-gap recovery in hyperliquid-websocket. Immediately before new risk, have Risk re-read account state, open orders and capacity and recheck the daily stop, limits and all reservations from desk-risk-limits. Reserve the approved revision once. Incomplete historical recovery may still permit a reduce-only protective stop or exit when Risk verifies the current position and orders and the ticket can only reduce risk; all other approval, native-gate and single-send checks still apply, and unresolved reservations remain held. A failed applicable gate blocks the send; changed economic fields need a new PASS and approval.