The explorer, over the whole chain

The explorer reads the same warehouse the datasets are cut from: every event
log Ethereum has emitted, back to genesis. A block-by-block explorer shows you
one block. This one answers the questions a paper asks: everything one contract
did in March, every Swap a pool emitted around a depeg, every log a wallet
touched in a block range you can name.

Search

The search box at Explorer classifies what you paste:

The 0x prefix is optional. Anything else is refused with a note, never
guessed at. The catalogue underneath the box lists common event signatures
(Transfer, Swap, Sync, and so on) as one-click searches.

The address lens

/explorer/address/0x… lists every log where the address is the sender,
the recipient or the emitting contract, newest first. Each row links to
its block, its transaction and its emitter, and names the event when the
signature is one we recognise.

Notes your space has attached to the address appear under it, and any signed-in
reader can add one.

The event lens

/explorer/events/0x… lists every log carrying that signature, with the
contracts that emitted it most inside the range on the left. Click an emitter
to open its address lens already narrowed to this event.

How fresh the lenses are

Both lenses read the warehouse’s bulk table, which the ingester confirms
64 blocks (about thirteen minutes) behind the chain. For the newest 100
blocks they read the head window instead, the table the chain-head follower
keeps within seconds of the head, so a transaction from the last minute is on
the page with its logs. The seam is invisible: the two parts are read under
the same filters and the same cursor, so paging older crosses it without a
row repeating or going missing. A range you close explicitly (a block or date
filter with an end) is history and reads the bulk table alone.

The head window is unfinalized by definition: a reorg can rewrite it, and
the follower repairs it when one does. The bulk table is the record; the
window is what lets you look before the record is written. The status page
shows where each ends.

Filters: block range, date range, event

Both lenses open on the newest 50,000 blocks (about seven days), and both say
so. To read further back, set a range:

• Block from / Block to. Exact, and the fastest: the warehouse is
  partitioned by block number.
• Date from / Date to. UTC calendar days, translated to blocks before the
  query runs: the first block mined on Date from and the last block mined on
  Date to. The readout under the form always shows the block range that was
  actually read, so a date never hides its translation. A date the chain does
  not reach (tomorrow, or before ingestion began) is ignored, and the page says
  which bound it dropped.
• Event (address lens only). Narrows the address’s logs to one signature.

Both a block bound and a date bound may be set; the tighter one wins. A range
can reach back to genesis, and a wide range over a busy contract is simply
more pages.

Pages: newer and older

A page holds 100 logs. Older and Newer move by cursor, not by page
number: each link names the last block and log index it saw, and the next page
is everything strictly beyond it. A page therefore never shifts under you when
the ingester appends a block, and a link you copy today opens on the same rows
tomorrow (inside the same range). An expired or edited cursor returns you to
the first page with a note.

Taking the data

Download CSV exports the rows the filters describe, not just the page on
screen, with every column of the raw log table: block, timestamp, transaction
hash and index, sender, recipient, value, emitter, the four topics, the data
blob and the log index. It needs the Data subscription and is capped at
50,000 rows inline.

Beyond the cap, or for anything you would rather have run in the background,
create a data request opens the raw-logs query manager with the same
address, event and block range already filled in. See
Downloading data for how a request is sized and run.

Blocks and transactions

A block page lists its transactions with status, gas used and the
fee, read from receipts fetched in one batch alongside the block. If the node
cannot return receipts the page says “receipts unavailable” above the table
rather than showing every transaction as pending; open a transaction to fetch
its receipt on its own.

A transaction page decodes its logs against the signatures we know, labels the
contracts it touched, and shows the notes your space has attached to any value
on it. Save to research on either page snapshots it into a research page
(see Research pages).

What the explorer does not do

• It does not hold balances or a transaction list per address. The warehouse is
  event logs; a plain ETH transfer that emitted no log is not in it.
• It does not count. Pages are cursors, so there is no “page 7 of 340”: the
  CSV and the data-request estimate are where a row count comes from.