HyperLiquid After the Speculation Cooldown: Analyzing Its Cross-Chain Bridges and HyperEVM Architecture from a Technical Perspective

HyperLiquid, as a highly regarded on-chain order book exchange, has a TVL that has surpassed $2 billion, earning it the title of "on-chain Binance". This article will delve into HyperLiquid from the perspectives of technical structure and security, focusing on the construction and risks of its cross-chain bridges contracts, as well as the dual-chain architecture of HyperEVM and HyperL1.

HyperLiquid cross-chain bridges解析

HyperLiquid has deployed a cross-chain bridges contract on Arbitrum to store users' USDC assets. The bridge contract includes four groups of validators:

• hotValidatorSet: responsible for high-frequency operations such as user withdrawals
• coldValidatorSet: responsible for modifying system configurations, handling bridge contract locking status, etc.
• lockers: similar to a security committee, can suspend bridge contract operations in emergency situations
• finalizers: Confirm cross-chain bridges status changes, such as user deposits and withdrawals.

Deposit Process

The HyperLiquid bridge contract uses the Permit method of EIP-2612 to handle deposits, allowing only USDC to be deposited. The deposit operation is relatively simple, using the batchedDepositWithPermit function to process multiple deposits in batch.

Withdrawal Process

The withdrawal process is relatively complex:

1. Users initiate withdrawal requests and need to gather 2/3 of the signing weight from the hotValidatorSet.
2. Enter the 200 seconds "dispute period"
3. Two situations may arise during the dispute period:
   • Lockers believe there is an issue and can vote to freeze the contract.
   • coldValidatorSet can invalidate some withdrawal requests
4. After the dispute period ends, the finalizers call the function to finalize the final state and transfer USDC to the user.

cross-chain bridge locking mechanism

• Need 2 lockers to vote to lock the bridge contract
• You can withdraw your vote through the unvoteEmergencyLock function.
• Unlocking requires 2/3 signature weight from coldValidatorSet, and can simultaneously update the validator set.

Validator set update

The updateValidatorSet function updates the hotValidatorSet, requiring signatures from all members, with a 200-second dispute period.

Potential Risks of Cross-Chain Bridges

1. Hackers controlling coldValidatorSet can bypass defenses to steal assets.
2. Finalizers may refuse to confirm withdrawals, leading to review attacks.
3. Lockers may maliciously lock the bridge contract, hindering withdrawals.

HyperEVM and Dual-Chain Architecture

HyperLiquid adopts a dual-chain architecture:

• HyperLiquid L1(L1): Order book dedicated chain, permissioned
• HyperEVM(EVM): permissionless chain, capable of deploying smart contracts

Two chains interact through Precompiles and Events:

• Precompiles: EVM reads L1 state
• Events: EVM writes data to L1

HyperBFT consensus

Based on the improvement of HotStuff, the theoretical processing speed can reach 2 million orders per second.

Developer's Notes

1. msg.sender may be the system contract address rather than the user address.
2. The non-atomicity of EVM and L1 interaction may lead to asset risks.
3. The EVM contract address needs to create a mapping account on L1.
4. Cross-chain assets may temporarily be unable to check the balance.

Overall, HyperEVM is similar to the layer 2 architecture based on HyperLiquid L1, but it offers higher interoperability. Developers need to pay attention to handling various edge cases in cross-chain interactions.