Events and logs

Logs work exactly as on Ethereum. The thing to know is not about logs, it is about the state window behind the endpoint you are reading them from.

Reading logs

const logs = await provider.getLogs({
  address: '0x…',
  topics: [id('Bumped(address,uint256)')],
  fromBlock: head - 5000,
  toBlock: head,
});

eth_getLogs, bloom filters, indexed topics and receipt logs are standard. Contract events are emitted, indexed and filtered the way any Ethereum tool expects.

The 512-block state window

The public RPC keeps state for 512 blocks. Beyond that window, state reads are refused (measured on both public endpoints on 2026-10-15):

• eth_getBalance, eth_getCode, eth_getTransactionCount and eth_getProof answer

-32000 World state unavailable.

• eth_call answers -32603 Internal error.

At about 0.62 seconds per block, 512 blocks is about five minutes. Anything older is outside the window.

Earlier, eth_getTransactionCount beyond the window returned a false 0x0 instead of an error, an answer that looks like a measurement. If your code was written against that behaviour, treat an error at an old height as "not answerable on this endpoint", never as zero.

Prove facts about accounts with eth_getProof inside the window, which either answers with a proof or fails. Never with a nonce read at an old height.

Historical logs

For history beyond the window, use the indexer rather than the RPC. It holds indexed transactions per address and per block. See Indexer API.

If you need full history under your own control, run an archive node. The package and the exact options are published; see Run a node.

Log volume and empty blocks

The chain produces a block about every 0.62 seconds whether or not there are transactions, so most blocks are empty and carry no logs. A subscriber that treats a run of empty blocks as a stall will raise false alarms; chain liveness is the block number advancing, not the transaction count.

A note on log-filter caches

If you run a node, the log-filter cache can grow to several gigabytes while being almost entirely zeros. It is a computed index, not history: it can be rebuilt, so clearing it loses no chain data. Headers are not in that category and must never be treated the same way.