Indexed Hedera EVMBlockchain Data

Hedera EVM is the smart-contract service inside Hedera, not a separate network and not a rollup. It has no consensus of its own and settles to nothing: a deployment or a call is an ordinary Hedera transaction, ordered by the same hashgraph voting and consensus timestamps as an HBAR transfer, and the service has been part of the network since its mainnet opened in 2019. Gas is charged in HBAR. Above that boundary it behaves as an EVM team expects, with Solidity bytecode deploying unchanged and ERC-20 and ERC-721 contracts decoding against their ABIs. Two things are local. A Hedera account is numbered and reaches this service through an EVM address alias, so one owner has two identifiers. And a token issued by the Hedera Token Service is reachable from a contract through a system contract, so an ERC-20 interface here can be a view onto a protocol-level asset.

SonarX indexes this surface in the shapes an EVM team already queries: contract deployments and calls, receipts, event logs decoded against contract ABIs, internal value transfers, and token transfers and balances. Those records land in the normalized model SonarX uses on every network it covers.

Full historical coverage is provisioned for Hedera EVM on request. Balance tables and the balance APIs can be enabled for Hedera EVM on request. Kafka streaming can be enabled for Hedera EVM on request.

This service has no ledger of its own, and that is the engineering story. Its transactions are the ledger’s transactions, so contract records carry consensus timestamps and any block number attached to them is derived rather than native. Token pointers are the second trap: an ERC-20 interface may present a Hedera Token Service asset through a system contract, so counting the interface and the protocol asset separately states one holding twice. Identity is the third, since an owner reaches contracts through an EVM alias while the ledger knows it as a numbered account. Contract records and native records therefore join on a timestamp, never on a height.

Protocol analytics is the direct case: lending, exchange and vault contracts studied through decoded logs and internal transfers rather than through balances alone, and DeFi analytics is the solution area it sits in. Token accounting is the recurring one, and it hinges on resolving system-contract views, because a report that counts an ERC-20 interface and the ledger asset behind it states the same position twice. Contract-level risk work is the third, tracing which deployments hold assets that also move through native transfers, which is a join across the two datasets rather than a single query. Teams comparing dual-surface designs usually pull Sei EVM alongside this one.

Tell us the delivery target, how far back you need and how fresh it has to be, and the share is scoped against that. Hedera EVM coverage is provisioned on request, so tell us the history depth and the delivery target and we will scope it. The published coverage matrix for every network SonarX indexes lives in the data documentation, and the rest of the catalogue is at all indexed chains.