What Happens When You Place a Trade on Hyperliquid?
Follow an order from the trading interface through consensus, matching, margin checks, and account updates.
Submitting an order starts a sequence of state changes. The action must be signed, relayed to the network, ordered by consensus, validated against the account, matched against the book when possible, and then reflected in balances, positions, fees, and margin.
Understanding this sequence makes execution problems easier to diagnose because an order can fail or change state at several different points.
The user signs an action
Hyperliquid trading uses cryptographic signatures. A main account can sign directly, or an authorized API wallet can sign supported actions for the account.
The signature proves authorization. It does not guarantee execution. The network still needs to accept the action, confirm the nonce is valid, and check market and account rules.
Automated systems should separate these concepts. A locally signed request, an API acknowledgement, an accepted order, and a fill are different states.
The network determines transaction order
The action enters Hyperliquid's L1 transaction flow. HyperBFT establishes the order in which committed actions are processed.
That ordering matters when orders compete for the same liquidity. A resting ask may have enough size for one incoming order but not another, so the sequence can affect fill quantity and price.
HyperCore validates the account
Before an order can change market state, HyperCore checks that the action is valid. The checks can depend on balance, margin, position size, account mode, market parameters, reduce only rules, order type, and other protocol constraints.
A rejected order therefore does not necessarily indicate a connectivity problem. The request may have reached the network but failed a financial or protocol rule.
The order meets the book
A marketable order trades against resting liquidity. A limit order that does not cross can remain on the book if its time in force allows it.
The difference between adding and consuming liquidity determines maker or taker treatment. Maker and taker fees are therefore an outcome of how the order interacts with the book, not only the order label chosen in the interface.
Partial fills are common. A large order can trade at several price levels and leave an unfilled remainder depending on its order type.
A fill changes financial state
For a spot trade, balances change. For a perpetual trade, the fill can change position size, entry price, realized profit and loss, unrealized profit and loss, margin requirements, and available collateral.
Cross margin positions can affect one another because they share account equity. A fill in one market can therefore change the risk buffer of another position even when that second position did not trade.
Funding and future mark price changes continue to alter account equity after the initial execution.
Production systems need reconciliation
A robust trading application should not treat the submission response as final truth. Connections can drop after an order was accepted, cancels can race against fills, and partial execution can leave residual exposure.
The safer pattern is to reconcile open orders, fills, balances, and positions against authoritative Hyperliquid state. WebSockets provide live events, while periodic state reads help recover from missed messages.
Continue reading
Read How an Onchain Order Book Works for matching and queue mechanics, then Building With the Hyperliquid API for the application side of submission and reconciliation.