# 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. More specifically, the batcher should post to Espresso as soon as it receives a block, but submit to L1 slower for better compression. 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 rollup with maximum load (block time depending on the specific rollup). Confirmations should appear on Espresso every 2-4 seconds. After submitting a transaction to the sequencer, that specific transaction should appear in a batch on Espresso within 10 seconds. Batches should be appear on L1 at a configurable interval, typically in the range of 30 minutes or so. 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.

# Soft Confirmation Integrity: The integration must not weaken soft confirmations provided by a rollup’s sequencer. That is, while Espresso confirmations are valid even under a weakened security assumption where the sequencer may be malicious, if we consider the case with a stronger assumption where the sequencer is correct, online, and honest, the rollup should finalize what the sequencer produces.

Assumption: The rollup sequencer is correct, online, and honest. It produces a valid sequence of rollup blocks every few seconds or faster, and it never reorgs.

Acceptance: Run the rollup and subscribe to the sequencer feed, a feed which derives from Espresso, and a feed which derives the finalized block sequence from L1. All of these should yield the same blocks in the same order (but at different times).

Acceptance: Consider rollup-specific adversarial behavior which could break sequencer confirmations, such as an adversary sending non-sequencer blocks directly to Espresso. Such attacks should not cause Espresso to finalize something different than the sequencer feed.

# 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.

# 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 rollup node, called Caff node, which derives from Espresso. Run a 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” transactions to Espresso (e.g. transactions that look valid but are sent from outside the batcher) and to L1 (e.g. transactions 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.

Note that this requirement may not be required for the first version of every rollup integration, but we must achieve it eventually. If it’s future work for a rollup integration, we should note that in the specific page.

Acceptance: Run a 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.