FAQ
Is this financial advice?
No. Everything on the terminal is a statistic derived from historical and live market data. Pairs can and do break; stops and timeouts exist because mean reversion is a tendency, not a law.
Where do the pair signals come from?
Pairs are screened and fitted daily by a statistical pipeline that tests for a stable long-run relationship between coin pairs, then publishes the eligible ones with their fitted parameters and band levels. The terminal consumes that daily solve — the day's published list of eligible pairs with their locked statistics — and computes live z-scores against it in the browser.
Can the terminal see every market on Hyperliquid?
Yes — every coin, HIP-3 builder markets included, with HIP-4 to follow when the venue ships it. Pairs are a stricter club: only coins with a full year of trading history qualify for the daily pair screen, so the eligible universe grows as listings age in. A young market is fully visible here from day one — it just hasn't done the time yet.
Why do the numbers change once a day?
By design. The statistics (β, μ, σ, bands) are refit and locked daily so that every live reading has a fixed, stated reference. See Z-Scores & Bands.
Why is a pair suspended?
Its most recent daily fit is missing a required statistic. Rather than display a number computed from mismatched inputs, the terminal suspends the pair until the next clean fit.
Can a z-score be extreme, like ±8σ?
Yes — a genuinely blown-out spread reads exactly that way. The daily screen filters on statistical eligibility, not on the current z level, so pairs can appear already deep past their bands.
What if a pair I hold disappears from the daily solve?
Pairs can and do leave the daily solve — a pair drops out when it fails the pipeline's statistical gates or loses its threshold solution at a refit. Nothing happens to your money: an open position was locked at entry, so it keeps being monitored and priced on that locked recipe, armed exits still fire, and the pair's page keeps working in a reduced state that says exactly what it's pricing. A watch on a dropped pair has nothing locked to price — watches float with the daily solve — so the page shows the watch honestly without a chart until you remove it or the pair returns.
Where did my closed pair go?
Nowhere — it aged out of the Watch page's default view, by design. Closed rows show in the main view for 7 days, then the row moves off the working surface so the Watch page stays about what's live. The full record is on the Watch page's CLOSED tab: every closed pair you've ever traded, newest first, with the close reason, entry z → close z, hold days, entry gross, and realized $ where a number can honestly be claimed. Expanding a row shows the recipe frozen at entry. A row marked unpriced (or showing "—") means the fill journal never round-tripped flat — a leg was hand-closed on the exchange, or an exit's fills weren't journaled — so no realized number exists and none is invented. The tab's export CSV downloads the whole history, not just the rows loaded. See Closed history — the CLOSED tab.
What does "no longer tracked" mean on my position?
Tracking is the statistical pipeline's signal state, not yours: a pair is tracked while the pipeline has an open out-of-sample signal on it. The chip appears when that signal closes while your position is still open — the pair can still be in the daily solve; the pipeline's signal on it has simply closed. Nothing changes for your money: the recipe was locked at entry, so pricing, monitoring and armed exits run exactly as before, and the row leaves your Watch list only once you're flat. It is a different state from a pair disappearing from the daily solve — a dropped pair left the feed entirely; a no-longer-tracked pair is still there. See Positions — locked at entry.
Can I watch many pairs at once?
Yes. On the Pairs page, expand the book rail into the screener, check the pairs you want, and add them as one action — one request, one refresh. New watches take the suggested settings; a pair you already watch is skipped and keeps its custom settings, because a bulk add never overwrites an existing watch. Batches cap at 50 per request, and a batch that would pass your watchlist ceiling is refused with the numbers stated rather than partially applied. Bulk adds are watches only — arming is always per pair, on its own ticket.
How do I stop watching pairs?
The same way you started, wherever the watch lives: per-variant remove on the pair page's Track tab, a worded remove on every watching row of the Watch page (dormant rows included), or check any number of rows — on the Watch page or in the screener, with a select-all on the group head — and stop watching clears them as one request. Skips are named per item, never silent: an armed watch is excluded by design (a commitment stands down from its own pair page, not a bulk sweep), and a watch whose entry is filling settles first.
Why is this pair's entry blocked when my terms look fine?
Because the venue is refusing — not your terms. Hyperliquid caps each market's total open interest, and when one of the pair's coins sits at that cap the exchange rejects any position-increasing order on it: either direction, from anyone, until open interest drops. Your recipe, bands and caps can all be fine and the entry still bounces — the block is market-wide and outside the terminal's control. The pair's page says so with an amber at venue OI cap — entries blocked chip, arming is refused with the capped coin named, and an engine caught mid-entry stands down with the cap as its reason instead of grinding rejected orders. Closes and reduces are unaffected — reduce-only orders pass a cap by the venue's own rule — so you can always get out. The terminal re-checks the venue's capped list every ~60 seconds; the moment the coin frees, the chip clears and entries work again. See Venue open-interest cap — entries blocked.
Why can't I arm a pair that shares a coin with one I already hold?
By design: one coin, one pair. Hyperliquid nets each coin into a single account position, so two hedge-weighted pairs sharing a coin would merge into one number that cannot be honestly attributed back to either pair. The terminal refuses to create that state rather than display a guess — conflicting pairs are greyed with the owning pair named, and they unlock the moment it closes. The coin itself stays yours: you can hold it outright, trade it yourself, and resize your pair freely — only a second pair through the same coin is refused. The rule binds open positions (and an entry mid-fill), not armed entries: several armed pairs may share a coin and compete — see Why did my armed entry disarm itself?. When browsing for new pairs, the free legs chip on the screener hides pairs that share a coin with your open positions or a filling entry, so everything left is clear of this rule. See Pairs Trading 101.
Why did my armed entry disarm itself?
Another pair you armed filled first and took a coin they share. Armed entries sharing a coin all hunt at once, and the first fill wins the legs: the moment a position is born, every other armed entry sharing either of its coins is stood down to plain watching — your terms are kept, so re-arming is one click. Nothing re-arms automatically; re-entering after the winner closes is always your deliberate act. A toast announces each stand-down as it happens (ARM CONSUMED, with the winning pair named) and the journal records which pair consumed it. See Overlapping armed entries — first fill wins.
What happens if I trade a coin one of my pairs holds?
Nothing is blocked — the coin is yours. But the venue nets each coin into one position, so after a personal trade the venue total is the pair's leg plus your personal residual, and "you trimmed the pair" vs "you traded personally" is genuinely unknowable. The desk tracks the pair by its own fill ledger and never guesses: your row shows a neutral residual chip (venue holds less / holds more / points against the pair), exits size only up to the venue holding that points the pair's way, and a row is closed for you only when the venue provably holds nothing in a leg — marked liquidated when the venue's fill flag confirms a liquidation, manual_venue otherwise. The one exception is yours to choose: when the venue holds more than the pair's book, the exit ticket offers an opt-in flatten — the armed exit also nets out the extra with one reduce-only clip, sized to the live gap at fire. It is never on by default, disarming clears it, and the row says venue holds more · exit flattens it while it's set. See Venue truth.
Can I set my own profit target or stop?
Yes. When you arm or update an exit, the ticket pre-fills the model's entry-frozen terms, but the profit target, stop, and give-up time are yours to change — typed as a distance from your entry in % (or σ), with the dollar amount at your actual size shown beside it. The exit then carries an amber custom exit chip and keeps the model's numbers next to yours; blanking a field or typing the suggested value back restores the model's terms. The guard rails are named, never silent: a stop cannot sit on the profitable side of your entry or closer than a small floor, a custom target still waits out the 24-hour minimum hold (the stop and timeout are exempt), and a stop looser than the model's is flagged as more room — and more risk — than the solved terms carry. One honest note: targets are held at least 24 hours, while the strategy's published backtest stats were measured with a 3-day hold. Changes reach the engine within about five minutes, and the ticket says so before you confirm.
Why can't I arm an exit on this position?
Because it was entered past-stop — past the stop constraint, behind the launcher's loud confirm — and the spread hasn't healed back inside the stop yet. The deal you accepted at entry is exactly this: no exit, stop or timeout fires while the position sits beyond its own stop boundary, because a stop that would fire the moment the position settles isn't a stop. The ARM EXIT button states the live distance (z now x, stop at y) and goes clickable the moment live z is back inside — the server re-checks with live prices when you arm — and from then on the entry-frozen solver terms fire normally. Until then, closing is manual and always available: EXIT NOW and −REDUCE work throughout. Two notes: a re-armed exit runs the frozen solver terms verbatim (custom terms aren't available on past-stop rows), and the amber past-stop entry chip stays on the row either way, so the provenance never disappears. See Past-stop entries.
I don't see my order on the exchange — where is it?
Working server-side, by design. The engine's algos fire immediate-or-cancel clips: each clip either fills or vanishes on the spot, so between clips nothing rests on the exchange — an empty venue Open Orders list is normal while an entry is working. The order's home is the terminal: the pair's page shows ENTRY WORKING with dollars filled so far, the Watch row shows FILLING, and the pair desk Blotter's Algos tab lists every server-side algo on the account — state, reason, filled dollars, and a cancel. The wallet page's Open orders tab carries a pointer row whenever algos are working. If a fill stalls, the state turns amber ENTRY STALLED with the engine's own reason and an alert is raised; a stalled entry is force-cancelled after a hard time cap, and cancelling settles what filled — the traded legs become a real position with its stop, exit and timeout live, and the untraded remainder is reported as an honest shortfall.
How do I see what just traded?
Three surfaces, ordered by recency. The instant a fill lands, a toast rises bottom-centre on whatever page you're on (with a sound), and finished algo parents announce DONE or FAILED the same way. Missed the toast? The Trades panel — at the bottom of the right rail on the Trade Cockpit and the Pair Desk, and above the solve card on the Watch page — keeps a scrolling window of your recent activity in two tabs: FILLS, each print with side, size, coin, price, and time (dollar amount and direction on hover), and ALGOS, your latest algo parents with intent, slippage, and verdict. Rows greyed under earlier — before this session come from the venue's recent-fill snapshot, so the window is seeded even after a reload; the panel holds the latest 200 rows and counts unread fills while collapsed. For the full record, the Blotter and the Watch page's CLOSED tab remain the deep history.
What happens if my armed exit stalls while firing?
It retries, then stands back up — never silently. An exit in flight can stall when the venue or its rate limits refuse orders mid-fire. When that happens, the Watch row shows an amber EXIT STALLED chip with the engine's own reason instead of claiming the exit is still firing, and an alert is raised. The engine retries on a backoff; if the venue keeps refusing, it cancels the stalled order cleanly and the exit re-arms — it fires again on its next crossing. A stuck order is also force-cancelled after a hard time cap regardless of cause, so your stop and timeout are never left dark behind a wedged order.
Can I add to or reduce an open position?
Yes — from the pair page's +ADD and −REDUCE buttons. An add scales the position up on the recipe locked at entry (one position, one recipe — an add never picks up today's refit) and climbs the same permission ladder and caps as an entry. A reduce sheds a fraction (25/50/75% chips, or a leg-A dollar amount) with reduce-only clips — it can shrink the position but never flip it; reducing to flat closes it. Every scale fill is journaled, so the entry becomes the journal-weighted average and the Watch row's expanded view shows the full fill history. Two things never change on a scale: the exit terms and the clocks — target, stop and timeout still run from the original open. One working order per position at a time: while a scale is settling the row shows SCALING and exits hold.
What happens if my margin runs out while a watch is armed?
The entry refuses or pauses by name — and your stops keep firing regardless. At the moment an armed entry would fire, the engine checks your live margin available (the venue's withdrawable figure plus free spot USDC) against what the two legs need; short, and the fire is refused with both numbers — margin available ~$X, entry needs ~$Y — deposit USDC or free margin. The watch stays armed and re-checks every ~10 minutes while the signal holds, so a deposit heals the refusal without waiting for another band crossing. If margin runs dry mid-fill instead, the venue's own insufficient margin rejections pause the entry with that reason on the row and an alert; the engine retries on a backoff — deposit and the pair completes, stay unfunded and it stands down honestly with what filled settled and any shortfall named. Exits, stops, reduces and closes are reduce-only orders, which the venue exempts from margin checks — running out of margin can stop you getting in, never getting out. See Margin runs out — entries refuse, exits still fire.
I've used 68% of my margin — am I 68% of the way to liquidation?
No — barely a third. "Margin used" and the "margin ratio" are two different margins. Margin used is initial margin — the capital your open positions have committed (size × mark price ÷ leverage, summed): capital utilisation, how much of your equity is working. The margin ratio is the liquidation clock: maintenance margin ÷ account value, and maintenance is about half of initial margin at max leverage. Worked example: $872 equity with $598 margin used reads 68.6% used — but maintenance is ≈ $299, so the margin ratio is 34.3%, with $573 of margin available above the line. Liquidation comes when the margin ratio hits 100% — account value falling to the maintenance requirement — not when margin used reaches 100%. Every term is defined in the Glossary.
Does the terminal trade for me?
The engine works orders you arm — it never decides to trade. Thirteen algos have live engines today: TWAP (native), Adaptive Market, Now (IOC), TWAP+, VWAP, POV (Participation), Iceberg, Chase, Scale / Ladder, Stop / Take (native), Bracket (TP + SL), PairGlide, and Autospreader (the pair algos arm from the pair ticket). Arming requires a connected wallet that has signed in and enabled trading — an order-only agent your wallet approves on Hyperliquid itself, plus a builder-fee cap (the transitional rail that collects accrued construction fees) — and every armed order's construction fee is disclosed on the ticket before you sign anything. Armed watches and armed exits fire server-side: the engine monitors the bands and forwards the order through your agent even while your browser is closed — Hyperliquid places the trade. The rest of the Launcher catalogue is a preview: configure it, see the schedule on the chart, price it against the live book, with the gate stated on the Arm button itself.
Can I trade HIP-3 builder markets here?
Yes — as single-coin orders. Every HIP-3 builder-deployed market gets the full cockpit, and the single-coin algos in the Launcher arm on them exactly as on any other market. Pairs are the one exception today: the pair pipeline (signals, watches, pair positions) is built on Hyperliquid's main perp listings — HIP-3 pair support is coming, but no builder market is a pair leg yet. Two things to know before you trade one: a HIP-3 deployer can scale the venue's trading fees — when a market carries a fee multiplier, the cockpit's cost estimator shows it in amber before you commit; and HIP-3 positions margin separately per builder market — your wallet page shows a per-market HIP-3 subtotal block rather than folding them into the headline margin numbers, because a single "margin used" figure across separately-margined books would be a lie.
Why does a HIP-3 market's coin card show fewer numbers?
Because on a builder market, the exchange is the only honest source. A HIP-3 card (a stock, an ETF, gold, an index) shows venue data only — live price, open interest, funding, leverage — plus a short description and which builder dex runs the market. The rows a crypto card carries beyond that (market cap, FDV, protocol usage, unlock dates) describe crypto assets and come from crypto data feeds; a dex-prefixed ticker has no honest match there, so those rows are absent rather than guessed. The card's footer says exactly this.
How am I charged?
A construction fee — a software fee journaled to your tab when the terminal builds an order from your parameters, at the per-algo rate shown on the ticket before you commit (the schedule). If the order never fills — cancelled, expired, or failed — the fee is rebated to your tab automatically; partial fills rebate the unfilled fraction. Every account starts with a USD 20 construction credit that offsets these fees — a fee offset only, not money, never withdrawable. Accrued construction fees are collected through the transitional builder rail inside the 0.04% cap your own wallet signed — one fee, accrued once at construction, collected once, never twice — and the reconciliation ledger on your account page credits back any over-collection. Fees never flow through the agent key, and you are never asked to prepay. No success fees, no subscriptions, no hidden charges. See Legal & Risk.
How do I fund a Hyperliquid account?
On Hyperliquid itself — never through us. The terminal never takes deposits and never holds funds; trading capital lives in your own Hyperliquid account. If you don't have one yet, start there — that link carries our referral code: Hyperliquid gives you its referral discount (currently 4% off trading fees, on your first $25M of volume) and pays us a share (currently 10%) of the protocol fees it collects from you. Hyperliquid pays that share out of its own fees — it never adds to what you pay, and it is separate from the construction fee. See Legal & Risk.
Do you hold my funds?
Never. pairpetuals.com is a data and analysis terminal: it constructs orders, your wallet authorizes them, and Hyperliquid executes them. Matching, execution, settlement, and custody all occur on the Hyperliquid protocol — we never hold funds and never see wallet keys. The agent your wallet approves can only place orders; it cannot withdraw or transfer, expires on its own, and is revocable at any time — see the next answer. See Legal & Risk.
How do I revoke the trading key?
In the account rail on any trading page, the Trading · agent key card has a Revoke key button — the first click asks you to confirm, the second revokes. It takes effect on this site at once: the engine stops signing with the key within seconds, armed watches and armed exits stop firing, and the key is never reused — enabling trading again mints a fresh one. Be deliberate if you hold open positions: an armed exit is worked through this key, so after revoking, your target, stop, and timeout no longer fire — manage or close those positions yourself. The approval recorded on Hyperliquid itself is removed from Hyperliquid's own API settings page, and it expires on its own within 180 days regardless. The builder-fee cap is a separate approval, also revocable through Hyperliquid.
Can I run the terminal myself?
Not yet — but a desktop app is coming. It's the same terminal, running as an app on your own machine: orders are signed locally, so your keys stay with you, on your hardware, and never touch our servers. There's no download today — the Desktop · soon button on pairpetuals.com opens the waitlist, and we'll email you when it's live.
Why can't I connect my wallet?
Wallet connection isn't offered in some regions — the connect window names the detected country when that applies. Everything else stays open: live markets, pairs, wallet lookups, and these docs all work without connecting. The list of restricted jurisdictions is in the Terms of Use, §3. If your region is detected wrongly (a VPN or corporate network can do that), the check re-runs each time you open the connect window from an ordinary connection.
What are the "tape reads"?
Heuristics over public prints — suspected TWAPs, sweeps, block prints, aggressor flips, funding flips, OI jumps. They are always worded as "suspected" because that is what they are: inferences from public data, not facts. See The Trade Cockpit.
Where do the "known liq levels" come from?
From the venue itself, not a model. The terminal maintains its own watch registry of Hyperliquid's most active wallets — ordered by 30 days of large-taker notional, refreshed nightly — and a paced sweep re-reads each registry wallet's positions roughly every 20 minutes, recording the venue's own computed liquidation price for every levered position it finds. No leverage assumptions, no estimated bands: every level on the instrument's forward rail — board and drill alike — is a real position's real liquidation price. The trade-off is stated on the page: the registry sees the wallets it watches, not the whole venue, so every total is a lower bound on the real liquidation mass — a floor, never an estimate. The coverage line under the instrument says exactly how many wallets were swept and what they hold. See Liquidations.
Why do the evidence stats say "warming"?
Because the cascade archive isn't 30 days deep yet — and a statistic from a thin window would overstate certainty. The snapback and pair-edge numbers (and the second-leg pressure annotations) are computed nightly from our own archive of confirmed cascade episodes, and every one of them is withheld behind the same 30-day gate: until the window fills, the surfaces read warming — Xd of 30d instead of a number, and they light up by themselves the day it does. Nothing is broken; the terminal is refusing to show a stat it cannot yet defend. The same honesty applies past the gate — an empty denominator renders "absence is the reading", never 0%. See Liquidations.
Where does The Wire come from?
The Wire is machine-written twice a day — 06:30 and 18:30 UTC — and machine-checked before anything publishes. Every number starts in a fact pack built from venue data the terminal already maintains: Hyperliquid market stats (price, volume, open interest, funding) plus our own confirmed-liquidation archive. The movers are picked by the data — volume and move-size rules — never by the writer; a language model only explains them, reporting what trader chatter on X attributes the moves to. Before publish, every draft passes mechanical checks: every numeral in the prose must exist in the fact pack, every ticker must be a market in the pack, and advice grammar, promotion, and disparagement are refused outright. A section that fails is omitted with an honest line; an edition with too few clean sections is withheld entirely, and the last published issue stands under its real date. Issues are frozen at publish — a day's page never silently changes — and kept for a rolling month. It is market reporting, not investment advice.
Why are The Wire's liquidation numbers a lower bound?
Because they are confirmed events, not estimates. Hyperliquid publishes no liquidation feed, so most trackers infer liquidations from leverage assumptions; our detector ingests only fills carrying Hyperliquid's own liquidation marker — every row is a real liquidation, but not every liquidation becomes a row. That is 100% precision with partial recall, so every liquidation figure on The Wire is labeled confirmed (lower bound) — a floor, never an estimate. The Liquidations page runs on the same detector and carries the same label.
Why do some cost numbers say "> visible book"?
The exchange feed shows a bounded number of book levels. When a clip you're pricing exceeds what's visible, the terminal flags it instead of extrapolating a cost it cannot know. Stale or missing data is always labeled — never dressed up as live.
Is my data shared with the exchange?
Browsing requires no account. The terminal reads public Hyperliquid market data over its published API and WebSocket feeds.