erigon_getHeaderByNumber
JSON-RPC method retrieves block header information by block number on the Hyperliquid EVM blockchain. This method is an alias for ots_getHeaderByNumber
and exists for compatibility with tools expecting Erigon-specific endpoints.
Get your own node endpoint todayStart for free and get your app to production levels immediately. No credit card required.You can sign up with your GitHub, X, Google, or Microsoft account.
Parameters
- block number (integer, required): The block number to retrieve the header for
Response
The method returns a block header object with the following fields:Response structure
number
— the block numberhash
— the block hashparentHash
— the parent block hashnonce
— proof-of-work nonce (always 0x0000000000000000 for PoS)sha3Uncles
— SHA3 hash of the uncles datalogsBloom
— bloom filter for the logstransactionsRoot
— root of the transaction triestateRoot
— root of the final state triereceiptsRoot
— root of the receipts trieminer
— address of the beneficiarydifficulty
— difficulty for this blocktotalDifficulty
— total difficulty of the chain until this blockextraData
— extra data field of this blocksize
— size of this block in bytesgasLimit
— maximum gas allowed in this blockgasUsed
— total gas used by all transactionstimestamp
— Unix timestamp of the blockmixHash
— mix hash for the blockbaseFeePerGas
— base fee per gas (post-EIP-1559)
Usage example
Shell
Example response
Compatibility note
This method is functionally identical toots_getHeaderByNumber
. The erigon_
prefix exists for compatibility with:
- Otterscan block explorer (which checks for Erigon nodes)
- Tools expecting Erigon-specific endpoints
- Migration paths from Erigon to other node implementations
Use cases
Theerigon_getHeaderByNumber
method is essential for:
- Otterscan compatibility: Allow Otterscan to detect node type
- Tool migration: Support tools moving from Erigon nodes
- Block header retrieval: Efficiently fetch header data
- Cross-client compatibility: Work with tools supporting multiple clients
- Legacy support: Maintain compatibility with older integrations
- Node detection: Identify nodes supporting Erigon-like APIs
- Development tools: Support development frameworks expecting Erigon
- Block verification: Validate block headers across different clients
- API standardization: Provide familiar endpoints for developers
- Infrastructure flexibility: Allow switching between node types
Body
application/json