# Canonical: https://www.uddalak.xyz/hyperliquid-academy/article/31-hypercore-hyperevm-precompiles
# Author: Uddalak Das
# Last source: https://www.uddalak.xyz/hyperliquid-academy/article/31-hypercore-hyperevm-precompiles

---
title: "How HyperCore and HyperEVM Communicate"
description: "How HyperEVM smart contracts read HyperCore state through precompiles, and why that matters for DeFi composability."
track: "Architecture & Build"
level: "Advanced"
primary_icp: ["builder", "DeFi-native user"]
secondary_icp: ["institutional decision-maker"]
reading_time: "6 min"
last_reviewed: "2026-09-07"
---

# How HyperCore and HyperEVM Communicate

HyperCore and HyperEVM share Hyperliquid consensus but execute different types of state. HyperCore maintains native financial state such as order books, positions, balances, staking, and vault data. HyperEVM runs general purpose smart contracts.

The two environments communicate through explicit system interfaces rather than behaving like one undifferentiated program.

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

## Read precompiles expose selected HyperCore state

A precompile is callable from the EVM at a known system address, but its logic is implemented by the chain rather than ordinary Solidity bytecode.

Hyperliquid uses read precompiles to expose selected native state to contracts. Depending on the interface, a contract can inspect information such as spot balances, perpetual positions, oracle values, staking data, or vault state.

This allows an EVM application to make decisions using native HyperCore information without depending entirely on an external indexer.

For example, a strategy contract could inspect an oracle value before applying its own risk rule, or a vault could read relevant account state before determining whether another action is allowed.

## A shared L1 does not mean identical timing

Builders should not assume a precompile read and a HyperCore transaction occur inside one atomic execution frame.

HyperCore and HyperEVM have defined sequencing and state availability rules. The EVM view reflects the HyperCore state exposed at the relevant point in the chain's processing cycle.

For applications that only display data, small timing differences may be unimportant. For liquidation sensitive strategies or automated trading logic, the exact timing semantics can affect safety.

Production contracts should therefore be designed around the documented state boundary rather than an assumption of perfect simultaneity.

## CoreWriter handles supported actions in the other direction

[CoreWriter](/hyperliquid-academy/article/32-corewriter-explained) lets a HyperEVM contract encode a supported action for later processing by HyperCore.

This makes the connection bidirectional. A contract can read selected financial state, apply its own programmable logic, and request supported native actions.

The word supported is important. CoreWriter is not a general permission to mutate arbitrary HyperCore state. The protocol defines the action types that can cross the boundary and how they are encoded.

## Asynchronous execution changes application design

A contract that sends a CoreWriter action should not assume the corresponding HyperCore state change completed inside the same EVM call.

The application needs to handle pending state, possible failure, and the chance that relevant market conditions change before HyperCore processes the action.

This resembles distributed system design more than a chain of ordinary internal Solidity calls. Builders need explicit reconciliation and state transition handling.

## Why this architecture is useful

On another chain, an application might need an oracle bridge or offchain service to learn about positions on a separate exchange. Hyperliquid can expose selected native market state directly to contracts running on the same L1.

That creates useful building blocks for lending systems, structured products, automated vaults, collateral logic, and applications that combine EVM assets with native trading state.

It also preserves a clear security boundary. HyperCore remains specialized while HyperEVM remains programmable.

## What builders should verify before using the interfaces

Check the exact precompile address, returned data format, update timing, CoreWriter action schema, authorization model, and failure behavior from the current documentation.

Do not assume every Hyperliquid API action is available through CoreWriter or that every piece of HyperCore state has a read precompile.

## Continue reading

Read [Hyperliquid L1 Read Precompiles: Complete Guide](/hyperliquid-academy/article/80-hyperliquid-l1-read-precompiles-complete-guide) for the detailed read surface and [CoreWriter Actions: Complete Reference](/hyperliquid-academy/article/81-corewriter-actions-complete-reference) for supported writes.

## Sources

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