Watching & Tracking

The terminal separates three states with deliberately different semantics, all on the Watch page — one table with live-count filter tabs:

• Watching — interested. The pair is in your book and visible; nothing is committed.
• Armed — committed, unfilled. A resting trade persists in your Watch list and the engine fires it when the band crosses. Nothing rests on the exchange until it fires. Armed rows sort on the pair, spread-now and days-armed headers — the DAYS column shows how long each entry has been armed.
• Positions — money at risk, judged against the recipe locked at entry. Position columns sort on click — live numbers snapshot as of the click, and the order holds until you re-sort. The Watch page's Algos tab marks each parent order with what it did — entry, exit, add, reduce, open or close — and pair orders show their combined slippage vs arrival once the engine journals it at finish.

Watching — floats daily

A watch follows a pair using whatever the current daily solve says. Every day the statistics refit, and your watch floats with them — you are always looking at today's recipe.

Watch settings are expressed in z-space (entry, exit, stop, timeout), either as absolute levels or relative to the suggested ones. Because they are in z-space, they remain meaningful across daily refits by construction. Tracked pairs (those the statistical pipeline has an open out-of-sample signal on) come with the model's terms locked at signal time; untracked pairs refit daily, and the arm ticket says so.

The screener — watching in bulk

On the Pairs page, the book rail on the right edge expands into a screener: one click widens the strip across the chart into a sortable table of the full eligible universe — composite, half-life, Hurst, spread volatility, Sharpe, dollar balance, and live z per pair. In the narrow strip, the Positions and Armed entries group heads carry small sort chips — pair name, distance from the mean in your display unit, and P&L — snapshotted as of the click, never reshuffled by ticks. Two numbers carry honesty chips: the Sharpe column is marked in-sample because it is measured on the fit window the model was trained on, not out-of-sample; the half-life cell's tooltip carries θ, the mean-reversion pull rate it implies. Sorting a live column snapshots the values at the moment you click — re-click to refresh.

Column heads do double duty: the funnel beside a sortable column sets a threshold — composite or Sharpe at least x, half-life or Hurst at most x, live |z| at least x. Thresholds cut only the browse section, and a statistic the pipeline has not produced never passes a cut — "—" is not a value. The live-z threshold is checked against prices from the moment you apply it, and the active-thresholds chip shows that time; re-apply to refresh, or click the chip once to clear every threshold.

The half-life and Hurst columns carry an optional heat tint: a faint background from green (faster reversion, more mean-reverting) to red (slower, trendier). Hurst is graded on fixed anchors around the 0.5 random-walk pivot; half-life is graded against today's eligible universe, so the same four-day half-life reads differently on a fast day than a slow one. The tint is paint only — the numbers keep their own ink — and the heat toggle in the screener header turns it off.

A free legs chip sits beside the filters when you're signed in. Watching is free — you can watch any number of pairs, shared coins and all — but commitment is exclusive: the exchange nets each coin into one account position, so arming a pair whose coin is already used by an open position or an armed entry is refused until that coin frees up (one coin, one pair). The chip applies that same rule to browsing: on, the browse list hides pairs that share a leg with your book and says how many it hid; off, you see the full universe. It cuts browsing only — your own Positions, Armed and Watching groups always render — and it is a courtesy, not the check itself: the arm ticket still verifies everything at the moment you arm. The chip appears in the narrow strip too, and the two views share the one setting.

The Positions, Armed and Watching groups collapse — in the screener and the narrow strip alike, and the choice is shared between the two views. Collapsed rows stop updating live entirely; the count on the group head stays visible, so the book never hides what it holds. Picking any row closes the screener back to the side strip and opens that pair's page.

Check pairs in the browse section and add them as one action: a single request creates every watch with the suggested settings. A pair you already watch is skipped and keeps its custom settings — a bulk add never overwrites an existing watch — and every skipped pair reports why. If a batch would pass your watchlist ceiling, the whole request is refused with the numbers stated, never a silent partial add.

Watching — and stopping watching — are the only actions the screener offers. Arming stays on the pair's own ticket, where the full recipe and fee are in front of you.

Stopping a watch — everywhere it lives

Removing a watch is as easy as adding one, wherever you meet it:

• On the pair's page, the Track tab lists your variants with a per-variant remove; the hero button says watching · manage whenever the pair is in your book, so the page never pretends otherwise.
• On the Watch page, every watching row — including dormant ones whose pair has left the daily solve — carries a worded remove button, and the rows are checkable: select as many as you like (the group head selects them all) and stop watching clears them as one action.
• In the screener, the WATCHING group is checkable the same way — pick rows, or the whole group from its head, and stop watching (n) removes them in one request. A removed pair simply migrates back to the browse section.

Bulk removal follows the bulk-add grammar: one request, one refresh, per-item skips with the reason named. Two kinds of watch are excluded by design: an armed watch is a commitment, and commitments stand down on their own surfaces — disarm it from its pair page; a watch whose entry is filling settles first — the request is refused for that item until the fill completes. Removing a pair removes all its plain watch variants, and the result counts watches, not pairs, when the two differ.

Arming a watch — the entry fires itself

Arm a watch with a leg-A dollar size and from there the engine is mechanical: it monitors the live z server-side and, when the entry band crosses, forwards a β-weighted two-leg entry through the order-only agent your wallet approved — while your browser is closed, if that's when it happens. At the moment of fire the full recipe is frozen, so a refit between fire and fill can never bend your terms. The entry side is set by whichever band fires.

• Arming requires a connected wallet that has signed in and enabled trading — see Getting Started.
• An arm fires once. The fill consumes it: the moment the position exists, the watch drops back to plain watching, and closing the position never re-arms it. Re-entering is a deliberate re-arm, never automatic. The fill also consumes every other armed entry sharing either of the new position's coins — see Overlapping armed entries below.
• One armed variant per pair, and a pair sharing a coin with an open position (or an entry mid-fill) cannot be armed — positions own their coins. Other armed entries don't block: overlapping arms are allowed and compete.
• Armed fires accrue a construction fee — journaled to your tab when the order is built, 0.04% per leg, rebated automatically if nothing fills; the transitional builder rail collects it on fills. Both facts are disclosed on the arm ticket before you confirm.

A firing entry is watched as closely as the exit. While it fills, the pair's page shows it in the hero — ENTRY WORKING, with dollars filled so far — and the Watch row says FILLING; the buy, sell and arm buttons stand down while a working entry exists, so a half-filled order can never be doubled by accident. If the fill stalls, the state turns amber ENTRY STALLED with the engine's own reason, an alert is raised, and a worded cancel entry sits right on the row. A remainder too small for the venue to accept never stalls at all — the order finishes with the shortfall named. A stalled entry is force-cancelled after a hard time cap regardless of cause — the cap is a pre-committed rule, not an engine choice — and cancelling — yours or the cap's — settles what filled: the legs already traded become a real position with its stop, exit and timeout live, and the untraded remainder is an honest shortfall, never worked blind. One thing you will never see is the order resting on the exchange: the engine's entries execute as immediate-or-cancel clips, so between clips there is nothing on the venue to cancel. The pair page, the Watch page, and the pair desk Blotter's Algos tab (the Blotter is the pair desk's working-orders panel) are where a working order lives — and the wallet page's Open orders tab says so whenever server-side orders are working.

Overlapping armed entries — first fill wins

Several pairs sharing a coin may all be armed at once — armed entries are competing hunters, not commitments. The first to fire claims its coins on the spot: while it fills, competitors are refused at the fire gate, so no overlap can ever build exposure alongside it. When the fill lands, the winner takes the legs — every other armed entry sharing either of the new position's coins is stood down to plain watching, with its terms kept for a one-click re-arm. Nothing re-arms itself: re-entering after the blocking position closes is always a deliberate act.

The terminal keeps the competition visible. Armed rows sharing a coin carry a neutral shares BTC · 2 armed chip — it measures overlap, it isn't a warning — and the arm ticket says who else is hunting a coin before you commit. When a fill consumes siblings, a toast announces each stand-down (ARM CONSUMED, with the winning pair named) and the journal records it. If two overlapping entries cross in the same tick, the higher statistical composite fires first, and a pair with a composite beats one without. The one coin, one pair law is unchanged where it matters: across open positions, a coin still belongs to exactly one pair.

Positions — locked at entry

When a position opens, the full recipe — β, μ, σ, and every band level — is locked as a snapshot. The position is judged against the numbers that justified it at entry, not against whatever today's refit says. It stays locked until closed.

This mirrors how the underlying strategy is evaluated: a trade's thesis is the recipe it entered on.

Open positions can arm an exit — one order, three ways out: the profit target (held at least 24 hours — the stop and timeout are exempt), the stop, or the timeout, whichever comes first. The armed exit persists in your Watch list — nothing rests on the exchange until it fires — and closes are sized from what you actually hold, reduce-only by construction.

The exit terms are yours to amend. The exit ticket pre-fills the model's entry-frozen terms, but the target, stop, and give-up time are editable — typed as a distance from your entry in % of the first leg (or in σ), always with the dollar equivalent at your actual size beside it. The stop you type is additive: the desk adds your distance to your actual entry level and locks the sum as an absolute level on the adverse side — a stop of 0.75σ on a position entered at +2.4σ arms at +3.15σ, and that sum is the exact level that fires (and the level the chart's STOP · yours line draws). The distance must be at least 0.75σ — a stop closer to your entry than the engine's minimum risk distance is refused by name, never silently clamped. An amended exit carries an amber custom exit chip and keeps the model's numbers on display next to yours; blanking a field, or typing the suggested value back, reverts to the model's terms. Two honest footnotes sit on the ticket itself: a custom profit target still respects the 24-hour minimum hold, and changes reach the engine within about five minutes.

Firing is watched as closely as arming. If the exit engine stalls mid-fire — the venue or its rate limits refusing orders — the row says so instead of pretending: an amber EXIT STALLED chip with the engine's own reason replaces the firing state, and an alert is raised. The terminal retries the stalled order on a backoff; if the venue keeps refusing, it stands the order down cleanly and the exit re-arms, ready to fire on its next crossing. A stuck order is force-cancelled after a hard time cap regardless of cause — a pre-committed rule, not an engine choice — so the stop and timeout are never left dark behind a wedged order.

Past-stop entries

A pair can be stretched past the stop constraint when you meet it — live z already sits at or beyond the stop the solve was run around. The page doesn't refuse: BUY and SELL still route to the launcher, but a tracked entry here is past-stop, and the launcher asks a loud two-click confirm that states exactly what you're accepting before anything fires. (An armed watch never fires in this zone — the engine only fires entries inside the entry band; a past-stop entry is something you do knowingly, live.)

Three things, and the confirm says all three:

• You entered past the stop constraint. The solve's terms still freeze at entry, like any position — but the position is born already outside its own stop boundary.
• No exit, stop or timeout fires until the spread heals back inside the stop and you re-arm the exit. A stop that would fire the instant the position settles isn't a stop, so the engine doesn't monitor a past-stop position at all while its exit is unarmed — and the row never paints an exit it isn't running: no target/stop line, no stop hit tint, and ARM EXIT stays disabled with the live distance stated (z now x, stop at y). Past-stop positions are also born without a timeout, for the same honesty.
• Closing is manual meanwhile. EXIT NOW and −REDUCE work throughout — they are your out, and +ADD stays live too.

The row carries an amber past-stop entry chip on every surface. Once live z is back inside the stop boundary, ARM EXIT goes clickable — the server re-checks with live prices at the moment you arm — and from then on the entry-frozen solver terms fire normally, as a real venue trade. A re-armed exit runs the frozen solver terms verbatim: custom targets, stops and give-up times aren't available on past-stop rows. Disarming puts the row back in the unmonitored state; the chip stays either way, so the provenance never disappears.

Scaling a position — add and reduce

An open position can be scaled from its pair page: +ADD buys more of both legs on the recipe locked at entry — one position, one recipe; an add never picks up today's refit — and −REDUCE sheds a chosen fraction (or leg-A dollar amount), reduce-only by construction, so it can shrink the position but never flip it. Both open a ticket with the same two-click confirm as arming.

Every scale fill is journaled into the position, so the Watch list stays honest by construction: the entry shown becomes the journal-weighted average, sizes and P&L fold the new fills in, and the row's expanded view carries the full fill history — time, intent (entry / add / reduce), side, size and price — as the audit trail. A neutral SCALED chip marks a position that was scaled after entry; while a scale is working, the row shows SCALING and exits hold until it settles — one working order per position at a time.

What scaling never changes: the exit terms and the clocks. Target, stop and timeout still run from the original open — the ticket says so — and the amend path above is how terms change. Adds climb the same permission ladder as entries and count toward your caps; reduces, like closes, are cap-exempt. Reducing all the way to flat closes the position.

Because the recipe is locked, a position survives the pair leaving the daily solve entirely: if a pair drops out at a refit — it failed the pipeline's statistical gates or lost its threshold solution — your position keeps being priced and monitored on the locked recipe, armed exits still fire, and its pair page keeps working in a reduced state marked not in today's solve.

A quieter state than dropping is no longer tracked. Tracking is the pipeline's signal state: a pair is tracked while the statistical pipeline has an open out-of-sample signal on it. When that signal closes while your position is still open, the row shows an amber no longer tracked chip — the pair may still be in the daily solve; the pipeline's signal on it has simply closed. Nothing about your money changes: the recipe was locked at entry, so pricing, monitoring and armed exits run exactly as they did the moment before. The chip is information, not an instruction, and the row leaves your Watch list only once you're flat.

Venue truth

The Watch page never pretends. Position rows are verified against the venue's own state: a position the engine cannot fully verify shows amber and unsized rather than a green side chip, and a leg that was hand-closed or resized on the exchange directly is flagged (sized down on venue, grew on venue, closed on venue) instead of silently absorbed.

Personal trading in a pair-leg coin nets into the same venue position, so a row can also carry a residual chip: venue holds less (exits size to the smaller — the desk never guesses trimmed-vs-personal), venue holds more, or venue points against (exits stand down). The extra behind venue holds more is yours and is never touched silently — but closing the pair would leave it open, so the exit ticket names the gap in plain numbers and offers an opt-in: the exit also flattens it. Checked, the armed exit adds one reduce-only clip per affected leg, sized to the live venue-vs-journal gap re-read at the moment it fires — not the gap when you armed. The opt-in is never on by default, disarming the exit clears it, and a gap that has flipped direction or shrunk below the venue's minimum is skipped with the event named. Flatten fills are never journaled into the pair — they exist only to net the venue back to the pair's book. A row running with the opt-in says so: venue holds more · exit flattens it.

Venue open-interest cap — entries blocked

Hyperliquid caps each market's total open interest, and when a coin sits at that cap the venue itself refuses any position-increasing order on it — either direction, from anyone, regardless of the terms you set. Closes and reduces still pass: the cap blocks growth, not exit.

The terminal checks the venue's capped list (re-read every ~60 seconds) and says so before money moves. A pair with a capped leg carries an amber at venue OI cap — entries blocked chip in its hero; arming an entry or an add is refused with the coin named and a plain statement that closes still work; and an engine already working an entry stands down cleanly, naming the cap as its reason, rather than burning rejected orders against a wall — including the ugly case where one leg filled and the hedge leg is the one that's capped. Exits, reduces and armed exits are untouched throughout: reduce-only orders pass a cap by the venue's own rule, so you can always get out.

The block is not yours to fix and not the terminal's: it frees on its own when open interest in that market drops — other traders closing — and the chip clears on the next check.

Margin runs out — entries refuse, exits still fire

Armed entries spend margin, and an account can drift toward empty between arming and firing. The engine handles it by name, in layers — and the one thing never gated is your way out.

At fire time, the entry is refused with both numbers. The moment an armed entry would fire, the engine reads your live margin available — the venue's own withdrawable figure, plus free spot USDC on a unified account — against what the two legs need, sized at each coin's max leverage with a 15% buffer. Short, and the fire is refused honestly — margin available ~$X, entry needs ~$Y — deposit USDC or free margin. The watch stays armed, an alert is raised once per starvation episode, and the engine re-checks every ~10 minutes while the signal holds — a deposit heals the refusal without waiting for the spread to cross the band again.

Mid-fire, starvation pauses by name — and a deposit completes the pair. The fire-time check is deliberately optimistic (a per-coin leverage you lowered on the venue can slip past it), so the venue's own answer is the backstop. When margin runs dry while an entry is filling, the venue refuses clips with its insufficient margin message; after two consecutive margin rejections on a leg the entry pauses with that exact reason on the row and an alert is raised. The engine retries on a backoff: deposit while it waits and the schedule resumes and the pair completes; stay unfunded and it stands down honestly — what filled settles by the same rules as any stalled entry, a shortfall named, a single filled leg flagged for you to flatten, never worked blind.

Exits are never margin-gated. Stops, targets, timeouts, reduces and closes are reduce-only orders, and the venue exempts reduce-only orders from margin checks — your stop still fires with margin available at zero. Running out of margin can block you from getting in; it can never block you from getting out.

Closed history — the CLOSED tab

Closed rows age out of the Watch page's main view after 7 days — the default view stays a working surface, not an archive. Nothing is deleted: the CLOSED tab keeps your full trade history, forever, one page at a time (a load more button walks it, newest first).

Each row keeps the salients of what the pair was: the close reason, entry z → close z, hold days, entry gross (summed from your actual entry and add fills — journal truth, not an estimate), and realized $ with its % of gross. Expanding a row shows the full recipe frozen at entry — β, μ, σ, the entry/exit/stop levels with their basis, the timeout, and the long-window anchors — plus how many times the position was scaled.

Realized numbers follow one law: a dollar figure is claimed only when the journal round-tripped flat — every unit opened was closed through journaled fills. A row that doesn't meet that bar — a leg hand-closed on the exchange, or an exit whose fills weren't journaled — shows — and is counted as unpriced, never estimated. The strip above the table is computed server-side over your whole history, not the loaded page: total closed, realized Σ over priced rows only, and a win rate that counts priced rows only — unpriced rows are named, never blended in. While the priced sample is small, the strip says so.

The export CSV button downloads every closed round trip — it walks the full history page by page, not just the rows on screen — with the same honesty: realized columns are empty, never zero, where the law says "—". Rows that were removed before ever holding a fill are not history and don't appear here.

Variants

You can keep any number of watch variants per pair for observation, but only one can be armed per pair — the legs net at the exchange per coin, so multiple armed variants on the same pair would interfere with each other. It is the same ownership rule as one coin, one pair.

From Watch to desk

Every row in your Watch list carries a TRADE → button that opens the Pair Desk. A position loads its locked recipe; a watch loads today's solve — the header chip always says which one the page is running on.

What "watching" means

An unarmed watch is observation only: the pair is in your book and visible when you look. Only armed watches and exits are monitored server-side — the terminal monitors nothing you have not armed, and what fires is your standing instruction, at your terms. There are no push notifications yet; armed orders fire while the engine is running and land in your Watch list and blotter.