# HyperEVM on Substreams Now Supports Extended Blocks

**URL:** <https://forum.thegraph.com/t/hyperevm-on-substreams-now-supports-extended-blocks/7090>\
**Category:** General\
**Created:** [September 28, 2026, 7:16pm UTC](https://forum.thegraph.com/t/hyperevm-on-substreams-now-supports-extended-blocks/7090 "2026-09-28T19:16:07Z")\
**Posts on this page:** 1\
**Page:** 1

<div class="post-metadata">

**Author:** ![brandonkramer](https://sea2.discourse-cdn.com/flex020/user_avatar/forum.thegraph.com/brandonkramer/32/1336_2.png) [@brandonkramer](https://forum.thegraph.com/u/brandonkramer)\
**Post date:** [September 28, 2026, 7:16pm UTC](https://forum.thegraph.com/t/hyperevm-on-substreams-now-supports-extended-blocks/7090/1 "2026-09-28T19:16:07Z")

</div>

Substreams and Firehose endpoints for HyperEVM, [operated by Pinax](https://app.pinax.network/docs?from=nav), 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**

- The Graph Docs: [HyperEVM Mainnet | Docs | The Graph](https://thegraph.com/docs/en/supported-networks/hyper-evm/)

- Pinax chain page: [HYPEREVM Blockchain Data | Pinax](https://pinax.network/chain/hyperevm)

- Developer docs: [https://substreams.dev](https://substreams.dev)

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](mailto:info@thegraph.foundation) via email.