Hyperliquid Feature Analysis
Key Concepts
| ID | Term | Definition |
|---|---|---|
| 1 | HyperCore | The native execution layer where Hyperliquid’s trading logic lives. |
| 2 | HyperEVM | Hyperliquid’s EVM-compatible smart contract layer. It is part of the same L1 as HyperCore, not a separate chain. |
| 3 | CLOB | Central Limit Order Book. A trading model where bids and asks are stored in an order book and matched by price-time priority. |
| 4 | Mark price | A reference price used for margining, liquidations, TP/SL triggers and unrealized PnL. |
| 5 | Maintenance margin | The minimum margin required to keep a position open. If account equity falls below it, the position can be liquidated. |
| 6 | Multi-sig | Native account control where a defined set of signers and a signature threshold are required to approve actions. |
| 7 | HIP-3 | Hyperliquid’s proposal for builder-deployed perpetual markets, where deployers can launch perps with their own market settings while inheriting HyperCore infrastructure. |
| 8 | CoreWriter | A HyperEVM system contract that allows smart contracts to send encoded write actions to HyperCore. |
| 9 | HLP | Hyperliquid’s main protocol vault, used for market making, liquidations, Earn supply and fee accrual. |
| 10 | EVM | Ethereum Virtual Machine. The smart contract execution environment used by Ethereum. |
| 11 | PnL | Profit and Loss. |
1. Summary
Hyperliquid is a custom Layer 1 blockchain built around HyperCore and HyperEVM, designed to support a fully onchain financial system.
HyperCore is the native trading engine. It handles perpetuals, spot markets, order books, matching, margin, funding, liquidations, vaults, staking and multi-sig.
HyperEVM is the EVM-compatible smart contract environment. It allows builders to deploy dApps and smart contracts that can interact with HyperCore instead of building from zero.
2. Architecture
Hyperliquid
│
├── HyperCore
│ │
│ ├── Trading products
│ │ ├── Perpetuals
│ │ └── Spot markets
│ │
│ ├── Trading infrastructure
│ │ ├── CLOB order book system
│ │ └── Clearinghouse
│ │
│ ├── Risk mechanics
│ │ ├── Oracle prices
│ │ ├── Mark price
│ │ ├── Funding
│ │ ├── Liquidations
│ │ └── Margin tiers
│ │
│ └── Protocol-level features
│ ├── Vaults
│ ├── Staking
│ └── Multi-sig
│
└── HyperEVM
│
├── EVM-compatible smart contract layer
├── Smart contracts
├── dApps
├── DeFi integrations
└── Connection with HyperCore liquidity
| Component | Role |
|---|---|
| HyperCore | Core exchange logic and native protocol features. |
| HyperEVM | Smart contract layer for builders. |
3. HyperCore Features
| Feature | Description | Hyperliquid |
|---|---|---|
| Perpetuals | Derivative markets where users can trade long or short exposure with leverage, without owning the underlying asset. | Supports 100+ perp assets. Max leverage depends on the asset and ranges from 3x to 40x. |
| Spot markets | Markets where users buy and sell the actual asset. | HyperCore includes fully onchain spot order books. Spot balances and holds are managed by the spot clearinghouse. |
| CLOB order book system | The central limit order book model where buy and sell orders are stored and matched based on price-time priority. | Each asset has an onchain order book. Orders follow tick size and lot size rules and are matched by price-time priority, similar to centralized exchanges. |
| Clearinghouse | The system that tracks user balances, positions, collateral, margin usage and liquidation risk. | The perps clearinghouse manages margin state per address, including balances and positions. Deposits go to cross margin by default, while isolated margin is also supported. |
| Oracle prices | Reference prices used by the protocol for margin, funding, liquidations and other risk calculations. | Validators publish oracle prices every 3 seconds. These prices are used for funding and as part of the mark price used for margining, liquidations and TP/SL triggers. |
| Funding | Periodic payments between long and short traders that help keep perpetual prices close to the underlying market price. | Funding is peer-to-peer and paid every hour. If the perp trades above the oracle price, longs pay shorts; if it trades below, shorts pay longs. |
| Liquidations | The process of closing positions when users no longer have enough margin to support them. | Liquidations happen when account equity falls below maintenance margin. Maintenance margin is half of the initial margin at max leverage, ranging from 1.25% for 40x assets to 16.7% for 3x assets. Hyperliquid first tries to close the position through market orders on the order book. If the account falls below 2/3 of the maintenance margin and the position cannot be closed through the book, a backstop liquidation happens through the liquidator vault. Liquidations use the mark price, not just the instantaneous book price. |
| Margin tiers | Position-size-based rules that define max leverage and maintenance margin requirements. | Larger positions have lower max leverage and higher maintenance margin requirements. For example, on mainnet BTC has 40x max leverage up to 150M USDC notional, but only 20x above 150M USDC. |
| Vaults | Pooled capital structures where users deposit funds into trading, liquidity or market-making strategies. | Vaults can be built with custom accounting and can access HyperCore features. |
| Staking | Native staking/delegation mechanism connected to HYPE and validator participation. | Users transfer HYPE from spot to a staking account and delegate it to validators. Validators need 10k self-delegated HYPE to become active, produce blocks, and receive rewards proportional to delegated stake. Delegations have a 1-day lockup, while moving HYPE back from staking to spot has a 7-day unstaking queue. Rewards accrue every minute, are distributed daily, and are automatically redelegated. |
| Multi-sig | Native account-control feature where multiple signatures are required to approve actions. | Supports multi-sig as a native primitive, not as a smart contract wallet. A user can be converted into a multi-sig user by defining authorized users and a signature threshold. After conversion, all actions must be sent as MultiSig actions containing signatures from enough authorized users. One authorized user acts as the transaction leader and submits the final action. A multi-sig account can have up to 10 authorized users. Important limitation: converting a user to multi-sig does not make the HyperEVM side controlled by the multi-sig. |
4. HyperEVM
The main value of HyperEVM is that builders can deploy EVM applications while connecting to HyperCore liquidity instead of building liquidity from zero.
| Feature | Description |
|---|---|
| EVM compatibility | Builders can deploy EVM-compatible contracts and applications using familiar Ethereum tooling. |
| Same L1 as HyperCore | HyperEVM and HyperCore share the same L1, reducing the need for external bridging between them. |
| HyperCore liquidity access | HyperEVM apps can interact with parts of HyperCore, including spot and perp order books. |
| Native token integration | A token can exist as an ERC-20-style contract on HyperEVM and be linked to a HyperCore spot asset. |
| Builder tooling | The ecosystem includes RPCs, explorers, indexers, oracles, account abstraction tools, cross-chain messaging and Safe-style multi-sig tooling. |
| Current stage | HyperEVM is still in alpha, with gradual rollout. Higher throughput and write system contracts are not fully live on mainnet yet. |
| Read precompiles | Smart contracts can read HyperCore state, such as positions, balances, vault data, staking delegations and oracle prices. |
| CoreWriter | A HyperEVM system contract that allows smart contracts to send write actions to HyperCore. |
5. Key Protocol-Level Features
5.1 Vaults
Vaults on Hyperliquid are pools of capital that can be used by a trader, market maker, automated strategy, or the protocol itself.
Users deposit funds into a vault and get exposure to the vault’s performance. The return is not fixed; it depends on the vault’s real PnL. If the vault makes money, depositors share the profit proportionally. If the vault loses money, depositors also share the loss.
For example, if a vault has 900 USDC and a user deposits 100 USDC, the vault now has 1,000 USDC and that user owns 10% of the vault. If the vault later grows to 2,000 USDC, the user’s 10% share is worth 200 USDC before any fees or profit share.
What makes Hyperliquid vaults important is that they can become active participants in HyperCore. Through HyperEVM, builders can create tokenized vaults with custom accounting, while using CoreWriter and precompiles to interact with HyperCore.
This means a vault can do more than hold capital. It can trade, provide liquidity, access spot markets, support HIP-3 markets, delegate actions to agents, or participate in liquidation strategies.
The main protocol vault is HLP, the Hyperliquidity Provider vault. HLP provides liquidity through market-making strategies, performs liquidations, supplies USDC in Earn, and receives part of trading fees. Users can deposit into HLP and share in its PnL. HLP has a 4-day withdrawal lockup.
5.2 Staking and Validator Governance
Staking on Hyperliquid happens inside HyperCore. HYPE can be moved from a user’s spot account to a staking account, where it can then be delegated to one or more validators.
Hyperliquid only supports delegated proof of stake, meaning users do not validate blocks directly. Instead, they delegate HYPE to validators. Active validators produce blocks and receive rewards proportional to the total stake delegated to them.
To become active, a validator needs 10k self-delegated HYPE, and this self-delegation is locked for one year. If the validator drops below 10k self-delegated HYPE, it enters undelegate-only mode, meaning it cannot receive new delegations.
Delegations to a validator have a 1-day lockup. Moving HYPE back from the staking account to the spot account has a 7-day unstaking queue.
Rewards accrue every minute, are distributed daily, and are automatically redelegated to the same validator, meaning rewards compound.
Governance relevance
HYPE holders do not vote directly on every protocol decision like in a traditional DAO. Instead, they delegate HYPE to validators, and validators participate in consensus, jailing and some protocol-level enforcement through stake-weighted voting.
This means staking is not only about earning rewards. It also influences who has power in the validator set and who participates in operational governance.
5.3 Multi-sig
Hyperliquid supports multi-sig as a native HyperCore primitive, instead of relying only on smart contract wallets.
A normal user can be converted into a multi-sig user by defining a list of authorized users and a signature threshold. After that, actions must be submitted as MultiSig actions and signed by enough authorized users.
One authorized user acts as the transaction leader, collects the required signatures and submits the final action.
The key limitation is that HyperCore multi-sig does not fully control the HyperEVM side. Converting a user to multi-sig does not make the HyperEVM account controlled by the multi-sig, and CoreWriter does not work for multi-sig users.
6. KYC
Hyperliquid does not require KYC for normal trading. However, access can still be restricted through the frontend based on jurisdiction.
Restrictions can be applied through IP checks before wallet connection and through the connected wallet address after connection.
This means some features may be disabled or hidden.
7. Strategic Takeaways
| Area | Hyperliquid | What we can do differently |
|---|---|---|
| Governance | Governance is mostly validator and stake-weighted, focused on consensus, validator jailing and protocol-level enforcement rather than a classic token-holder DAO model. | Follow a more traditional DAO-style governance model, where token holders can vote directly on protocol decisions. |
| KYC | Hyperliquid does not require normal KYC for trading, but frontend access can still be restricted based on jurisdiction and/or IP checks. | Offer optional KYC for institutions or users who need more regulatory clarity and trust. |
| Matching-orders |
References
- Hyperliquid Docs: https://hyperliquid.gitbook.io/hyperliquid-docs