The Deception of Trustless Pricing: Hyperliquid’s HIP-3 and the Fragility of Permissionless Markets

Over the past seven days, a single market on Hyperliquid—xyz:SKHYNIX deployed by Trade.xyz—recorded a cascade of liquidations that had nothing to do with market volatility. The victims weren’t caught by a flash crash or a sudden loss of liquidity. They were caught by a feature. A feature that many in the community had assumed was just a technical detail until it turned against them. Hyperliquid positions itself as a high-performance L1 with native perpetuals, offering a permissionless environment where any team can deploy their own market. That sounds empowering. But with permission comes responsibility, and as this incident reveals, the burden of that responsibility lands squarely on the user. The culprit is HIP-3, a proposal that governs how the mark price—the price used to calculate unrealized PnL and trigger liquidations—is determined. Under HIP-3, the final mark price is computed from three components: a chain-wide median derived from validator submissions, and two components pushed directly by the market deployer. That’s right—the same entity responsible for running the market also controls two of the three inputs to the price that decides whether your position lives or dies. In the documented example, if the chain median says 100 and the deployer pushes 150, the final mark price becomes 150. The deployer, in effect, holds a veto over the price. Based on my audit experience with decentralized derivative protocols, such delegation of pricing authority is a red flag I rarely see printed so explicitly in code. Let’s compare this to the established alternatives. dYdX relies on multiple independent oracles (Chainlink, etc.) to compute its mark price, distributing trust across a network of data providers. GMX uses an on-chain AMM-based pricing model that reflects actual trades, eliminating the need for external oracles altogether. Both sacrifice a degree of flexibility for a baseline of security. Hyperliquid’s HIP-3 prioritises freedom for the deployer, but the cost is that the deployer becomes a single point of failure—or, worse, a vector for intentional manipulation. The recent anomaly suggests that Trade.xyz either misconfigured its push or suffered a bug, but the mechanism would allow a bad actor to trigger liquidations at scale before any countermeasure could react. Connect first, transact second. Always. That phrase guides every piece I write, and it’s never been more relevant. The protocol’s official response—acknowledging the issue and stating a review of the mechanism is warranted—is a start. But it doesn’t address the fundamental question: if the architecture allows a deployer to override the chain’s consensus on price, what exactly is being decentralised? Here’s where the contrarian angle comes in. Some proponents argue that such a tiered pricing model is a feature, not a flaw. They say permissionless markets need custom pricing strategies—for example, to support exotic assets or low-liquidity pairs—and that forcing a one-size-fits-all oracle would stifle innovation. They claim that the deployer’s reputation serves as implicit collateral, and that the market will punish bad actors through loss of trust and user exodus. There’s a thread of truth there: decentralisation doesn’t have to mean uniform trustlessness. But in practice, this argument collapses when you consider that the deployer also sets the liquidation parameters and profit and loss mechanics. The incentives are not aligned with the traders. In a bear market where every basis point of slippage hurts, asking users to trust a single entity’s price feed is asking for trouble. The market is already speaking. HYPE’s price action shows nervousness, and on-chain analytics reveal a dip in new liquidity being deployed into Trade.xyz’s market. Other deployers on Hyperliquid are now scrambling to prove the robustness of their own setups. The narrative that Hyperliquid is “the decentralised FTX” has taken a hit. But more importantly, this incident exposes a blind spot in how we audit permissionless systems. We obsess over smart contract bugs and oracle manipulation when oracles are external—but when the oracle is built into the deployer’s own dashboard, we rarely give it the same scrutiny. Connect first, transact second. Always. The lesson here isn’t just for Hyperliquid. Every L1 that supports permissionless market creation should ask itself: does the pricing mechanism protect the trader or the deployer? If the answer leans toward the latter, a correction is coming. Looking ahead, I expect Hyperliquid to move quickly—either through an emergency HIP to restrict the deployer’s influence or through mandatory third-party auditing of price push logic. The window for action is narrow. If they fail to act, the capital will flow to protocols where trust is coded into the architecture, not assumed in the identity of a market maker. We’ve seen this cycle before—from Mt. Gox to Terra—and each time the survivors were those that turned a crisis into a commitment to better design. So here’s my forward-looking judgment: in six months, HIP-3 will either be remembered as the bug that forced Hyperliquid to mature, or as the design flaw that opened the door for a more accountable competitor. The choice is theirs. The rest of us should watch closely, and question every assumption that ties our safety to someone else’s integrity.