HyperEVM on Substreams Now Supports Extended Blocks

General
1

Substreams and Firehose endpoints for HyperEVM, operated by Pinax, now serve extended blocks. Until now HyperEVM was served as base blocks. This post covers what changed and what it means if you index Hyperliquid’s EVM.

Base versus extended

Firehose, the extraction layer under Substreams, has two EVM block models.

  • A base block is built by polling an RPC node and holds only what the RPC exposes: header, transactions, receipts, logs.
    An extended block is built from an instrumented node and holds the full execution trace: every internal call with caller, input, output, and gas; every balance change; every storage write; every code change. Both use the same protobuf, sf.ethereum.type.v2.Block. On a base block the trace fields are empty, and detail_level tells you which model you are reading.

What this unlocks on HyperEVM

Three things on HyperEVM routinely happen without an event:

  • Native HYPE transfers inside a call. Liquidations paid in HYPE, WHYPE unwraps, fee sweeps to a treasury. Extended blocks record the balance change.

  • Storage changes. A health factor crossing a threshold, a vault share price updating, an oracle write. A module can trigger on the variable itself instead of waiting for a Transfer that may never come.

  • Calls into HyperCore. HyperEVM contracts read HyperCore state (positions, spot balances, oracle prices) through read precompiles. Those reads emit no event, so they only appear in a call trace, and extended blocks record both the query and the value HyperCore returned. Writes go through CoreWriter, which emits a RawAction log; extended blocks add the full call path behind each action, so you can see which contract sent it and what else changed in the same call.

In practice

Foundational modules that read from calls, such as ERC-20 metadata extraction, now work on HyperEVM. Modules written for Ethereum, Base, or Arbitrum that depend on call or state data port over without a rewrite. Firehose removes the RPC round-trips polling requires and handles forks, so real-time consumers get reorg-safe data with no extra code. Output goes to SQL, key-value stores, PubSub, files, or a Subgraph: one module, many sinks.

Get started

Questions about the block model or migrating a module from base to extended are welcome in this thread or by reaching out to The Graph Foundation via email.