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 number
- hash— the block hash
- parentHash— the parent block hash
- nonce— proof-of-work nonce (always 0x0000000000000000 for PoS)
- sha3Uncles— SHA3 hash of the uncles data
- logsBloom— bloom filter for the logs
- transactionsRoot— root of the transaction trie
- stateRoot— root of the final state trie
- receiptsRoot— root of the receipts trie
- miner— address of the beneficiary
- difficulty— difficulty for this block
- totalDifficulty— total difficulty of the chain until this block
- extraData— extra data field of this block
- size— size of this block in bytes
- gasLimit— maximum gas allowed in this block
- gasUsed— total gas used by all transactions
- timestamp— Unix timestamp of the block
- mixHash— mix hash for the block
- baseFeePerGas— 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