Overview
Hyperliquid combines HyperCore, which supports native trading functionality, with HyperEVM for general-purpose compatible contract execution. Its blockchain uses HyperBFT, a consensus design related to HotStuff. These components should be distinguished from the interfaces through which users access them.
Mechanisms
A trading-oriented network still has consensus, validator, application and operational dependencies. An order acceptance is not equivalent to an executed trade, and an executed trade is not the same as a completed withdrawal. For derivatives, collateral, funding and liquidation mechanics create additional risks beyond simply holding an asset.
Risks and interpretation
Assess each market and integration separately: price sources, liquidity, liquidation rules, bridge paths and administrative powers can differ. This resource explains architecture and risk categories; it does not recommend leveraged trading. Use the linked documentation to identify the relevant version rather than treating a platform-wide description as evidence about a specific contract.
- 01Limit order
- 02Available liquidity
- 03Matched quantity
- 04Remaining order
Read these as connected concepts, not necessarily consecutive steps.
Read the explanation
HyperCore maintains order books, where orders are matched by price and time priority. A limit price constrains acceptable execution prices; it does not guarantee that enough counterparties exist. HyperEVM provides a distinct contract environment. HYPE is the network’s native token and is used for HyperEVM gas; owning it is not the same thing as opening a trading position.
Put the mechanism into context
In a fictional spot order book, you place a resting limit buy for 10 units at $20 maximum. Only 4 units are offered at $20 or less. Assume no fees and no other matching orders. Work out what fills now and what remains unfilled.
Apply it in the workshop →What this mechanism does not guarantee
Assess each market and integration separately: price sources, liquidity, liquidation rules, bridge paths and administrative powers can differ. This resource explains architecture and risk categories; it does not recommend leveraged trading. Use the linked documentation to identify the relevant version rather than treating a platform-wide description as evidence about a specific contract.
Worked case: order, fill and withdrawal
A fictional screen shows an accepted order for ten units and an execution of four. The accepted quantity is not the executed quantity. Six units remain subject to the order’s terms and current status. A later withdrawal is another instruction requiring its own completion evidence. Do not use a single “completed” flag for these different events.
Your analysis checklist
Record requested, executed and outstanding quantities separately. For a hypothetical leveraged position, also identify collateral, funding and liquidation dependencies before interpreting a profit figure.