EVikkk

Debunking Hyperliquid FUD (Part 1: HLP, liquidations, and platform guarantees) It's sad to see coordinated misinformation campaigns targeting Hyperliquid, which have led to widespread misunderstanding of what we are all working so hard to build. In response, this series of posts provides detailed, factual explanations of how Hyperliquid works. As a community, we must actively fight FUD by spreading the truth. The tone with which we do this also matters: the best way to grow as a protocol and ultimately house all finance is to remain humble and welcome more users into the ecosystem. -- The first post focuses on HLP and liquidations on Hyperliquid. High level summary The FUD is that the Hyperliquid protocol is subject to large losses stemming from manipulation. On the contrary, Hyperliquid's margining design mathematically guarantees platform solvency. Note that HLP’s losses are isolated to the vault itself, and Hyperliquid does not depend on HLP’s operation to exist. This was true even before the JELLY incident. After the JELLY incident, there is an additional change to protect HLP from losses during backstop liquidations. The fundamental changes are to HLP, not the platform itself. HLP background HLP is a permissionless protocol vault pioneered by Hyperliquid. HLP does not collect fees from depositors, and historically has returned 60M USDC in pnl to its depositors. On CEXs, this profit typically goes to the internal market making desks instead of users. HLP plays two roles: market making and backstop liquidations. In terms of market making, HLP runs a passive strategy that accounts for less than 2% of Hyperliquid's total volume. The vast majority of volume on Hyperliquid is between two non-HLP users. Liquidations On Hyperliquid, liquidations are first sent to the book as a market order. This allows any user to participate in providing liquidity to liquidations, which is profitable flow on average. On other exchanges, this flow is internalized by the exchange as a revenue source. HLP only performs backstop liquidations, which involves taking over positions that are unable to be market liquidated. When account values go negative, the last resort for platform solvency is auto-deleveraging (ADL). ADL closes underwater positions against the most profitable and highly leveraged positions on the other side, ensuring the protocol's solvency. ADL is extremely rare but importantly targets the attacker's position on both sides during manipulation attempts as described below. JELLY incident An attacker recently attempted to exploit HLP by opening a large long and short against themself. Open interest caps allowed a position worth 4M USDC at the time of trade, but the logical issue was that HLP collateralized the liquidation with its full balance. It is false that the platform itself had solvency risks, but HLP was indeed overexposed to the manipulation. Changes made Now the liquidator component vault of HLP has capped collateral, limiting its potential loss by backstop liquidations. A historical analysis was conducted based on this new system. Apart from the JELLY incident, this change would not have caused additional ADLs in the past, even during extreme volatility. However, it would have minimized HLP’s losses during the JELLY incident to low six figures, which is far less than the attacker spent on market manipulation. In particular, ADL would have closed the attacker’s momentarily profitable long position, leaving other JELLY positions untouched. Validators now actively discuss delistings in an open governance forum on Discord. Several interesting dashboards have been created by users and validators: stalequant.github.io/hyperli…, data.asxn.xyz/dashboard/hl-r…. Market cap of the underlying spot assets will likely be an important input into delisting considerations. While delistings are important to ensure that users on the platform do not suffer from potential price manipulation, they are not required for platform solvency. New state of margining system and HLP Hyperliquid still functions as before, handling under-collateralized positions in the order of 1) market liquidations 2) backstop liquidations 3) ADL. Backstop liquidations on HLP now have additional protections to cap the total losses, making mark price manipulation attacks more expensive than the limited available gain from HLP. HLP's role continues to shrink as Hyperliquid grows, and at this point is nonessential to the protocol's operation. HLP still exists as a source of protocol yield through backstop liquidations and providing consistent background liquidity.

The Hyperliquid L1 will be transitioning to HyperBFT, a custom consensus algorithm written from the ground up. The implementation is in final stages of testing on testnet. The mainnet migration is expected to happen in the coming weeks. The Hyperliquid L1 is one of a few chains in production with real demand above 20k TPS. With a scope expanding far beyond perps trading (more on that later), it is crucial to optimize the foundational consensus algorithm. Like most modern consensus algorithms, HyperBFT is based on Hotstuff and subsequent improvements. Huge thanks to the researchers who continue to push the boundaries of what is possible on a decentralized state machine. Some properites of HyperBFT: 1) TPS will be massively improved. The current bottleneck for the Hyperliquid L1 is Tendermint, which caps out at 20k orders/second. HyperBFT can support up to 100x the throughput, though in practice the state machine execution will be a bottleneck at around 200k orders/second. 2) Consensus does not block on execution. Unlike Ethereum and Tendermint, the consensus algorithm can continue sequencing transactions without waiting for the hash of the current block being executed. 3) Confirmation latency will improve and stabilize, with block times bounded only by the network delay. Unlike earlier BFT algorithms such as Tendermint, there is no synchronous timescale baked into the consensus algorithm itself under normal block production. Blocks are produced as quickly as a quorum of validators can communicate. This property is sometimes called "optimistic responsiveness." The mainnet rollout will be incremental, focusing first on stability at performance parity with the current L1 before cranking up throughput.