Hyperliquid Security: Beyond Orderbooks and Into Architecture

Hyperliquid has rapidly emerged as the dominant on-chain perpetual futures exchange, processing over $5 billion in daily volume with sub-second finality. For security auditors and protocol teams building on this infrastructure, the architecture introduces a fundamentally different threat model than what Ethereum native DeFi demands. This post dissects the security implications of Hyperliquid's dual-engine design, from consensus assumptions down to smart contract-level pitfalls, and provides an actionable audit framework for teams deploying on HyperEVM.
 

HyperBFT Consensus: What Changes From Ethereum's PoS

Hyperliquid's consensus layer, HyperBFT, derives from the HotStuff family of BFT protocols. While superficially similar to Ethereum's Gasper, the security guarantees diverge in critical ways that directly affect protocol design.

HyperBFT operates under a classical BFT assumption, the network tolerates up to f Byzantine validators out of 3f+1 total. Block finality is deterministic and immediate, once a block is finalized, it cannot be reverted. There are no probabilistic confirmation windows, no reorg risk, and no need for confirmation counting logic in your contracts. This is a genuine security advantage, entire classes of reorg based attacks (sandwich attacks exploiting block reordering, time-bandit attacks, uncle-block manipulation) simply do not exist on Hyperliquid.

However, this comes with a critical tradeoff. The validator set is significantly smaller than Ethereum's, and the chain's consensus liveness depends on more than two-thirds of staking power remaining honest and online. A compromise of enough validator keys or coordinated censorship by a majority coalition could halt the chain or manipulate state.

For protocol builders, the practical implication is straightforward, you do not need reorg protection logic, but you do need to account for potential chain halts and validator-level censorship in your protocol's failure modes. A lending protocol on HyperEVM should consider what happens to undercollateralized positions if the chain goes down for two hours during a volatile market. Unlike Ethereum, where this is a near-theoretical concern, Hyperliquid has experienced bridge freezes and downtime events in production.

Security Boundary Between HyperCore and HyperEVM

The single most important architectural concept for security on Hyperliquid is the separation between HyperCore and HyperEVM. These are not two chains. They share one consensus and one block sequence, but they maintain completely independent state and execute under different models.

HyperCore is a purpose built Rust execution engine that handles all trading logic, order matching, margin computation, liquidations, and oracle price aggregation. It is not a smart contract environment. There is no EVM, no Solidity, and no permissionless code execution. Every state transition is deterministic and hard-coded into the node software.
 

HyperEVM is a permissionless Cancun fork EVM (without blob support) that runs alongside HyperCore under the same HyperBFT consensus. Developers deploy Solidity contracts here. EIP-1559 is enabled, and both base fees and priority fees are burned.
 

The critical security insight is this, smart contract bugs on HyperEVM cannot break HyperCore's trading engine. A reentrancy vulnerability in a lending protocol on HyperEVM will not affect the order books, liquidation logic, or margin system. This isolation is an intentional design choice, it prevents gas contention between trading operations and arbitrary contract execution, and it creates a hard security boundary between financial primitives and user-deployed logic.

However, the interaction between these two domains introduces a novel attack surface. The communication is unidirectional and asynchronous:

• HyperCore → HyperEVM (Read): Smart contracts call precompile addresses (starting at 0x0000...0800) to read HyperCore state, positions, balances, oracle prices. These return a consistent snapshot of the latest HyperCore state at the time the EVM block is constructed.
   
• HyperEVM → HyperCore (Write): Smart contracts call the CoreWriter system contract at 0x3333...3333, which emits an event. HyperCore processes this event as an action (place order, transfer funds) in the next block cycle.

1// Writing to HyperCore from HyperEVM via CoreWriter
2contract MyVault {
3    address constant CORE_WRITER = 0x3333333333333333333333333333333333333333;
4
5    function placeOrder(bytes memory encodedAction) external {
6        // This emits a log; HyperCore processes it in the NEXT block cycle.
7        // The action is NOT atomic with this EVM transaction.
8        // If the action fails on HyperCore (e.g., insufficient margin),
9        // the EVM transaction still succeeds — no revert.
10        CoreWriter(CORE_WRITER).sendRawAction(encodedAction);
11    }
12}
13
14// CRITICAL: CoreWriter actions are delayed by several seconds on-chain
15// to prevent latency advantages over the L1 mempool.

Non-Atomicity

If you are porting a protocol from Ethereum to HyperEVM, this is the section that will save you from a critical vulnerability.

On Ethereum, a single transaction can atomically read state, perform computation, call external contracts, and revert everything if any step fails. This atomicity is the foundation of flash loans, atomic arbitrage, and composable DeFi. On Hyperliquid, cross-engine operations are fundamentally non-atomic.

When a HyperEVM contract calls CoreWriter to place an order on HyperCore, the EVM transaction completes and is finalized. The CoreWriter action is then queued and executed in a subsequent HyperCore block. If that action fails because the user has insufficient margin on HyperCore, or the order cannot be filled, or the asset has been delisted, the original HyperEVM transaction does not revert. Your contract has already committed its state changes.

This creates a class of vulnerabilities that does not exist on Ethereum:

Scenario: A vault contract on HyperEVM accepts a user deposit (updating EVM state), then calls CoreWriter to open a hedging position on HyperCore. The CoreWriter action fails silently. The vault now holds user funds but has no hedge, exposing depositors to unhedged risk.

Implement a two-phase commit with verification. Accept deposits into a pending state, issue the CoreWriter action, and only finalize the deposit after a subsequent transaction verifies (via precompile read) that the HyperCore action succeeded.

1// Two-phase commit pattern for cross-engine safety
2contract SafeVault {
3    mapping(address => uint256) public pendingDeposits;
4    mapping(address => uint256) public confirmedDeposits;
5
6    // Phase 1: Accept deposit, mark as pending
7    function deposit(uint256 amount) external {
8        IERC20(usdc).transferFrom(msg.sender, address(this), amount);
9        pendingDeposits[msg.sender] += amount;
10        // Issue CoreWriter action to open hedge
11        _sendHedgeAction(amount);
12    }
13
14    // Phase 2: Called in a subsequent block after CoreWriter executes
15    function confirmDeposit(address user) external {
16        // Read HyperCore state via precompile to verify hedge exists
17        (int64 size,,) = IL1Read(PRECOMPILE).getPosition(
18            address(this), ETH_PERP_ID
19        );
20        require(size != 0, "Hedge not confirmed on HyperCore");
21
22        uint256 pending = pendingDeposits[user];
23        pendingDeposits[user] = 0;
24        confirmedDeposits[user] += pending;
25    }
26
27    // Escape hatch: if hedge never confirms, user can reclaim
28    function reclaimPending() external {
29        uint256 pending = pendingDeposits[msg.sender];
30        require(pending > 0, "Nothing pending");
31        pendingDeposits[msg.sender] = 0;
32        IERC20(usdc).transfer(msg.sender, pending);
33    }
34}

Oracle Design: Validator-Maintained Feeds and Manipulation Resistance

Hyperliquid's oracle system is structurally different from Ethereum's Chainlink-based model. Validators are directly responsible for publishing spot oracle prices every 3 seconds. The oracle price for each perpetual asset is computed as a weighted median of prices.

This design eliminates the multi-hop dependency chain of Chainlink (data providers → Chainlink nodes → on-chain aggregator → consumer contracts) but concentrates oracle trust in the validator set. The security implications are significant:

What you gain: Oracle prices are native to the L1. HyperEVM contracts can read them through precompiles with no external dependency, no stale-price risk from on-chain update lag, and no gas-war competition to front-run oracle updates. For lending protocols, this means you can query a live order-book-derived price instead of relying on a Chainlink heartbeat that may be minutes old.

What you lose: The oracle is only as trustworthy as the validator set. A compromised  oracle_updater address which security researchers have identified as a single privileged key with no timelock or multi-sig requirement, could set arbitrary prices across all markets, triggering instantaneous cascading liquidations. The JELLY incident of March 2025 demonstrated this in practice: an attacker manipulated external spot markets to distort the oracle feed, forcing the protocol's backstop vault (HLP) to absorb $12 million in unrealized losses. Hyperliquid's response, manually overriding the oracle and delisting the market via validator vote, underscored the centralized intervention capabilities that exist beneath the decentralized surface.

For HyperEVM builders, the audit checkpoint is clear, if your protocol depends on HyperCore oracle prices via precompiles, you must design for the scenario where those prices are transiently incorrect. Implement circuit breakers that pause operations when price moves exceed reasonable thresholds, and never assume the oracle is manipulation proof simply because it is validator maintained.
 

Liquidation Engine and Cascading Failure Modes

Hyperliquid's liquidation architecture is deeply integrated into HyperCore and follows a multi-tier waterfall that differs from AMM-based liquidation patterns familiar on Ethereum.

When a position's account equity falls below maintenance margin, the clearinghouse initiates liquidation by sending market orders to the order book, not by calling a public  liquidate()  function on a smart contract, as in Aave or Compound. For large positions (above $100K USDC notional), only 20% is liquidated initially, with a 30-second cooldown before subsequent tranches. This staged approach prevents order book disruption but introduces a window where partially-liquidated positions remain at risk.

If market liquidation orders cannot fill, due to insufficient book depth or extreme volatility, the position falls to the backstop liquidator vault (HLP), which absorbs the position and its collateral. If even HLP cannot cover the losses, Auto-Deleveraging (ADL) activates, profitable positions on the opposing side are forcibly closed at the oracle price to prevent bad debt.

The cascading failure mode that HyperEVM builders must understand operates as follows: thin liquidity on a HyperCore perp market → large position liquidation overwhelms the book → HLP absorbs a losing position → HLP drawdown reduces the backstop for all markets → a second liquidation on a different market finds insufficient backstop → ADL triggers, forcibly closing positions of users who have no direct exposure to the original market.

For protocols building vaults or yield strategies on HyperEVM that interact with HyperCore positions, the critical design question is: what happens to your vault's HyperCore positions during an ADL event? If your vault holds a profitable short that gets ADL'd, the position is closed at oracle price without your contract's consent. Your vault's accounting must handle this gracefully, the position will simply vanish from HyperCore state between one block and the next.

Cross-Margin Vault Security: Isolated vs. Shared Collateral Risks

Hyperliquid supports three margin modes, cross, isolated, and portfolio margin, each with distinct security profiles for vault builders.

Cross margin shares collateral across all open perpetual positions. This is capital-efficient but creates contagion risk: a loss in one position erodes margin for all others, potentially triggering a cascade of liquidations across unrelated markets. The March 2025 ETH margin exploit demonstrated this precisely, a trader opened a $200M position at 50x leverage, withdrew margin to push the position toward liquidation, and profited $1.8M while HLP absorbed $4M in losses. This was not a code bug, it was a mechanism edge case in cross-margin accounting that allowed unrealized PnL to be withdrawn and weaponized.

Isolated margin constrains risk to a single position. Liquidation of an isolated position does not touch cross-margin collateral or other isolated positions. For vault protocols, isolated margin is the safer default for speculative positions, but it comes with strict constraints: some assets are designated strict isolated, meaning margin cannot be removed once added.

Portfolio margin (the newest addition) unifies spot balances and perp positions into a single margining account, enabling capital-efficient strategies like the carry trade. However, this introduces borrow-lend mechanics into the margin system, with interest rate models and liquidation thresholds that create new surfaces for economic attacks.

For HyperEVM vault builders, the key audit question is: does your vault use cross-margin on HyperCore, and if so, have you modeled the impact of an adversarial liquidation cascade on your depositors funds? A vault that holds multiple cross-margin positions is exposed to correlated liquidation risk in ways that are non-obvious from the EVM contract alone the risk lives in HyperCore state that your contract can only observe, not control.
 

HyperEVM vs. Standard EVM

While HyperEVM is Cancun compatible, several behavioral differences require auditor attention:

Block timing is non-uniform. Small EVM blocks execute every ~1 second with a 2M gas limit. Large EVM blocks execute every ~1 minute with 30M gas limit. Developers must explicitly toggle between block types. A contract deployment that exceeds 2M gas will fail on small blocks. Time-dependent logic (e.g., block.timestamp for interest accrual) must account for this irregular cadence.

No reorg handling needed. block.number increases monotonically and finality is instant. If your Ethereum contract includes confirmation-counting logic or reorg-recovery code, it is dead weight on HyperEVM, but leaving it in is not a vulnerability, just technical debt.

msg.sender behaves differently for cross-engine calls. When a user initiates a transaction on HyperCore that indirectly triggers HyperEVM execution via system contracts, msg.sender in the EVM contract will be the system contract address, not the user's address. Contracts that rely on msg.sender for access control or accounting must handle this case explicitly.

Priority fees are burned, not paid to validators. This eliminates the MEV extraction incentive that drives much of Ethereum's block-builder economy, but Hyperliquid's transaction ordering within HyperCore still creates MEV-like opportunities through the deterministic ordering of actions (non-order actions → cancellations → new orders).
 

Hyperliquid's Official Risk Taxonomy

Hyperliquid's own documentation enumerates five risk categories, and every builder should internalize them as baseline assumptions rather than edge cases.

Smart contract risk, the official docs state explicitly that the platform depends on the correctness of Arbitrum bridge smart contracts, and bugs could result in loss of user funds. This is not a theoretical hedge. The bridge contract at  0x2Df1c51E09aECF9cacB7bc98cB1742757f163dF7 on Arbitrum has custodied billions of USDC at peak, representing one of the highest-value smart contract targets in DeFi.

L1 risk - Hyperliquid acknowledges its own chain has not undergone testing comparable to Ethereum. The network may experience downtime from consensus failures. This was demonstrated in production during the November 2025 POPCAT incident, when all Arbitrum deposits and withdrawals were frozen for approximately two hours during what was labeled as maintenance.

Market liquidity risk, low liquidity on newer or less-traded assets creates slippage risk. This is particularly dangerous in the context of HyperCore's liquidation engine, because thin books mean market liquidation orders can cascade through price levels, amplifying losses.

Oracle manipulation risk, validators maintain oracle prices, and a compromised or manipulated oracle feed can trigger incorrect liquidations. The docs are clear that this is a known, unmitigated risk for extended manipulation periods.

Risk mitigation measures, Hyperliquid implements open interest caps based on liquidity, basis, and leverage. When an asset hits its OI cap, no new positions can be opened, and resting orders cannot be placed more than 1% from the oracle price. Crucially, HLP is exempt from these restrictions to continue quoting liquidity. This exemption means the backstop vault operates under looser constraints than regular participants, a design choice that trades systemic protection for liquidity continuity, but one that also means HLP can be exposed to scenarios that regular users are shielded from.

What the official risk page does not address is equally important: it does not discuss the closed-source nature of the L1 node software, the centralized oracle update key architecture, the lack of escape hatches in bridge withdrawals, or the governance opacity that independent researchers have documented through binary reverse-engineering.
 

Bridge Security Deep-Dive: The Arbitrum Trust Boundary

Every dollar on Hyperliquid enters through a bridge, and until the full migration to native USDC via Circle's CCTP is complete, the Arbitrum bridge remains the primary custodial boundary.

The bridge architecture uses a layered validator model. Hot validators (4 addresses in the current configuration) sign withdrawal requests using online keys. Cold validators (also 4 addresses, controlled by the Hyperliquid foundation) handle administrative operations, updating validator sets, changing bridge configuration, and invalidating problematic withdrawals. A separate group of lockers (5 addresses) can pause the bridge in emergencies.

The withdrawal flow works as follows: a user signs an EIP-712 typed message on Hyperliquid requesting a withdrawal. Validators sign the withdrawal as a separate transaction. Once 2/3 of staking power has signed, an EVM transaction is submitted to the bridge contract on Arbitrum. A dispute period follows, during which the bridge can be locked if the withdrawal is deemed malicious. After the dispute period, finalization transactions distribute USDC to the destination address.

The security concerns are significant. The dispute period is approximately 200 seconds compared to roughly one week for Arbitrum and Optimism's dispute windows. Independent analysis has characterized the bridge as effectively a 3-of-4 multisig with additional steps, where the same team controls both hot and cold validator sets. The dispute process is not open to the public, only validators can raise disputes. There is no documented escape hatch or forced-withdrawal mechanism that allows users to unilaterally exit if validators become unresponsive or adversarial.

The bridge contract is upgradeable via proxy, with admin-only upgrade rights. The closed-source Hyperliquid chain's validator set is not necessarily linked to the validator set recognized by the bridge contract on Arbitrum, creating a potential divergence between on-chain governance and bridge security.

For HyperEVM protocol builders, the practical recommendation is, treat bridged assets as carrying custodial risk proportional to the bridge's trust model. Do not assume Ethereum-equivalent custody guarantees. If your protocol holds user funds that depend on bridge withdrawals for exit, implement emergency withdrawal mechanisms that can function even during bridge freezes, for example, allowing users to withdraw to HyperEVM-native assets that do not require the Arbitrum bridge.
 

HIP-3 Builder Security

HIP-3 introduced a framework for third-party builders to launch their own perpetual contract DEXs on Hyperliquid's infrastructure. Builders stake 500,000 HYPE tokens, gain access to HyperCore's matching and clearing engine, and take responsibility for defining market parameters including oracle sources, leverage tables, and margin modes. Since launch, HIP-3 markets have exceeded $5 billion in cumulative volume.

This decentralized listing model transfers substantial operational and security risk from the protocol to individual builders:

Oracle responsibility, builders designate an oracleUpdater address that feeds prices to their markets. This is a single key with the power to set mark prices used for margin calculations and liquidation triggers. A compromised builder oracle can trigger cascading liquidations across all positions in that market. The oracle update function can be called every 2.5 seconds with no on-chain deviation limits or multi-sig requirement.

Parameter misconfiguration, builders set margin tables (marginTiers  with lowerBound  and maxLeverage), funding multipliers, interest rates, and OI caps. Incorrect parameters can create exploitable conditions, excessively high leverage on illiquid assets, or margin tables that allow positions to grow beyond the market's ability to liquidate them safely.

Emergency powers, builders can invoke haltTrading to pause their markets. While intended as a safety mechanism, a malicious or compromised builder could halt trading at a strategically chosen moment to lock in attacker profits or create bad debt.

Validator slashing, builders staked HYPE can be slashed by validator vote if their actions cause market failures or performance issues. This is the accountability mechanism, but it is reactive rather than preventive, and the slashing criteria are not codified in deterministic on-chain logic.

1// HIP-3 Builder Oracle Update — single key, no deviation limits
2// type SetOracle action from the HIP-3 deployer API:
3//
4// {
5//   "markPxs": [[price1], [price2]],  // outer list can be 0, 1, or 2 prices
6//   "asset": "MYTOKEN"
7// }
8//
9// SECURITY IMPLICATIONS:
10// - markPxs median is taken with the local mark price
11// - Builder can supply 0 external prices, relying entirely on local book
12// - Minimum 2.5s between SetOracle calls - no faster rate limiting
13// - No on-chain deviation bounds from previous price
14// - Stale mark prices (no update for 60s) trigger automatic trading halt
15//
16// RECOMMENDATION: Builders should implement off-chain monitoring that:
17// 1. Alerts on oracle price deviations > 5% from reference sources
18// 2. Auto-halts the market if the oracleUpdater key shows signs of compromise
19// 3. Uses a separate monitoring key that can trigger haltTrading independently

For teams auditing HIP-3 builder deployments, the key concern is that the builder effectively operates as a semi-trusted market operator. The staking requirement provides economic disincentive against malicious behavior, but the technical controls (single oracle key, configurable parameters, halt power) create a trust surface that more closely resembles a centralized exchange operator than a permissionless DeFi protocol.
 

Recommendations for Protocol Teams Building on HyperEVM

Based on the complete threat model analyzed in this post, here are concrete recommendations for teams deploying protocols on Hyperliquid:

Design for chain halts. Implement grace periods in time-sensitive operations (interest accrual, liquidation triggers, auction deadlines). If your protocol penalizes users for inaction during a specific time window, those penalties must pause if block production stops. Ethereum protocols rarely need this, Hyperliquid protocols always do.

Never assume cross-engine atomicity. Every interaction between HyperEVM and HyperCore via CoreWriter must be treated as an eventually-consistent, possibly-failing operation. Use two-phase commits with verification reads. Build escape hatches for stuck pending states.

Diversify oracle sources even when precompiles are available. HyperCore's precompile oracle data is convenient but concentrated in the validator set. For high-value lending or options protocols, consider supplementing precompile reads with independent price verification from on-chain TWAP calculations on HyperEVM DEXs or cross-chain oracle feeds via LayerZero.

Model ADL impact on vault accounting. If your protocol holds HyperCore perp positions, write explicit test cases for the scenario where a position disappears between blocks due to Auto-Deleveraging. Your vault's share price calculation and withdrawal logic must handle this without breaking invariants.

Implement circuit breakers for oracle deviation. Define a maximum acceptable price change per block for each asset your protocol depends on. If a precompile read returns a price that deviates beyond this threshold from the last known good price, pause protocol operations and emit an alert. This is your primary defense against oracle manipulation.

Treat the bridge as a dependency, not infrastructure. The Arbitrum bridge is not equivalent to Ethereum L1 settlement. It has a 200-second dispute period, team-controlled validators, and no public dispute mechanism. Design withdrawal flows that can function through alternative exit paths (native USDC via CCTP, HyperEVM-native assets) if the primary bridge is frozen.

Audit HIP-3 builder parameters if integrating with third-party markets. If your protocol reads prices or interacts with positions on HIP-3-deployed markets, verify the builder's oracle configuration, margin tables, and OI caps. A builder's misconfigured market can propagate risk into your protocol through shared collateral or price feeds.

Plan for the closed-source reality. Hyperliquid's L1 is not open source. You cannot independently verify the node software's behavior. Design your protocol's security model to be resilient even if the L1 behaves differently from documentation for example, by not relying on undocumented timing guarantees or assuming transaction ordering is perfectly fair.
 

Conclusion

Building on Hyperliquid is not inherently more or less secure than building on Ethereum, it is differently secure. The deterministic finality eliminates reorg risk. The HyperCore isolation protects the trading engine from smart contract bugs. The native oracle precompiles remove Chainlink dependency.

But the non-atomic cross-engine communication, the validator concentrated oracle trust, the smaller validator set, and the novel margin-liquidation cascade dynamics introduce threat vectors that Ethereum auditors will not find in their standard playbooks. Teams building on HyperEVM must internalize these differences at the architecture level, not treat them as footnotes in an otherwise Ethereum-identical deployment.

The protocols that will survive on Hyperliquid are the ones that audit for the chain they are actually on not the chain they wished they were on.