By Zhou, ChainCatcher
Talk around whether HyperEVM is already dead has become louder. Crypto KOL katexbt called it a major failure and said 13 of 18 projects there were a waste of time.
After ChainCatcher’s earlier look at how trade.xyz came close to monopolizing the HIP-3 perpetual market on Hyperliquid, this report turns to the other side of the platform: why its application layer has failed to gain real momentum.
The trading side keeps attracting capital while the app layer weakens
Hyperliquid is an independent blockchain built around a high-speed in-house system with on-chain trading at the center.
During the broader crypto market pullback in 2026, DeFiLlama data showed total value locked across DeFi falling from about $115 billion to around $70 billion, a decline of roughly 39%. Most chains saw TVL shrink with the market. Hyperliquid was one of the few that remained comparatively resilient.
Inside the chain are two engines that share the same validator set but serve very different roles.
The first is HyperCore, the trading engine. Hyperliquid’s on-chain high-performance order-book exchange runs there, handling both perpetuals and spot trading. It is not open to outside deployment, and its trading logic is fixed inside the system.
The second is HyperEVM, the application engine. It launched in February 2025 and is Ethereum-compatible, allowing developers to build lending, staking, and decentralized exchange applications. Apps on HyperEVM can call into HyperCore’s trading functions and liquidity, but the actual matching process remains under HyperCore’s control.
In simple terms, Hyperliquid kept its most profitable business inside a closed trading engine and placed the open developer environment in a separate layer beside it.
The performance gap between those two engines is wide.
On the trading side, Hyperliquid captured more than half of on-chain perpetual trading volume on most trading days in 2026. According to DeFiLlama, in the 30 days through Aug. 10, the Hyperliquid exchange itself generated about $46.17 million in fees. Add trade.xyz, which ranked behind it, and the total related to trading reached roughly $56 million.
The application side was much smaller. All DeFi protocols on HyperEVM combined generated less than $6 million in fees, leaving a gap close to 10x.
The divergence also shows up in capital. HRC’s report for the second quarter of 2026 said TVL across the full Hyperliquid chain stood at about $1.44 billion at the end of the quarter and dropped further to about $1.2 billion by early August, including the trading side. The share actually sitting in HyperEVM applications was not large and was still shrinking.
Public data cited in the article put HyperEVM’s daily average active sending addresses at about 8,000. Over the same period, Base had more than 250,000 and Arbitrum had more than 110,000. For a platform that already dominates on-chain perpetuals and appears to have both users and money, an app layer operating at second-tier scale is hard to explain away as simple early-stage weakness.
Inside HyperEVM, the composition is also narrow. As of early August, after excluding bridged-in assets, application capital was largely concentrated in two categories: liquid staking at about $978 million and lending at about $671 million.
The largest protocol was Kinetiq, a HYPE liquid staking protocol, at around $780 million.
The area that would normally be expected to thrive on a DeFi chain, decentralized exchanges, has gone the other way. On many other chains, DEXs sit at the center of DeFi and leading projects often reach tens of billions of dollars in scale. On HyperEVM, 44 related protocols together had only about $221 million, and the largest native trading venue was only in the tens of millions.
HRC said PRJX alone accounted for 92.3% of HyperEVM decentralized trading volume in the second quarter, while HyperSwap took 7.5%. The remaining forty-plus protocols had barely any activity.
The trading engine keeps pulling away capital and attention, leaving the application layer unable to retain either projects or users.
Why HyperEVM has failed to take off
The article argues that the contrast is not just an operations issue. It is embedded in the chain’s architecture and choices.
Matching is monopolized by the core, leaving little room for DEXs
One of HyperEVM’s main selling points is that applications can directly tap into HyperCore’s order book. That is a powerful feature. It also sharply limits the range of applications that can justify existing there.
Matching and liquidity are controlled by HyperCore, and the deployment environment itself is closed. Third-party developers can only build on HyperEVM and then route back into HyperCore’s liquidity.
That leaves real room mainly for applications tied to the order book, such as liquid staking, lending, basis trades, and market making.
Token Terminal data cited in the report showed Hyperliquid’s chain-wide daily active addresses holding in the 60,000 to 70,000 range for a long period, with HyperEVM accounting for only about 10% to 20% of that total. Most active users remained on the HyperCore trading side.
That also explains why DEXs lose their point here. HyperCore already handles matching with an engine that is more efficient than an automated market maker. Launching another decentralized exchange on HyperEVM starts to look like rebuilding something the system has already finished.
Concentration is not a lack of competition but the outcome of shared liquidity
According to the HRC report, shared liquidity removes the space smaller platforms would normally have to survive through independent order books. When traders see the same asset listed in two places on one interface, orders quickly route toward the deeper book. Duplicate listings are pushed almost immediately to the venue with better liquidity.
That helps explain why decentralized trading on HyperEVM converged around PRJX, and why the trading layer showed a similar pattern. The HIP-3 listing layer converged to a single operator in five months, and by July tradeXYZ had taken almost all of the volume.
Under a shared-liquidity structure, permissionless entry and eventual dominance by one operator can exist at the same time. The concentration on the application layer is presented in the report as a direct outcome of the system’s design rather than a simple failure to compete.
A fairness-first approach also shut down the ecosystem distribution machine
Another weak point for HyperEVM comes from Hyperliquid’s long-stated emphasis on fairness.
The team has acknowledged that HyperEVM moved forward slowly because it followed a “no insiders” principle: no one received advance notice, and no one was paid for integrations or marketing.
The trade-off was clear. Developer tooling and ecosystem support at launch were not as complete as on rival chains.
The report does not argue that fairness itself is the problem. It argues that a protocol already generating millions of dollars in daily fees and sitting on substantial capital and users could still support the application layer through grants, business development, and marketing without violating that principle. Instead, it chose not to do so.
At Hyperliquid’s current scale, the article says, “no insiders” has shifted from an early operating principle into a reason for inaction. The resources exist. What is missing is the willingness to use them.
KOL @Ace_da_Book said the chain offers builders no incentives and does not try to manufacture winners, yet it still attracts high-quality teams that believe in fair competition. In his view, HyperEVM suits teams that can work alongside the HyperCore order book and focus on tokenized RWA and high-quality assets, rather than projects built for attention markets.
Looked at another way, that is also a harsh filter. Without subsidies or narrative protection, projects face experienced traders the moment they go live, so failure arrives fast.
Cross-engine writes do not guarantee execution, and the developer experience stays awkward
The last source of friction is developer experience.
HyperEVM uses a dual-block design. High-frequency small blocks handle low-latency contract transactions, while larger blocks arriving around every second handle settlement with HyperCore. The speed benefit comes with a cost: contract actions and core matching happen in different stages and are not completed synchronously in one transaction.
There are two channels between HyperEVM and HyperCore. The read path uses precompiles, allowing contracts to directly access order-book prices, positions, and balances. That path works smoothly. The write path goes through a system contract called CoreWriter. By mid-2025 it was live on mainnet, allowing contracts to place orders and transfer funds into HyperCore.
The issue is the nature of that write path. It is not synchronous. After a contract calls CoreWriter, the EVM-side transaction completes immediately, but the actual core action only executes in a later core block. It can also fail quietly because of insufficient margin or because the order does not fill. If that happens, the EVM-side transaction does not roll back.
For developers, that changes the assumptions they can make. They cannot treat execution as one atomic step in the way they often do on Ethereum. To make a vault or lending app robust, they may need to split logic into two stages, first sending the instruction and then checking through the read channel whether the HyperCore-side action actually succeeded, while also handling stuck intermediate states. Those cross-engine edge cases are not part of ordinary EVM development.
That creates a real barrier for general-purpose developers considering a move. The teams willing to enter tend to be those already planning to build around HyperCore liquidity, not teams pursuing independent application categories.
Is HyperEVM in decline, or is it succeeding on different terms?
The HRC report described the drop in TVL as a structural adjustment. Over the same period, on-chain stablecoin supply increased fourfold, gas consumption and transaction count both moved higher, and usage was still growing. What contracted was DeFi collateral tied up in leverage and LST loops. Under that reading, more of the capital on Hyperliquid is now there for trading rather than farming.
The article says that explanation is not entirely baseless, but it also exposes the core issue. If an ecosystem is left with little beyond trading and leverage loops, that is not a new model of success. It is evidence of what failed to emerge.
Crypto KOL Cain O'Sullivan offered a different frame. In his view, critics are judging HyperEVM by the wrong standard. He argued that HyperEVM was never meant to be a general-purpose chain. It is a tokenization layer for HyperCore liquidity and a route for value entering and leaving the ecosystem. Without an EVM-compatible layer, he said, HyperCore would not have native USDC, and the team’s move away from Core vaults toward EVM versions supports that reading.
Even under that definition, though, HyperEVM’s value remains fully dependent on HyperCore. It looks closer to a programmable outer layer attached to the trading engine than to an economy capable of growing on its own.
Calling HyperEVM a tokenization layer may fit. It also suggests the team never truly intended to build a broad general-purpose ecosystem from the start. Developers who arrived for that narrative were the ones left disappointed.
The article closes that point bluntly: much of what looked like prosperity inside HyperEVM was built on leverage. Once that heat faded, what remained was a narrow base of genuine demand centered on trading and the order book.
Before asking whether HyperEVM is dead, ask what Hyperliquid is supposed to be
The report argues that “is it dead” may be the wrong question. There is still real capital moving on-chain, and high-value assets are still active. But HyperEVM has not developed the breadth or retention expected of a general-purpose application ecosystem.
Hyperliquid placed most of its resources and attention on the trading engine, locking matching and liquidity inside a closed high-performance system. That choice helped it build a clear edge in perpetual markets. It also meant the application layer beside it could only grow into a supporting role. The piece treats that not as unavoidable destiny but as a deliberate trade-off.
More than a year later, the cost is easier to see. The trading side keeps drawing in capital. The application layer cannot keep projects or users. Most of what survives revolves around the order book, while genuinely independent general-purpose demand has barely appeared.
Instead of debating whether HyperEVM has died, the article says the better question is more basic: what kind of chain does the market actually want Hyperliquid to be?