Recently, discussions about whether HyperEVM is dead have clearly intensified. Crypto KOL katexbt bluntly called it a massive failure, with 13 out of 18 projects deemed a waste of time.
Our last article wrote about trade.xyz achieving near-monopoly in Hyperliquid's HIP-3 perpetual market. This article looks at the other side of the platform: why its application layer hasn't taken off.
Trading Side Continuously Sucks Money, Application Layer Bleeds
Hyperliquid is an independent public chain, running on a self-developed high-speed mechanism, focusing on on-chain trading.
Against the backdrop of the overall crypto market correction in 2026, according to DeFiLlama data, the total DeFi industry TVL has shrunk from about $115 billion to around $70 billion, a drop of about 39%. Most public chain TVLs have shrunk with the market, and Hyperliquid is one of the few public chains that has remained relatively stable.
This chain actually has two engines internally, sharing the same validators but with completely different functions.
The first is called HyperCore, the trading engine. The high-performance order book exchange on-chain is here, where perpetual contracts and spot trading are completed. It is not open to the public; no one can build applications on it, and all trading logic is hardcoded inside.
The second is called HyperEVM, the application engine. Launched in February 2025, it is Ethereum-compatible. Developers can build DeFi applications like lending, staking, and decentralized exchanges on it. Applications on HyperEVM can remotely call the trading and liquidity of HyperCore, but the actual matching is always controlled by HyperCore.
Image Source: RootData
Simply put, Hyperliquid locks the most profitable trading business in a closed engine and leaves the part open to developers to HyperEVM next to it.
The performance gap between the two engines is enormous.
On the trading engine side, Hyperliquid has captured over half of the on-chain perpetual trading volume on most trading days in 2026. According to DeFiLlama, in the 30 days leading up to August 10, the Hyperliquid exchange itself generated about $46.17 million in fees. Combined with the second-ranked trade.xyz, the total trading-related fees were about $56 million.
The application engine side is much weaker. The total fees of all DeFi protocols on the entire HyperEVM add up to less than $6 million, a difference of nearly tenfold.
The divergence in capital scale is equally apparent. According to the HRC Q2 2026 report, the entire chain's TVL was about $1.44 billion at the end of Q2 and further dropped to about $1.2 billion by early August (including the trading side). The proportion of funds truly deposited in the HyperEVM application layer is not high and is still shrinking.
According to public data, the average daily active sending addresses on HyperEVM are only about 8,000, while Base had over 250,000 and Arbitrum over 110,000 in the same period. It's hard to explain this gap with 'the industry is still young' for a platform that already dominates the perpetual trading space and appears to lack neither money nor users.
Looking inside HyperEVM. As of early August, after removing assets bridged over, the application funds are basically 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 size of about $780 million.
Meanwhile, decentralized exchanges, which should be the most prosperous, have completely regressed. On other public chains, DEX is usually the core of DeFi, with leading projects easily reaching tens or hundreds of billions in scale. On HyperEVM, 44 related protocols add up to only about $221 million, with the largest native trading platform only in the tens of millions.
According to HRC, in Q2 decentralized trading volume on HyperEVM, PRJX alone accounted for 92.3%, HyperSwap accounted for 7.5%, and the remaining forty-plus had almost no volume.
The trading engine continuously sucks away funds and attention; the application layer cannot retain projects or users.
Why HyperEVM Hasn't Taken Off
This contrast isn't simply an operational issue; it's written into the chain's architecture and choices.
1. Matching Monopolized by the Core, DEX Becomes Redundant
HyperEVM's biggest selling point is that applications can directly call HyperCore's order book. This capability is powerful but simultaneously confines the scope of viable applications.
Trading matching and liquidity are monopolized by HyperCore, and the deployment environment is not open to the public. That is, third-party developers can only build houses 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 reliant on the order book: liquid staking, lending, basis trading, market making.
According to Token Terminal, Hyperliquid's daily active addresses have long remained at a high level of 60,000 to 70,000, with HyperEVM accounting for only about 10-20% of that, while the vast majority of active users are concentrated on the HyperCore trading side.
DEX loses its meaning here because matching has already been done by HyperCore with an engine far more efficient than an Automated Market Maker (AMM). Deploying a decentralized exchange on HyperEVM would be reinventing the wheel.
2. Monopoly Isn't Lack of Competition; It's an Architectural Inevitability
According to the HRC report, shared liquidity eliminates the space for small platforms to survive on independent order books. When a trader sees the same asset listed in two places in the same interface, they immediately send the order to the deeper order book. Duplicate listings are almost instantly routed to where liquidity is better.
This explains why decentralized trading on HyperEVM converges to a single entity, PRJX, and also explains the same phenomenon on the trading layer. The HIP-3 listing layer converged to a single operator within five months; trade.xyz had captured nearly all volume by July.
Permissionless entry and ultimate monopoly naturally coexist under shared liquidity. The high concentration in the application layer is a mathematical result of this architecture, not a lack of competition.
3. The Fairness Ethos Personally Shut Down the Distribution Engine
Another shortcoming of the HyperEVM ecosystem comes from Hyperliquid's long-emphasized fairness ethos.
Officials admit that HyperEVM has long been in a state of slow progress because it adheres to the 'no insiders' principle: no one was notified in advance, and no payments were made for integrations or marketing.
The cost is that its development tools and supporting infrastructure at launch were less mature than those of other chains.
Adhering to fairness itself is not a problem. But a protocol that already generates millions of dollars in daily fees, holds vast funds and users, is fully capable of supporting its application layer with grants, business partnerships, and marketing without compromising fairness. It chose to do nothing.
At Hyperliquid's current scale, 'no insiders' has gone from an initial principle to an excuse for inaction. It has the resources to ignite an ecosystem; it lacks only the will.
KOL @Ace_da_Book pointed out that this chain offers zero incentives for builders, no kingmakers, yet still attracts high-quality teams that believe in fair competition. HyperEVM is suitable for teams that can synergize with HyperCore's order book, working on tokenized RWAs and quality assets, not for projects focused on attention markets.
However, from another perspective, this is also a brutal filter. Without subsidies and narrative protection, projects directly face mature traders upon launch, so failure naturally comes quickly.
4. Cross-Engine Write Operations Don't Guarantee Execution; Developer Experience Remains Cumbersome
The final layer of resistance comes from the development experience.
HyperEVM employs a dual-block design: high-frequency small blocks handle low-latency contract transactions, while large blocks (approximately one second) handle settlement with HyperCore. The benefit is speed; the cost is that contract operations and core matching reside in different stages and are not completed synchronously within the same transaction.
There are two channels between HyperEVM and HyperCore. The read channel uses a precompile; contracts can directly read order book prices, positions, and balances—this one is smooth. The write channel goes through a system contract called CoreWriter, which was enabled on the mainnet around mid-2025. Contracts can use it to place orders and transfer funds to HyperCore.
The problem lies in the nature of this write channel; it's not synchronous. After a contract calls CoreWriter, the EVM transaction is completed immediately, but the actual core action is scheduled for execution in a subsequent core block. It may also fail silently due to reasons like insufficient margin or unfilled orders, in which case the EVM transaction does not revert.
For developers, this means you can't assume one-step completion like on Ethereum. To build a stable vault or lending application, you need to split it into two steps: first send the instruction, then use the read channel later to confirm whether the core action actually succeeded, while also managing intermediate stuck states. These kinds of cross-engine pitfalls don't exist in regular EVM development.
Therefore, for general developers looking to migrate in, this is a significant barrier. Those willing to come in are mostly teams already focused on leveraging HyperCore's liquidity, not developers pursuing independent application scenarios.
Is HyperEVM's Desolation a 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 on-chain stablecoin scale quadrupled, gas consumption and transaction counts are rising—usage is actually growing. What's shrinking is only the DeFi collateral stuck in leverage and LST loops. Capital on Hyperliquid is increasingly for trading rather than farming.
This explanation can somewhat hold up, but it precisely illustrates the problem. A so-called ecosystem reduced to only trading and leverage loops is itself evidence of failure, not another form of success.
Crypto KOL Cain O'Sullivan suggests that critics are using the wrong framework. In his view, HyperEVM was never intended to be a general-purpose chain. It is HyperCore's liquidity tokenization layer, 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 EVM versions is evidence.
However, even by his definition, HyperEVM's value is entirely dependent on HyperCore. It is more like a programmable peripheral of the trading engine, not an independently growing economic entity.
Defining HyperEVM as a tokenization layer might make sense, but this also indicates the team never really intended to build a general-purpose ecosystem from the start. Developers who came in expecting that general narrative became the disappointed party.
The part of HyperEVM's ecosystem that seemed prosperous was essentially a false boom fueled by leverage. What's revealed after the fire recedes is the small circle of real demand surrounding trading and the order book.
Conclusion
Whether HyperEVM is dead might be the wrong question. There is still real capital flowing on-chain and high-value assets operating. But it has indeed failed to grow the breadth and retention that a general-purpose application ecosystem should have.
Hyperliquid has placed almost all its resources and focus on the trading engine, locking matching and liquidity in a closed, high-performance system. This choice has given it a clear advantage in the perpetual market, but it also predetermined that the adjacent application layer could only grow as a supporting role. This is not an architectural destiny; it's an active trade-off.
Over a year later, the cost is becoming clear: the trading side continues to suck money, while the application layer cannot retain projects or users. What survives are mostly financial applications revolving around the order book; truly independent, general-purpose demand has barely emerged.
Rather than continuing to debate its death, perhaps we should first ask a more fundamental question: What kind of chain are we actually demanding Hyperliquid to be?
