
T9 · Blockchain · Computed in your browser
This site’s own block and transaction pages, built from a committed snapshot, with every field tagged and a recompute button wherever the chain can prove it.
An explorer page mixes values copied from the chain, values it computed from them, and values it added from elsewhere. Read a page knowing which is which.
The key, used on every row
Built from the committed snapshot, fetched 2026-10-23. Open any row.
These four requests return what the panels above were built from. Send them to your own node, or any endpoint you trust, as JSON-RPC over HTTP POST. Then hash the header and compare.
The block (header fields, transaction hashes only)
{"jsonrpc":"2.0","id":1,"method":"eth_getBlockByNumber","params":["0x190a18f",false]}Its parent, for the base fee
{"jsonrpc":"2.0","id":2,"method":"eth_getBlockByNumber","params":["0x190a18e",false]}The transaction
{"jsonrpc":"2.0","id":3,"method":"eth_getTransactionByHash","params":["0x09a42b694a7c6af85d289c8ee503e8e1e1109e1487d9b3b51650e17343d345a5"]}Its receipt
{"jsonrpc":"2.0","id":4,"method":"eth_getTransactionReceipt","params":["0x09a42b694a7c6af85d289c8ee503e8e1e1109e1487d9b3b51650e17343d345a5"]}Fetched once from a public Ethereum node on 2026-10-23 and committed to this site; nothing is fetched while you read, and this site’s checks recompute every hash in it.
Every field on an explorer page comes from one of four places, and the colour on each row says which. Green fields are in the block header, which the block’s hash commits to. Blue ones are in the transaction the sender signed or the receipt the node made by running it. Amber ones are computed from those by arithmetic or hashing, so you can redo them. Magenta ones are the explorer’s own additions: the chain does not hold them. Open any row for what it means, where it comes from and the node call that returns it.
A block’s hash is not a field in the block. Every node computes it as the Keccak-256 hash of the header’s encoding, and the Recompute button does exactly that to the committed header. The transaction hash is the same: the hash of the transaction’s encoded bytes. For a typed transaction those bytes are the type number followed by the payload.
The base fee in a header is set by the block before it. The target is half the gas limit. If the parent used exactly the target, the fee stays; if more, it rises by the parent’s fee times the excess over the target, divided by the target and by 8, and by at least one wei; if less, it falls by the same expression for the shortfall. The Recompute button on Base fee per gas does that with the committed parent and checks it against this block’s header. Fees are shown in wei, the smallest unit, and never converted to a currency.
What the sender paid is derived: the gas used times the effective gas price, which is the base fee plus the smaller of the sender’s tip cap and the room under their fee cap. Burnt fees for the block are its gas used times its base fee. The gas limit and the other block figures are as of the snapshot date, and the page shows them only from the committed block.
The “tokens transferred” list is built by reading logs. A log records which contract wrote it, a first topic that is the hash of the event’s signature, any indexed arguments as further topics, and the rest as data. For a standard fungible-token Transfer, the two indexed addresses are the sender and receiver and the data is the amount. The explorer cannot know a transfer happened, only that this contract said so: any contract can write any log. Amounts here are raw units; the token’s name and decimals are separate lookups, which is why those slots are magenta and empty.
The extra-data field holds up to 32 bytes the block’s builder chose to write. It is in the header, so it is certain that the block carried it, and nobody checks what it says. Read it as text only with the button; the text is whatever was written. The fee recipient and every address on these pages are shown shortened and unlabelled: nothing on chain says who owns an address.
A transaction’s status is in the receipt. A failed transaction is still in its block, and it still paid for the gas it used. The block tags latest, safe and finalized, in the strip under the transaction, say how settled a block is: latest is the most recent block, and finalized is one that validators have voted to finalise, with two consecutive checkpoints backed by two-thirds of the staked ether. This block was at or behind finalized when it was fetched.
Where the data comes from: the Ethereum block, its parent, one transaction and its receipt were fetched once, on 2026-10-23, from a public node endpoint, and committed to this site; nothing is fetched while you read. The transaction was chosen because the token transfer it logs runs between two contracts (the sender of any transaction is always an account). The Bitcoin tab uses a testnet3 block from Bitcoin Core’s test data. The numbers recompute when this site is checked, so none of it depends on trusting where it came from.
Recompute a block hash and its base fee from your own node.
ethereum.org: block explorers Block explorers (ethereum.org). page updated 2026-03-02.
Read 2026-10-23: The field lists for block, transaction, account and token pages. The page names explorers; none is used here
Explorer indexer docs Indexer architecture overview (documentation of an open-source block explorer). undated.
Read 2026-10-23: Realtime and catch-up indexers; off-chain integrations for prices, verification and labels
Ethereum yellow paper Ethereum: A Secure Decentralised Generalised Transaction Ledger (Gavin Wood). Shanghai version efc5f9a, 2025-02-04. Its section 4.4 lists 17 header fields; the blob, beacon-root and requests-hash fields are not in it.
Read 2026-10-23: Section 3 (KEC is Keccak-256, not the final SHA-3), 4.4 (17 header fields, through baseFeePerGas and withdrawalsRoot), 4.4.1 (receipts and logs), Appendix B (RLP, titles)
EIP-2718 Typed Transaction Envelope (M. Zoltu). created 2020-06-13; Final.
Read 2026-10-23: a transaction is TransactionType || TransactionPayload or a legacy transaction; the type is a number from 0 to 0x7f; the transactions trie holds those bytes
EIP-1559 Fee market change for ETH 1.0 chain (V. Buterin, E. Conner, R. Dudley, M. Slipper, I. Norden, A. Bakhta). created 2019-04-13; Final.
Read 2026-10-23: the constants (denominator 8, elasticity 2), the base-fee reference code, the Backwards compatibility note that the base fee is one additional item at the end of the header, the type-2 payload and signature, the effective gas price and the burn
ERC-20 Token Standard (F. Vogelsteller, V. Buterin). created 2015-11-19; Final.
Read 2026-10-23: Methods and events; the Transfer event; the optional name, symbol and decimals
Solidity: ABI specification Contract ABI Specification (Solidity docs, latest). read 2026-10-23.
Read 2026-10-23: Function selectors and canonical signatures, static types in 32-byte words, events: topics[0] and indexed arguments
Solidity: introduction to smart contracts Introduction to Smart Contracts (Solidity docs, latest). read 2026-10-23.
Read 2026-10-23: Logs and events; gas used before a revert is not refunded
ethereum.org: JSON-RPC JSON-RPC API (ethereum.org). page updated 2026-06-28.
Read 2026-10-23: Block tags (latest, safe, finalized), hex encoding of quantities and data, the methods an explorer calls, receipt fields
ethereum.org: transactions Transactions (ethereum.org). page updated 2026-10-07.
Read 2026-10-23: The transaction’s fields and types, the lifecycle (pending, included, safe, finalized), 21,000 gas for a plain transfer
ethereum.org: proof of stake Proof-of-stake (ethereum.org). page updated 2026-10-07.
Read 2026-10-23: 12-second slots, 32-slot epochs, finality when two consecutive checkpoints gather votes from two-thirds of the staked ether
Bitcoin Core, blockfilters.json src/test/data/blockfilters.json, the BIP 158 test vectors, Bitcoin Core (MIT). tag v32.0, commit 465dde27. These are testnet3 blocks.
Read 2026-10-23: each vector’s block height, block hash and full block bytes; the first 80 bytes of each are the header used here
ethereum.org: nodes and clients Nodes and clients (ethereum.org). page updated 2026-07-13.
Read 2026-10-23: Execution and consensus clients; why run your own node
Everything here is paraphrased from the sources, not quoted at length, and every claim is attributed to one. Each entry says which parts of the source were read, and whether the build or the plan read them. Anything illustrative is labelled as such. Where a source is silent or could not be read, the page leaves the fact out.