Hyperliquid
Badges
About
Hyperliquid is a performant exchange on Arbitrum, utilizing a custom consensus algorithm called HyperBFT.
Badges
About
Hyperliquid is a performant exchange on Arbitrum, utilizing a custom consensus algorithm called HyperBFT.
Why is the project listed in others?
Consequence: projects without a proper proof system fully rely on single entities to safely update the state. A malicious proposer can finalize an invalid state, which can cause loss of funds.
Consequence: projects without a sufficiently decentralized data availability committee rely on few entities to safely attest data availability on Ethereum. A small set of entities can collude with the proposer to finalize an unavailable state, which can cause loss of funds.
Learn more about the recategorisation here.
Arbitrum OneFunds can be stolen if
Funds can be frozen if
MEV can be extracted if
| SEQUENCER FAILURE | STATE VALIDATION | DATA AVAILABILITY | EXIT WINDOW | PROPOSER FAILURE | |
| Arbitrum One L2 | Self sequence | Fraud proofs (INT) | Onchain | 7d | Self propose |
| Hyperliquid L3 • Individual | No mechanism | None | External | None | Cannot withdraw |
| Hyperliquid L3 • Combined | No mechanism | None | External | None | Cannot withdraw |
Sequencer failure
No mechanismThere is no mechanism to have transactions be included if the sequencer is down or censoring.
State validation
NoneCurrently the system permits invalid state roots. More details in project overview.
Data availability
ExternalProof construction and state derivation rely fully on data that is NOT published onchain.
Exit window
NoneThere is no window for users to exit in case of an unwanted regular upgrade since contracts are instantly upgradable.
Proposer failure
Cannot withdrawOnly the whitelisted proposers can publish state roots on L1, so in the event of failure the withdrawals are frozen.
Arbitrum OneThe system has a centralized operator
Hyperliquid is composed of two sets of permissioned validators, one being a “hot” validator set, and the other being a cold one. The hot validator set is responsible for initiating withdrawals upon user requests, while cold validators are responsible for vetoing them and rotate the hot set in case of failure. Both sets are currently composed of 4 validators with equal power. The system accepts a request if signed by 2/3+1 of validators power. A different set of permissioned actors (lockers) can pause the bridge in case of ermengecies, while finalizers are responsible to finalize withdrawals and validator set updates.
MEV can be extracted if the operator exploits their centralized position and frontruns user transactions.
Funds can be stolen if the permissioned validator majority sign an invalid withdrawal request (CRITICAL).
Funds can be frozen if the permissioned validator set stops processing withdrawals (CRITICAL).
Funds can be frozen if the permissioned lockers maliciously pause the bridge.
Funds can be stolen if the permissioned finalizers don't finalize withdrawals.
The system uses the following set of permissioned addresses:
Permissioned actors responsible for initiating withdrawals upon user requests. They can also update the challenge period, both hot and cold validator sets with a delay, and add or remove lockers and finalizers. The system accepts a request if signed by 2/3+1 of validators power. Currently all validators have equal power.
Permissioned actors responsible for vetoing withdrawals and validator set rotations initiated by hot validators within 3m 20s. They can also update the block time, change the lockers threshold, and rotate the hot validator set in case of a failure, and its own set. The system accepts a request if signed by 2/3+1 of validators power. Currently all validators have equal power.
Permissioned actors responsible for pausing the bridge in case of an emergency. The current threshold to activate a pause is 2.
Permissioned actors responsible for finalizing withdrawals and validator set updates.
