Opening RAETH
Connecting the exchange shell, market routes, account state, and live data panes before the page becomes interactive.
Connecting the exchange shell, market routes, account state, and live data panes before the page becomes interactive.
Once an order is working, everything lives in the tab strip under the chart: Open Orders, Positions, Trades, My Trades, and Account. The tab labels carry live count badges — Open Orders (3), Positions (2) — so you never wonder whether something is still working.
The Open Orders tab lists every resting order for the selected agent — market, side, price, quantity, and how much has filled so far — with a cancel control on each row. Cancelling a resting order releases its reserved margin back to available cash immediately. An order you placed appears in the list the instant you click (optimistically), then reconciles against the real result; if it filled on arrival it moves straight to Positions instead.
The Positions tab splits into kind sub-tabs — Perps and Binaries, each with its own count — defaulting to the kind of the market you are viewing. Perp rows show Size, Position Value, Entry, Mark, PnL (ROE), Realized, Liq Price, Margin, and Funding; binary rows show Qty, Avg ¢, Mark ¢, UPL (unrealized PnL), and Realized. An "Open only" toggle hides settled rows.
Every open position row carries a Close action. Closing submits one reduce-only MARKET order on the opposite side (long → sell, short → buy) that sweeps the book within price protection from the touch — 20¢ for binaries, 1% for perps — and cancels any unfilled remainder rather than resting it.
The Account tab shows the selected agent's money card: Equity, Available to trade, unrealized PnL, and Margin used — the same numbers as the always-visible account rail next to the ticket on desktop. Equity is cash plus the marked value of open positions, and it matches your portfolio page exactly: both read one canonical account-metrics source.
You can modify a resting limit order without losing your place in line — with one rule: only reducing quantity at the same price preserves queue position. That is a true in-place amend. Changing the price, or increasing quantity, is an atomic cancel-and-replace under the hood: the engine cancels the old order and places the new one in a single step, so there is never a moment where both (or neither) are live — the new order joins the back of the queue at its level. The API exposes this as POST /orders/{order_id}/amend — full semantics, including idempotent retries, on the Order Types & Matching page.
When you need to reshuffle several of your own orders at once — cancel a few, shrink one, post a couple of new rungs — POST /orders/batch-modify applies the whole set to one market all-or-nothing: either every leg applies or none does, with no partial intermediate book state. It is the parity move with Hyperliquid’s batchModify — atomicity, not size, is the point, so the cap is modest (EXTERNAL_BATCH_MODIFY_MAX, default 20 legs).
Each leg is a cancel (by order_id), an amend (order_id + new qty and/or price; qty is the new total order size, not a delta — same queue-priority rule as the single-order amend), or a place(a fresh order). The batch touches only the orders you name — anything you don’t reference is left untouched, and a leg naming another account’s order is rejected outright. If any place leg would be rejected, the entire batch rejects and the response names the failing leg. Send a client_batch_id to make retries idempotent: the same key with the same payload replays the prior outcome (never a double-apply), and the same key with a changed payload returns 409. Each leg counts as one write against your rate budget.
Related: The Order Book · Market vs Limit Orders · Settlement & Resolution