0xDala

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.

There's been a lot of discussion on Hyperliquid's margin design. I’ll address some flaws in the common arguments and explain Hyperliquid's first-principles based approach to improving the system. To my knowledge, this is the first such design in margining systems. Perhaps other teams will find it useful for their own logic. Like good theories in physics, the best margining design is simple, canonical, explainable, and works in a wide variety of pathological scenarios. 1. The conclusion of some people has been that there needs to be a centralized force that detects and limits malicious behavior. This completely violates the purpose of defi and everything Hyperliquid stands for. This forces users back to a web2 world where the platform has the final say. True decentralized finance is worth it, even if it is 10x harder to build. Just a few years ago, no one believed DEX/CEX volumes would reach its ratio today. Hyperliquid is leading the charge here and has no intention to stop. 2. Some assume that copying approaches from CEXs will work in defi. The most common suggestion I've seen is per-address margin requirement fraction scaling with position size, as CEXs only offer higher leverage for smaller positions. However, this doesn't work to prevent manipulation attempts on a DEX because a sophisticated attacker can easily open positions on many accounts. Nonetheless, this will help somewhat reduce the impact of "organic whale" positions and is on the list of features to implement. 3. Another suggestion is to implement some features that severely limit usability of the platform in exchange for safety. For example, if unrealized pnl is not withdrawable, many attacks are not possible. Indeed, Hyperliquid pioneered isolated-only perps for illiquid assets which feature this safety mechanism. However, this change would have a crippling effect on funding arbitrage strategies, where unrealized pnl from Hyperliquid needs to be withdrawn to offset the loss on other venues. Real user needs are a top priority in system design. 4. There were also suggestions to innovate on design by having margin settings based on global parameters. However, liquidation prices need to be deterministic functions of price and position size. If global parameters such as open interest were added as inputs to margin requirements, users would lose confidence in the ability to use leverage at all. So what's the answer? We all want defi, but a permissionless system must be robust to manipulation at all scales. The answer lies in understanding the true problem with large positions: they are difficult to mark. The first order approximation of mark price times size breaks down when market impact approaches maintenance margin. It's impossible to accurately simulate market impact because book liquidity is a path-dependent function of time and actions of other participants. Without simulating market impact, it can be possible for liquidation to be a low-slippage way to exit at a price that is unfavorable to the liquidator. Therefore, Hyperliquid's margining system update has the following desirable property: any liquidated position is either a loss relative to entry price, or at least a (20% - 2 * maintenance_margin_ratio / 3) = 18.3% loss relative to the last margin transfer out (using an example of 20x leverage). An organic 20x user who makes 100% return on equity after a 5% move will still be able to withdraw the majority of the pnl without closing the position. However, by introducing separate margin requirements between transfers and opening new positions, profitable manipulation attempts require moving the mark price almost 20%. This kind of attack is infeasible from a capital perspective. Finally, I'd like to point out that the mark price problem also solves itself as market makers continue scaling up on Hyperliquid. It's quite possible that the trader yesterday could have lost money in aggregate. $1.8M pnl longing on Hyperliquid could have been more than offset when pushing the price on other venues, or using other accounts on Hyperliquid. HLP took over an undesirable position, losing $4M. The only market participants who definitely made money in aggregate are the market makers. With millions of dollars of pnl to be made in the span of minutes, it's becoming clear to sophisticated participants that Hyperliquid is one of the venues with the best flow. As liquidity improves, it will become more and more expensive to dislodge prices. So while the margining system improvements will go a long way, the allure of easy pnl attracting market makers will provide an independent source of robustness over time. The future is decentralized. Hyperliquid.

Hyperliquid = HyperCore + HyperEVM. One piece of user feedback since HyperEVM’s alpha launch was to more intuitively communicate how the HyperEVM fits into the larger context of Hyperliquid. To this effect, the native pieces of the Hyperliquid execution state have been organized under one umbrella term: HyperCore. HyperCore consists of performant native components: order book perp and spot DEX, staking, oracles, multi-sig, etc. HyperEVM is a general purpose world-computer, allowing builders to deploy code that interacts with both HyperEVM and HyperCore. Together, they form one global, composable state on Hyperliquid, secured by the state-of-the-art HyperBFT consensus algorithm. Importantly, any interaction across the Core/EVM boundary is part of execution itself. There is one unified state, with no need for bridging, proofs, or trusted signers. HyperEVM offers builders a familiar interface to plug into the most powerful permissionless financial system in crypto. Let's walk through some concrete examples. A project XYZ deploys an ERC20 contract on the HyperEVM using standard EVM tooling. They deploy a corresponding spot asset XYZ permissionlessly in the HyperCore ticker auction. Once the XYZ HyperCore token and HyperEVM contract are linked, users can seamlessly transfer their XYZ balance to HyperCore for order book trading. Two key improvements compared to CEX listings: 1) The entire process is permissionless. No behind-the-scenes negotiations for preferential treatment. Hyperliquid is a neutral platform for finance. 2) There is no bridging risk between HyperCore and HyperEVM. On the other hand, CEXs need to manage deposits and withdrawals through wallets that could be hacked. HyperCore and HyperEVM are one unified state. Trading and building on the same chain is a 10x product improvement over CEXs. Let's go further. A lending protocol sets up a pool contract that accepts XYZ as collateral and lends out another token ABC to the borrower. To determine the liquidation threshold, the lending smart contract can read XYZ/ABC prices directly from the HyperCore order books using a "read precompile." For a Solidity developer, this is as simple as calling a built-in function. Suppose the borrower's position requires liquidation. The lending smart contract can send orders directly swapping XYZ and ABC on the HyperCore order books using a "write precompile." Again, this is a simple built-in function in Solidity. In a few lines of code, the lending protocol has implemented protocolized liquidations similar to how perps function on HyperCore. A theme of the HyperEVM is to abstract away the deep liquidity on HyperCore as a building block for arbitrary user applications. As these interactions become available on mainnet HyperEVM, I look forward to seeing the innovative ways that builders leverage these primitives to reinvent finance. These examples only scratch the surface of what is possible. Hyperliquid.

Execution Extremely proud of the community and team for the smooth launch of the HyperEVM. The upgrade happened amidst billions of dollars of daily volume, where the majority of defi derivatives trade. There was no downtime, and no performance degradation after the launch. The UX of trading is still so seamless that many users assume the HyperEVM is a separate chain! To be clear: the HyperEVM and the existing native Hyperliquid financial system are one composable state. The safest way to upgrade this uniquely complex system is a gradual rollout. Precompiles and other L1 interactions will build upon the sturdy foundation of the initial HyperEVM release. This will unlock an entirely new class of performant defi applications, but more on that later. Right now I want to focus on the execution of the launch. A bug in HyperEVM logic or an unoptimized code path would've crippled the entire blockchain, affecting hundreds of thousands of users and billions in open interest. This was a massively challenging launch: a jet's engine was flawlessly changed mid-flight. -- Philosophy The HyperEVM launch stayed true to Hyperliquid’s “no insiders” principle. Hyperliquid has always embodied the original ethos of crypto: no investors, no paid market makers, no fees going to any company. The HyperEVM launch is yet another example that integrity and fairness are the pillars of Hyperliquid. The tradeoff of a fair launch is that things are a bit messy to start. Tooling might not be there from day one. Builders need to familiarize themselves with the tech. But these short term obstacles are nothing compared to the long term value of fairness. No one had a head start or unfair advantages. I’m impressed that some teams deployed dapps, tooling, and analytics within hours of the HyperEVM release, a testament to the strength of the builders and community. Hyperliquid will eventually be the credibly neutral infrastructure that houses all of finance. Looking back, the L1 launch, HYPE genesis, and HyperEVM launch will all be important milestones. Success is path dependent, and there can be no blemishes on the fair trajectory towards the final state. The HyperEVM is a clean slate. The community is hungry for quality applications. Where else in the world is there such an imbalance between supply and demand for applications built? Fast, general purpose chains are nothing new. But on Hyperliquid, builders can plug into a mature, liquid, and performant onchain economy with real users. I've noticed a pattern that builders, traders, and communities who "make it" on Hyperliquid are those who call Hyperliquid home. Legacy players don't win just because of their credentials. Newcomers have equal opportunity to win by challenging the status quo and seizing the opportunities. There are empires to be built on the HyperEVM, and the community welcomes builders with open arms. Hyperliquid