HyperEVM Architecture

Launching soon. The vault described here is not yet deployed on mainnet.


The Zirodelta Lending Vault is only possible because of two pieces of Hyperliquid's infrastructure that do not exist anywhere else: HyperEVM and the CoreWriter precompile. This document explains what they are and why they matter for the vault's design.

What HyperEVM is

HyperEVM is Hyperliquid's EVM-compatible execution layer. It runs alongside Hyperliquid L1 (HyperCore) and allows Solidity smart contracts to be deployed using standard EVM tooling.

From a developer perspective, HyperEVM looks like a standard EVM chain. You can deploy contracts with Foundry, interact with them via ethers.js, and use the standard Solidity toolchain. What makes it different is what HyperEVM contracts can access.

The CoreWriter precompile

A precompile is a special address on an EVM chain that executes native code instead of EVM bytecode. Standard EVM chains have a handful of precompiles for operations like hashing and elliptic curve math.

Hyperliquid adds its own precompile: CoreWriter. A Solidity contract deployed on HyperEVM can call CoreWriter to execute Hyperliquid L1 exchange actions directly. This includes:

  • Supplying assets to Hyperliquid's native borrow/lend reserve

  • Borrowing from the borrow/lend reserve

  • Placing spot market orders on Hyperliquid L1

  • Transferring tokens between accounts

These are the exact operations the Zirodelta vault needs. Without CoreWriter:

  • A HyperEVM contract could not supply assets to HL's lending protocol

  • A HyperEVM contract could not initiate a spot borrow

  • The vault would be an island. A standard ERC-4626 vault disconnected from HL's L1 yield infrastructure

With CoreWriter, the vault is a first-class participant in Hyperliquid's native borrow/lend market.

Why this cannot be replicated on other chains

The phrase "no bridge, no wrapper, no cross-chain message" is not marketing. It is a technical description of what CoreWriter eliminates.

On any other EVM chain, for a smart contract to interact with Hyperliquid L1:

  1. Assets would need to be bridged out of Hyperliquid to the EVM chain (adding bridge risk)

  2. A wrapped token representing the asset would need to exist on the EVM chain

  3. A cross-chain messaging system (like LayerZero or Axelar) would need to relay instructions back to Hyperliquid

  4. Each step introduces latency, gas costs, counterparty risk, and operational complexity

CoreWriter replaces all of that with a single Solidity function call. The EVM contract and the Hyperliquid L1 reserve exist in the same system. The call is atomic. It either succeeds or fails as one unit, with no partial state where assets are in transit.

How the vault uses CoreWriter

The vault's deposit-to-yield flow works like this:

Every step that touches Hyperliquid L1 goes through CoreWriter. No bridge. No wrapped token. No external oracle for rates. The vault reads supply and borrow rates directly from the HL lending reserve state.

Reading the lending reserve

The vault also reads Hyperliquid L1 data to price shares and calculate yields. The relevant info endpoints are:

These are the same endpoints documented in Endpoints. The vault uses them to determine the current yield rate for depositors and the current cost of borrowing for traders.

Audit and deployment

The vault contract will be audited before deployment on HyperEVM mainnet. Audit reports will be published at zirodelta.com/researcharrow-up-right when available.

See also: Vault Overview · Depositing · Key Concepts: CoreWriter

Last updated

Was this helpful?