Author: Shew, GodRealmX
Hyperliquid, which has attracted much attention in the market recently, is one of the most influential on-chain order book exchanges. Its TVL has exceeded 2 billion US dollars. While being evaluated by Messari as "Binance on the chain", it has even brought the Layer3 and application chain narratives that have faded from the public's perspective back into the spotlight. With the brilliant achievement of FDV reaching 30 billion US dollars within one month of the launch of the token, Hyperliquid has received widespread attention from ordinary users to practitioners. At the same time, a large number of research reports on Hyperliquid have emerged on the market, but these articles basically focus on its features in order book product functions and trading mechanisms, without in-depth exploration of the technical structure and security risks behind it.
The author of this article aims to fill this gap and examine Hyperliquid from the perspective of technical structure and security, helping more people understand the structure and principles of this star project. We will elaborate on the structure and hidden dangers of the Hyperliquid cross-chain bridge contract and the dual-chain structure of HyperEVM and HyperL1 from two perspectives to help everyone deeply understand the technical architecture and implementation behind it.
(Hyperliquid currently accounts for 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 the relevant bridge contracts, we are more aware of the risks of bridge contracts. Hyperliquid has deployed a bridge contract on Arbitrum to store the USDC assets deposited by users. We can see some behaviors of the Hyperliquid node 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, corresponding to different functions. Among them, hotValidatorSet is used to respond to high-frequency behaviors such as user withdrawal operations, and generally uses hot wallets to respond to Hyperliquid users' withdrawal requests at any time.
The coldValidatorSet is mainly used to modify the system configuration, such as rewriting the list of validator sets such as hotValidatorSet or lockers, or processing the locking status of the bridge contract, and coldValidatorSet has the right to directly invalidate certain withdrawal requests.
Lockers are a group of validators with special permissions, similar to the "security committee" commonly used by Layer2, who will use voting to decide whether to suspend the operation of the cross-chain bridge in some emergencies. Currently, the lockers set of the Hyperliquid bridge contains 5 addresses, and only 2 lockers need to vote to suspend the operation of the bridge contract.
As for finalizers, they are actually a special group of validators, which are mainly used to confirm the state changes of the cross-chain bridge. From the contract level, they mainly confirm user deposits and withdrawals. Hyperliquid's cross-chain bridge uses a "submit-confirm" mechanism. For example, after a user initiates a withdrawal, it will not be executed immediately. It takes a period of time (this period is called the dispute period). After the dispute period is over, the members in the finalizers execute the withdrawal transaction, and the withdrawal can be executed normally.
Once a problem occurs in the cross-chain bridge, for example, if a withdrawal statement claims that the assets to be withdrawn are greater than the actual asset balance owned by the user, the Hyperliquid node can use lockers to vote to suspend the operation of the cross-chain bridge contract during the dispute period, or coldValidatorSet can directly invalidate the problematic withdrawal request.
Currently, Hyperliquid has only 4 validator nodes, so hotValidatorSet and coldValidatorSet only correspond to 4 on-chain addresses. When Hyperliquid is initialized, it automatically registers the addresses in hotValidatorSet as members of lockers and finalizers, while coldValidatorSet is controlled by Hyperliquid itself and uses cold wallets to store keys.
deposit
Hyperliquid's bridge contract processes user deposit operations based on the Permit method of EIP-2612, and the bridge contract only allows users to deposit USDC. Permit is simpler than the traditional Approve-Transfer model and is also easier to support batch operations.
Hyperliquid's bridge contract uses the batchedDepositWithPermit function to process multiple deposits in batches. The deposit action here is relatively simple, there is no risk to fund security, and the processing flow is very concise. It only uses the Permit method to optimize UX.
Withdrawals
Compared to deposits, withdrawals are a highly risky operation, so the logic of withdrawals is much more complicated than deposits. When a user initiates a withdrawal request, the Hyperliquid node calls the batchedRequestWithdrawals function of the bridge contract. At this time, the bridge contract requires that each withdrawal request must collect 2/3 of the signature weight of hotValidatorSet. Note that many documents describe this as "collecting 2/3 of the signatures", but in fact the bridge contract checks "2/3 of the signature weight". Currently, HyperLiquid has only 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.
When a withdrawal request is initiated, the cross-chain bridge will not immediately transfer the USDC controlled by the contract, but there will be 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. Lockers believe that there are serious problems with the current withdrawal request, and can directly vote to suspend/freeze the contract;
2. The node believes that there is a problem with some withdrawal behaviors. At this time, the coldValidatorSet member can call the invalidateWithdrawals function to invalidate the withdrawal.
If no problems arise during the dispute period, after the dispute period ends, members in the finalizers can call the batchedFinalizeWithdrawals function in the bridge contract to finalize the final status. Only after this function is triggered will USDC be transferred to the user's wallet address in Arbitrum.
So from the perspective of the security model, if a malicious attacker wants to tamper with Hyperliquid's withdrawal process, they need to break through three lines of defense:
1. Master 2/3 of the signature weights in hotValidatorSet. In other words, you need to obtain a certain number of private keys or collude. Currently, HyperLiquid has only 4 validators, and the possibility of being controlled or colluded by attackers is not low.
2. During the dispute period, the attacker should avoid being discovered for malicious transactions. Once discovered, it is very likely that lockers will lock the contract. We will discuss this in detail below.
3. Obtain the private key of at least one finalizers member to make your withdrawal behavior finally confirmed. Currently, the finalizers members are basically the same as the hotValidatorSet members, so as long as the attacker meets the above condition 1, condition 3 is automatically met.
Locking of bridge contracts
We have mentioned many times before that Hyperliquid has set up a function to lock the cross-chain bridge contract. Specifically, locking the cross-chain bridge requires lockers to call the voteEmergencyLock function in the cross-chain bridge contract to vote. Currently, when two lockers call this function to vote, the cross-chain bridge contract will be locked and suspended.
However, it should be noted that HyperLiquid's cross-chain bridge also provides an unvoteEmergencyLock function, which allows lockers 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 signatures of more than 2/3 of the coldValidatorSet members.
The emergencyUnlock function will also input new hotValidatorSet and coldValidatorSet validator address sets while unlocking, and will be updated immediately.
Validator set update
Compared to 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 the signatures of all hotValidatorSet members, and the operation has a 200-second dispute period.
When the dispute period ends, the finalizers member needs 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 introduce the update logic of lockers and finalizers. The update of both requires hotValidatorSet signatures, and removing a member requires coldValidatorSet signatures.
In summary, Hyperliquid's bridge contract contains the following risks:
1. After hackers control coldValidatorSet, they can ignore any obstacles to steal user assets. Because coldValidatorSet has the operation permission of the emergencyUnlock function, it can invalidate the locker's locking action on the bridge contract and update the node list in real time. Currently, Hyperliquid only has 4 validator nodes, and the possibility of private keys being stolen is not low;
2. Finalizers refuse to finalize the user's withdrawal transaction and launch a review attack; in this case, the user's assets will not be stolen, but they may not be able to withdraw funds from the bridge contract;
3. Lockers maliciously set the cross-chain bridge. At this time, all withdrawal transactions cannot be executed and can only wait for coldValidatorSet to be unlocked;
HyperEVM and dual-chain interaction architecture
In order to make order book transactions programmable, such as introducing scenarios that require smart contracts to implement, Hyperliquid launched a solution called HyperEVM. Compared with the traditional EVM, it has two special advantages: first, HyperEVM can read the order book status of HyperLiquid, and second, the smart contracts in HyperEVM can interact with the Hyperliquid order book system, which greatly expands the application scenarios of Hyperliquid.
To give a simple example, if the user needs to ensure the privacy of the order placement operation, a layer of privacy can be added on HyperEVM through a smart contract similar to Tornado Cash, and then the order placement action can be triggered 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, and the transaction processing speed in the EVM environment is much slower. In order to avoid the order book system working slower, Hyperliquid uses a "dual-chain solution", which essentially allows Hyperliquid node devices to run two blockchains at the same time at the software level. Each node stores the data of the two chains locally and processes the transactions of the two chains separately.
Hyperliquid has set up a chain specifically for its customized order book system, and added an EVM-compatible chain (HyperEVM). The data of these two chains is propagated among the node groups through the same consensus protocol, existing as a unified state, but running separately in different execution environments. We call the order book dedicated chain Hyperliquid L1 (L1), which is a permissioned chain; and the chain used for HyperEVM is HyperEVM (EVM), which is permissionless and anyone can deploy contracts. These contracts can access information in L1 through precompiled code.
It should be noted that the block generation speed of Hyperliquid L1 is faster than that of HyperEVM chain, but these blocks will still be executed in sequence. Contracts on the EVM chain can read data in past L1 blocks and write data to future L1 blocks. As shown below:
In order to enable interaction between HyperL1 and HyperEVM, Hyperliquid uses two technical means: Precompiles and Events.
Precompiles
The so-called precompiles, to put it simply, are to move some operations that are difficult to implement and have high complexity in smart contracts directly to the underlying layer for implementation, and to move the calculation processes that are unfriendly to Solidity and more troublesome to the outside of conventional smart contracts for processing. This type of precompiled code can be implemented in languages such as C and C++ that are closer to the underlying device than Solidity.
The precompilation method allows EVM to support more advanced and complex functions, which is convenient for supporting the needs of smart contract developers. In terms of expression, precompilation is essentially a set of special smart contracts. Other smart contracts can directly call these special contracts, pass in parameters and obtain the return results of precompiled execution. Currently, the ecRecover instruction is implemented in the native EVM through precompilation. It can check whether the secp256k1 signature is correct inside the EVM, and this instruction is located at the address 0x01.
Using precompilation to add some special functions is the current mainstream practice. For example, Base adds P256 precompiled code to facilitate users to perform WebAuth identity authentication operations.
(This image is from the Rollup Codes website)
In line with this current mainstream solution, HyperEVM has also added a series of precompiled codes to enable EVM to read the status of the Hyperliquid order book system. Currently, a known precompiled code address of Hyperliquid is 0x0000000000000000000000000000000000000000800, which can read the position of the user's perpetual contract in the most recent L1 block.
Events
We mentioned above that HyperEVM can write data into HyperL1 blocks, and the writing behavior depends on Events. Events is a native concept in EVM, which allows smart contracts to send log information to the outside world (such as front-end applications or listeners) during execution, making it easier for the outside world to monitor the operation of smart contracts.
For example, when a user uses the token transfer function of the ERC-20 contract, the contract will throw the corresponding Transfer Event so that front-end applications such as block browsers can learn about the token transfer. These Events information will be included in the block, and there are a lot of mature solutions for monitoring and retrieving Events logs.
Now many cross-chain related scenarios will use Events to pass cross-chain parameters. For example, Arbitrum is deployed in a bridge contract on the Ethereum mainnet. Users can call related functions to throw events to trigger transactions on Arbitrum.
Known information shows that the HyperLiquid node will listen to
The Events thrown by 0x3 ...
For example, the above event address will provide a function. When the user calls this function, the event address will throw an Event named IocOrder. When the Hyper L1 block is generated, the HyperLiquid node will first query the Events thrown by the event address in the recent HyperEVM. When a new IocOrder event is retrieved, it will be converted into an order operation in Hyper L1.
HyperBFT
At the consensus protocol level, Hyperliquid uses 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 the information, HyperLiquid initially used the Tendermint consensus algorithm, which is the default consensus algorithm used in the Cosmos system. However, the algorithm is inefficient and requires All-to-All message exchanges at each stage. Each node must send messages to all other nodes, and the communication complexity is O(n²), where n is the number of nodes.
If Tendermint is used, Hyperliquid can process up to 20,000 orders per second. In order to reach the speed of centralized exchanges, 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 transmission method of HyperBFT consensus in a non-parallel situation. It can be seen that all messages are summarized and broadcasted uniformly by the Leader, eliminating the step of exchanging messages between nodes and greatly reducing the complexity.
In simple terms, HyperBFT is a consensus protocol in which the current leader produces blocks, all nodes participate in voting and send the voting results to the leader, and then the next leader takes over. In fact, the specific details involved in Hotstuff and Tendermint are much more complicated, and this article is limited by the length and focus and will not go into details here.
Important points for developers
The above data reading mechanism based on Precompiles is relatively perfect. Solidity developers do not need to write corresponding code to read the Hyper L1 state, but they need to pay attention to the msg.sender problem. Similar to most Ethereum Layer 2, HyperLiquid also allows users to interact directly with the system contract in Hyper L1, indirectly triggering transaction actions on the HyperEVM chain. At this time, if the smart contract reads the msg.sender field in the transaction, it will be found that msg.sender corresponds to the address of the HyperL1 system contract, not the user address that initially initiated the transaction on HyperL1.
As for the interaction between EVM and L1, developers need to pay attention to a series of issues. The first issue is the non-atomicity of the interaction. If a user places an order indirectly in L1 through the aforementioned event address on HyperEVM, but there are not enough assets in L1, then the transaction will definitely fail, but there will be no error return prompt when the user calls the function of the event address. The non-atomicity of the interaction may cause damage to the user's assets. At this time, for developers, it is necessary to manually handle the failure of placing orders on the EVM smart contract side. In addition, the smart contract in the EVM should have a function for the final fund recovery to prevent the user's assets from being unable to be withdrawn in L1 forever.
Secondly, the contract address corresponding to EVM must have a mapping account in L1. After the user completes the deployment of the smart contract in EVM, a small amount of USDC needs to be transferred to the mapping address in 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, and there are clear requirements in the Hyperliquid documentation.
Finally, developers need to pay attention to some special cases, especially the balance of tokens. Hyper L1 has a special address for asset transfer, but when users send assets to this special address, the assets will cross from L1 to the HyperEVM chain. Since the HyperLiquid node actually executes the EVM chain and the L1 chain at the same time, HyperEVM may not produce blocks for a long time after the user transfers the assets, and the user cannot read his balance on the EVM chain.
Simply put, at this time, the user's assets are stuck in the cross-chain bridge and cannot be queried either in the L1 or EVM chain. The protocol built by developers should handle the above special situations to avoid panic among users.
In summary, HyperEVM is similar to the second layer based on Hyperliquid L1. HyperEVM relies on precompiled code to read L1 status and also relies on Events to interact with Hyper L1. L1 also has some system contracts to help users trigger transactions in HyperEVM or perform cross-chain asset transfers. However, unlike the general Layer1-Layer2 architecture, Hyperliquid provides HyperEVM with higher interoperability.
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?
