Pinax Launches Extended Blocks for HyperEVM

Full execution traces for Hyperliquid’s EVM, now in the Pinax app.

Starting today, Pinax serves HyperEVM as extended blocks on our Firehose and Substreams endpoints. Until now, HyperEVM was only available as base blocks. That meant you could index what contracts logged, but not everything they did.

To close that gap we built custom instrumentation into the HyperEVM node. This post covers what changed, what we built, and how to start using it.

Base blocks vs extended blocks

Firehose has two ways to build an EVM block. Both use the same schema, sf.ethereum.type.v2.Block. The difference is where the data comes from.

• Base blocks are rebuilt by polling a standard JSON-RPC node. You get block headers, transactions, receipts and event logs.
• Extended blocks come from an instrumented node that records the full execution of every transaction. You get everything above, plus internal calls, native value transfers inside calls, balance changes, storage changes, nonce and code changes, and gas used per call.

The block’s detail_level field tells you which one you’re reading. Our guide to block types has the full comparison and shows how to check any chain.

What we built

HyperEVM runs on its own node software, and no Firehose instrumentation existed for it. Getting to extended blocks meant adding tracing directly to the node’s execution path. It now records:

• Full transaction traces: nested call trees with call type, caller, address, value, input, output, gas and status for every call.
• Per-call state changes: balance, storage, nonce and code changes, including contract creation.
• Classified balance changes: each balance movement carries a reason, so fees, transfers and system movements can be told apart.
• Stable ordinals: receipt logs, call logs and state changes follow a single ordering, so downstream systems can reconcile exactly and replay safely.
• System calls: HyperEVM system and protocol-level activity is instrumented alongside user transactions.

Why it matters on HyperEVM

Logs only show what a contract chose to emit. On HyperEVM, a lot happens without an event:

• Native HYPE inside a call. A liquidation paying out in HYPE, a WHYPE unwrap or a fee sweep to a treasury moves value through internal calls. Extended blocks record the balance change.
• Reads from HyperCore. Contracts read positions, spot balances and oracle prices from HyperCore through precompiles. Those reads emit no event, so they only show up in a call trace. Writes through CoreWriter emit a log, and extended blocks add the call path behind each one.
• State that changes quietly. A health factor crossing a threshold, a vault share price updating, an oracle write. A Substreams module can now trigger on the storage change itself instead of waiting for an event that may never come.

For accounting, reconciliation, compliance and protocol analytics, you can now build from what actually executed, not only from what was logged.

What changes for developers

• Modules port over. Substreams modules written for Ethereum, Base or Arbitrum that rely on calls or state changes now run on HyperEVM without a rewrite.
• Call-based foundations work. Modules such as ERC-20 metadata extraction and native balance tracking, which read from calls rather than logs, now work on HyperEVM.
• Reorg-safe streaming. Firehose handles forks for you and removes RPC polling, so real-time consumers get consistent data without extra code.
• Send it anywhere. Substreams can sink to SQL, ClickHouse, a key-value store, PubSub, files or a Subgraph.

One trade-off: extended blocks are larger, so Substreams egress is higher than on base blocks. For log-only workloads, you’ll see little difference in results but more data transferred.

Get started in the Pinax app

1. Sign up and create an API key at app.pinax.network.
2. Point your Substreams or Firehose client at the HyperEVM endpoint:
   Substreams: hyperevm.substreams.pinax.network:443
   Firehose: hyperevm.firehose.pinax.network:443
3. Check that you’re receiving extended blocks: detail_level should read DETAIL_LEVEL_EXTENDED. The block types guide explains how.

The Pinax docs cover authentication, endpoints and sinks. Chain details are at pinax.network/chain/hyperevm.

HyperEVM extended blocks are also available through The Graph Market, served from the same Pinax infrastructure.

Building on HyperEVM and need execution-level data at scale? Talk to us. We’d like to hear what you’re working on.