HyperEVM showed that liquidity does not guarantee distribution when projects launch without protection.
Most HyperEVM project failures are predictable outcomes of a no-subsidy, no preferential treatment, no-narrative environment, not design flaws.
Without CEX listings, hedging venues, or committed market makers, price discovery on HyperEVM becomes asymmetric and failure cascades quickly.
HyperEVM is an extension of a mature trading system, where new products are judged immediately against existing markets.
Despite early chaos, fair launch enables permissionless access to real traders from day one, making surviving products structurally stronger.
When HyperEVM launched in Feb 2025, the assumption was simple and widely shared. Hyperliquid had already solved the hardest part of crypto: real users, real liquidity, real volume. If builders could deploy into that environment, distribution would take care of itself.
Well, that assumption turned out to be wrong. Over the past few months, HyperEVM has proven to be one of the most difficult places in crypto to launch and sustain a project. Most HyperEVM tokens that went live traded down aggressively. Some lost relevance within weeks. Others shut down entirely. Today, sentiment around HyperEVM is near an all-time low, and even within the Hyperliquid community, views around the value of HyperEVM are divided.
This is where the framing of this piece matters. When people talk about HyperEVM’s “failures,” they are usually pointing to outcomes: tokens trading down, projects disappearing, sentiment collapsing. I call these HyperEVM’s “deadly sins,” not because they reflect design mistakes or negligence, but because they are the predictable consequences of an ecosystem that refuses to cushion early-stage projects with subsidies, preferential treatment, or narrative protection.
In other words, these are not sins committed by HyperEVM. They are sins exposed by HyperEVM.
There are no grants. No foundation-led liquidity programs. No coordinated market making. No insider allocations. Tokens are listed permissionlessly and exposed directly to one of the most vibrant onchain trading venues in crypto. If they do not deliver immediate, legible value from day 1, the market moves on.
Whether this is healthy or not in the long term is a separate question. This report is not about defending HyperEVM, nor is it about dismissing it. It is about explaining what HyperEVM reveals when projects are forced to operate without subsidies, kingmaking, or narrative buffers. In that environment, most projects fail quickly, especially those built as lazy forks or short-term extraction plays. But a small number survive, or even thrive, for very specific reasons.
Understanding why requires being precise about what HyperEVM actually is, how the Hyperliquid community thinks about fairness and HYPE, and what kinds of products this system is structurally willing to support. That is the goal of this piece.
Before talking about HyperEVM outcomes, it is worth getting the architecture right. A surprising amount of discussion around HyperEVM starts from an incorrect understanding of how Hyperliquid is structured.
Hyperliquid is a protocol with two execution environments. Both are secured by the same validator set and finalized under the same HyperBFT consensus. However, they do not share a unified execution engine or a single state machine.
Source: Hyperliquid Docs
HyperCore is a deterministic execution environment built specifically for trading. Spot and perpetual markets live there. Orderbooks, margin accounts, liquidation logic, oracle pricing, and staking are all implemented at this layer. Execution is tightly constrained. For a trading venue operating at scale, correctness, solvency, and latency matter much more than general programmability.
Meanwhile, HyperEVM is a general-purpose EVM environment introduced later in Feb 20, 2025 that runs alongside HyperCore. It supports permissionless deployment of smart contracts using standard EVM tooling. HyperEVM contracts can read state from HyperCore and submit actions into HyperCore through system interfaces via precompiles and CoreWriter. The reverse is not true. HyperCore does not call into the EVM, nor does it depend on EVM execution for its own correctness. Composability is asymmetric, by design.
The two environments also advance differently. HyperCore updates continuously at high frequency to support trading. HyperEVM follow a dual block structure: fast blocks produced every second with a lower (2M) gas limit, and larger blocks produced less frequently with a higher (30M) gas limit.
This matters because HyperEVM is not a neutral base layer like Ethereum or Solana. Hyperliquid did not start as a smart contract platform and later attract users. It built the exchange first. Users, liquidity, and culture formed around HyperCore before HyperEVM existed, and HyperEVM was introduced as a complementary interface into that system rather than as a reset.
For builders, this changes the problem. They are not shaping primitives for a future user base. They are deploying into an environment where trading is already mature, liquid, and culturally dominant, and where users already have high standards. New products are evaluated relative to an existing trading stack, not in isolation.
Understanding this starting point is necessary to interpret what follows. Without it, the difficulties HyperEVM projects faced look arbitrary. With it, they become easier to explain.
Every HyperEVM token launch so far has struggled. This was not caused by poor timing or market conditions, but by the environment these tokens launched into.
On paper, HyperEVM has one advantage that most projects would want. Listing on HyperCore is permissionless and inexpensive (hello Binance). There are no listing fees comparable to major CEXs.
In practice, that openness does not solve the harder problems of distribution and liquidity. Unlike projects launching on other major L1s + CEXs, HyperEVM tokens are introduced directly into the Hyperliquid exchange without insulation. There are no grants, no foundation-led liquidity programs, no coordinated market-making arrangements, and no marketing push. Tokens are exposed to traders immediately, in their raw form.
Distribution constraints compound this. Many HyperEVM builders, aligned with Hyperliquid’s ethos, view CEXs as competitors of Hyperliquid rather than partners. CEX listings are often deprioritized. At the same time, CEXs have little incentive to list assets that do not come with listing fees, marketing budgets, or a clear expectation of sustained trading volume.
So without external trading venues, hedging markets, or committed market makers, price discovery becomes asymmetric. Market makers face inventory risk they cannot hedge. New tokens compete directly with established markets that already offer deep liquidity and efficient capital deployment.
This produces a familiar outcome. Takers face wide spreads and shallow depth. Liquidity dries up, and price goes down. Once that spiral starts, it is hard to reverse. Projects that do not provide immediate, legible value lose relevance quickly. Hyperliquid does not intervene to slow this process or buy time. What remains is direct market feedback.
That same discipline shows up in how the community reacts to ecosystem support proposals. The response to the proposed HIP-5 was not a rejection of builders or a denial that ecosystem projects face real challenges, but a rejection of mechanisms that would soften or distort this feedback loop by diverting value from HYPE or introducing discretionary allocation. In other words, the community response is consistent with the launch environment. Fairness, predictability, and neutrality are prioritized over managed ecosystem growth.
Taken together, HyperEVM operates under clear tradeoffs. There are no shortcuts, no kingmaking, and no expectation of protection. Projects either earn relevance quickly or fade. This stance follows directly from the same values that shape the protocol itself, but it also makes HyperEVM one of the hardest environments in crypto to launch a token.
One view is that HyperEVM functions mainly as a proving ground for HyperCore: builders experiment on the EVM, successful ideas are absorbed into Core, and the rest are discarded. In that framing, HyperEVM projects are effectively second-class citizens. Given everything discussed so far, it is reasonable to question whether HyperEVM is even worth building on.
My answer is that it still is.
HyperEVM exists because Jeff does not want Hyperliquid to be a closed system run by a single team. It is the layer that allows permissionless innovation. HyperEVM was never intended to replicate HyperCore or compete with it. Instead, it was designed to sit next to it, grow alongside it. Jeff has been clear that the system only makes sense as both because their responsibilities are separated.
Source: X (@MavenHL)
The portfolio margin design clarifies this boundary. Borrowing exists on HyperCore only to improve trading efficiency. It is internal to margin accounts, capped, asset-restricted, non-tokenized, and non-composable. Users do not interact with a lending market, choose pools, or manage rates. Borrowing happens as a consequence of trading.
But HyperCore stops there.
It does not tokenize deposits, issue transferable receipt tokens, or expose composable lending primitives. Jeff has been explicit that lending markets and financial products should be built by independent teams on the EVM. In practical terms, Core generates demand through trading, and HyperEVM is where that demand must be turned into products.
Source: Discord
This reframes the underlying concern. HyperEVM is not being displaced by Core. It is being given responsibility. Builders are not protected from the market, and they are not guaranteed relevance. They are expected to earn it by building things traders actually use. That position is uncomfortable, but it is also rare.
Hyperliquid has one of the most active onchain trading communities today. These are not passive users or incentive farmers. They understand leverage, funding, risk, and opportunity cost. Liquidity is deep. Volume is real. Price discovery is continuous. If a product integrates into that environment and provides clear utility, it does not need to manufacture demand.
There is also a tradeoff Jeff has emphasized repeatedly. A fair launch makes the early phase messy. Tooling lags. Documentation is incomplete. Builders need to spend time understanding how the system actually works. But this messiness is preferable to the alternative: insiders, preferential access, and protected incumbents. On HyperEVM, everyone starts from roughly the same position.
The result is a clean slate with an unusual imbalance. There are far fewer serious applications than there are users who want them. Fast, general-purpose chains are not new. What is new is the ability to plug into a mature, liquid, onchain trading economy with real users from day one.
That is why HyperEVM is hard. But that is also why it is worth building on. If a product works here, it scales quickly because real traders want it, and use it. Success under these conditions is difficult to fake, and it tends to last much longer.
At this point, the environment HyperEVM operates in should be clear. Trading is already solved. Liquidity already exists. Users already have habits, expectations, and alternatives. The question is no longer whether HyperEVM can support arbitrary applications, but which types of applications make sense under these conditions.
The first category is products that sit downstream of trading activity. HyperEVM works best when it takes existing economic activity on HyperCore and turns it into something more legible, flexible, or usable. That can take many forms.
Lending markets that wrap Core-level borrowing demand. Structured products that package trading strategies or carry trades. Vaults that automate cross-margin behavior. Interfaces that expose risk, yield, or capital usage in a way users can reason about. New market structures that would be unsafe or impractical to run inside the matching engine without polluting Core. Importantly, these products do not invent demand—they organize demand that already exists.
(h/t to Hypurrcollective for the amazing ecosystem map below)
Source: Hypurrcollective
The second category is infrastructure that reduces friction for existing users. This includes analytics, risk dashboards, accounting layers, developer tooling, and bridges that make Hyperliquid easier to monitor, analyze, and integrate into broader workflows. These products rarely generate speculative excitement, but they compound usage by making the core system easier to operate at scale.
The third category is products that improve the economic utility of holding HYPE. A large share of Hyperliquid’s most active traders are also long-term HYPE holders. Many of them stake. Today, native staking yield is relatively low, hovering around 2%. This is where HyperEVM has a clear role. Products that strengthen HYPE’s position as the core asset (by improving yield, flexibility, capital efficiency, etc.) tend to be viewed more favorably.
What consistently struggles on HyperEVM are products that assume they are building a parallel economy. Applications that need users to adopt new mental models before value becomes clear, or that depend on future coordination rather than existing demand, tend to stall. The user base is not waiting to be convinced. It is already busy deploying capital elsewhere.
Seen this way, HyperEVM is not hostile to experimentation. It is selective about where experimentation happens. Execution and risk experimentation are pushed down into HyperCore only when absolutely necessary. Everything else is pushed outward to the EVM, where failure is cheap and feedback is fast.
This is why certain projects appear better aligned than others. Teams working on lending, structured yield, risk tooling, capital abstraction, and infrastructure tied directly to HyperCore activity are responding to demand that already exists. Examples include HyperUnit, HyperLend, Felix, Kinetiq, Hyperbeat, Liminal, Rysk, and Project X.
Stepping back, this is also the role HyperEVM was built to play. Without HyperEVM, development on Hyperliquid would be limited to what Hyperliquid Labs could build directly. Even with an insanely competent team, that approach does not scale indefinitely. HyperEVM opens the system to external builders and lets the market, rather than a single team, decide what gets built.
HyperEVM is not a sandbox nor a sidechain. It is the userland of Hyperliquid.
From the inside, HyperEVM does not feel “dead.” It feels compressed.
What many are interpreting as ecosystem failure looks, to us, like an ecosystem shedding false positives faster than anywhere else in crypto. HyperEVM is one of the few ecosystems where distribution is not granted, liquidity is not sponsored, and narratives are not preloaded. That makes the early experience brutal, but also unusually honest, something that is highly lacking in this space with false incentives.
Sentiment is undeniably weak today. Builders are discouraged. Traders are skeptical. Attention has rotated to the newest shiniest perp dex. Historically, this is exactly where durable crypto ecosystems quietly find their footing.
The absence of grants, foundation incentives, or insider allocations means HyperEVM projects are forced to answer a hard question right from the onset: who is this being built for, and why should they care? Most projects fail that test. A few don’t, and those that survive tend to develop tighter feedback loops with users, stronger product discipline, and clearer alignment with HYPE holders.
We also think HyperEVM is misunderstood. It is not a general-purpose EVM where speculative apps can rely on narrative momentum. It is best viewed as a functional extension of Hyperliquid itself. A place to build tools, primitives, and workflows that make trading, liquidity, and on-chain activity on Hyperliquid more efficient, expressive, or capital-aware, to work on the over-arching goal of being the blockchain to house all of finance.
From a community lens, bottoms in sentiment are often prerequisites for real traction. When hype leaves, what remains are builders willing to iterate in public, users willing to test without incentives, and communities that form around actual utility rather than token performance. That is the phase HyperEVM is entering now.
Our conviction remains that HyperEVM will not be defined by the number of projects that launched, but by a small, high quality set of builders and projects that earn their place through usage, fairness, and tight alignment with Hyperliquid’s core users. The ecosystem will likely be smaller than many expected, and stronger because of it.
Dive into 'Narratives' that will be important in the next year
Hyperliquid
Stable
