# Fast Confirmations: Confirmations from Espresso must come faster (in terms of interval and in terms of latency from when the transaction was submitted) than confirmations from the L1. Assumption: Espresso is fully functional, meaning blocks are produced within 4 seconds of each transaction submission, and a submission is confirmed within 10 seconds. Acceptance: Run the Nitro rollup with maximum load (1 non-empty block every 250ms). Confirmations should appear on Espresso every 2-4 seconds. After submitting a transaction to the Nitro sequencer, that specific transaction should appear in a batch on Espresso within 10 seconds. Batches should be appear on L1 not more than once every 30 minutes. The deltas between

1.

Transaction submitted to sequencer

2.

Transaction confirmed on Espresso

3.

Transaction confirmed on L1

should not change over time as the rollup runs.

# Liveness: The rollup should continue to run, post Espresso confirmations within 10 seconds of each rollup block produced by the sequencer, post L1 batches at least once every hour, and not reorg.

Assumption: Espresso is fully functional or degraded, meaning it is fully functional except for periods lasting no more than 24 hours where one or more of the following apply:

• The builder is unreachable or unable to drive confirmation of transactions

• The query service is unreachable or returning bad data

• HotShot consensus is not producing new blocks or confirming transactions submitted to it by the builder

Acceptance: Run the rollup as described above, checking for the same properties, but occasionally restart the Espresso builder and subsets of Espresso nodes.

# Confirmation Integrity: Every message posted to Espresso must eventually be posted to L1 in the same order, and vice versa.

Acceptance: Run a Nitro rollup for a fixed amount of time (say 1 hour) under heavy load with random transaction submissions. After 1 hour stop the rollup. Fetch all the messages that were posted to Espresso during that time and all the messages that were posted to L1. Check that these lists are the same.

Acceptance: Run a Nitro rollup until some batches have been posted both to Espresso and the L1. Then force the L1 to reorg back to an earlier state in which those batches have not been posted. Wait for some time and check that the batches are eventually posted to the L1 again, in the same order as they were originally (the order in which they were finalized on Espresso).

# Deterministic Derivation: It must be possible to derive the rollup state from Espresso, and deterministically arrive at the same state that will eventually be finalized on L1.

Acceptance: There is a version of the Nitro node which derives from Espresso. Run a Nitro rollup and run this node. It should be possible to query this node’s RPC for updated states every 2-4 seconds. Once a state is finalized on L1, it should match the state that was earlier reported by the Espresso-deriving node for the same block. Repeat this test while manually sending some “invalid” confirmations to Espresso (e.g. confirmations that look valid but are sent from outside the batcher) and to L1 (e.g. confirmations that were not previously posted to Espresso).

# Permissionless Batching: It must be possible to run more than one batcher at the same time without having them interfere, and the safety and liveness of the rollup and of Espresso confirmations should hold as long as one of the batchers is correct and honest.

Acceptance: Run a Nitro rollup. Run two separate instances of the batcher on separate nodes. Let the rollup run for some time and check all the properties outlined above. Stop one of the batchers, let the rollup run longer, and check all the properties again. Restart that batcher, then stop the other batcher, and check again.