Author: Shew, Xianrang GodRealmX
The Hyperliquid, which has recently attracted widespread market attention, is one of the most influential on-chain order book trading platforms, with a TVL of over $2 billion. It has been evaluated by Messari as the "on-chain Binance", and has even brought the narratives of Layer3 and application chains, which had faded from the public eye, back into the spotlight. With the impressive achievement of reaching a FDV of $30 billion within one month of its Token launch, Hyperliquid has gained widespread attention from ordinary users to industry practitioners. Meanwhile, a large number of research reports on Hyperliquid have also emerged in the market, but these articles have mainly focused on the characteristics of its order book product functions and trading mechanisms, without delving into the technical structure and security risks behind it.
The author of this article aims to fill this gap, examining Hyperliquid solely from the perspective of technical structure and security, to help more people understand the structure and principles of this star project. We will elaborate on the construction and vulnerabilities of the Hyperliquid cross-chain bridge contract, as well as the dual-chain structure of HyperEVM and HyperL1, to help everyone gain a deeper understanding of its underlying technical architecture and implementation.
(Currently, Hyperliquid occupies 67% of the total USDC supply on Arbitrum)
Analysis of the HyperLiquid Cross-Chain Bridge
Since HyperLiquid has not open-sourced its core components, but has open-sourced the related bridge contracts, we have a better understanding of the risks in the bridge contract area. Hyperliquid has deployed a bridge contract on Arbitrum to store the USDC assets deposited by users, and we can see the partial behavior of the Hyperliquid nodes in the Bridge component.
Validator Set
From the perspective of node identity division, Hyperliquid has 4 groups of validators, namely hotValidatorSet, coldValidatorSet, finalizers, and lockers, each with different functions. The hotValidatorSet is used to respond to high-frequency actions such as user withdrawals, generally using a hot wallet to respond to Hyperliquid users' withdrawal requests at any time.
The coldValidatorSet is mainly used to modify system configurations, such as rewriting the list of hotValidatorSet or lockers validators, or handling the lock status of the bridge contract, and the coldValidatorSet has the power to directly invalidate certain withdrawal requests.
The lockers are a group of validators with special privileges, similar to the "security committee" commonly used in Layer2, who will vote to decide whether to temporarily suspend the operation of the cross-chain bridge in some emergency situations. Currently, the lockers set of the Hyperliquid bridge contains 5 addresses, and only 2 lockers need to vote to pause the operation of the bridge contract.
As for the finalizers, they are also a group of special validators, mainly used to confirm the state changes of the cross-chain bridge, and from the contract level, they mainly confirm the user deposits and withdrawals. The Hyperliquid cross-chain bridge uses a "submit-confirm" mechanism, where the user's withdrawal request will not be executed immediately, but needs to wait for a period of time (this period is called the dispute period). After the dispute period ends, the members of the finalizers execute the withdrawal transaction, and the withdrawal can be executed normally.
If the cross-chain bridge has problems, such as a withdrawal declaration requesting more assets than the user actually has, the Hyperliquid nodes can use the lockers to vote to temporarily pause the operation of the cross-chain bridge contract, or the coldValidatorSet can directly invalidate the problematic withdrawal request.
Currently, Hyperliquid only has 4 validator nodes, so the hotValidatorSet and coldValidatorSet correspond to only 4 on-chain addresses. When Hyperliquid is initialized, it automatically registers the addresses in the hotValidatorSet as members of the lockers and finalizers, while the coldValidatorSet is controlled by the Hyperliquid team itself, using a cold wallet to store the private keys.
Deposit
Hyperliquid's bridge contract uses the Permit method based on EIP-2612 to handle user deposit operations, and the bridge contract only allows users to deposit the USDC asset. Permit is more concise than the traditional Approve-Transfer mode, and also facilitates batch operations.
Hyperliquid's bridge contract uses the batchedDepositWithPermit function to batch process multiple deposits, and the deposit action is relatively simple, without any financial security risks, and the processing flow is very concise, using only the Permit method to optimize the UX.
Withdrawal
Compared to deposits, withdrawals are a highly dangerous operation, so the withdrawal logic is much more complex. 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 have the signature weight of 2/3 of the hotValidatorSet. Note that many documents describe this as "gathering 2/3 of the signatures", but in fact the bridge contract checks the "2/3 of the signature weight". Currently, HyperLiquid only has 4 nodes with the same weight, so checking the signature weight and checking the number of signatures are temporarily the same, but in the future, HyperLiquid may introduce high-weight nodes.
After a withdrawal request is initiated, the cross-chain bridge will not immediately transfer the USDC controlled by the contract, but will have a "dispute period", similar to the "challenge period" in the fraud proof protocol. Currently, the dispute period of the Hyperliquid bridge contract is 200 seconds, and two situations may occur during the dispute period:
1. The lockers believe that the current withdrawal request has serious problems, in which case they can directly vote to pause/freeze the contract;
2. The nodes believe that some withdrawal behaviors are problematic, in which case the coldValidatorSet members can call the invalidateWithdrawals function to invalidate the withdrawal.
If no problems arise during the dispute period, after the dispute period ends, the members of the finalizers can call the batchedFinalizeWithdrawals function in the bridge contract to finalize the final state, and this function will trigger the USDC to be sent to the user's wallet address on Arbitrum.
So from the perspective of the security model, if a malicious attacker wants to tamper with the withdrawal process of Hyperliquid, they need to break through three lines of defense:
1. Mastering 2/3 of the signature weight of the hotValidatorSet, in other words, they need to obtain a certain number of private keys or collude; currently HyperLiquid only has 4 validators, so the possibility of the attacker controlling or colluding is not low;
2. During the dispute period, the attacker should avoid having their malicious transactions discovered, otherwise the lockers may intervene and lock the contract. We will discuss this part in more detail below.
3. Obtain the private key of at least one finalizers member to have their withdrawal behavior finally confirmed. Currently, the finalizers members and the hotValidatorSet members are basically the same, so as long as the attacker meets the above condition 1, they automatically meet condition 3.
Locking of the Bridge Contract
We have mentioned several times that Hyperliquid has set up a function to lock the cross-chain bridge contract. Specifically, to lock the cross-chain bridge, the lockers members need to call the voteEmergencyLock function in the cross-chain bridge contract to vote, and currently when 2 lockers call this function to cast their votes, the cross-chain bridge contract will be locked and suspended.
However, it should be noted 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 the function called emergencyUnlock, which requires the signature weight of more than 2/3 of the coldValidatorSet members.
The emergencyUnlock function will not only unlock the lock, but also input new hotValidatorSet and coldValidatorSet validator address sets, and will immediately update them.
Validator Set Update
Compared to trying hard 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 the signatures of all hotValidatorSet members, and this operation has a 200-second dispute period.
After the dispute period ends, the finalizers members need to call the finalizeValidatorSetUpdate function to complete the final state 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 of the lockers and finalizers, both of which require hotValidatorSet signatures to update, and removing a member requires coldValidatorSet signatures.
In summary, the risks of the Hyperliquid bridge contract include:
1. After the hacker takes control of the coldValidatorSet, they can steal user assets without any obstruction. This is because the coldValidatorSet has the operation authority of the emergencyUnlock function, which can invalidate the locking action of the bridge contract, and can also update the node list immediately. Currently, Hyperliquid only has 4 validator nodes, so the possibility of the private keys being stolen is not low;
2. The finalizers refuse to make the final confirmation of the user's withdrawal transaction and launch an audit attack; in this case, the user's assets will not be stolen, but they may not be able to withdraw from the bridge contract;
3. The lockers maliciously lock the cross-chain bridge, in which case all withdrawal transactions cannot be executed and can only wait for the coldValidatorSet to be unlocked;
HyperEVM and Dual-Chain Interaction Architecture
In order to make order book transactions more programmable, such as introducing privacy transactions that require smart contracts to implement, Hyperliquid has launched a solution called HyperEVM. Compared to the traditional EVM, HyperEVM has two special advantages: one is that HyperEVM can read the order book status of HyperLiquid, and the other is that the smart contracts in HyperEVM can interact with the HyperLiquid order book system, which greatly expands the application scenarios of HyperLiquid.
For example, if a user needs to ensure the privacy of the order placement operation, they can add a layer of privacy through a smart contract similar to Tornado Cash on HyperEVM, and then trigger the order placement action in the HyperLiquid order book system through a specific interface.
Before introducing HyperEVM, we need to introduce 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", which essentially means that Hyperliquid nodes run two blockchains at the software level, with each node storing data from both chains and processing transactions on both chains separately.
Hyperliquid has set up a chain specifically for its customized order book system, and has also added an EVM-compatible chain (HyperEVM). The data of these two chains is propagated among the node group through the same consensus protocol, and exists as a unified state, but runs separately in different execution environments. We call the order book-specific chain Hyperliquid L1 (L1), and this chain is permissioned; the chain used for HyperEVM is HyperEVM (EVM), which is permissionless, and anyone can deploy contracts that can access information in L1 through pre-compiled code.
It is worth noting 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 following figure:
To enable interaction between HyperL1 and HyperEVM, Hyperliquid uses two technical means: Precompiles and Events.
Precompiles
Precompiles are essentially special smart contracts that are pre-compiled and deployed at specific addresses, allowing other smart contracts to directly call these special contracts, pass in parameters, and obtain the results of the pre-compiled execution. The current native EVM already uses precompiles to implement the ecRecover instruction, which can check the correctness of secp256k1 signatures within the EVM.
Using precompiles to add some special functions is currently a mainstream approach, such as Base adding P256 precompile code to facilitate user WebAuth identity authentication.
(This image is from the Rollup Codes website)
Consistent with this mainstream approach, HyperEVM has also added a series of precompile codes to implement the reading of the Hyperliquid order book system status by the EVM. Currently, a known Hyperliquid precompile code address is 0x0000000000000000000000000000000000000800, which can read the user's perpetual contract position information in the latest L1 block.
Events
As mentioned earlier, HyperEVM can write data into HyperL1 blocks, and this writing behavior is based on the implementation of Events. Events are a native concept in the EVM, allowing smart contracts to send log information to the outside world (such as front-end applications or listeners) during the execution process, so that the outside world can monitor the running status of the smart contract.
Now many cross-chain related scenarios use Events to pass cross-chain parameters, such as the bridge contract deployed on the Ethereum mainnet by Arbitrum, where users can call related functions to trigger events on Arbitrum.
According to the available information, HyperLiquid nodes will listen to the Events thrown by the address 0x3333333333333333333333333333333333333333, and based on the information contained in the Events, they will convert the user's intentions into transaction actions and write them into the future Hyperliquid L1 blocks.
For example, the above event address will provide a function, and when the user calls this function, the event address will throw an Event named IocOrder. When a Hyper L1 block is generated, the HyperLiquid node will first query the Events thrown by the event address in the recent HyperEVM, and when a new IocOrder event is detected, it will convert it into an order placement operation in the Hyper L1.
HyperBFT
At the consensus protocol level, Hyperliquid adopts a protocol called HyperBFT, which is a derivative method based on HotStuff. According to the information, Hyperliquid initially used the Tendermint consensus algorithm, which is the default consensus algorithm used in the Cosmos system, but this algorithm has low efficiency and requires an All-to-All message exchange in each phase, with a communication complexity of O(n²), where n is the number of nodes.
If Tendermint is used, Hyperliquid can only process a maximum of 20,000 orders per second. To achieve the speed of a centralized exchange, the HyperLiquid team developed the HyperBFT algorithm based on HotStuff and implemented it in Rust, which can theoretically process up to 2 million orders per second.
The following figure shows the message passing mode of the HyperBFT consensus in the non-parallel case, where all messages are summarized and uniformly broadcast by the Leader, eliminating the step of nodes exchanging messages with each other, and greatly reducing the complexity.
In simple terms, HyperBFT is a consensus protocol where the current leader blocks, all nodes participate in voting, and the voting results are uniformly sent to the Leader, and then the next leader rotates. In fact, the specific details of Hotstuff and Tendermint are much more complex, but due to the limitations of the article's length and focus, they are not elaborated here.
Points to Note for Developers
The data reading mechanism based on Precompiles is relatively perfect, and Solidity developers do not need to write specific code to read the Hyper L1 state, but they need to pay attention to the issue of msg.sender. Similar to most Ethereum second-layer solutions, HyperLiquid also allows users to directly interact with the system contracts in Hyper L1, indirectly triggering transaction actions on the HyperEVM chain. In this case, if the smart contract reads the msg.sender field in the transaction, it will find that the msg.sender corresponds to the address of the Hyper L1 system contract, rather than the user's address who initially initiated the transaction on Hyper L1.
For the interaction between EVM and L1, developers need to pay attention to a series of issues. The first issue is the non-atomic nature of the interaction. If a user indirectly places an order on L1 through the aforementioned event address on HyperEVM, but there are insufficient assets on L1, the transaction will definitely fail, but the user will not receive an error message when calling the function of the event address. The non-atomic nature of the interaction may lead to the user's assets being damaged. In this case, developers need to manually handle the failure of order placement in the EVM smart contract. Moreover, the smart contract in the EVM should have a function for the final recovery of funds to avoid the user's assets being permanently unrecoverable on L1.
Secondly, there must be a mapped account on L1 for the contract address corresponding to the EVM. After the user deploys the smart contract in the EVM, they need to transfer a small amount of USDC to the mapped address on L1 to force L1 to create an account for the contract address. This operation may be related to the underlying consensus of HyperLiquid, and there are clear requirements in the HyperLiquid documentation.
Finally, developers need to pay attention to some special situations, especially the balance of tokens. HyperL1 has a special address for asset transfer, but when users send assets to this special address, the assets will be transferred from L1 to the HyperEVM chain. Since HyperLiquid nodes actually execute both the EVM chain and the L1 chain, the user's balance may not be readable on the EVM chain for a long time after the user transfers the assets.
In simple terms, the user's assets are stuck in the cross-chain bridge, and cannot be queried on either L1 or the EVM chain. The protocol developed by the developer should handle the above special situations to avoid causing panic among users.
In summary, HyperEVM is similar to a second layer based on the HyperLiquid L1. HyperEVM relies on precompiled code to read the state of L1 and also relies on Events to interact with HyperL1. L1 also has some system contracts to help users trigger transactions on HyperEVM or perform cross-chain asset transfers. But unlike the general Layer1-Layer2 architecture, HyperLiquid provides higher interoperability for HyperEVM.
Reference materials
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?
