STEP 1 OF 3
NEXT: How the address is derived →
L1 EVENT LOG · WATCHED, NOT TRUSTED
event BatchPosted(uint256 indexed rollupCount);
address
0xA9c1…04Fe (EEZ)
topics[0]
keccak256("BatchPosted(uint256)")
topics[1]
rollupCount (indexed) =
3
— rollups settled in this batch, not a batch ordinal
data
(empty — nothing but the indexed topic)
tx calldata
the batch payload — this is what the deriver decodes
DERIVER SCANNING L1 — NO NODE OPERATOR CONSULTED
PINNED
PROTOCOL RESEARCHERS
How the deriver rebuilds L2 from L1
The deriver watches L1 for BatchPosted events instead of trusting any node’s live output — the log is the trigger, the posting transaction’s calldata is the data.
Replaying those batches forward, after re-checking that the ones it already indexed are still canonical, reconstructs the chain from L1 alone.
WHAT YOU'LL LEARN
- 01 · WATCH L1The deriver watches L1 for BatchPosted events instead of trusting any node’s live output. The log carries no payload.
- 02 · DECODE THE CALLDATAhandle_event routes to on_batch_posted, which decodes the posting transaction’s calldata and replays the blocks through execute_block.
- 03 · REVALIDATE, THEN SCAN FORWARDcatch_up() drops indexed batches whose L1 block is no longer canonical, then scans forward from that anchor — or from deploy_block on a cold start.
Verified against eez-rollup0 @ a4b9b2f — pre-mainnet; interfaces may move.