Author: Shew, Xianrang GodRealmX

Recently, Hyperliquid has garnered significant market attention as one of the most influential on-chain order book exchanges, with a TVL exceeding $2 billion. It has been described by Messari as the "on-chain Binance," and has even brought the previously fading narratives of Layer 3 and application chains back into the spotlight. With a remarkable achievement of raising its FDV to $30 billion within a month of its token launch, Hyperliquid has attracted widespread attention from both ordinary users and industry professionals. Meanwhile, a plethora of research reports on Hyperliquid have emerged in the market, but these articles primarily focus on its order book product features and trading mechanisms, without delving into the underlying technical structure and security risks.

The author of this article aims to fill this gap by examining Hyperliquid purely from the perspectives of technical structure and security, helping more people understand the structure and principles of this star project. We will elaborate on two main aspects: the construction and risks of Hyperliquid's cross-chain bridge contract, and the dual-chain structure of HyperEVM and HyperL1, to help everyone gain a deeper understanding of its underlying technical architecture and implementation methods.

(Currently, Hyperliquid occupies 67% of the total USDC supply on Arbitrum)

HyperLiquid Cross-Chain Bridge Analysis

Since HyperLiquid has not open-sourced its core components but has open-sourced related bridge contracts, we have a better understanding of the risks associated with the bridge contracts. Hyperliquid has deployed a bridge contract on Arbitrum to store the USDC assets deposited by users, and we can observe some behaviors of Hyperliquid nodes within the Bridge component.

Validator Set

From the perspective of node identity classification, Hyperliquid has four groups of validators: hotValidatorSet, coldValidatorSet, finalizers, and lockers, each corresponding to different functions. The hotValidatorSet is used to respond to user withdrawal operations and other high-frequency actions, typically using hot wallets to promptly respond to Hyperliquid users' withdrawal requests.

The coldValidatorSet is primarily used to modify system configurations, such as rewriting the list of hotValidatorSet or lockers validators, or handling the locking status of the bridge contract. Additionally, the coldValidatorSet has the authority to directly invalidate certain withdrawal requests.

Lockers are a group of validators with special permissions, similar to the "security council" commonly used in Layer 2, who will vote to decide whether to pause the cross-chain bridge in certain emergency situations. Currently, the lockers set for the Hyperliquid bridge includes five addresses, and only two lockers need to vote to pause the bridge contract's operation.

The finalizers are also a special group of validators, primarily responsible for confirming the state changes of the cross-chain bridge. From the contract perspective, they mainly confirm user deposits and withdrawals. Hyperliquid's cross-chain bridge uses a "submit-confirm" mechanism; for example, when a user initiates a withdrawal, it is not executed immediately but requires a waiting period (referred to as the dispute period). After the dispute period ends, members of the finalizers execute the withdrawal transaction, and the withdrawal can then be processed normally.

If an issue arises with the cross-chain bridge, such as a withdrawal request claiming to withdraw assets greater than the user's actual asset balance, Hyperliquid nodes can use lockers to vote to pause the cross-chain bridge contract during the dispute period, or the coldValidatorSet can directly invalidate the problematic withdrawal request.

Currently, Hyperliquid has only four validator nodes, so the hotValidatorSet and coldValidatorSet correspond to only four on-chain addresses. During initialization, Hyperliquid automatically registers the addresses in the hotValidatorSet as members of the lockers and finalizers, while the coldValidatorSet is controlled by Hyperliquid itself, using cold wallets to store keys.

Deposits

Hyperliquid's bridge contract uses the Permit method based on EIP-2612 to handle user deposit operations, and only allows users to deposit USDC as an asset. The Permit method is simpler than the traditional Approve-Transfer model and facilitates batch operations.

Hyperliquid's bridge contract employs the batchedDepositWithPermit function to process multiple deposits in batches. The deposit action is relatively straightforward, with no security risks involved, and the processing flow is simple, merely utilizing the Permit method to optimize user experience.

Withdrawals

In contrast to deposits, withdrawals are a highly risky operation, so the withdrawal logic is much more complex than that of deposits. When a user initiates a withdrawal request, Hyperliquid nodes will call the batchedRequestWithdrawals function of the bridge contract. At this point, the bridge contract requires that each withdrawal request must gather 2/3 of the signature weight from the hotValidatorSet. It is important to note that many documents describe this as "gathering 2/3 of the signatures," but in reality, the bridge contract checks for "2/3 of the signature weight." Currently, HyperLiquid has only four nodes with equal weight, so checking signature weight and checking the number of signatures are temporarily consistent, but in the future, HyperLiquid may introduce nodes with higher weights.

When a withdrawal request is initiated, the cross-chain bridge does not immediately transfer the USDC controlled by the contract; instead, there is a "dispute period," similar to the "challenge period" in fraud proof protocols. Currently, the dispute period for the Hyperliquid bridge contract is 200 seconds, during which two scenarios may occur:

1. Lockers believe that the current withdrawal request has serious issues, and they can directly vote to pause/freeze the contract;
2. Nodes believe that certain withdrawal actions have issues, at which point members of the coldValidatorSet can call the invalidateWithdrawals function to invalidate that withdrawal.

If no issues arise during the dispute period, once the dispute period ends, members of the finalizers can call the batchedFinalizeWithdrawals function in the bridge contract to finalize the status, at which point the USDC will be sent to the user's wallet address on Arbitrum.

From the perspective of the security model, if a malicious attacker wants to manipulate the withdrawal process in Hyperliquid, they need to break through three lines of defense:

1. Gain control of 2/3 of the signature weight within the hotValidatorSet, meaning they need to obtain a certain number of private keys or conspire; currently, HyperLiquid has only four validators, making it relatively likely for attackers to control or conspire with them;
2. During the dispute period, the attacker should avoid having their malicious transaction detected; once detected, it is likely to prompt lockers to lock the contract. We will discuss this part in detail later.
3. Obtain the private key of at least one finalizers member to have their withdrawal action ultimately confirmed. Currently, the members of finalizers and hotValidatorSet are basically the same, so as long as the attacker meets condition 1, they automatically satisfy condition 3.

Locking the Bridge Contract

We have mentioned several times that Hyperliquid has set up a function to lock the cross-chain bridge contract. Specifically, locking the cross-chain bridge requires members of the lockers to call the voteEmergencyLock function in the cross-chain bridge contract to vote. Currently, when two lockers call this function to cast their votes, the cross-chain bridge contract will be locked and its operation paused.

However, it is important to note that HyperLiquid's cross-chain bridge also provides the unvoteEmergencyLock function, allowing lockers members to withdraw their votes. Once the cross-chain bridge contract is successfully locked, it can only be unlocked through a function called emergencyUnlock, which requires collecting more than 2/3 of the signature weight from coldValidatorSet members.

The emergencyUnlock function, while unlocking, will also input new hotValidatorSet and coldValidatorSet validator address sets and will update immediately.

Updating the Validator Set

Instead of trying to break through the existing defenses in the withdrawal process, a better attack method is to directly use the updateValidatorSet function to update the hotValidatorSet and coldValidatorSet validator sets. This requires the caller to provide signatures from all hotValidatorSet members, and this operation has a 200-second dispute period.

After the dispute period ends, members of the finalizers need to call the finalizeValidatorSetUpdate function to complete the final status update.

At this point, we have introduced most of the details of the Hyperliquid cross-chain bridge. This article does not cover the update logic for lockers and finalizers; both updates require signatures from the hotValidatorSet, while removing a member requires a signature from the coldValidatorSet.

In summary, the Hyperliquid bridge contract contains the following risks:

1. If a hacker controls the coldValidatorSet, they can ignore any obstacles to steal user assets. The coldValidatorSet has the operational authority for the emergencyUnlock function, which can invalidate the locking actions of the lockers and can instantly update the node list. Currently, Hyperliquid only has four validator nodes, making the possibility of stolen private keys relatively high;

2. Finalizers may refuse to provide final confirmation for user withdrawal transactions, launching a review attack; in this case, user assets will not be stolen, but withdrawals from the bridge contract may be impossible;

3. Lockers may maliciously lock the cross-chain bridge, at which point all withdrawal transactions cannot be executed, and users must wait for the coldValidatorSet to unlock.

HyperEVM and Dual-Chain Interaction Architecture

To make order book trading programmable, such as introducing privacy transactions that require smart contracts, Hyperliquid has launched a solution called HyperEVM. It has two special advantages over traditional EVM: first, HyperEVM can read the state of the HyperLiquid order book; second, smart contracts within HyperEVM can interact with the Hyperliquid order book system, greatly expanding Hyperliquid's application scenarios.

For example, if a user needs to ensure the privacy of their order placement, they can use a smart contract similar to Tornado Cash on HyperEVM to add a layer of privacy, and then trigger the order placement action in the HyperLiquid order book system through a specific interface.

Before introducing HyperEVM, we need to discuss the special architecture that Hyperliquid has prepared for HyperEVM. Since Hyperliquid has a customized ultra-high-performance order book system, the transaction processing speed in the EVM environment is much slower. To avoid slowing down the order book system, Hyperliquid uses a "dual-chain solution," essentially allowing Hyperliquid node devices to run two blockchains simultaneously at the software level. Each node locally stores data from both chains and processes transactions for both chains separately.

Hyperliquid has specifically set up a chain for its customized order book system while adding an EVM-compatible chain (HyperEVM). The data from these two chains is propagated among the node group through the same consensus protocol, existing as a unified state but running in different execution environments. We refer to the order book-specific chain as Hyperliquid L1 (L1), which is permissioned; while the chain used for HyperEVM is HyperEVM (EVM), which is permissionless, allowing anyone to deploy contracts that can access information within L1 through precompiled code.

It is important to note that the block generation speed of Hyperliquid L1 is greater than that of the HyperEVM chain, but these blocks will still be executed in order. Contracts on the EVM chain can read data from past L1 blocks and write data to future L1 blocks. As shown in the figure below:

To enable interaction between HyperL1 and HyperEVM, Hyperliquid utilizes two technical means: Precompiles and Events.

Precompiles

Precompiles, in simple terms, are operations that are difficult to implement in smart contracts due to their complexity, which are directly moved to the underlying layer for implementation. This allows cumbersome calculations that are not friendly to Solidity to be handled outside of regular smart contracts. Such precompiled code can be implemented using languages like C or C++, which are closer to the device's underlying architecture than Solidity.

The use of precompiles allows EVM to support more advanced and complex functions, facilitating the needs of smart contract developers. In essence, precompiles are a set of special smart contracts that other smart contracts can directly call, passing parameters and obtaining the return results of the precompiled execution. Currently, the native EVM has implemented the ecRecover instruction through precompiles, which can check whether secp256k1 signatures are correct within the EVM, and this instruction is located at address 0x01.

Adding special functions using precompiles is a mainstream practice; for example, Base has added P256 precompiled code to facilitate WebAuth identity authentication operations.

(This image is from the Rollup Codes website)

In line with this mainstream approach, HyperEVM has also added a series of precompiled codes to enable EVM to read the state of the Hyperliquid order book system. One known address for a Hyperliquid precompiled code is 0x0000000000000000000000000000000000000800, which can read the position status of users' perpetual contracts in the most recent L1 block.

Events

As mentioned earlier, HyperEVM can write data to the HyperL1 block, and this writing behavior relies on Events. Events are a native concept within the EVM that allows smart contracts to send log information to the outside (such as front-end applications or listeners) during execution, facilitating external monitoring of the smart contract's operation.

For example, when a user uses the token transfer function of an ERC-20 contract, the contract will emit a corresponding Transfer Event to inform front-end applications like block explorers of the token transfer status. This Events information will be included in the block, and there are many mature solutions for listening to and retrieving Events logs.

Currently, many cross-chain-related scenarios use Events to transmit cross-chain parameters. For instance, in the bridge contract deployed on the Ethereum mainnet by Arbitrum, users can call related functions to emit events that trigger transactions on Arbitrum.

Available information indicates that HyperLiquid nodes will listen to Events emitted by 0x3333333333333333333333333333333333333333 (event address) to understand user intentions based on the information contained in the Events and convert that intention into transaction actions, writing them into future Hyperliquid L1 blocks.

For example, the aforementioned event address provides a function that, when called by a user, will emit an Event named IocOrder. When a Hyper L1 block is generated, HyperLiquid nodes will first query the Events emitted by the event address in the most recent HyperEVM, and when a new IocOrder event is retrieved, it will be converted into an order placement operation in Hyper L1.

HyperBFT

At the consensus protocol level, Hyperliquid adopts a protocol called HyperBFT, which is a derivative method based on HotStuff. Currently, HutStuff-2 is one of the latest consensus protocols with the lowest complexity.

According to available information, HyperLiquid initially used the Tendermint consensus algorithm, which is the default consensus algorithm used in the Cosmos system. However, this algorithm is relatively inefficient, requiring All-to-All message exchanges at each stage, where each node must send messages to all other nodes, resulting in a communication complexity of O(n²), where n is the number of nodes.

If Tendermint were used, Hyperliquid could process a maximum of 20,000 orders per second. To achieve the speed of centralized exchanges, the HyperLiquid team developed the HyperBFT algorithm based on HotStuff and implemented it in Rust, theoretically allowing for a maximum of 2 million orders per second.

The following diagram illustrates the message-passing method of HyperBFT consensus in a non-parallel scenario, showing that all messages are aggregated by the Leader and broadcast uniformly, eliminating the need for nodes to exchange messages among themselves, significantly reducing complexity.

In simple terms, HyperBFT is a consensus protocol where the current leader produces blocks, all nodes participate in voting and send the voting results back to the Leader, and then the next leader rotates. In reality, the specific details involved in Hotstuff and Tendermint are much more complex, and this article does not delve into them due to space constraints and focus.

Key Points for Developers to Note

The data reading mechanism based on Precompiles mentioned above is quite perfect; Solidity developers do not need to write corresponding code to read the Hyper L1 state. However, attention must be paid to the issue of msg.sender. Similar to most Ethereum Layer 2 solutions, HyperLiquid also allows users to interact directly with the system contracts within Hyper L1, indirectly triggering transaction actions on the HyperEVM chain. In this case, if the smart contract reads the msg.sender field within that transaction, it will find that msg.sender corresponds to the address of the HyperL1 system contract, rather than the address of the user who originally initiated the transaction on HyperL1.

For the interaction between EVM and L1, developers need to be aware of a series of issues. The first issue is the non-atomicity of the interaction. If a user places an order indirectly on L1 through the aforementioned event address on HyperEVM, but there are insufficient assets on L1, that transaction will certainly fail. However, there will be no error return prompt when the user calls the function at the event address. The non-atomicity of the interaction may lead to damage to the user's assets. In this case, developers need to manually handle the order placement failure on the EVM smart contract side. Additionally, the smart contracts within EVM should have functions for the final recovery of funds to prevent user assets from being permanently unrecoverable on L1.

Secondly, the contract address corresponding to EVM must have a mapped account on L1. After a user deploys a smart contract within EVM, they need to transfer a small amount of USDC to the mapped address on L1, forcing L1 to create an account for the contract address. This part of the operation may be related to the underlying consensus of HyperLiquid, as clearly required in Hyperliquid's documentation.

Finally, developers need to pay attention to some special cases, particularly regarding token balances. Hyper L1 has a special address for asset transfers, but when users send assets to this special address, the assets will cross from L1 to the HyperEVM chain. Since HyperLiquid nodes actually execute both the EVM chain and the L1 chain simultaneously, there may be a delay in block generation on HyperEVM after the user transfers assets, during which the user cannot read their balance on the EVM chain.

In simple terms, the user's assets are stuck in the cross-chain bridge at this point, and they cannot be queried on either L1 or the EVM chain. The protocol constructed by developers should handle the above special cases to avoid causing panic among users.

In summary, HyperEVM is similar to a Layer 2 based on Hyperliquid L1. HyperEVM relies on precompiled code to read the L1 state and also depends on Events to interact with Hyper L1. L1 also has some system contracts to help users trigger transactions within HyperEVM or perform cross-chain asset transfers. However, unlike typical Layer 1 to Layer 2 architectures, Hyperliquid provides greater interoperability for HyperEVM.

References

Hyperliquid: The Hyperoptimized Order Book L1

hyperliquid-dex/contracts

The Not-So-Definitive guide to Hyperliquid Precompiles.

What is the difference between PBFT, Tendermint, HotStuff, and HotStuff-2?

免责声明：本文章仅代表作者个人观点，不代表本平台的立场和观点。本文章仅供信息分享，不构成对任何人的任何投资建议。用户与作者之间的任何争议，与本平台无关。如网页中刊载的文章或图片涉及侵权，请提供相关的权利证明和身份证明发送邮件到support@aicoin.com，本平台相关工作人员将会进行核查。