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

---
title: "HyperCore Explained"
description: "How Hyperliquid's native financial execution environment handles markets, margin, matching, and state."
track: "Foundations"
level: "Beginner"
primary_icp: ["DeFi-native user", "trader"]
secondary_icp: ["builder", "institutional decision-maker"]
reading_time: "5 min"
last_reviewed: "2026-09-07"
---

# HyperCore Explained

HyperCore is Hyperliquid's native financial execution environment. It is where spot and perpetual order books, account balances, positions, margin checks, liquidations, vault state, staking, and several protocol level market primitives are maintained.

The useful distinction is between a blockchain that merely executes exchange contracts and a blockchain whose state machine already understands exchange activity. HyperCore belongs to the second category. Matching, clearing, and risk checks are part of the L1's financial state transition logic rather than logic delegated to a separate offchain engine.

```mermaid
flowchart LR
    A[Signed user action] --> B[HyperBFT orders transactions]
    B --> C[HyperCore validates state]
    C --> D[Order book matching]
    C --> E[Margin and risk checks]
    D --> F[Fills]
    F --> G[Balances and positions update]
    E --> G
```

## What HyperCore actually stores

HyperCore contains market state and account state that a normal general purpose chain would leave to application contracts.

For markets, that includes native central limit order books, resting orders, fills, spot pairs, perpetual contracts, funding related state, and market specific parameters. For accounts, it includes balances, positions, entry prices, unrealized profit and loss, margin requirements, staking balances, vault participation, and other financial state.

This matters because every validator executing the same committed transaction order arrives at the same market outcome. Matching is therefore not a private service run beside the chain.

## Matching and clearing happen together

An order book alone is not enough to run a leveraged exchange. After two orders match, the system must update both traders' positions, transfer fees, recalculate margin, and ensure the resulting accounts remain valid.

HyperCore performs those steps inside the same financial execution environment. A fill is not considered separately from the balance sheet it changes.

That is why [the trade lifecycle](/hyperliquid-academy/article/05-trade-lifecycle) includes consensus, validation, matching, and clearing rather than only a price match.

## Why HyperCore is specialized

Exchange workloads are unusually sensitive to transaction ordering, latency, and repeated state updates. A liquid market can process large numbers of order submissions and cancellations while continuously recalculating positions and risk.

Hyperliquid's documentation currently reports about 200,000 orders per second of mainnet capacity, with the execution layer described as the current throughput bottleneck. It also reports roughly 0.2 second median end to end latency and 0.9 second p99 latency for geographically colocated clients. Those figures describe protocol performance under stated conditions, not a guarantee for every trader or API client.

Specialization comes with a boundary. HyperCore is not where arbitrary Solidity applications are deployed. General application logic belongs on [HyperEVM](/hyperliquid-academy/article/03-hyperevm-explained).

## HyperCore and HyperEVM share one L1

HyperCore and HyperEVM are different execution environments under the same Hyperliquid consensus. Contracts on HyperEVM can read selected HyperCore state through precompiles. Supported actions can move in the other direction through [CoreWriter](/hyperliquid-academy/article/32-corewriter-explained).

This division lets the chain keep trading logic specialized while still supporting open smart contract development. A lending protocol, vault, or options application can live on HyperEVM and still compose with parts of HyperCore state through explicit interfaces.

## What HyperCore does not guarantee

Native execution does not guarantee deep liquidity, profitable trading, stable oracle inputs, or low slippage in every market. Those depend on participants, market design, risk parameters, and external conditions.

HyperCore solves a narrower infrastructure problem. It makes exchange state and financial risk part of the chain's native execution model.

## Continue reading

Next, read [HyperEVM Explained](/hyperliquid-academy/article/03-hyperevm-explained) for the programmable side of the network and [HyperBFT Explained](/hyperliquid-academy/article/04-hyperbft-explained) for the consensus layer that orders transactions before HyperCore executes them.

## Sources

- https://hyperliquid.gitbook.io/hyperliquid-docs/hypercore
- https://hyperliquid.gitbook.io/hyperliquid-docs/hypercore/overview
- https://hyperliquid.gitbook.io/hyperliquid-docs/hypercore/clearinghouse