# Canonical: https://www.uddalak.xyz/hyperliquid-academy/article/03-hyperevm-explained
# Author: Uddalak Das
# Last source: https://www.uddalak.xyz/hyperliquid-academy/article/03-hyperevm-explained

---
title: "HyperEVM Explained"
description: "What HyperEVM is, why it exists, and how smart contracts connect to HyperCore."
track: "Foundations"
level: "Beginner"
primary_icp: ["builder", "DeFi-native user"]
secondary_icp: ["institutional decision-maker"]
reading_time: "5 min"
last_reviewed: "2026-09-07"
---

# HyperEVM Explained

HyperEVM is Hyperliquid's general purpose smart contract environment. It gives developers an EVM compatible execution surface on the same L1 that contains HyperCore, so Solidity applications can exist beside Hyperliquid's native financial engine.

The architecture separates two jobs. HyperCore specializes in exchange state such as order books, positions, margin, and liquidations. HyperEVM handles arbitrary application logic that does not need to become part of the native exchange engine.

```mermaid
flowchart LR
    A[HyperCore financial state] --> B[Read precompiles]
    B --> C[HyperEVM contract]
    C --> D[Application logic]
    D --> E[CoreWriter]
    E --> A
```

## What runs on HyperEVM

HyperEVM can host the kinds of contracts developers already build on other EVM chains. That includes lending markets, automated market makers, liquid staking systems, vaults, token contracts, options protocols, account tooling, and application specific logic.

This is why protocols such as HyperLend, Morpho, Kinetiq, Valantis, Rysk, and other ecosystem applications can build around Hyperliquid without forcing their logic into HyperCore.

The distinction also keeps native market infrastructure focused. HyperCore does not need to absorb every new financial application as a protocol level feature.

## EVM compatibility matters for builders

Developers can use familiar Solidity patterns, Ethereum tooling, wallet integrations, and standard contract development workflows. The chain identifier, gas asset, and network specific interfaces still need to be configured correctly, but teams do not need to learn an entirely new smart contract language to deploy applications.

HYPE is used as the gas asset on HyperEVM. Gas on HyperEVM is separate from the trading fee model used for HyperCore orders, which is why [gas and trading fees should not be treated as the same cost](/hyperliquid-academy/article/56-hyperevm-gas-vs-hypercore-trading).

## Reading HyperCore from a contract

HyperEVM contracts can access selected HyperCore data through read precompiles. These system interfaces expose information such as positions, spot balances, oracle prices, vault equity, staking information, and other approved state.

A precompile looks callable from the EVM side but its implementation is provided by the chain. This gives contracts a direct route to selected native market state without requiring every application to maintain its own offchain replica.

The exact timing semantics matter. A developer building liquidation sensitive or trading sensitive logic should understand when the precompile view is updated relative to HyperCore execution rather than assuming every read is simultaneous with every native action.

## Sending actions toward HyperCore

[CoreWriter](/hyperliquid-academy/article/32-corewriter-explained) provides the opposite direction. A HyperEVM contract can encode supported HyperCore actions and send them for later processing.

That does not make the two environments one atomic execution frame. An EVM contract call can submit a supported action, but HyperCore processes that action under its own rules and timing. Builders therefore need to model pending state, failures, and changes that can happen between submission and execution.

## Why the split matters

A general purpose EVM is flexible. A native exchange engine is specialized. Hyperliquid keeps both, with explicit interfaces between them.

For users, this means the same network can support direct trading on HyperCore and application driven DeFi on HyperEVM. For builders, it means an application can use smart contract logic while still connecting to selected native financial state rather than recreating an exchange from scratch.

## Continue reading

Read [How HyperCore and HyperEVM Communicate](/hyperliquid-academy/article/31-hypercore-hyperevm-precompiles) for the interface boundary, then [CoreWriter Explained](/hyperliquid-academy/article/32-corewriter-explained) for supported writes back toward HyperCore.

## Sources

- https://hyperliquid.gitbook.io/hyperliquid-docs/for-developers/hyperevm
- https://hyperliquid.gitbook.io/hyperliquid-docs/for-developers/hyperevm/interacting-with-hypercore