Interpreting the Different Stages of Transaction Confirmation Revenue for L2

2024.01.03

Interpreting the Different Stages of Transaction Confirmation Revenue for L2

Introduce the entire process of L2 transaction execution and analyze the security performance at each stage of the transaction flow.

2024.01.03 - 11:27:07

Navigating Web3 tides with focused insights

Introduce the entire process of L2 transaction execution and analyze the security performance at each stage of the transaction flow.

Author: Nic @imToken Labs

When can you be certain that an L2 (Layer 2) transaction will be included in a block? When can you be confident that the outcome of an L2 transaction won't be discarded due to a re-org?

This article introduces readers to the complete lifecycle of L2 transactions and analyzes the security properties at each stage.

Prerequisites:

The full process of L1 (Layer 1) transactions
Causes and impacts of re-orgs
Understanding the roles and operations within Ethereum's current PBS architecture
Understanding the differences between Optimistic Rollups and Validity (ZK) Rollups

Understanding L1 Transactions

Transaction Flow

After a user signs and sends a transaction, it is broadcast across the peer-to-peer network, where it waits to be picked up by a miner under PoW consensus or a proposer under PoS consensus for inclusion in a block. Once users see their transaction included in the latest block, they still cannot be 100% certain it will become part of the blockchain’s permanent history—because blockchains may experience “re-orgs.” Users must wait until the likelihood of a re-org affecting that block becomes sufficiently low before they can be confident the transaction has been finalized.

L1 Transaction Flow Diagram

Even after a transaction is included in a block, re-orgs are still possible. Only when the probability of a re-org becomes negligible can we consider the transaction finalized.

The likelihood and cost of re-orgs vary depending on a chain's consensus algorithm and asset market cap; this article does not delve into calculating re-org costs.

Understanding L2 Transactions

Transaction Flow

After a user creates and signs an L2 transaction, it is typically sent directly to the Sequencer—the entity responsible for ordering transactions—which includes the transaction in an L2 block. Subsequently, when the Sequencer submits the L2 block data back to L1 via an L1 transaction, users can observe their transaction as included in the latest L2 block.

However, note that since L2 block data is submitted to L1 through an L1 transaction, there remains a possibility of an L1 re-org causing the L2 block to ultimately not become part of the blockchain’s history—equivalent to an L2 re-org. Therefore, users must wait until the chance of an L1 re-org becomes sufficiently low before being confident their transaction is permanently recorded.

L2 Transaction Flow Diagram

Users first wait for their transaction to be included in an L2 block, then for that L2 block data to be submitted to L1 via an L1 transaction, and finally for the L1 transaction to be finalized.

Compared to L1 transactions, L2 transactions add the initial step of waiting for the Sequencer to include the transaction in an L2 block. However, with sufficient L2 block capacity and fast block production, this additional wait time is minimal. Most of the delay comes from confirmation on L1. Overall, the user experience between L1 and L2 transactions is quite similar.

But could users trade some guarantees for better experience?

Pre-Confirmation / Fast Confirmation / Soft Confirmation

Ideally, users should only trust their transaction is included once they’ve seen the L2 block (containing their transaction) confirmed on L1—and even then, only after the risk of a re-org drops to near zero.

But what if users choose to trust the Sequencer? Perhaps the Sequencer is operated by the L2 team or a reputable institution. If the Sequencer promises upon receiving a transaction that it will be included immediately—or in block X—then for users willing to trust it, this promise may suffice. Just like trusting your wallet: once it confirms a transaction, most users don’t double-check repeatedly on Etherscan.

Such a guarantee provided by the Sequencer is known as Pre-Confirmation, Fast Confirmation, or Soft Confirmation—an early, soft assurance of inclusion. It doesn’t require waiting for submission to L1, but it’s merely a verbal commitment. The Sequencer might break the promise due to bugs or malice, resulting in wasted time or even double-spending attacks.

Next, we’ll explore various ways different L2s present transaction inclusion status.

Arbitrum/Optimism Transaction Inclusion Status

Currently, after submitting a transaction on Arbitrum or Optimism, users almost instantly receive a transaction receipt showing execution results. This indicates the Sequencer has already ordered and simulated execution locally—the receipt serves as a Pre-Confirmation.

For more detailed information about Arbitrum’s transaction lifecycle, copy the link below into your browser: https://docs.arbitrum.io/tx-lifecycle
For Optimism’s transaction lifecycle, visit: https://community.optimism.io/docs/protocol/txn-flow/#posting-to-l1

Checking Transaction Status on Arbitrum

On Arbitrum Explorer, transactions marked as Pre-Confirmation—including those not yet submitted to L1—are displayed. For example, in the image below, Block Number 145353000 shows a "Confirmed by Sequencer" label:

The above image shows a transaction confirmed only by the Sequencer, not yet submitted to L1.

In contrast, for a transaction already submitted to L1 (as shown below), the status reads "69 L1 Block Confirmations," meaning the Layer 1 block containing this transaction data has 69 subsequent blocks built on top of it:

The L1 block containing this transaction has 69 descendants. More confirmations mean higher security.

Or take the transaction shown in the screenshot below—its corresponding L1 block has 6,174 descendant blocks, making it extremely secure:

Still, there’s room for improvement by incorporating L1 finality information.

Simply displaying the number of L1 block confirmations offers limited help, as users must interpret the associated security level themselves. Since Layer 1 (i.e., Ethereum) already has a finality mechanism like Casper FFG, explorers could directly indicate whether the relevant L1 block has been finalized. Currently, Optimism’s explorer already implements this feature.

Checking Transaction Status on Optimism

On Optimism Explorer, Pre-Confirmation transactions—those not yet submitted to L1—are also visible. As shown below, Block Number 111526300 displays a "Confirmed by Sequencer" label:

A transaction confirmed only by the Sequencer, not yet uploaded to L1.

However, the explorer currently lacks a clear definition of "Confirmed by Sequencer." It claims these confirmations are “equivalent to a few block confirmations on L1,” implying the block has already been submitted to L1 with several following blocks:

Yet newly appearing transactions also show "Confirmed by Sequencer," and even transactions from dozens of days ago—well past the challenge period—still display the same status:

Transactions from days ago still labeled 'Confirmed by Sequencer.'

Note: This may result from the explorer placing different statuses in separate locations: The "Confirmed by Sequencer" next to the block number only indicates local confirmation by the Sequencer, while L1 submission status must be verified using other indicators—such as the "L1 State Batch" info discussed next.

Additionally, for transactions already submitted to L1 (as shown below), two extra pieces of information appear: “L1 State Batch Index” and “L1 State Root Submission Tx Hash.” These indicate which state batch contains the L2 transaction and which L1 transaction submitted that batch:

Clicking into State Batch #3480 reveals its status is Finalized. This corresponds to Ethereum mainnet’s Finalized state—securely backed by two epochs of validator votes.

△ State Batch 3480 was included in L1 Block 18457449, which has been finalized.

Source: https://etherscan.io/block/18457449

If a batch has been submitted but not yet finalized on L1, it shows as Unfinalized:

State Batch 3494 has been submitted to L1, but the L1 block containing it hasn’t been finalized yet.

Compared to Arbitrum Explorer, Optimism Explorer provides richer data (e.g., State Batch) and integrates L1 finality directly into the L2 explorer interface, letting users know whether the L1 block has been finalized without requiring manual interpretation of confirmation counts.

StarkNet Transaction Inclusion Status

Currently, after submitting a transaction on StarkNet, users can quickly retrieve a transaction receipt—but it often shows status as RECEIVED. This means a node has received the transaction and validated it successfully, but it’s still pending inclusion and execution by the Sequencer. No execution results are available during the RECEIVED state. Users can monitor progress via transaction status shown on StarkNet Explorer.

Note: If the Sequencer processes quickly enough, the RECEIVED state might be skipped entirely, moving straight to executed status. For more details on StarkNet’s transaction flow, visit: https://docs.starknet.io/documentation/architecture_and_concepts/Network_Architecture/transaction-life-cycle/

On Starkscan (a StarkNet Explorer), Pre-Confirmation transactions are visible. For instance, in the image below, the transaction status is "Accepted on L2," indicating the Sequencer has scheduled it into an L2 block:

"Accepted on L2" means the transaction has been scheduled into an L2 block but not yet submitted to L1.

Before "Accepted on L2," two prior states exist: Received and Pending, representing “transaction received and validated” and “currently being processed by the Sequencer.” After execution completes, the status advances to Accepted on L2:

Transaction received and validated

Transaction currently being processed by the Sequencer

Only after the data is submitted to L1 does the status become "Accepted on L1," as shown in the transaction below:

Transaction data has been submitted to L1

Although StarkNet offers more granular transaction states, allowing users to track processing progress, data submission to L1 may take four to five hours (likely due to lengthy zero-knowledge proof generation). During this time, users rely heavily on the Sequencer’s Pre-Confirmation.

Moreover, the explorer only displays "Accepted on L1" for submitted transactions, without integrating L1 finality or block confirmation metrics—forcing users to manually verify whether sufficient blocks follow or finalization occurred.

Overall, StarkNet’s performance bottlenecks force prolonged reliance on Pre-Confirmation, and lack of L1 finality integration leads to suboptimal user experience—areas needing future improvement.

zkSync Transaction Inclusion Status

Similar to StarkNet, zkSync has a PENDING state, indicating the node has received and validated the transaction, now awaiting inclusion and execution by the Sequencer. No execution results are available in PENDING state.

Users can monitor progress via zkSync Explorer.

Note: If the Sequencer acts quickly, the PENDING state may be skipped entirely.

For a detailed overview of zkSync’s transaction flow, visit: https://era.zksync.io/docs/reference/concepts/finality.html#finality-on-ethereum

On zkSync Explorer, Pre-Confirmation transactions are visible. For example, in the screenshot below, the status is "zkSync Era Processed," indicating the transaction has been scheduled into an L2 block:

This transaction has been scheduled into an L2 block and is now awaiting upload to L1 ("Ethereum Sending").

After the Sequencer produces an L2 block, the block and its transactions go through three sequential stages: Committed → Proven → Executed, representing “submitted to L1,” “validity proven,” and “L2 state updated on L1,” respectively. Below are examples of blocks and transactions at different stages:

Batch 292700 has been submitted to L1, entering the Committed phase. Source: https://explorer.zksync.io/batch/292700

Transactions within Batch 292700 have changed from "Ethereum Sending" to "Ethereum Validating," indicating they’re awaiting ZK proof validation.

Hovering over the "Ethereum Validating" icon reveals further sub-stages, including links to previous-stage transactions:

This transaction enters the 'Validating' stage; the link to the prior 'Sending' stage transaction is also shown.

Once validity of Batch 292000 is proven, it enters the Proven phase:

After proof submission, the batch enters Proven state, with a link to the proving transaction.

Internal transactions move from 'Validating' to 'Executing,' i.e., awaiting execution.

After a batch is proven, a waiting period (officially ~21 hours) follows before transactions execute and the L2 state updates on L1. This is a safeguard during alpha stage, allowing time to respond to potential bugs. Once executed, the batch reaches the final Executed state:

After execution, the batch reaches final Executed state, with a link to the execution transaction.

Transactions within the batch are now marked as 'Executed'

Compared to StarkNet, where L2-to-L1 transition happens in one step, zkSync breaks it down into finer-grained stages: Committed → Proven → Executed.

While this safety measure extends total processing time to about a day, the Committed state allows users to quickly confirm inclusion (beyond just Pre-Confirmation), reducing reliance on Sequencer trust.

Furthermore, zkSync Explorer provides rich, comprehensive data at every stage, enabling anyone to monitor real-time status and even independently verify transitions (e.g., from Committed to Proven, Proven to Executed).

However, note that as an alpha-stage safeguard, the zkSync Sequencer can currently modify historical records.

This means that even though transactions quickly exit Pre-Confirmation into Committed state, the Sequencer can still remove them from history until reaching the Executed state. Thus, users must still trust the Sequencer for up to a full day.

L1 Can Also Support Pre-Confirmation

If we can predict who will produce the next block, L1 can also support Pre-Confirmation.

Take Ethereum: currently, actual block producers are Builders. A Builder could offer Pre-Confirmation services, providing users with inclusion guarantees. However, since Builders aren’t guaranteed to win block production rights (they must bid competitively), such guarantees are weak. Moreover, weaker Builders with poor competitiveness rarely win bids, making their Pre-Confirmation service unreliable.

To avoid this issue, a better approach would be for Proposers to provide Pre-Confirmation, since “which Proposer proposes which block” is usually predetermined and deterministic.

However, under current PBS architecture, Proposers only propose blocks—they don’t construct them. Actual block construction and content decisions are made by Builders. Hence, Proposers cannot directly insert transactions or instruct Builders to do so. Only when future PBS upgrades introduce features like Inclusion Lists or allow Proposers to participate in block construction could they potentially offer reliable Pre-Confirmation services.

Note: For more on PBS, visit: https://mirror.xyz/0x347c9872A2a1dE370D798f9FE96341A9A0E05af8/oG_4j_-TweXHX_LMag656k_pAyJWIBXpEDrzpUfVsss.

Improving Pre-Confirmation

Pre-Confirmation is merely a verbal commitment from a Builder or L2 Sequencer—with no obligation to fulfill it and no penalty for breaking it.

Can we make this commitment stronger? Yes. Because both the block producer and the commitment content (e.g., “include this transaction in block 1,350,000”) can be codified as verifiable conditions, we can use smart contracts to enforce Pre-Confirmation. Require Builders or Sequencers to deposit collateral when offering Pre-Confirmation services, and sign their commitments. If users detect unfulfilled promises, they can submit the signed commitment to the contract, which verifies whether the condition was met (e.g., checking if the transaction appeared in block 1,350,000).

While such contract applications remain in concept phase, the video linked below demonstrates one implementation example: https://www.youtube.com/watch?v=Uw5HxSYXwYo

Summary

After an L1 transaction is included in an L1 block, the probability of a re-org gradually decreases, increasing user confidence in its inclusion.
Compared to L1, L2 transactions have an additional workflow step: “inclusion in an L2 block and waiting for submission to L1.”
During this additional L2-specific phase—before data is submitted to L1—the only guarantee users receive is the Sequencer’s verbal promise, known as Pre-Confirmation, Fast Confirmation, or Soft Confirmation.
If the Sequencer is malicious or suffers a bug, it may break its promise, leading to failed transaction inclusion.
Currently, most L2 explorers display Pre-Confirmation states—such as Arbitrum/Optimism’s “Confirmed by Sequencer” or StarkNet’s “Accepted on L2.” When seeing such messages, pay attention to the temporal reliability of these assurances.
If you prefer not to trust the Sequencer’s Pre-Confirmation, wait longer and verify via L2 explorer data showing whether the L2 data has been submitted to L1.
Pre-Confirmation can be enhanced with economic incentives—for example, penalizing Sequencers via smart contracts when they violate commitments, giving users clearer guarantees.