The Decline of Hype: A Technical Perspective on Hyperliquid's Bridge Contract, HyperEVM, and Its Potential Issues

Article Source: Xianrang GodRealmX

Author: Shew, Xianrang GodRealmX

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

The author of this article aims to fill this gap by examining Hyperliquid purely from the perspective of technical structure and security, helping more people understand the structure and principles of this star project. We will elaborate from two perspectives: the construction and hidden dangers of the Hyperliquid cross-chain bridge contract, and the dual-chain construction of HyperEVM and HyperL1, to help everyone deeply understand 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 contract. Hyperliquid has deployed a bridge contract on Arbitrum to store user-deposited USDC assets, and we can observe some behaviors of Hyperliquid nodes within the Bridge component.

Validator Set

From the perspective of node identity classification, Hyperliquid has 4 groups of validators: hotValidatorSet, coldValidatorSet, and finalizers and lockers, corresponding to different functions. Among them, hotValidatorSet responds to high-frequency actions such as user withdrawal requests, generally using hot wallets to promptly respond to withdrawal requests from Hyperliquid users.

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

The lockers are a group of validators with special permissions, similar to the "security committee" commonly used in Layer2, who will vote to decide whether to pause the cross-chain bridge in certain emergencies. Currently, the Hyperliquid bridge's lockers set contains 5 addresses, and it only takes 2 lockers to vote to pause the bridge contract's operation.

As for the finalizers, they are also a group of special validators mainly used to confirm 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 "commit-confirm" mechanism; for example, after a user initiates a withdrawal, it will not be executed immediately, but will require a waiting period (this period is called the dispute period). After the dispute period ends, members of the finalizers will execute the withdrawal transaction, and only then can the withdrawal be executed normally.

If a problem occurs with the cross-chain bridge, for example, if a withdrawal claim is trying to withdraw more assets than the user actually holds, Hyperliquid nodes can use lockers to vote to pause the operation of the cross-chain bridge contract during the dispute period, or the coldValidatorSet can directly invalidate the problematic withdrawal request.

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

Deposits

The bridge contract of Hyperliquid 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 more concise compared to the traditional Approve-Transfer model and facilitates batch operations.

The bridge contract of Hyperliquid uses the batchedDepositWithPermit function to batch process multiple deposits. The deposit action here is relatively simple, with no risk to fund safety, and the processing flow is very straightforward, simply using the Permit method to optimize UX.

Withdrawals

Compared to deposits, withdrawals are a highly risky operation, so the withdrawal logic is much more complex than deposits. When a user initiates a withdrawal request, the Hyperliquid node will call the batchedRequestWithdrawals function of the bridge contract. At this point, the bridge contract will require that each withdrawal request must gather 2/3 of the signature weight from the hotValidatorSet; note that many documents describe this as "gathering 2/3 of the signatures", but in fact, the bridge contract checks for "2/3 of the signature weight." Currently, HyperLiquid only has 4 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.

After initiating a withdrawal request, the cross-chain bridge will not immediately transfer the USDC controlled by the contract, but 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 can directly vote to pause/freeze the contract;

2. Nodes believe that certain withdrawal actions have issues; in this case, members of the coldValidatorSet can call the invalidateWithdrawals function to render that withdrawal invalid.

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

Therefore, 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 defenses:

1. Control over 2/3 of the signature weight within hotValidatorSet; in other words, obtaining a certain number of private keys or collusion; currently, HyperLiquid has only 4 validators, so the possibility of being controlled or colluded by attackers is not low;

2. During the dispute period, attackers should avoid having their malicious transactions detected; once detected, it is likely that lockers will act to lock the contract. We will specifically discuss this part below.

3. Obtain the private key of at least one finalizers member to have your withdrawal action confirmed. Currently, the members of finalizers and hotValidatorSet are basically consistent, so as long as the attacker satisfies condition 1, they automatically satisfy condition 3.

Bridge Contract Locking

Previously, we have repeatedly mentioned that Hyperliquid has set up a function to lock the cross-chain bridge contract. Specifically, locking the cross-chain bridge requires locker members to call the voteEmergencyLock function in the cross-chain bridge contract to vote. Currently, when 2 lockers call this function to give a vote, the cross-chain bridge contract will be locked and its operation will be paused.

However, it should be noted that HyperLiquid's cross-chain bridge also provides the unvoteEmergencyLock function, allowing locker members to withdraw their votes. Once the cross-chain bridge contract is successfully locked, it can only be unlocked through a function called emergencyUnlock, requiring the collection of signatures from more than 2/3 of the coldValidatorSet members.

The emergencyUnlock function will input a new set of hotValidatorSet and coldValidatorSet validator addresses while unlocking, and will update immediately.

Validator Set Update

Compared to struggling 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 the operation has a 200-second dispute period.

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

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

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

1. If hackers control the coldValidatorSet, they can disregard any obstacles to steal user assets. This is because the coldValidatorSet has operational authority over the emergencyUnlock function, which can invalidate the locking actions of lockers against the bridge contract, and can update the node list instantly. Currently, Hyperliquid only has 4 validator nodes, making the possibility of stolen private keys not low.

2. Finalizers refuse to confirm the user's withdrawal transaction for finalization, initiating a review attack; in this case, user assets will not be stolen, but may be unable to withdraw from the bridge contract;

3. Lockers maliciously lock the cross-chain bridge, preventing all withdrawal transactions from executing, and can only wait for the coldValidatorSet to unlock;

HyperEVM and Dual-Chain Interaction Architecture

To make order book trading programmable, such as introducing privacy trading scenarios that require smart contracts to implement, Hyperliquid has launched a program called HyperEVM. It has two special advantages compared to traditional EVM: first, HyperEVM can read the state of HyperLiquid's order book, and second, smart contracts in 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 an order placement operation, 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 Hyperliquid has prepared for HyperEVM. Due to Hyperliquid's customized ultra-high performance order book system, transaction processing speed in the EVM environment is significantly 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 on the software level, with each node locally storing data from both chains and processing transactions separately for the two chains.

Hyperliquid has set up a dedicated chain for its customized order book system, while also adding an EVM-compatible chain (HyperEVM). The data of these two chains is propagated among the node community 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 a permissioned chain; while the chain for HyperEVM is HyperEVM (EVM), which is permissionless, allowing anyone to deploy contracts that can access information within L1 through precompiled code.

It should be noted that the block generation speed of Hyperliquid L1 is greater than that of the HyperEVM chain, but these blocks will still be executed in sequence. 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 achieve interaction between HyperL1 and HyperEVM, Hyperliquid utilizes two technical means: Precompiles and Events.

Precompiles

所谓的预编译（Precompiles），说白了就是将一些在智能合约中不易实现、复杂度较高的操作直接挪到底层中实现，把对Solidity不友好、较为麻烦的计算流程挪到常规的智能合约外部去处理，这类预编译代码可以用C、C++等比Solidity更贴近设备底层的语言来实现。

The precompiled method allows the 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 invoke, passing parameters and obtaining the return results of precompiled execution. Currently, the native EVM has implemented the ecRecover directive in a precompiled manner, which can check whether secp256k1 signatures are correct within the EVM, and this directive is located at address 0x01.

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

(This image is from the Rollup Codes website)

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

Events

As mentioned above, HyperEVM can write data to the HyperL1 block, and the write behavior relies on Events. Events are a native concept within the EVM, allowing smart contracts to send log information to external parties (such as front-end applications or listeners) during execution, facilitating external monitoring of smart contract operations.

For example, when users use the token transfer function of the ERC-20 contract, the contract will throw the Transfer corresponding Event to facilitate block explorers and other front-end applications to understand the token transfer situation. These Events information will be included in the block, and there are many mature solutions for listening and retrieving Events logs.

Currently, many cross-chain related scenarios use Events to pass cross-chain parameters; for example, in the bridge contract deployed on the Ethereum mainnet by Arbitrum, users can call related functions to throw events to trigger transactions on Arbitrum.

Known information indicates that HyperLiquid nodes will listen to

0x3333333333333333333333333333333333333333 (event address) throws Events, based on the information contained in Events to understand the user's intent, and convert that intent into transaction actions, writing them into future Hyperliquid L1 blocks.

For example, the aforementioned event address will provide a function that, when called by the user, will throw an event named IocOrder. When a block is generated in Hyper L1, the HyperLiquid node will first query the most recent events thrown by the event address in 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 employs a protocol called HyperBFT, which is a derivative method based on HotStuff. Currently, HutStuff-2 is one of the newest and least complex consensus protocols.

According to the information, initially HyperLiquid used the Tendermint consensus algorithm, which is the default consensus algorithm within the Cosmos system, but this algorithm is relatively inefficient, as it requires All-to-All message exchanges at each stage, and 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 is adopted, Hyperliquid can handle up to 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 capable of processing up to 2 million orders per second.

The figure below shows the message transmission method of the HyperBFT consensus in a non-parallel situation. It can be seen that all messages are summarized and uniformly broadcasted by the Leader, eliminating the step of nodes exchanging messages with each other, significantly reducing complexity.

In simple terms, HyperBFT is a consensus protocol where the current leader generates blocks, all nodes participate in voting, and the voting results are sent back to the Leader, followed by a rotation to the next leader. In reality, the specifics involved in Hotstuff and Tendermint are much more complex, but this article will not elaborate further due to space constraints and focus.

Key Points for Developers to Note

The aforementioned data reading mechanism based on Precompiles is quite perfect, as Solidity developers do not need to write corresponding code to read Hyper L1 states, but attention should be paid to the msg.sender issue. Like most Ethereum layer twos, HyperLiquid also allows users to directly interact with system contracts within Hyper L1, indirectly triggering transaction actions on the HyperEVM chain. If the smart contract reads the msg.sender field during this transaction, it will find that msg.sender corresponds to the address of the HyperL1 system contract, rather than the user address that initiated the transaction on HyperL1 initially.

For EVM and L1 interactions, developers need to be aware of a series of issues. The first issue is the non-atomicity of interactions; if a user indirectly places an order on L1 through the aforementioned event address, but there are insufficient assets on L1, that transaction will certainly fail, but there will be no error return prompt when the user calls the function of the event address. The non-atomicity issue may lead to the loss of user assets. At this point, developers need to manually handle the case of order placement failure on the EVM smart contract side. Moreover, smart contracts within the EVM should have functions for final fund recovery to avoid user assets being permanently unrecoverable from L1.

Secondly, the contract address corresponding to the EVM must exist as a mapped account in L1. When the user completes the deployment of the smart contract within the EVM, they need to transfer a small amount of USDC to the mapped address in L1, forcing L1 to create an account for the contract address. This operation may relate to HyperLiquid's underlying consensus, which is clearly required in Hyperliquid's documentation.

Finally, developers need to pay attention to some special cases, particularly regarding token balance situations. 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 are effectively executing both the EVM chain and L1 chain simultaneously, if it takes a long time for HyperEVM to produce a block after the user transfers assets, the user may not be able to read their balance on the EVM chain.

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

In summary, HyperEVM is similar to a layer two based on Hyperliquid L1; HyperEVM relies on precompiled code to read the L1 state and also relies on Events to interact with Hyper L1. L1 also has some system contracts to help users trigger transactions in HyperEVM or conduct cross-chain asset transfers. However, unlike the general Layer1—Layer2 architecture, Hyperliquid provides higher 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?