# Canonical: https://www.uddalak.xyz/hyperliquid-academy/article/54-hyperliquid-state-what-lives-where
# Author: Uddalak Das
# Last source: https://www.uddalak.xyz/hyperliquid-academy/article/54-hyperliquid-state-what-lives-where

---
title: "Understanding Hyperliquid State: What Lives Where?"
description: "Hyperliquid state is split by function across HyperCore and HyperEVM, with explicit interfaces connecting native market state to EVM applications."
pillar: "Foundations"
track: "Foundations"
cluster: "Foundations"
level: "Intermediate"
primary_icp: ["builder", "DeFi-native user"]
secondary_icp: ["institutional decision-maker"]
content_type: "reference"
reading_time: "3 min"
last_reviewed: "2026-09-07"
last_verified: "2026-09-07"
volatile: false
prerequisites: ["53-hypercore-vs-hyperevm"]
related: ["61-hypercore-hyperevm-precompiles", "72-hypercore-to-hyperevm-asset-transfers", "85-hyperliquid-market-data-is-structured"]
---

# Understanding Hyperliquid State: What Lives Where?

Understanding Hyperliquid gets easier once you stop treating “the chain” as one undifferentiated database. HyperCore stores the native market and account state required for trading. HyperEVM stores EVM accounts, contracts, storage, and transaction state. Both advance under HyperBFT, but applications access them through different APIs and system interfaces.

## HyperCore state

HyperCore maintains the pieces a native exchange needs: spot and perpetual markets, order books, account balances, positions, margin information, oracle inputs, funding state, vault information, staking state, and protocol-specific asset metadata.

The Info API and WebSocket subscriptions expose much of this state to offchain applications. HyperEVM read precompiles expose a selected subset directly to contracts.

## HyperEVM state

HyperEVM looks more familiar to Ethereum developers. Addresses have native HYPE balances for gas, contracts have bytecode and storage, ERC-20 tokens maintain contract-level balances, and transactions execute EVM calls.

An asset representation on HyperEVM should not automatically be treated as the same accounting object as a corresponding HyperCore balance. The transfer path between environments matters.

## State transitions across the boundary

The two environments communicate through protocol-defined mechanisms rather than arbitrary shared-memory access. Read precompiles allow one-way reads of supported HyperCore state. CoreWriter queues supported actions from HyperEVM into HyperCore. System transfers move assets where the protocol supports them.

Those constraints are a feature. They make the boundary explicit, which lets developers reason about timing, permissions, and failure cases instead of assuming every piece of state is instantly writable everywhere.

## Why this matters for debugging and risk

If an application shows an unexpected balance, the first question should be: which environment's balance is being displayed? If an EVM transaction succeeds but a native action has not appeared yet, the next question is whether the cross-environment action has been processed. If a trading bot sees a position discrepancy, the source of truth should be the appropriate HyperCore state, not a stale frontend cache.

This distinction also matters for audits. A HyperEVM protocol can be correct at the Solidity level while still mishandling native-state timing, oracle interpretation, or asset transfers.

## How this connects

Start with [HyperCore vs HyperEVM: Which Layer Does What?](/hyperliquid-academy/article/53-hypercore-vs-hyperevm) if the underlying concept is unfamiliar. Related reading: `61-hypercore-hyperevm-precompiles`, `72-hypercore-to-hyperevm-asset-transfers`, `85-hyperliquid-market-data-is-structured`.

## Sources

- https://hyperliquid.gitbook.io/hyperliquid-docs/hypercore/overview
- https://hyperliquid.gitbook.io/hyperliquid-docs/for-developers/hyperevm
- https://hyperliquid.gitbook.io/hyperliquid-docs/for-developers/hyperevm/hypercore-less-than-greater-than-hyperevm-transfers