Strike WebSocket

Polling is fine for a brief. A watch that must notice something within seconds uses a stream.

The public stream carries mark price, depth updates, trades and klines. The user stream carries order fills, position and balance updates for the account.

1. The rule that matters most

Silence is not information. A watch reporting "no alert" on a socket that died two hours ago looks exactly like a calm market. Every watch on this desk must be able to tell the two apart, and must say which it has.

Concretely, a watch process:

• Records the UTC time of the last message of any kind, not just the last matching one.
• Has a staleness threshold. Past it, the watch reports unavailable, not "condition did not fire".
• Reconnects with backoff, and logs every disconnect and reconnect with times.
• On reconnect, re-reads state from REST or the MCP rather than assuming nothing happened while it was away.

A watch that cannot meet those four is not run.

2. Keeping a local order book in sync

/v2/depth gives the snapshot; the stream gives deltas. The documented procedure:

1. Fetch /v2/depth?symbol=BTC-USD&limit=1000 and record lastUpdateId.
2. Connect and subscribe to {symbol}@depth.
3. Drop any depthUpdate whose u <= lastUpdateId.
4. Apply everything after that.

Per-symbol +1 continuity between consecutive u values is not guaranteed - the engine skips ids when the book does not change. A gap is not a missed update and is not a reason to resynchronise. A genuinely out-of-order or backwards u is.

lastUpdateId, U and u can exceed 2^53. In Python that is free; in JavaScript, parse them as strings or BigInt or they will silently round.

3. A watch process on the desk computer

Watches live in /workspace/trading-desk/watch/, one directory per watch, each with the script, a log and the condition in plain language.

mkdir -p /workspace/trading-desk/watch/ada-funding
cd /workspace/trading-desk/watch/ada-funding
# Write the condition down before the code, in the words the user used.
cat > CONDITION.md <<'TXT'
Alert when ADA-USD hourly funding turns negative.
Checked every 5 minutes against /v2/premiumIndex.
Stale after 15 minutes without a successful read -> report unavailable.
TXT

For a five-minute condition, poll REST on a loop and skip the socket entirely - it is less to supervise and less to get wrong. Reach for the stream when the condition is genuinely sub-minute, or when the desk needs fills the moment they happen.

Run watches with nohup or the runtime's own background mechanism, write a log with UTC timestamps, and record the watch in desk.md so the desk knows what is running. A watch nobody remembers starting is a watch nobody notices stopping.

4. Alerts

An alert states: what fired, the value that fired it, the threshold, the UTC time, and the source. It never states what to do about it - that is the floor's job, through the lifecycle.

discord_send_message (see strike-research-tools) pushes an alert to the user's phone when they have configured a webhook. Keep it under 2000 characters, never include the token or an account identifier, and only for alerts the user asked for.

5. The user stream and fills

The authenticated stream is the fastest way to know a fill happened, but it is not the desk's record of what happened. Reconciliation always reads back from the MCP - strike_get_fill_history, strike_get_order_history, strike_get_open_positions. A stream message is a prompt to go and check, never the check itself.

6. Supervision

Each watch reports, on request: uptime, last message time, reconnect count, and whether it currently considers itself live or stale. The Desk Lead asks for that before treating any watch's silence as meaningful. A watch that cannot answer is presumed dead and restarted.