A transaction must undergo the repeatable process of "submission → sequencing → consensus confirmation → state visibility" before it can be recognized as "confirmed" by other chains, bridges, or applications in a multichain environment. Espresso Network (ESP) acts as a shared confirmation and settlement base layer, receiving blocks from Rollup sequencers. The validator network uses HotShot to provide BFT endorsement within seconds, making Espresso-confirmed blocks available for downstream access.
This process resolves the challenge of confirmation sequencing: applications no longer need to wait for Ethereum L1 final settlement to obtain a verifiable sequence and state view; L1 settlement can still proceed according to bridge rules. Understanding when each stage is triggered and how confirmations are relayed back helps clarify the boundaries for cross-chain state reads.
What prerequisites are needed for a transaction to enter Espresso?
Before a transaction enters the Espresso confirmation path, the relevant system must be ready for integration: the target environment must be connected to Espresso; there must be an authorized sequencer (or equivalent block builder); and the transaction must be accepted according to the environment’s execution and sequencing rules. Espresso does not replace each environment’s execution layer but provides decentralized confirmation for the sequencer’s transaction output.
| Preparation Item |
Core Check |
Impact if Not Ready |
| Environment Integration |
Has the Rollup/application integrated with Espresso? |
Block cannot enter confirmation layer |
| Authorized Sequencer |
Is there a sequencer authorized to submit blocks to Espresso? |
Submission and queuing cannot start |
| Transaction Acceptance |
Has the transaction been accepted by the environment’s mempool/sequencing rules? |
No block can be sent for confirmation |
| Downstream Consumer |
Have bridges, applications, or solvers subscribed to the confirmation view? |
Confirmation is completed but unreadable across environments |
The table above shows that second-level confirmation requires "integration + authorized submission + downstream reading" to all be in place. Users typically only notice that "the transaction has been submitted to a Rollup," while the system must include that transaction in a block destined for Espresso.
Step 1: How are transactions submitted and queued?
The process starts when a user or application submits a transaction to a Rollup (or other execution environment). The transaction enters the environment’s receiving and queuing logic. An authorized sequencer sorts and batches transactions into blocks or batches following local rules, then submits them to Espresso. Espresso receives the sequencer’s block stream, not individual user transactions.
During the submission and queuing stage, the interface may quickly display "received" or "pre-confirmed"—these are feedback from the Rollup’s own sequencer; Espresso confirmation has not yet occurred. Internally, the sequencer locks the batch order, generates a block for submission, and sends it via the integration interface. This process can be repeated as needed—new transactions are batched and submitted as they arrive.
If the sequencer is delayed, censored, or fails to submit as required, the transaction remains in the local queue and downstream cannot see Espresso-level Finality. Whether sequencing is centralized is a structural issue discussed in the comparison of shared sequencing layers; here, we focus on "what happens after submission and how confirmation is completed."
Step 2: How does HotShot complete sequencing and confirmation?
Once a block enters Espresso, the validator network runs HotShot consensus: under a Proof of Stake (PoS) and Byzantine Fault Tolerance (BFT) framework, it reaches agreement on block order and data availability (DA). HotShot is designed for optimistic responsiveness—confirming as quickly as possible when network conditions allow. Public sources describe mainnet confirmation times as typically several seconds.
Confirmation is triggered when validators with sufficient weight vote on the proposed block. Once the threshold is met, the block becomes an Espresso-confirmed block, with its sequence and commitment finalized at the consensus layer. Execution remains with each Rollup or application environment, which deterministically transitions state for the confirmed sequence; Espresso itself does not execute business logic.
| Process Stage |
Trigger Condition |
System Action |
User/Application Visible Change |
| Submission |
Sequencer batches and submits block |
Block enters Espresso confirmation path |
Often shows "processing/pre-confirmed" |
| HotShot Confirmation |
Validators reach BFT voting threshold |
Block achieves Espresso Finality |
Espresso confirmation view is queryable |
| Downstream Reading |
Bridge/application subscribes to confirmation results |
Cross-environment logic advances by confirmation sequence |
Cross-chain actions can be triggered by confirmation state |
| L1 Settlement (later) |
On-chain per bridge and contract rules |
Matching batch submitted to Ethereum L1, etc. |
L1 final settlement completed (longer delay) |
This table distinguishes between "second-level confirmation" (completed by HotShot consensus on Espresso) and "L1 final settlement." The latter can proceed as originally designed, but the protocol layer can require that only blocks matching Espresso confirmation are eligible for settlement on the bridging L1.
Figure 1. Main Espresso confirmation path: user/application submission → Rollup sequencer batching → HotShot validator confirmation → Rollup/bridge/application consumption of Finality.
Validator participation in confirmation relies on staking and protocol incentives; ESP staking and protocol fees explain ESP’s role in validator staking and fee payments, which are foundational for the confirmation layer’s ongoing operation and do not alter the above sequence.
Step 3: How are confirmation results relayed to Rollup, bridge, or application?
After HotShot confirmation, Espresso-confirmed blocks become queryable within seconds. Rollup nodes, batch submitters, bridge components, messaging protocols, solvers, and other on-chain applications can use query services or event streams to access the confirmed sequence and state commitment, updating their view of the "confirmed state" for the environment.
Relay does not mean execution results are pushed to all chains, but rather that a verifiable, shared source of truth is provided: whoever reads the confirmation first can advance cross-environment logic according to their own rules. Protocol constraints ensure only blocks matching Espresso confirmation are accepted during bridging L1 settlement, preventing sequencers from rewriting the confirmed sequence after the fact. For users, this means cross-chain operations become available more quickly; for systems, the confirmation layer provides composable intermediate facts before L1 final settlement.
How is this different from "waiting for Ethereum L1 final settlement"?
When relying solely on Ethereum L1 final settlement, Rollup batches must wait for L1 finality before bridges and cross-chain applications consider the state secure—typically a process taking more than ten minutes. The Espresso path achieves BFT confirmation within seconds after sequencer submission, allowing downstream to read the confirmation state earlier, with L1 settlement remaining as a subsequent security anchor.
| Dimension |
Espresso Confirmation Path |
Waiting for Ethereum L1 Final Settlement Only |
| Confirmation Entity |
HotShot validator network (BFT) |
Ethereum L1 consensus finality |
| Typical Delay |
Several seconds |
Usually more than ten minutes |
| When Downstream Can Read |
Immediately after Espresso confirmation |
Usually only after L1 finality |
| Relationship with Sequencer |
Each environment can retain its sequencer, with decentralized confirmation layer endorsement |
Batches go directly to L1, paced with L1 |
| Ambiguity Constraints |
Can require settlement batches to match Espresso confirmation |
Relies on L1 contracts and proof windows |
This table highlights the difference in "who provides a trustworthy sequence commitment first" and "when bridges and applications initiate cross-environment actions." Espresso does not eliminate L1 settlement but inserts a repeatable, rapid confirmation layer in between.
Figure 2. Espresso path vs. L1-only settlement path: left shows bridges/applications reading after second-level HotShot confirmation; right shows actions taken after L1 finality.
What are the risks and failure points in this process?
Failure points exist in submission, consensus, and downstream consumption. If the sequencer censors, crashes, or delays submission, transactions cannot enter HotShot; if the validator network fails to meet the voting threshold, confirmation is delayed or stalls; if downstream fails to subscribe to the Espresso view, cross-chain logic may still follow the old timeline even if the user sees success.
Structural risks also include: confirmation layer security depends on staking distribution and BFT assumptions; Espresso Finality and L1 final settlement are different security boundaries—if applications treat second-level confirmation as equivalent to L1 finality, they may miscalibrate bridging and settlement parameters; integration or query defects can lead to "confirmed but unreadable" states. These risks pertain to mechanism boundaries, not investment advice.
Summary
Second-level confirmation on Espresso Network is a repeatable process: transactions are first accepted by the Rollup environment, batched and submitted by an authorized sequencer; HotShot validators complete BFT confirmation within seconds; Espresso-confirmed blocks are immediately available for Rollup, bridge, and application reading; L1 final settlement can still proceed according to matching rules. Analyzing the triggers and failure points for submission, confirmation, and relay clarifies that "second-level Finality" is a confirmation sequence design, not a one-off event.
FAQ
What is Espresso Network?
Espresso Network serves as a shared confirmation and settlement base layer for multichain and application environments. Each environment retains its own execution and sequencing rules; after submitting blocks to Espresso, validators provide fast Finality via HotShot, which can be read by other chains and bridges.
How does Espresso achieve second-level Finality?
After authorized sequencers submit blocks to Espresso, validators run HotShot consensus, confirming block order and data availability once the BFT voting threshold is reached. Public sources describe typical confirmation times as several seconds, allowing downstream to read confirmation views without waiting for Ethereum L1 final settlement.
What is HotShot consensus?
HotShot is the Byzantine Fault Tolerant consensus protocol used by Espresso Network to rapidly reach agreement among validators on block order and availability. It is designed for fast confirmation when network conditions are favorable, providing second-level Finality for Rollups and applications, but does not execute transactions itself.
How does Espresso improve cross-chain confirmation speed?
Cross-chain bridges, messaging protocols, and solvers can directly read Espresso-confirmed blocks to obtain confirmed state views of integrated chains, without always waiting for the L1 finality window to close. With confirmation sequencing advanced, cross-environment actions can start earlier, while protocol constraints still ensure that on-chain settlement batches match Espresso confirmation.
What are the risks of using Espresso?
Primary risks include sequencer submission failure or censorship, validator consensus not reaching threshold in time, errors in query and integration components, and conflating Espresso Finality with L1 final settlement, leading to security boundary misjudgments. The confirmation layer also depends on staking and BFT assumptions; interruption at any stage can prevent the "second-level confirmation" path from completing.
