Hyperliquid is forcefully killing HyperEVM

Author: Zhou, ChainCatcher

Recently, discussions around whether HyperEVM is dead have noticeably intensified. Crypto KOL katexbt bluntly stated that it is a huge failure, with 13 out of 18 projects considered a waste of time.

In our previous article, we wrote about how trade.xyz achieved near-monopoly in Hyperliquid's HIP-3 perpetual market; this article looks at another side of the platform, examining why its application layer is struggling to take off.

The Trading Side Continues to Attract Capital, While the Application Layer Bleeds

Hyperliquid is an independent public chain that operates on a self-developed high-speed mechanism, focusing on on-chain trading.

Against the backdrop of an overall correction in the crypto market in 2026, according to Defillama data, the total value locked (TVL) in the entire DeFi industry shrank from about $115 billion to around $70 billion, a decline of approximately 39%. Most public chains saw their TVL shrink with the market, while Hyperliquid is one of the few public chains that maintained relative strength.

Internally, this chain actually has two engines that share the same batch of validators but have completely different roles.

The first is called HyperCore, which is the trading engine. The high-performance order book exchange on-chain is it, where perpetual contracts and spot trading are completed. It is not open to external applications; others cannot build applications on it, and all trading logic is hard-coded inside.

The second is HyperEVM, which is the application engine. It was launched in February 2025 and is compatible with Ethereum, allowing developers to build DeFi applications such as lending, staking, and decentralized exchanges on it. Applications on HyperEVM can call HyperCore's trading and liquidity remotely, but the actual matching is always controlled by HyperCore.

Image source: RootData

In simple terms, Hyperliquid locks the most profitable trading business in a closed engine and leaves the part open to developers to the adjacent HyperEVM.

The performance gap between the two engines is very large.

On the trading engine side, Hyperliquid consumed more than half of the on-chain perpetual trading volume on most trading days in 2026. According to DeFiLlama, in the 30 days up to August 10, the Hyperliquid exchange itself generated about $46.17 million in fees, plus the subsequent trade.xyz, bringing the total trading-related fees to about $56 million.

On the application engine side, it is much weaker. The total fees from all DeFi protocols on HyperEVM combined are less than $6 million, a difference of nearly ten times.

The divergence in capital scale is also evident. According to the HRC Q2 2026 report, the total locked amount of the entire Hyperliquid chain was about $1.44 billion at the end of Q2, further dropping to around $1.2 billion by early August (including the trading side). The proportion of funds truly settled in the HyperEVM application layer is low and still shrinking.

According to public data, the average daily active sending addresses on HyperEVM are only about 8,000, while during the same period, Base exceeded 250,000 and Arbitrum exceeded 110,000. A platform that has already dominated the perpetual trading track and seems to lack neither money nor users has an application layer with only second-tier scale; this gap is hard to explain with "the industry is still early."

Looking further into HyperEVM, as of early August, after removing assets from cross-chain bridges, application funds were primarily consumed by two categories: liquid staking at about $978 million and lending at about $671 million.

Ranking first is the HYPE liquid staking protocol Kinetiq, with a scale of about $780 million.

However, the decentralized exchanges that should be thriving have completely degraded. On other public chains, DEXs are usually at the core of DeFi, with leading projects often reaching tens or hundreds of billions in scale. But on HyperEVM, the 44 related protocols combined have only about $221 million, and the largest native trading platform is only in the tens of millions.

According to HRC, in Q2, PRJX alone accounted for 92.3% of decentralized trading on HyperEVM, while HyperSwap accounted for 7.5%, with the remaining forty or so having almost no volume.

The trading engine continues to siphon off funds and attention, leaving the application layer unable to retain projects or users.

Why HyperEVM Struggles to Take Off

This contrast is not simply an operational issue; it is embedded in the architecture and choices of this chain.

1. Matching is Exclusively Controlled by the Core, Making DEX Redundant

The biggest selling point of HyperEVM is that applications can directly call HyperCore's order book. This capability is powerful but simultaneously restricts the range of applications that can survive.

Trading matching and liquidity are monopolized by HyperCore, and the deployment environment is not open to external developers. This means that third-party developers can only build on HyperEVM and then call HyperCore's liquidity in reverse.

The result is that the applications that truly have a reason to exist here are concentrated in a few categories that rely on the order book: liquid staking, lending, basis trading, and market making.

According to Token Terminal, the daily active addresses across the entire Hyperliquid chain have long maintained a high level of 60,000 to 70,000, with HyperEVM accounting for only about 10% to 20%. The vast majority of active users are concentrated on the HyperCore trading side.

The reason DEXs lose significance here is that matching has already been efficiently completed by HyperCore using an engine far superior to automated market makers. Deploying a decentralized exchange on HyperEVM is equivalent to reinventing the wheel.

2. Monopoly is Not Due to Insufficient Competition, but an Inevitable Result of Architecture

According to the HRC report, shared liquidity eliminates the space for small platforms to survive on independent order books. When traders see the same asset listed in two places on the same interface, they will immediately send their orders to the deeper order book, and re-listing will almost instantly be routed to the place with better liquidity.

This explains why decentralized trading on HyperEVM converges towards PRJX alone and also explains the same phenomenon on the trading layer. The listing layer of HIP-3 converged to a single operator within five months, with tradeXYZ having consumed nearly all transactions by July.

Permissionless entry and eventual monopoly coexist naturally under shared liquidity. The high concentration of the application layer is a mathematical result of this architecture, not a lack of competition.

3. The Fairness Philosophy Has Shut Down the Distribution Machine

Another shortcoming of the HyperEVM ecosystem comes from the fairness philosophy that Hyperliquid has always emphasized.

The official acknowledgment is that HyperEVM has been in a state of slow progress for a long time because it insists on the "no insiders" principle: no one is notified in advance, and no payments are made for integration or marketing.

The cost is that the development tools and support available at its launch are not as complete as those on other chains.

There is nothing wrong with insisting on fairness. However, a protocol that already earns millions of dollars in fees daily and possesses substantial funds and users is fully capable of supporting the application layer through funding, business cooperation, and marketing without compromising fairness. It chooses to do nothing.

At the current scale of Hyperliquid, "no insiders" has transformed from an initial principle into an excuse for inaction. It has the resources to ignite the ecosystem; it just lacks the will.

KOL @AcedaBook pointed out that this chain offers zero incentives for builders and has not created a king, yet it still attracts high-level teams that believe in fair competition. HyperEVM is suitable for teams that can collaborate with HyperCore's order book and work on tokenized RWA and quality assets, rather than projects focused on attention markets.

However, from another perspective, this is also a cruel selection. Without subsidies and narrative protection, projects face mature traders directly upon launch, and failure comes quickly.

4. Cross-Engine Writes Do Not Guarantee Transactions, and the Development Experience Remains Awkward

The final layer of resistance comes from the development experience.

HyperEVM adopts a dual-block design, with high-frequency small blocks responsible for low-latency contract trading and larger blocks responsible for settlement with HyperCore. The benefit is speed, but the cost is that contract operations and core matching occur in different stages and are not completed synchronously in the same transaction.

There are two channels between HyperEVM and HyperCore. One for reading uses precompiled contracts, allowing contracts to directly read order book prices, positions, and balances, which works smoothly. The writing channel uses a system contract called CoreWriter, which has been enabled on the mainnet since mid-2025, allowing contracts to place orders and transfer to HyperCore through it.

The problem lies in the nature of the writing channel; it is not synchronous. After a contract calls CoreWriter, the EVM transaction is immediately completed, while the actual core action will only be executed in subsequent core blocks, and it may quietly fail due to insufficient margin or unfulfilled orders, at which point the EVM transaction will not roll back.

For developers, this means they cannot assume a one-step process as they would on Ethereum. To stabilize a vault or lending application, it must be broken down into two steps: first sending the command, then going back to use the reading channel to confirm whether the core side succeeded, while also leaving a fallback for any stuck states. These kinds of cross-engine pitfalls do not exist in regular EVM development.

Therefore, for general developers looking to migrate, this is a significant barrier. Those willing to come in are mostly teams already working around HyperCore liquidity, rather than developers pursuing independent application scenarios.

Is the Quietness of HyperEVM Decline or Another Form of Success?

The HRC report mentions that this round of TVL decline is a structural adjustment. During the same period, the scale of on-chain stablecoins quadrupled, gas consumption and transaction numbers are rising, indicating that usage is actually increasing; only the DeFi collateral stuck in leverage and LST loops is shrinking. The capital on Hyperliquid is increasingly for trading rather than farming.

This explanation barely holds up, but it precisely illustrates the problem: an ecosystem that consists solely of trading and leverage loops is itself evidence of failure, not another form of success.

Crypto KOL Cain O'Sullivan stated that the pessimists are using the wrong framework. In his view, HyperEVM never intended to be a general-purpose chain; it is the tokenized layer of HyperCore liquidity, the channel for value entering and exiting this ecosystem. Without this EVM-compatible layer, there would be no native USDC on HyperCore, and the team's shift from Core vaults to the EVM version is also evidence of this.

However, even by his definition, the value of HyperEVM is entirely dependent on HyperCore; it is more akin to a programmable peripheral of the trading engine rather than an independent growing economy.

Defining HyperEVM as a tokenized layer may make sense, but it also indicates that the team never truly intended to create a general-purpose ecosystem. Those developers who came in with the narrative of generality have become the disappointed party.

The apparent prosperity in the HyperEVM ecosystem is merely a false fire built on leverage. Once the fire recedes, the underlying reality reveals itself as a small circle of genuine demand centered around trading and order books.

Conclusion

Whether HyperEVM is dead or not may be the wrong question to ask. There is still real capital flowing on-chain, and high-value assets are in operation. However, it has indeed failed to grow the breadth and retention that a general application ecosystem should have.

Hyperliquid has staked almost all its resources and attention on the trading engine, locking matching and liquidity in a closed high-performance system. This choice has allowed it to establish a clear advantage in the perpetual market, but it also determines that the adjacent application layer can only grow into a subordinate role. This is not the fate of the architecture; it is a deliberate trade-off.

More than a year has passed, and the cost has become quite clear: the trading side continues to attract capital, while the application layer cannot retain projects or users. Those that survive are mostly financial applications revolving around the order book; truly independent general demand has hardly emerged.

Rather than continuing to debate whether it is dead, it is better to first clarify a more fundamental question: what exactly are we asking Hyperliquid to become?