Hyperliquid and the JELLY attack: Context, vulnerability and team solution

Incident Overview

This week, Hyperliquid was the target of a well-executed attack aimed at jeopardizing the solvency of the protocol by exploiting certain limitations in the liquidation mechanisms. First, let's recap the events.

On March 26, 2025, several newly created addresses opened positions on the JELLY token, a memecoin launched on Pump fun and available for trading on Hyperliquid. At the time, the token’s market cap was around $10 million. The three positions were as follows: a $4.5 million short and two long positions of around $2.5 million each (with leverage).

Moments later, the short position turned profitable, and the trader began withdrawing margin gradually, thereby forcing their own liquidation. At that point, Hyperliquid’s liquidation mechanism was triggered, but it failed to execute: there was not enough liquidity in the order book to close the position.

As a result, the position was transferred to the specialized liquidation vault (a module directly tied to the HLP, which we'll discuss shortly) with the aim of closing it as quickly as possible without significantly impacting the price.

However, in parallel with the short position's liquidation, a Solana-based address bought a massive quantity of JELLY on the spot market, driving the token’s price up by about 250%. In just a few minutes, the position now held by the HLP was showing an unrealized loss of roughly $12 million.

To protect the platform's integrity and the user funds in the HLP vault, Hyperliquid had to act quickly: validators unanimously voted to close the position by ignoring the JELLY oracle price (oracle override) and artificially modifying it to erase all HLP debts.

The foundation announced that all traders with long positions would be reimbursed (except wallets involved in the attack, which were flagged by the team) as if their positions had been closed at JELLY’s real market price at the time.

---

How Liquidation Works on Hyperliquid

Now that the context is clear, it’s important to understand how liquidation works on Hyperliquid, what safeguards are in place to prevent this kind of incident, and why they failed to activate.

Liquidator Vault (and HLP)

As with any leverage-enabled platform, when a position on Hyperliquid falls below its maintenance margin, it becomes eligible for liquidation. The protocol relies on an internal system, the Liquidator Vault, to take over the position and unwind it through the order book.

The Liquidator Vault is part of the Hyperliquidity Provider (HLP), a community vault on Hyperliquid designed to automatically execute market-making strategies. Users can deposit USDC to share in potential profits or losses, proportional to their contribution.

The vault’s strategy targets positions that are below two-thirds of their maintenance margin for liquidation. Specifically, it places orders (buy or sell, depending on the situation) on the order book to partially or fully close the position.

Under normal market conditions, this works without issue. But with low-liquidity assets, the risk becomes critical, and a final safety mechanism may be triggered.

Auto-Deleveraging (or ADL)

To reinforce this setup, Hyperliquid has implemented a mechanism called auto-deleveraging (ADL), which acts as a last-resort safety net when handling a liquidation.

ADL operates in a surprisingly simple way. In a severe emergency, where a liquidation poses too much risk to the protocol, ADL can be triggered. It then takes the positions of other traders on the same asset and uses their unrealized gains to offset the losses from the at-risk position.

For example, in the risky liquidation of a short position on token AAA, if ADL is triggered, the module identifies all long positions on AAA and ranks them by unrealized profit. It then closes as many positions as needed (starting with the most profitable) to seize their gains and cover the loss.

In short, ADL is a loss-sharing mechanism to protect the protocol. It’s an intrusive measure: the idea is that, in an emergency, it’s better to make profitable users pay than to drain the HLP, which is funded by users who didn’t want exposure to high-risk positions.

It’s important to note that ADL only activates in extreme cases (it has never been triggered in Hyperliquid’s history), when margin coverage fails, the liquidator can’t absorb the risk without unrecoverable loss, and the protocol’s integrity is at stake.

---

The JELLY Incident

The targeted attack on the JELLY token exposed structural weaknesses in Hyperliquid’s liquidation system. In theory, two mechanisms should have prevented this scenario: the Liquidator Vault (run by the HLP) and auto-deleveraging (ADL). Yet despite the large unrealized loss, ADL never triggered. So why not?

As we explained earlier, the Liquidator Vault failed to execute the liquidation properly. The position was far too large relative to JELLY’s market cap and available order book liquidity.

But why didn’t ADL trigger? First, remember that the Liquidator Vault is a semi-independent entity. It’s part of the HLP but not the only vault, and each has its own segmented trading account.

Next, ADL’s trigger logic is based on a ratio: the risk posed by a liquidation versus the total available collateral in the vault’s account. If the ratio is too high, ADL activates.

And here lies the issue: since the position was transferred to the HLP, the trigger ratio was no longer calculated based on the Liquidator Vault’s holdings but on the total assets across the entire HLP. Therefore, the large unrealized loss did not trigger ADL.

In other words, fund pooling within the HLP prevented ADL from detecting a "critical" loss on just the liquidation strategy, even though the position posed a systemic risk to the protocol. This design, while effective in low-volatility contexts, allowed a risky position to remain open for too long without activating the intended safety mechanism.

Ultimately, this is why the Hyperliquid team had to call a validator vote to execute a preferential-price liquidation of JELLY (based on the pre-manipulation price). The validator quorum was reached in just minutes, with zero dissenting votes, leading to the outcome we now see.

---

Measures Implemented

Following the incident, the Hyperliquid team quickly acknowledged the severity of the situation and announced several corrective actions to prevent a similar scenario from recurring. These measures primarily aim to strengthen liquidation mechanisms, limit the HLP's exposure, and clarify safety thresholds such as the ADL.

Segmentation of the Liquidator Vault and Loss Threshold

The first key decision concerns the Liquidator Vault. From now on, its share in the HLP's global strategy will be strictly limited to a small percentage of the vault’s total value. Moreover, this share will be re-evaluated less frequently to avoid it representing a disproportionately large part of the vault, as seen during the JELLY attack.

This measure aims to limit the vault’s maximum exposure in case of a complex or poorly executed liquidation.

In parallel, a specific trigger threshold has been introduced for the ADL: if losses from the Liquidator Vault exceed a certain level, the auto-deleveraging will now be activated, independently of other strategies within the HLP. In other words, the ADL’s trigger no longer depends on the overall pooled balance, but rather on the liquidator’s specific account.

This is a logical fix. The JELLY incident showed that under specific conditions, the ADL trigger could be bypassed — something that (theoretically) should no longer happen.

Dynamic Adjustment of Maximum Open Interest

One of the issues in the JELLY incident was the opening of an oversized position ($4.5 million) on a token with very low capitalization ($9 million). Yet, the Open Interest Cap (OI cap) formula, designed to limit total position size on an asset, deemed the trader’s position acceptable.

The Hyperliquid team acknowledged a weakness in this evaluation mechanism. The OI cap formula will now be improved to directly account for an asset’s real market capitalization and order book depth.

This measure aims to prevent massive positions from being opened on illiquid or low-cap assets, reducing vectors for similar attacks.

Governance and Delisting Mechanism

To strengthen the protocol’s long-term resilience, validators will now have the ability to vote on-chain to delist an asset that falls below certain critical thresholds (e.g., volatility, suspected manipulation, lack of volume or market making).

This measure offers an additional lever to react to abnormal behavior around an asset and, most importantly, to prevent dangerous assets from remaining listed on the platform.

---

Conclusion and Opinion

The JELLY incident exposed significant technical vulnerabilities in Hyperliquid’s design that could have led to the protocol’s collapse. It revealed how the structural architecture could be exploited and introduced doubt among users, who now fear it could happen again.

However, it would be unfair to claim this episode completely discredits Hyperliquid. First, it's important to recall that the attack was intentional, premeditated, and expertly executed — likely by a group of experienced traders. The team’s rapid response (enabled by a small validator set) prevented a catastrophic outcome.

Second, the team’s response deserves praise. Not only were the flaws publicly acknowledged, but concrete measures were rolled out at record speed to address the identified issues.

Contrary to what some may claim, the decision to force the JELLY price for a preferential exit benefited users: all traders with long positions on JELLY were refunded as if their positions had been closed at the real market price, with only a few wallets flagged for involvement in the attack being excluded.

This bold decision also illustrates an important point some pretend to discover today: yes, Hyperliquid is still partially centralized. Yes, emergency decisions can be made by a small group of validators. But this has never been hidden. Since its inception, the team has consistently framed this as a transitional phase — one that enables rapid iteration on a complex product before moving toward a more open architecture.

Hyperliquid is still a young and evolving protocol, quickly propelled into the spotlight. Problems are common for such projects, often victims of their own success. This episode will obviously serve as a lesson, as it exposed the limits and vulnerabilities of a model — fortunately without causing any actual damage.