For everyone / How it works

How a transaction travels

From your wallet to Ethereum in five steps, most of them faster than you can see. This page is the machine; the confirmations page is what each step promises.

The journey

You sign something in your wallet and send it. It arrives at one computer, the sequencer, which writes it down so it cannot be lost, does the work right away, and knows the answer before you have let go of the button. Many times a second the sequencer bundles the answers it has just produced, signs the bundle and publishes it. A little less often, it wraps those bundles into a block that looks exactly like an Ethereum block, which is what your wallet and the explorer show you.

Then, separately, it writes down everything that was in that block and sends a fingerprint of the list to Ethereum. Anyone can pick up the list, replay it themselves, and check that they get the same answer. That last step is what makes Pickle a part of Ethereum rather than just a fast computer that says so.

1. You send it. Your wallet signs the transaction and submits it over standard JSON-RPC to the sequencer, the single process that runs the chain.

2. It is admitted and made durable. The sequencer recovers the signer, places the transaction on a bounded queue, and appends it to a checksummed log on disk before executing it, so an acknowledged transaction survives a crash.

3. It executes at once. A single coordinator commits transactions in admission order. The receipt exists before any block does.

4. It is preconfirmed, then confirmed. At a 10 millisecond scheduling target the interval's transactions are sealed into a signed mini-block; at a 250 millisecond scheduling target the interval's mini-blocks are wrapped into a standard EVM block with a number every tool understands.

5. It is committed to Ethereum. Each sealed block produces a payload carrying its full transaction list, stored in a data-availability layer, and one commitment per 60 second scheduling target is posted to an inbox contract on Ethereum. From those, anyone running a replica re-executes every transaction and arrives at the same state.

The RPC layer recovers the signer and places the transaction on a bounded admission queue with a per-sender cap; a full queue returns an error rather than growing memory without bound. Every accepted transaction is appended to a checksummed write-ahead log and made durable before it executes, one fsync per batch. A single execution coordinator commits in admission order and never executes the same sender concurrently, which preserves nonce safety without a mempool re-ordering step. Execution is immediate, so the receipt exists before the containing block is sealed.

A producer seals a mini-block at the 10 ms scheduling target: the interval's transactions, receipts and logs, a state-diff hash, a microsecond timestamp and a sequencer signature over the header. A second producer seals a Cancun-shaped EVM block at the 250 ms scheduling target wrapping the interval's mini-blocks; the next block's timestamp is fixed when the previous one is sealed, so a transaction reading the block timestamp sees the value the header commits to. Each sealed block emits a derivation payload, full transaction list, block range, parent hash, block hash and committed timestamp, to a content-addressed data-availability layer, and one envelope per 60 s scheduling target is committed to the L1 inbox, with calldata as fallback.

Three of those steps carry a number, and none is a promise

The 10 millisecond, 250 millisecond and 60 second figures are scheduling targets, the intervals the sequencer aims for. None is a latency guarantee and none is a throughput claim.

The lifecycle, step by step

  1. A client submits a signed transaction over standard JSON-RPC.
  2. The RPC layer recovers the signer and places the transaction on a bounded admission queue, with a per-sender cap. A full queue returns an error rather than growing memory without bound.
  3. A single execution coordinator commits transactions in admission order. The same sender is never executed concurrently, which preserves nonce safety without a mempool re-ordering step.
  4. Execution is immediate. The receipt exists before the containing EVM block is sealed.
  5. Every accepted transaction is appended to a checksummed write-ahead log and made durable before it executes, one fsync per batch, so an acknowledged transaction survives a crash.

Three ways to execute

The sequencer does not run every transaction the same way. It recognises three shapes and takes the shortest correct path for each:

  • A plain ETH transfer takes a native path, without starting the virtual machine at all.
  • The canonical ERC-20 transfer takes a fast path that moves the balance slot directly and emits the standard event, producing the same result the full machine would.
  • Everything else runs through the general EVM, which is revm pinned to the Cancun hardfork.

All three charge standard gas and split the fee the same way, so you cannot tell from the fee which path was taken, and you should not need to. The fast paths exist because most of a chain's traffic is the two simplest kinds of transaction, and they are where the time goes.

Why it is deterministic

Two things that other chains leave to the operator are compile-time constants here: the execution hardfork and the minimum gas price. Made tunable, either would let a replica reject or re-price a transaction the sequencer accepted, and independent derivation would halt. The same reasoning fixes the next block's timestamp at the previous seal, and makes the mini-block interval a consensus parameter rather than a per-operator setting: a replica has to agree on how the stream is cut to reproduce the same hashes.

Why it is built this way

The unusual decision is executing before sealing. On most chains a transaction waits for the next block and is executed as part of building it; here it is executed on arrival and the blocks are assembled afterwards from results that already exist. That is what makes the first moment fast, and it is why the mini-block exists as a separate thing from the block: the mini-block is the sequencer putting its signature on results it has already computed, while the ordinary block arrives on its own rhythm behind it. What each moment guarantees is on the confirmations page, and where the record ends up is on the settlement page.