Hyperliquid Wiki Protocol & Ecosystem Knowledge Base
🔍

Technical Glossary & Frequently Asked Questions

An exhaustive encyclopedic reference of decentralized finance terminology, Hyperliquid layer-1 protocol specifications, consensus mechanics, and compliance disclosures.

📚 Reference Encyclopedia ⚖️ Compliance & Disclaimers 🔍 White-Hat Standards

Protocol & Architectural Glossary

This technical glossary compiles definitions and mathematical primitives used across the Hyperliquid Layer-1 ecosystem, documentation, and client libraries.

Term / Acronym Full Name Definition & Technical Functionality
HyperBFT Hyper Byzantine Fault Tolerance Custom consensus algorithm written in Rust. Features single-round pipelining and linear message complexity $O(N)$ with optimistic sub-second finality (~200ms).
HyperEVM Hyperliquid Ethereum Virtual Machine Integrated EVM runtime embedded directly within the HyperBFT L1 state transition model, granting smart contracts atomic access to native order books via precompiles (HyperEVM specs ↗).
CLOB Central Limit Order Book Continuous on-chain matching engine where bids and asks are ordered by price and time priority (FIFO) directly inside validator state.
HLP Hyper Liquidity Provider Automated community market-making vault that acts as a decentralized counterpart to market participants, collecting spread and funding rate yield.
HIP-1 Hyperliquid Improvement Proposal 1 Standard for native fungible token issuance and transfers on the Hyperliquid L1 without requiring EVM contract deployments.
HIP-2 Hyperliquid Improvement Proposal 2 Permissionless liquidity bootstrapping mechanism that creates native spot order books paired with continuous Dutch auction bonding curves.
Mark Price Fair Market Value Oracle A smoothed, tamper-resistant price metric computed from median CEX spot prices plus an exponential moving average (EMA) of basis, protecting against manipulation.
ADL Auto-Deleveraging Fail-safe liquidation resolution mechanism that automatically closes profitable opposing positions if an underwater position cannot be cleared by market makers.
EIP-712 Structured Typed Data Hashing Ethereum standard for signing human-readable typed data off-chain (EIP-712 standard specification ↗), utilized by Hyperliquid for gasless state transitions.
Agent Wallet Delegated Session Key An ephemeral secondary Ethereum keypair authorized by a master cold wallet to sign trading actions without custody over asset deposits or withdrawals.
Builder Fee Protocol Referral & Fee Sharing On-chain attribution system allowing independent interface developers, trading bots, and analytic dashboards to earn customizable fee cuts with user approval.

Architecture & Core FAQ

💡
Architecture Highlights: Hyperliquid is not an Ethereum Rollup or an Appchain sidechain; it is an independent, sovereign Layer-1 Proof-of-Stake blockchain secured by dedicated hardware validators running native Rust binaries.

Is Hyperliquid a Layer-2 rollup or a standalone Layer-1?

Hyperliquid is an independent Layer-1 blockchain built from the ground up in Rust. It does not rely on Tendermint, Cosmos SDK, or OP Stack rollups. It executes its own consensus (HyperBFT) across globally distributed validator nodes, achieving 200,000+ orders per second throughput.

Why are order placements and cancellations gas-free?

On traditional general-purpose blockchains, every signature validation requires gas fees. On Hyperliquid, non-execution order lifecycle events (place, modify, cancel) are processed as specialized L1 state transitions optimized in C++/Rust. Instead of gas fees, the protocol employs deterministic rate limits based on account balance and past trading volume to prevent spam.

How does the native Arbitrum bridge work?

The native deposit bridge utilizes a multi-signature smart contract deployed on Arbitrum One. When a user deposits USDC, the Arbitrum contract locks the funds, and validator nodes observe the deposit log events. Once a 2/3 validator consensus threshold is reached, equivalent USDC is minted on the L1 state tree. Withdrawals require aggregated BLS/ECDSA validator signatures verified on Arbitrum.

What is the difference between Cross Margin and Isolated Margin?

Cross Margin: All available account balance across all perpetual positions is pooled together to maintain margin requirements. A profit in one position can offset an unrealized loss in another, maximizing capital efficiency.
Isolated Margin: A fixed, dedicated balance is assigned to an individual position. If the maintenance margin is breached, only the allocated balance is liquidated, preserving the remaining account equity.

What are the hardware requirements for operating a validator node?

Due to the high-throughput memory-mapped state design of HyperBFT, validator nodes require high-performance dedicated bare-metal hardware: minimum 32 physical CPU cores (validator hardware guidelines ↗), 128 GB ECC RAM, redundant NVMe PCIe 4.0 storage with >7,000 MB/s IOPS, and minimum 1 Gbps unmetered network connectivity.

Legal Disclaimers & White-Hat Compliance Directives

⚖️
Mandatory Compliance Notice: This documentation portal is an open-source, community-maintained educational resource. It is not an advertisement, prospectus, financial offering, or solicitation of any kind.

1. Nature of Documentation & Informational Purpose

All information, technical analyses, code snippets, architectural flowcharts, and mathematical formulas contained within this Wiki portal are published strictly for educational, analytical, and archival purposes. No part of this publication constitutes financial advice, investment advice, trading recommendations, or endorsements of any specific digital asset, protocol, or algorithmic strategy.

2. Independent Open-Source Community Resource

This Wiki is compiled and maintained by independent open-source software developers and DeFi researchers. This portal is not operated, owned, funded, or formally affiliated with Hyperliquid Foundation or its developers. All product names, trademarks, and registered trademarks mentioned are the property of their respective owners.

3. Inherent Risks of Cryptographic Protocols & Smart Contracts

Participating in decentralized financial protocols, blockchain networks, perpetual derivatives, and automated liquidity vaults entails significant financial, technical, and cryptographic risks. These include, but are not limited to:

  • Software & Smart Contract Vulnerabilities: Risk of undiscovered software bugs, consensus partitions, or cryptographic edge cases.
  • Market Volatility & Liquidation Risk: Leveraged derivative contracts carry the risk of total loss of collateral in adverse market conditions.
  • Oracle & Network Latency Risks: Potential discrepancies between external price feeds, network delays, or cross-chain bridge validation latency.
  • Regulatory Uncertainty: Evolving legal frameworks in various jurisdictions governing digital assets and decentralized networks.

4. User Responsibility & Jurisdictional Restrictions

Users are solely responsible for ensuring compliance with all local laws, taxation rules, and regulations applicable in their jurisdiction before interacting with any decentralized network or cryptographic software tool. This portal does not offer financial accounts, custodian services, asset custody, fiat gateways, or brokerage execution.

🔗 Official External References & Primary Sources

To verify the facts, technical formulas, and architectural parameters presented in this article, consult the following primary sources and official documentation: