The HIP-3 Trap: How Hyperliquid’s Permissionless Perpetuals Became a Centralization Vector

RayFox Special

Mark price divergence of 37% in under 120 seconds. Liquidations cascading across the SKHYNIX perpetual market on Hyperliquid. The cause was not a flash loan, not a rogue bot, but the protocol itself—a feature codified as HIP-3 that grants market deployers unilateral control over a critical pricing component.

In a bear market where liquidity is a dwindling resource, such mechanical failures are not anomalies. They are systemic warnings. When capital is scarce, trust in infrastructure becomes the only collateral. And trust is not granted by rhetoric; it is compiled by code.

The Context: Permissionless Markets, Centralised Pain

Hyperliquid is a Layer 1 blockchain built specifically for perpetual futures. Unlike general-purpose L1s, its core value proposition is speed and vertical integration—the chain itself runs the matching engine, and markets are deployed by independent teams via an open permissionless system. Any group can create a market by deploying a “market contract” that defines the parameters, including the mark price mechanism.

This is where HIP-3 enters. The Hyperliquid Improvement Proposal 3 defined the mark price for perpetuals as the median of three components: - Component A: a price pushed by the market deployer (the “deployer oracle price”) - Component B: another price pushed by the market deployer (the “external perpetual price”) - Component C: the chain median price (derived from on-chain order book data)

The final mark price is then median(A, B, C). On paper, this appears balanced—the deployer pushes two values, the chain generates one independently. But the arithmetic is ruthless: if the deployer pushes both A and B to the same value, and that value diverges from C, the median becomes the deployer’s value. The chain’s independent price is reduced to an outlier.

On the SKHYNIX market, deployed by a team called Trade.xyz, this is exactly what happened. According to on-chain data, the deployer’s pushed prices shifted to a level that deviated from the chain median by over 30%. The mark price followed. Liquidations were triggered. Positions were wiped. The anomaly was detected, and Hyperliquid’s team responded with a now-familiar phrase: “It may be necessary to review this mechanism.”

The Core: Why HIP-3 Is a Structural Failure

I have spent the past four years staring at liquidity design failure. In 2020, I audited Uniswap V2’s yield farming mechanics and calculated that 40% of LPs would suffer impermanent loss within six months—a forecast that earned me limited gratitude but confirmed my approach: treat every incentive as a probability distribution, not a promise.

HIP-3 triggers the same pattern. It does not require malice. It requires only a deployer who misconfigures their price feed, or a bug in their off-chain logic, or a moment of inattention during high volatility. The median-of-three formula then amplifies that error into a systemic event.

The Mathematics of Control

Let me be explicit. Let: - C = chain median price = 100 - D1 = deployer push A = 150 - D2 = deployer push B = 150

Final mark price = median(100, 150, 150) = 150.

The deployer’s two values dominate. A single deployer effectively holds two votes against the chain’s one. This is not a flaw; it is the design. HIP-3 intentionally gave deployers this weight, presumably to allow them to react faster than the chain’s median during fast markets. But the asymmetry is extreme.

Compare this to dYdX, which uses a set of independent oracle providers (Chainlink, Pyth, etc.) and takes a weighted median across multiple independent sources. No single actor can push multiple values. Or compare to GMX, which uses the oracle price from Chainlink adjusted by the GLP pool’s own trading activity—a system where no central party controls the mark.

Hyperliquid’s approach is closer to a market maker agreement than a decentralised price feed. It treats the deployer as a trusted price provider, and the median operation as a fallback for sanity checks. In practice, the fallback is irrelevant when the deployer coordinates their two outputs.

The Trust Assumption Is a Bug

The official documentation for HIP-3 states that deployers “can choose to operate their price feeds similarly to validators.” That is the core vulnerability. “Can choose” is not a constraint. In a permissionless environment, there is no guarantee that every deployer will run multiple independent feeds, or even honest feeds. The protocol should enforce decentralisation, not request it.

This is where my experience from the 2022 Terra collapse comes in. The anchor protocol’s stablecoin model also relied on voluntary market participation to maintain the peg—a structural fragility that became catastrophic when macroeconomic stress hit. Hyperliquid’s HIP-3 replicates the same mistake: it places a critical function in the hands of a single actor and hopes that actor behaves. Code should enforce; policy dictates. HIP-3 had no such enforcement.

The Real Risk: Not a Bug, but a Feature

What makes HIP-3 dangerous is not the anomaly itself. It is that the mechanism allows deployers to extract value through mark price manipulation. A sophisticated deployer could, on purpose, push prices to trigger liquidations of large positions, then profit from the resulting price movement. This is not theoretical—it is a viable MEV extraction strategy inherent in the design.

Let’s build the scenario: A deployer sees a large long position sitting on their market. They push the deployer prices down, the mark price falls, the position is liquidated. The deployer then buys the collateral at a discount. The profit is the difference between the forced liquidation price and the eventual market recovery. The chain median might read 100, but the deployer’s two pushes of 70 give a final mark of 70. The position is wiped. The deployer gains. The chain’s median is a ghost.

This is not hypothetical. The SKHYNIX anomaly has all the hallmarks of such an event—whether intentional or accidental remains to be seen. But the mechanism enables it. And in a permissionless system where anyone can deploy a market, the incentives for such behaviour are present.

Macro Trends Crush Micro-Protocols

In a bear market, liquidity is thin. Capital is risk-averse. Any protocol that introduces a centralised fragility will see outflows faster than in a bull market. The “macro” context here is not just central bank policy; it is the availability of risk capital. When asset prices are falling, users scrutinise every piece of infrastructure. A single liquidations scandal can kill a chain’s liquidity pool forever.

Hyperliquid’s total value locked (TVL) and trading volume will now be under pressure. Funds that were evaluating deployment will pause. Existing LPs may withdraw. The network effect—traders go where liquidity is—will amplify the damage. The macro trend of capital contraction will crush this micro-protocol if the HIP-3 flaw is not addressed swiftly.

The Contrarian Angle: Permissionless Deployer Is the New Oracle

Most analysis of Hyperliquid focuses on its validator set or its consensus speed. The community often asks: “Is the chain decentralised enough?” The answer almost always revolves around the number of validators and the distribution of tokens. But that view misses the application layer entirely. A chain can have 100 validators and still be centralised if the applications running on it embed a single point of failure.

HIP-3 inverts the usual narrative. We worry about centralised oracles like Chainlink, but here the oracle is the deployer—a completely unverified entity. In some ways, it is worse: at least Chainlink is an open, audited network with multiple nodes. Here, the deployer is a single team operating their own price feed, possibly also running the trading bots on the same market. The conflict of interest is structural.

The contrarian take? Hyperliquid is not a decentralised perpetual exchange; it is a platform for independent, centralised market makers to run their own casinos. The chain provides settlement and speed, but the pricing—the heart of any trading venue—is outsourced to a party with every incentive to manipulate it.

Regulators will take note. In traditional finance, a market where the exchange operator can influence execution prices is called a “market maker conflict of interest.” It is heavily regulated. The crypto industry often dismisses such concerns as legacy FUD, but HIP-3 is a clear example of how the technology can replicate the exact same conflicts—just under the banner of “permissionless innovation.”

The Depth of the Problem

The analysis provided by the macro watcher community reveals a risk matrix where three categories are rated “high”: technology risk, operational risk, and narrative risk. I agree. But I would add one more: liquidity risk. If deployers cannot be trusted, liquidity providers will demand higher fees or exit entirely. The bear market accelerates this because alternative venues like dYdX and GMX have proven track records of market neutrality.

From my 2023 work on the Warsaw CBDC pilot, I learned that any system that requires trust in a counterparty for a core function is not scalable to institutional adoption. Institutions will not trade on a platform where a single deployer can move the mark price by 30%. They will demand independent, immutable price feeds. HIP-3 fails that test completely.

What Needs to Happen Next

Hyperliquid must act. The official statement—“it may be necessary to review this mechanism”—is insufficient. What is required is a concrete proposal, likely HIP-4, that changes the mark price calculation to remove one of the deployer’s pushes, or to force the deployer to use a public, audited oracle feed that cannot be controlled by the same party.

Options: 1. Require that the deployer’s two prices be from different independent sources, with proof of origin (e.g., signed by separate oracles). 2. Reduce the deployer’s contribution to a single component, so the median reverts to a 2-of-3 vote where the chain has at least equal weight. 3. Use a weighted average where the chain median has a higher weight (e.g., 2x) to prevent outlier domination. 4. Remove the deployer’s price push entirely and rely on a decentralised oracle network for all components.

The fourth option is the most secure but reduces the speed advantage that Hyperliquid touts. However, in a bear market, security trumps speed. A slow but honest market is better than a fast one that can be gamed.

Trade.xyz must also be transparent. They need to release a full report on what caused the price feed anomaly. If it was a technical error, they must demonstrate how it will never happen again. If it was intentional, they must refund affected users and face removal from the Hyperliquid ecosystem. The community should demand nothing less.

The Takeaway: Trust Is Compiled, Not Granted

Hyperliquid’s HIP-3 is a case study in how permissionless design can reintroduce centralisation at the application layer. It is not a bug; it is a design philosophy that places speed and flexibility above trust minimalism. In a bull market, such trade-offs are often overlooked. In a bear market, they become existential.

Macro trends crush micro-protocols. The trend right now is toward capital preservation and risk aversion. Protocols that cannot demonstrate robust, independent pricing will be abandoned. The next HIP must close this vulnerability, or Hyperliquid will remain a cautionary tale—a reminder that code enforces, and policy dictates, and that even the most performant chain can be undermined by a single median formula.

I will be watching the on-chain data. If deployer pricing control is not curtailed, the chain’s liquidity will drain. And the next anomaly will not be a test—it will be a funeral.