How does HyperEVM turn exchanges into programmable financial engines?

Written by: ponyo_fp (Four Pillars Research Team)

Translated by: AididiaoJP, Foresight Newsna

Key Points

HyperEVM should be viewed as a smart contract layer, with its core value being that it allows applications to directly read and use transaction, collateral, position, and risk data from HyperCore.

The simplest way to assess the value of a HyperEVM application is to ask two questions: Why does it need EVM? Why does it need Hyperliquid?

Basic functionalities such as exchanges, lending, and asset wrappers are certainly necessary, but what truly sets apart products are those that cannot operate normally without HyperCore.

In the long run, the ultimate form is a highly integrated account — users only need one balance to perform all operations such as trading, lending, yield farming, hedging, and payments simultaneously.

Exchange First

Most smart contract platforms follow the route of "first creating the chain, then finding applications": first launching infrastructure, subsidizing liquidity, attracting developers, and finally hoping that applications will naturally form financial gravity.

Hyperliquid's path is completely opposite. It first builds the exchange, possessing a native spot and perpetual order book, trader market share, a protocol-owned liquidity system, and a real trading volume that has long been flowing through HyperCore. This fundamentally changes the positioning of HyperEVM — it is not just another place where DeFi contracts can be casually copied, but aims to turn the exchange itself into a programmable entity.

This article does not aim to comprehensively list all factors that could drive Hyperliquid's growth (HIP 3 market, builder code, portfolio margin, native liquidity, Unit assets, fee loops, etc. are equally important). Here, we focus on one question: What characteristics should truly worthwhile applications on HyperEVM have?

A valuable HyperEVM native application needs to meet three criteria simultaneously:

• It can express general logic that HyperCore itself cannot achieve (requires the flexibility of EVM);
• It relies on unique states that other chains do not possess (composability of HyperCore);
• It makes Hyperliquid more useful as a financial venue.

HyperCore is the home of transaction, collateral, and risk engines. HyperEVM is where application logic is developed. Through precompiles, contracts can directly query data such as HyperCore's balances, positions, prices, staking delegates, and treasury rights; through CoreWriter, contracts can also write operations back to HyperCore.

This design turns the exchange into a native input source for applications. Collateral, execution, settlement, and distribution can be more closely integrated on the same ledger.

Of course, not all HyperEVM applications need to pursue "novelty." The ecosystem needs familiar primitives before users can naturally engage in exchanges, lending, leveraging, rebalancing, and exiting. Local finance can keep capital within the system, making the entire ecosystem truly usable.

However, the deeper opportunities lie not in simply forking existing lending protocols to change the frontend, but in building credit, asset management, payments, and structured finance around the exchange ledger — these cannot be replicated by ordinary EVM chains through incentives.

CoreWriter also will not let HyperEVM become a synchronous extension of the order book. Cross-environment operations have ordering constraints, delayed writes, and state coordination issues that builders must handle regarding failure rollbacks, delayed execution, cross-environment collateral accounting, and risk management. While this reduces part of the design space, it also creates a unique moat.

Understanding the 2×2 Matrix of HyperEVM Economics

To assess HyperEVM applications, the best framework is a two-dimensional matrix:

• Horizontal axis: Does the application need general EVM logic?
• Vertical axis: Does the application directly combine with HyperCore's state or execution?

The category labels are not important; what matters is the dependency relationships that the product cannot eliminate.

Native EVM Finance

These applications require smart contracts, but the product models are mostly portable. AMM, money markets, CDP, routers, options venues, leveraged products, and yield markets all belong to this quadrant.

Felix is a typical representative. HyperLend also started here, as one of the main lending venues on HyperEVM (its roadmap will later evolve towards programmable HyperCore).

This quadrant is often underrated, but is actually very important. Any financial center needs banks, brokers, liquidity venues, and risk transfer markets to support more complex asset-liability products. Portability makes them the foundational layer of user activity.

Core Native Extension

These applications depend more directly on Hyperliquid, but the role of EVM is mainly to package, tokenize, or compose native primitives.

Typical examples include: Kinetiq, StakedHYPE, Kintsu, HLP wrapper, Unit-associated assets, etc. Their core mission is to make the assets within Hyperliquid more useful.

This quadrant is essential — collateral is the raw material for all financial activities. Money markets need assets that users are willing to borrow, structured products require assets that can be staked or hedged, and unified accounts need balances that can flow freely between different functions.

Programmable HyperCore

This is the most imaginative quadrant: applications need both EVM's general logic and deeply depend on HyperCore's state and execution. Here, exchange activities begin to be truly "productized."

• Rysk: Converts options into volatility income from users' existing assets;
• Liminal: Packages Hyperliquid strategies into tokenized products;
• Hyperbeat: Combines Core positions with the delta-neutral strategies of ERC-20 composability.

Derive occupies an edge position — it bridges the treasury through HyperEVM to make HYPE and kHYPE into collateral for options/perpetuals, but the core trading and settlement logic still lies in its own stack. It can expand the use of HYPE collateral, but does not strictly belong to the native programmable HyperCore.

Currently, projects that strictly fit the criteria of "contract-held assets + reading HyperCore state + executing with CoreWriter" are still in the early stage. Valantis Prime is a representative case in public beta: it uses HyperEVM smart accounts as a control layer, operates HyperCore through CoreWriter, and sets constraints such as permissions, proxies, session keys, guardians, making the account itself a programmable interface for the exchange.

HyperLend and Rysk also point to the same frontier from different angles, but ultimately, it still needs to be measured by the standard of "whether it genuinely holds assets and deeply integrates CoreWriter."

Financial Accounts are the Ultimate Form

The most valuable HyperEVM applications may not look like "applications" at all, but rather like an account.

Today, crypto users still have to switch between multiple interfaces: exchange balances are used for trading, wallet balances for DeFi, treasury shares represent yield, borrowing capability is hidden in money markets, and hedging requires opening another platform… This fragmentation is not just an experience issue, but also reflects the reality that liquidity, collateral, execution, and risk are dispersed across different systems.

HyperEVM has the opportunity to compress these systems into a single account. Users only need to deposit assets such as BTC, ETH, SOL, HYPE once; they can start from the same balance: trading on HyperCore, lending on HyperEVM, earning yields through the treasury, hedging with perpetuals, and directly completing expenditures from the payment account. The product is not a bridge; the product is that balance which can flow across functions.

Centralized exchanges have long understood this — their accounts feel unified because trading, margin, lending, and earnings are all in a controlled environment. But the problem lies in the closed ledger and opaque risk engines, preventing external developers from building freely.

Generic public chains are the opposite: users truly control accounts, but the financial stack is highly fragmented.

Hyperliquid occupies the sweet spot: HyperCore provides exchange-level liquidity and risk infrastructure, while HyperEVM offers an open application surface. The ultimate result is a unified financial account that is entirely controlled by the user, yet supported by HyperCore as a powerful balance sheet — this embodies the strongest realization of the "Universal Financial Home" vision.

Future evidence will appear at the account level: collateral follows users across trading, lending, saving, hedging, and spending; risk is priced in real-time from HyperCore's state; liquidation is deeply executed through HyperCore; structured products hedge with Core liquidity directly; and ERC-20 represents claims to various financial activities within the system.

The first wave of HyperEVM has made the ecosystem usable, and the next wave will make HyperCore truly programmable.