For everyone / How it works
Settlement and the record
Every block's contents are published, in order, block 0 included, and Ethereum always holds either the data or a commitment to data that is available elsewhere. That is what makes the chain checkable rather than merely asserted.
Two tiers of publication
| Tier | What it holds |
|---|---|
| Data-availability layer | the full payload, per blockcontent-addressed, keyed by its hash; the sequencer verifies the acknowledgement digest before relying on it |
| Ethereum inbox | a compact envelope naming the payloadone commitment per 60 s scheduling target, blob or calldata chosen from measured prices |
| Fallback | the full payload as calldata on Ethereumtaken whenever the data-availability path fails, so the chain stays derivable through an outage |
Imagine a shop that keeps every receipt in a filing room, and once a minute sends the bank a sealed summary saying "here is the fingerprint of the receipts I just filed". The bank cannot read the receipts from the fingerprint, but anyone who gets into the filing room can check that nothing was changed. And if the filing room is ever unreachable, the shop sends the bank the receipts themselves instead. Pickle's sequencer is the shop, the data-availability layer is the filing room, and Ethereum is the bank.
Each sealed block produces a derivation payload carrying its full transaction list. The payload is stored in a content-addressed data-availability layer, keyed by its hash, and the sequencer verifies the acknowledgement before relying on it. A compact envelope naming that payload is then committed to an inbox contract on Ethereum. If the data-availability path fails for any reason, the full payload is posted to Ethereum as calldata instead.
Every block is posted, in order, block 0 included. The inbox accepts appends only from the designated batcher key and emits an indexed event per batch; that index is the total order every verifier follows.
The payload carries the block's full transaction list together with the block range, parent hash, block hash and committed timestamp; the timestamp is included because it is part of the execution environment, not only of the header, and a replica must execute against the same clock to seal the same hash. Publication is two-tier: the payload to a content-addressed store under its hash with digest verification on acknowledgement, and an envelope to the L1 inbox per aggregation window. The inbox is batcher-gated and emits an indexed event per append. The commitment instrument, blob or calldata, is selected per submission from measured prices, since at this payload size execution gas dominates at low blob fees and plain calldata wins at high ones.
What a payload carries
- The block's full transaction list, so nothing about the block has to be trusted.
- The block range, parent hash and block hash, so the replica knows where it fits and what it must reproduce.
- The committed timestamp, because a transaction that read the clock saw that value, and a replica executing against a different clock would seal a different hash.
Why one commitment per window
Ethereum does not receive one transaction per sealed block. Full data goes to the data-availability layer per block; one commitment goes to Ethereum per aggregation window, on a 60 second scheduling target. Aggregation is what keeps modelled settlement cost in the low millions of dollars per year rather than the tens or hundreds of millions a per-block posting design would incur. The limits page gives the modelled range and what it rests on.
Independent verification
Any operator can run the same binary as a replica. It produces nothing. It reads the Ethereum inbox from its last applied index, fetches each payload by its content address or decodes the inline calldata fallback, re-executes every transaction in order against the committed timestamp, seals the block locally, and compares the hash to the one the sequencer committed.
On any mismatch, a replica halts permanently
Divergence is terminal by design: retrying would seal further blocks and walk away from the canonical chain, burying the cause. A halted replica is the signal that the published data and the committed hash disagree. Nothing on-chain arbitrates that disagreement; the trust model page says what follows from it.
A synced replica serves the standard read RPC from its own independently derived state. Its balances, receipts and headers are locally re-derived, not trusted copies of the sequencer's answers. Transaction submission is forwarded to the sequencer; a replica accepts nothing into a local mempool.
Where history is read from
The sequencer is optimised to answer about the present and keeps a short window of recent blocks. The complete history is indexed into the explorer's database, which is fed continuously by the sequencer and is where anything historical is answered. Both are downstream of the same published payloads, and a replica can rebuild either from Ethereum and the data-availability layer alone.