# Canonical: https://www.uddalak.xyz/hyperliquid-academy/article/120-how-hyperevm-applications-use-hypercore-liquidity
# Author: Uddalak Das
# Last source: https://www.uddalak.xyz/hyperliquid-academy/article/120-how-hyperevm-applications-use-hypercore-liquidity

---
title: "How HyperEVM Applications Use HyperCore Liquidity"
description: "HyperEVM applications can read native market state, move assets, and trigger supported HyperCore actions, letting smart contracts build around HyperCore liquidity without recreating the order book inside the EVM."
pillar: "Ecosystem"
track: "Ecosystem"
cluster: "Ecosystem"
level: "Advanced"
primary_icp: ["builder", "DeFi-native user"]
secondary_icp: ["institutional decision-maker"]
content_type: "mechanism"
reading_time: "3 min"
last_reviewed: "2026-09-07"
last_verified: "2026-09-07"
volatile: true
prerequisites: ["31-hypercore-hyperevm-precompiles", "32-corewriter-explained"]
related: ["79-hyperevm-lending-hypercore-portfolio-margin", "111-hyperevm-ecosystem-map"]
---

# How HyperEVM Applications Use HyperCore Liquidity

HyperCore liquidity becomes useful to HyperEVM applications through explicit interfaces. Read precompiles expose selected balances, positions, prices, and other state. CoreWriter sends supported actions back to HyperCore. Native transfer paths move capital between the environments. Together, these interfaces let a lending, vault, staking, or structured-product contract use HyperCore as a financial primitive.

## Read before acting

A contract can inspect supported HyperCore state rather than depend entirely on an offchain keeper's database. Position-aware applications can use this information in eligibility, accounting, or risk logic.

## Write supported actions

CoreWriter can submit defined action types. This makes contract-controlled hedging, staking, vault allocation, or lending operations possible while preserving HyperCore's own validation and execution rules.

## Capital mobility

An application can move supported assets between HyperEVM and HyperCore, but the transfer has explicit timing. Capital is not one instantly shared balance across both environments.

## Examples

A vault can hold EVM assets and hedge native perp exposure. A liquid staking protocol can manage HyperCore delegation while issuing an EVM receipt token. A lending application can let users unlock capital that is later deployed into native markets. A structured product can package EVM contracts around native execution.

## Where composability breaks

Not every HyperCore operation is exposed to contracts, and EVM state is not atomically identical to HyperCore state. Delay, unsupported actions, asset representation, account initialization, and separate liquidation systems are boundaries the application must respect.

Good architecture treats those boundaries as interfaces, not implementation details to ignore.

## How this connects

Start with [How HyperCore and HyperEVM Communicate](/hyperliquid-academy/article/31-hypercore-hyperevm-precompiles), [CoreWriter Explained](/hyperliquid-academy/article/32-corewriter-explained) if the underlying concept is unfamiliar. Related reading: [How HyperEVM Lending Composes With HyperCore Portfolio Margin](/hyperliquid-academy/article/79-hyperevm-lending-hypercore-portfolio-margin), [The HyperEVM Ecosystem Map](/hyperliquid-academy/article/111-hyperevm-ecosystem-map).

## Sources

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