The end-to-end procedure for one trade on the HyperGrok desk - from an idea to a reviewed, journaled result - with the ticket format, who owns each stage, and what "done" looks like. Use whenever the user wants to open, adjust or close a position, or whenever any Bot is about to touch the exchange write path.
Coding
HyperGrok Desk Monitoring
Try itHow the desk watches markets and the account between trades using Grok Bot routines and WebSocket or polling watches - the desk brief, book checks, funding and price watches, alert conditions and what a watch may and may not do. Use when the user asks for briefings, alerts, "watch X" or scheduled checks.
What it does
How the desk watches markets and the account between trades using Grok Bot routines and WebSocket or polling watches - the desk brief, book checks, funding and price watches, alert conditions and what a watch may and may not do. Use when the user asks for briefings, alerts, "watch X" or scheduled checks.
The skill document
Monitoring, briefs and watches
Monitoring is read-only. A watch may fetch, compute, save and alert. It may never send to the exchange. If a watch condition implies action ("stop got hit, re-enter"), the alert opens a proposal; the lifecycle does the rest.
Grok Bot routines
Each Bot can own routines (schedules or event triggers). Ask the owning Bot to create one with: schedule and time zone, input source, expected result, approval boundary. Keep routines few and specific; the app keeps only recent run records, so a routine that produces something durable should also write to /workspace/trading-desk.
Recommended starting set (the user picks; none is on by default):
| Routine | Owner | Schedule | Output |
|---|---|---|---|
| Desk brief | Desk Lead | once a day at the user's chosen time | briefs/YYYY-MM-DD-desk.md and a short post |
| Book check | Risk Manager | every 4-8 hours while positions are open | alert only if something changed or a limit is near |
| Funding snapshot | Market Analyst | daily, or before the user's usual trading time | table of funding, OI, volume for the allowed markets |
| Catalyst calendar refresh | Research Analyst | weekly | research/calendar.md |
| Weekly review | Trade Reviewer | weekly | review posted by DM |
The desk brief
Assembled by the Desk Lead from specialists' inputs, or generated by the Desk Lead directly if it is the only Bot awake:
DESK BRIEF | 2026-08-17 07:00 UTC | mainnet | account 0xabc...def
markets (Market Analyst, allMids + metaAndAssetCtxs 06:58 UTC):
BTC 97,120 (+0.8% 24h) | funding 0.0010%/h | OI $4.1B
ETH 3,004 (+0.2%) | funding 0.0012%/h | OI $1.2B
SOL 151.2 (-1.1%) | funding -0.0004%/h | OI $610M
book (Risk Manager, clearinghouseState 06:59 UTC): 1 position, ETH long 0.51 @ 3,000, uPnL +$2.0, margin ratio 4.9%, stop resting 2,900; open risk 0.5%; day PnL 0.0%
research (Research Analyst): ETH client release scheduled 2026-08-19 [link]; nothing breaking on held markets
open items: HG-20260816-01 live; no pending tickets
Facts with sources; interpretation, if any, on one clearly labelled line. No trade suggestions.
Watches
A watch is a condition plus an alert. Two ways to run one on the desk computer:
- Polling with
/infocalls on a short loop from a script under/workspace/trading-desk/watch/(respect rate limits:/inforequests carry weight; a poll every 5-15 seconds per market is plenty for a desk). - WebSocket subscriptions (
allMids,l2Book,trades,candle,userFills,orderUpdates,userEvents) perhyperliquid-websocket. Better for fills and order updates. Keep the process supervised (a routine can restart it) and log to a file.
Common watch conditions:
| Watch | Data | Alert to |
|---|---|---|
| Price crosses a level | allMids or candle | user, Desk Lead |
| Funding flips sign or exceeds a threshold | metaAndAssetCtxs funding / predictedFundings | user, Desk Lead |
| Order filled or cancelled | orderUpdates, userFills | Execution Trader, Trade Reviewer |
| Margin ratio above X or liquidation distance below Y | clearinghouseState | user, Risk Manager, Desk Lead |
| Position without a resting stop | clearinghouseState + frontendOpenOrders | Risk Manager, Desk Lead (incident) |
| Daily loss stop approached (80%) or hit | clearinghouseState vs start-of-day equity | user, Risk Manager |
| Exchange unreachable for more than N minutes | any /info call failing | Desk Lead |
An alert message carries: what fired, the value and the threshold, the source and UTC time, and the proposal id if related. Alerts do not include instructions to trade.
Hygiene
- Every watch script logs to
/workspace/trading-desk/watch/.logwith UTC timestamps. - A watch that fails silently is worse than none: routines that own a watch check its heartbeat.
- Do not run more than a few watches at once; each is a process on the shared computer.
- When the desk goes flat and the user is done for the day, stop the watches that only make sense with positions.
Never
- Never let a watch place, modify or cancel an order, or change leverage. Even a "protective" one. It alerts; the desk acts through a ticket.
- Never alert with unsourced numbers.
- Never poll faster than the desk needs; a rate-limited desk is a blind desk.
Related skills
What the desk does when something goes wrong on Hyperliquid - unknown send results, unexpected fills or positions, unprotected positions, stuck or orphaned orders, API outages, rate limiting, and suspected API wallet compromise. Contain first, reconcile from the exchange record, act only through approved tickets, then review. Use the moment anything does not match the ticket.
Subscribe to live Hyperliquid data over WebSocket from the desk computer - mids, order book, trades, candles, best bid/offer, and per-account fills, order updates and events - with raw JSON, Python SDK and TypeScript examples, plus how to run a supervised watch that logs to a file and alerts. Read-only. Use for monitoring, fill notifications and any watch that polling would make expensive.
How the HyperGrok trading desk works as a team of Grok Bots - roles, seats, shared workspace, evidence standard, approval model and handoff format. Use when setting up the desk, when a Bot is unsure who owns something, or when a request does not fit the normal trade lifecycle.
How the Risk Manager writes the desk's risk limits with the user, sizes every proposed trade from live account state and Hyperliquid's real constraints, checks the book, and issues a PASS or REJECT with exact ticket fields. Use for setting up or changing limits, sizing any trade, and answering "how's the book".
The Trade Reviewer's procedure for journaling desk activity and reviewing trades from the exchange record - process graded separately from outcome, execution costs measured, one repeatable finding per review, plus the weekly desk review. Use after any send, when a trade closes, on the weekly routine, or when the user asks "how did that go".