When Loyal Messengers Become Weapons: Mark Price Triggers Hyperliquid Liquidation Storm

In March 2025, a little-known token JELLY, with a daily trading volume of less than 2 million USD, triggered a multi-million dollar liquidation storm on a certain trading platform. Shockingly, the attacker neither tampered with the smart contract nor exploited traditional code vulnerabilities, but instead turned the platform's most critical security mechanism — mark price — into a weapon.

This is not a hacking attack, but a "compliance attack" on the system rules. The attackers exploited the platform's publicly available computing logic, algorithm processes, and risk control mechanisms to create a "no-code attack" that was extremely damaging to both the market and traders. The mark price, which should serve as the anchor of "neutrality and safety" in the market, turned from a shield into a sharp blade in this incident.

This article will conduct an in-depth analysis of the systemic risks of the mark price mechanism in the perpetual contract market for altcoins from both theoretical and practical perspectives, and will provide a detailed review of the Jelly-My-Jelly attack event. This incident not only reveals the structural vulnerabilities in oracle design and the double-edged sword nature of innovative liquidity pools, but also exposes the inherent asymmetry in the current mainstream liquidation logic regarding user fund protection during extreme market conditions.

The Core Paradox of Perpetual Contracts: The Imbalance of Liquidation Mechanisms Caused by False Security

mark price: A clearing tendency brought by a consensus game mistakenly thought to be safe.

To understand how the mark price becomes an entry point for attacks, one must first break down its compositional logic. Although the calculation methods vary slightly among exchanges, the core principle is highly consistent - a three-value median mechanism built around the "index price".

The index price is the cornerstone of the mark price. It is not derived from the derivatives exchange itself, but is calculated through a weighted average of the prices of the asset across multiple mainstream spot platforms, aiming to provide a fair reference price across platforms and regions.

A typical mark price calculation method is as follows:

Mark Price = Median (Price1, Price2, Last Traded Price)

• Price1 = Index Price × (1 + Funding Rate Basis ): Anchors the contract price to the index price and considers market expectations.

• Price2 = Index Price + Moving Average Basis: used to smooth short-term price anomalies.

• Last Traded Price = The latest transaction price on the derivatives platform.

The introduction of the median is intended to eliminate outliers and enhance price stability. However, the safety of this design is entirely based on a key assumption: that the number of input data sources is sufficient, the distribution is reasonable, liquidity is strong, and it is difficult to be manipulated in coordination.

However, in reality, the spot market for the vast majority of altcoins is extremely weak. Once an attacker is able to control the prices of a few low liquidity platforms, they can "pollute" the index price, thereby injecting malicious data into the mark price through the formula legally. This type of attack can trigger large-scale leverage liquidations at minimal cost, causing a chain reaction.

In other words, the aggregation mechanism is originally intended to disperse risk, but in a market with sparse liquidity, it instead creates a "centralized weakness" that can be controlled by attackers. The more a derivatives platform emphasizes the transparency and predictability of its rules, the more attackers can "programmatically exploit the rules" to construct a compliant path for destruction.

Clearing Engine: The shield of the platform, also a blade

When the market price fluctuates rapidly in an unfavorable direction, the trader's margin will be eroded by unrealized losses. Once the remaining margin falls below the "maintenance margin rate", the liquidation engine will be activated.

In these processes, the core triggering criterion is the mark price, rather than the platform's own latest transaction price. This means that even if the current market transaction price has not yet reached your liquidation line, as long as that "invisible" mark price has been reached, liquidation will be triggered immediately.

What is even more concerning is the "forced liquidation" mechanism.

In many exchanges, in order to avoid liquidation risk, risk control systems often adopt relatively conservative liquidation parameters. After a forced liquidation is triggered, even if the closing price is better than the actual price that would bring losses to zero, the platform usually does not return this "forced liquidation surplus", but directly injects it into the platform's insurance fund. This leads traders to have the illusion that "there is still margin, yet they are liquidated early", resulting in their account going directly to zero.

This mechanism is particularly common in assets with low liquidity. To hedge their own risks, platforms will set the liquidation line more conservatively, making it easier for positions to be "liquidated early" amid price fluctuations. The logic is sound, but the result creates a subtle misalignment of interests between the platform and traders in extreme market conditions.

The liquidation engine should be a neutral risk control tool, but in terms of profit attribution, parameter selection, and trigger logic, it tends to favor platform profitability.

The failure of the mark price leads to the distortion of the liquidation engine.

Under the platform's aversion to loss, the severe fluctuations in index price and mark price further exacerbate the forced liquidation line's shift before ( and after ).

The theory of mark price provides a fair, manipulation-resistant price benchmark by aggregating multi-source data and using median algorithms. However, this theory may hold when applied to mainstream assets with ample liquidity, but its effectiveness will face severe challenges when dealing with thinly traded altcoins in centralized exchanges.

The Failure of the Median: The Statistical Dilemma of Data Source Concentration

• Effectiveness in large datasets: Assume a price index contains 10 independent, highly liquid data sources. If one of the data sources presents an extreme quote for any reason, the median algorithm can easily identify it as an outlier and disregard it, taking the middle value as the final price, thereby maintaining the stability of the index.

• Vulnerabilities in small datasets: Now, we consider a typical altcoin scenario.

• Three data source scenario: If a cryptocurrency's mark price index only includes the spot prices from three exchanges (A, B, C). At this time, the median is the one in the middle of the three prices. If a malicious actor simultaneously manipulates the prices of two of the exchanges (, for example A and B), then no matter how accurate the price of C is, the median will be determined by the manipulated prices of A and B. At this point, the protective effect of the median algorithm is almost zero.

• Dual Data Source Scenario: If the index only includes two data sources, the median is mathematically equivalent to the average of the two prices. In this case, the algorithm completely loses its ability to exclude outliers. Any significant fluctuation from either data source will be directly and unattenuatedly transmitted to the mark price.

For the vast majority of altcoins, their trading depth and the number of listed exchanges are very limited, which makes their price indices easily fall into the aforementioned "small data set" trap. Therefore, the sense of security brought by the exchange's claim of a "multi-source index" is often just an illusion in the world of altcoins. Many times, the latest transaction price often equates to the mark price.

The Oracle Dilemma: When Spot Liquidity Dries Up as a Weapon

The foundation of the mark price is the index price, and the source of the index price is the oracle. Whether it is a CEX or DEX, the oracle serves as a bridge for information transmission between on-chain and off-chain. However, this bridge, although critical, is exceptionally fragile during times of liquidity scarcity.

Oracle: A fragile bridge connecting on-chain and off-chain

A blockchain system is essentially closed and deterministic, and smart contracts cannot actively access off-chain data, such as the market price of assets. Price oracles have emerged as a middleware system responsible for securely and reliably transmitting off-chain data to on-chain, providing "real-world" information inputs for the operation of smart contracts.

In perpetual contract trading platforms or lending protocols and other core DeFi infrastructure, the price data provided by oracles almost constitutes the cornerstone of their risk management logic. However, one often overlooked fact is that an "honest" oracle does not mean that it reports a "reasonable" price. The responsibility of an oracle is merely to accurately record the state of the external world as it can observe; it does not judge whether the price deviates from fundamentals. This characteristic reveals two distinctly different attack paths:

• Oracle Attack: Attackers manipulate the data source or protocol of the oracle through technical means, causing it to report incorrect prices.

• Market Manipulation: Attackers deliberately drive up or down prices by manipulating external markets, while properly functioning oracles accurately record and report this "manipulated" market price. The on-chain protocol has not been hacked, but it produces unintended reactions due to "information poisoning."

The latter is the essence of the Mango Markets and Jelly-My-Jelly incidents: it is not that the oracle was compromised, but rather that its "observation window" was contaminated.

Attack Pivot: When Liquidity Deficiency Becomes a Weapon

The core of this type of attack lies in exploiting the liquidity disadvantage of the target asset in the spot market. For assets with thin trading, even small orders can cause significant price fluctuations, providing an opportunity for manipulators.

The attack on a certain trading platform in October 2022 can be described as a "model" case. The attacker took advantage of the extreme liquidity exhaustion of its governance token (, with a daily trading volume of less than $100,000 ) at the time, by concentrating an investment of about $4 million across multiple exchanges to successfully inflate the token price by over 2300% in a very short period. This "abnormal price" was fully recorded by the oracle and fed to the on-chain protocol, causing its borrowing limit to skyrocket, ultimately "legitimately" draining the platform's entire assets ( of approximately $116 million ).

Attack Path Analysis: Five Steps to Breach the Protocol Defense

1. Target Selection: The attacker first filters the target tokens, which usually meet the following conditions: they have perpetual contracts listed on a certain mainstream derivatives platform; the oracle price comes from several known, illiquid spot exchanges; daily trading volume is low, the order book is sparse, and it is easy to manipulate.

2. Capital raising: Most attackers obtain temporary large funds through "flash loans". This mechanism allows borrowing and repaying assets in a single transaction without any collateral, significantly reducing the cost of manipulation.

3. Spot Market Flash Attack: Attackers rapidly place a large number of buy orders simultaneously across all exchanges monitored by the oracle within a very short time. These orders quickly clear the sell orders, pushing the price to a high level—far deviating from its true value.

4. Oracle Pollution: Oracles faithfully read prices from the aforementioned manipulated exchanges. Even with mechanisms such as median and weighted average to resist volatility, it is difficult to withstand simultaneous multi-source manipulation. The final index price is severely polluted.

5. Mark Price Infection: Contaminated index prices enter the derivatives platform, affecting the calculation of mark prices. The liquidation engine misjudges the risk interval, triggering large-scale "liquidations", resulting in significant losses for traders, while attackers can achieve arbitrage through reverse positions or lending operations.

The Attacker's "Playbook": The Double-Edged Sword of Transparency

Whether it is a CEX or DEX protocol, it often takes "open source transparency" as a virtue, publicly disclosing details such as its oracle mechanism, data source weights, and price refresh frequency, aiming to establish user trust. However, for attackers, this information becomes a "manual" for formulating attack plans.

Taking a certain trading platform as an example, its oracle architecture publicly lists all data source exchanges and their weights. Attackers can accurately calculate how much capital to invest in each of the weakest liquidity exchanges, thereby maximizing the distortion of the final weighted index. This kind of "algorithm engineering" makes attacks controllable, predictable, and minimizes costs.

Mathematics is simple, but people are complex.

Hunting Ground: An Analysis of Structural Risks of a Certain Trading Platform

After understanding the attack principles, the "attacker" next needs to select a suitable "battlefield"—a certain trading platform. Although manipulating the oracle is a common attack method, the reason why the "Jelly-My-Jelly" incident was able to occur on this platform and cause serious consequences lies fundamentally in the platform's unique liquidity architecture and settlement mechanism. These designs, aimed at enhancing user experience and capital efficiency, while innovative, unexpectedly provided attackers with a certain advantage.