A Taxonomy of Preconfirmation Guarantees and Their Slashing Conditions in Rollups

Thanks to mteam and Justin Drake, for feedback and comments on this article. Thanks to Ink L2 for funding my research

Preconfirmations in optimistic rollups can offer varying levels of guarantees to users, ranging from basic inclusion to strong assurances about ordering and execution outcomes. However, the lack of a formalized taxonomy has led to overlapping and sometimes tautological definitions across discussions. This document proposes a structured categorization of preconfirmation guarantees, with the goal of establishing clear boundaries between each type. It also defines the associated slashing conditions and computational complexities required to enforce them, enabling rollup designs to reason rigorously about safety, UX, and implementation tradeoffs.

There are four essential guarantees to a preconfirmation:

• Inclusion
  • Enforcing inclusion through a signed message requires the preconfirming sequencer to include the transaction in the specified block.
• Ordering
  • Enforcing ordering through a signed message requires the preconfirming sequencer to include the transaction at the specified sequence number in the specified block.
• Execution success
  • Execution success guarantees the transaction will not revert, regardless of its exact input state or gas consumption. However, it does not guarantee specific state changes unless a post-state commitment is also made.
• Post-State Guarantee
  • Enforcing post-state guarantee through a signed message requires the preconfirming sequencer to include the transaction and ensure pre state parameters and post state mutations during execution match the signed response from the preconfirming sequencer.

Category 0

Inclusion is guaranteed. No guarantees on ordering or execution success.

This is the weakest of guarantees. The transactor receives a guarantee of inclusion via the preconfirmation response. However, ordering is not guaranteed and the execution outcome is uncertain.

The slashing condition for this category would be a proof of non-inclusion for the transaction in the transaction tree.

However, a proof of non-inclusion for an unordered transaction tree can be computationally complex within the EVM by requiring a proof of exclusion for all transactions within the transaction tree.

Example:

DEX Mempool Inclusion for Limit Orders
A user submits a limit order to a rollup-based DEX. The sequencer provides a signed guarantee that the transaction will be included in the next block, but the final ordering is not specified. This allows the DEX frontend to show the user that their order will be considered, but without making promises about execution success or outcome (which could be affected by slippage, race conditions, or frontrunning)

Category 1

Inclusion and ordering are guaranteed. Execution success is not guaranteed.

The slashing condition for this category would be a proof of non-inclusion for the transaction in the transaction tree.

Using a sequence number for a signed sequencer transaction reduces computational complexity by allowing the proof of non-inclusion to be a proof by contradiction by providing the transaction at the specified sequence and accompanying Patricia Merkle Tree (PMT) witness.

Example:

NFT Minting with Priority Slot
During an NFT drop, users can pay for priority mint slots. The sequencer returns a signed preconfirmation promising that a minting transaction will be included at a specific sequence position. However, if the user has insufficient funds or gas, the transaction might still revert. This ensures fairness in ordering while offloading execution risk to the user.

Category 2

Inclusion and execution success are guaranteed. No guarantee on ordering or post-state.

This category guarantees that the transaction will execute without reversion with no guarantees on the state tree inputs or outputs for the transaction execution. This guarantee allows the sequencer issuing a preconfirmation the ability to extract MEV from preconfirmed transactions while giving the transactor strong guarantees of execution success.

The slashing condition for this category would be identical to category 0. However, the proof of non-reversion will require re-execution of the block within the EVM up until the transaction is executed.

Example:

Slippage-Bounded DEX Trade with MEV Flexibility
A user submits a trade to a DEX with a specified maximum slippage (e.g., “sell 1000 USDC for at least 0.98 ETH”). The sequencer returns a preconfirmation guaranteeing the transaction will succeed (i.e., not revert), so long as the post-trade price stays within the user’s slippage tolerance. The sequencer is free to reorder this trade relative to others and extract MEV (e.g., by sandwiching) as long as the final execution remains within bounds and succeeds. This gives the user execution confidence without demanding a specific ordering or state root.

Category 3

Inclusion, execution success, and post-state are guaranteed. No guarantee on ordering.

This is the strongest of guarantees. This guarantee provides the transactor with assurances of transaction inclusion and post state mutation. While ordering may be naturally inferred, it is not strictly enforced, as the transaction’s pre- and post-state can be independently verified. This allows the transaction’s position within the block to shift without affecting its execution outcome, as long as its state context remains isolated.

The slashing condition would be identical to category 2 with the addition of an EVM proof of post state would validate the post state mutations.

Example:

Escrow or Conditional Payment Contracts
In a cross-chain bridge or payment channel, a user sends a transaction with the expectation that it results in an exact post-state mutation (e.g., balanceOf(user) += 1 ETH). The sequencer signs a preconfirmation that commits not just to inclusion and successful execution, but to the specific post-state root that will result. This enables the preconfirmation to serve as an off-chain attestation in bridging protocols or conditional commitments, with strong slashing conditions if violated.

= Guaranteed | = Not Guaranteed

Category	Inclusion	Ordering	Execution success	Post-State Guarantee	Slashing Computation
0					O(n)
1					O(1)
2					O(n) + O(m)
3					O(n) + O(m)

* O(m) implies transaction execution

Footnote on slashing condition complexity:
While the naive approach to verifying slashing conditions (e.g., proving non-inclusion or incorrect post-state) may require O(n) or O(m) operations within the EVM, these costs can be significantly reduced through cryptographic proof systems. If the rollup leverages SNARKs (or similar succinct proofs), the entire slashing verification—regardless of whether it’s checking inclusion, execution success, or post-state validity—can be compressed to a constant-time verification cost on-chain, effectively reducing the computational complexity to O(1).

Why distinguish between Category 2 and Category 3?
Category 2 guarantees execution success but not post-state. This means the sequencer may reorder the transaction within the block, potentially altering its pre- and post-state, as long as it does not revert. This flexibility enables MEV extraction or batching optimizations while preserving the guarantee that the transaction “succeeds.”

In contrast, Category 3 explicitly guarantees the post-state, meaning the sequencer must ensure the transaction results in a specific state transition. Reordering is still allowed only if the transaction’s pre-state is isolated—i.e., unaffected by surrounding transactions. If the pre-state is not isolated, then ordering becomes implicitly fixed, since any change in sequencing would invalidate the expected post-state. However, ordering itself is not the slashing condition—only a mismatch in the committed post-state would be slashable.