Linea
Linea finality progresses from local block commitment to Ethereum settlement
Linea finality first confirms a transaction on the local network, then settles its state on Ethereum. Soft finality arrives when the Maru validator commits the transaction's block, normally in about one second on mainnet. Hard finality requires a verified validity proof and Ethereum consensus finalization of the verification block. A wallet receipt establishes local execution. It does not, by itself, establish Ethereum settlement, and pending replacement cannot cancel an executed transaction.
From Pending Submission to Ethereum Settlement
A transfer that already has a receipt follows the settlement path; a genuinely pending transaction may still allow replacement.
If keeping the transfer reversible matters, block inclusion is the boundary to watch. A wallet's supported cancellation method attempts a replacement with the same nonce, the account's transaction counter. The replacement must satisfy the network's acceptance rules and win inclusion before the original. A receipt closes that cancellation route. The remaining wait concerns whether Ethereum has finalized the state that contains the transfer.
| Stage | What Happens | Responsibility and User Control |
|---|---|---|
| Transaction submission | An RPC node receives the signed transaction for possible inclusion. | The signer may attempt a supported pending replacement. |
| Local block commitment | The sequencer executes the transaction, and Maru commits its block. | The mainnet operator controls ordering; inclusion ends pending replacement. |
| Batch and proof preparation | The coordinator groups blocks and requests execution, compression, and aggregation proofs. | Operator-run services schedule proving work. |
| Ethereum data publication | The coordinator submits compressed transaction data in Ethereum blobs. | The coordinator submits data; Ethereum includes the publication transaction. |
| Proof verification and state recording | LineaRollup checks the proof and records the resulting state. | Ethereum contracts enforce proof and state-continuity checks. |
| Ethereum consensus finalization | Ethereum finalizes the block containing the proof-verification transaction. | Ethereum validator consensus determines settlement finality. |
The transfer reaches hard finality once its block falls within the Ethereum-finalized range. If the original commits before the cancellation attempt, replacement cannot undo it.
The Finalized Block Boundary
The
finalized
tag identifies the latest Linea block whose state has reached hard finality. A compatible endpoint can return that block through
eth_getBlockByNumber
with
finalized
as the block parameter. This query names the settlement boundary, whereas
latest
names the current local head.
A transaction receipt supplies its
blockNumber
and
blockHash. Its block lies inside the settled prefix when its height is at or below the returned finalized height. Both responses must concern the same Linea network and canonical history. JSON-RPC returns block heights as hexadecimal quantities, so software should compare decoded numbers, not text strings.
An alternative is to read
currentL2BlockNumber
from
LineaRollup
on Ethereum. For
hard-finality
verification, the Ethereum read must use finalized L1 state. A value read from Ethereum's latest head can include a finalization transaction that Ethereum has not yet finalized.
A transaction hash alone identifies the transaction without establishing block inclusion. The receipt query returns
null
when the endpoint finds no receipt, including for pending transactions. An RPC service that lacks complete or current data can also leave an observer without a reliable answer.
Block explorers display indexed node data and do not participate in finalization. Their transaction labels reflect their underlying data feeds.
Validity Proofs and Ethereum Data
Execution, compression, and aggregation proofs establish different parts of the settled state transition. An execution proof checks that transactions follow the execution rules. A compression proof connects blob data to the batches that it represents. Aggregation combines those proofs for an Ethereum verification transaction. This lets Ethereum validate the transition without executing every Linea transaction again.
LineaRollup calls a verifier contract to check a proof covering a submitted range of blocks. The rollup also checks the submitted state against earlier data commitments. These linked commitments connect the new final state to the previously accepted state. Data publication alone leaves the execution claim unverified until the proof passes its corresponding checks.
Ethereum blobs carry compressed transaction data separately from the verification result. Their availability supports reconstruction of the transaction history. A proof establishes correctness; accessible data supplies the inputs needed to rebuild state.
Soft Finality Under Sequencer Control
About one second is Linea Mainnet's normal block-commitment timescale, under its operating assumptions. Its single Maru validator works with the sequencer to produce canonical blocks. Ordinary Ethereum reorganizations do not reorder transactions that Linea has already committed locally. That guarantee depends on the mainnet operator model before Ethereum verifies the proof. Multiple-validator configurations of the underlying stack use different consensus assumptions; their configuration does not describe the public mainnet automatically. An application can accept the local confirmation while requiring hard settlement for a later cross-layer operation.
Batch Timing and Ethereum Consensus
Linea Mainnet's estimated median hard-finality time is about two hours, with individual waits varying across batches. That estimate can change with batching policy, proving performance, and Ethereum submission conditions. The coordinator groups work around proving limits and submission policy. It can close batches because of trace limits, compressed data size, block limits, time deadlines, or protocol boundaries. A small transaction can therefore wait alongside other transactions for the same proof. Ethereum gas fees also affect the cost of publication and verification, although fee estimation and settlement status answer different questions.
Ethereum normally takes about 15 minutes to finalize a block, but that interval starts at L1 inclusion, after the preceding rollup work. It is not a complete estimate for a newly submitted Linea transaction. Faster proving can shorten one part of the pipeline while batching policy, submission delays, and Ethereum finality continue to determine the total wait. Network interruptions can lengthen it further.
Canonical Withdrawals and Message Delivery
Canonical Linea-to-Ethereum withdrawals become claimable when rollup finalization anchors their message Merkle root in the Ethereum contract. A claim proves that the specific message belongs under that root, then executes the destination call. Anyone may submit a valid claim, subject to the contract's requirements. The claim still needs an Ethereum transaction and gas. Claimability begins when the contract holds the required commitment; hard-finality tracking additionally waits for Ethereum consensus. Source finalization and destination execution record different events, so settling the source transaction alone does not prove delivery.
Interrupted Proving and Recovery Boundaries
A stalled finalization pipeline leaves newer locally committed blocks outside the Ethereum-settled range. Continued L2 block production does not prove that proof submission is progressing. The coordinator persists intermediate results so its services can resume after a restart, but restarting does not itself establish settlement. An RPC timeout concerns access to state and establishes neither transaction failure nor a protocol halt.
State recovery rebuilds Linea from finalized data and checks the resulting state root against the Ethereum commitment. That provides a recovery anchor if ordinary operator services fail. It does not give a sender an undo command for a committed transfer. Reconstruction also requires access to the relevant transaction data; a final state root alone cannot supply that history. If the necessary data cannot be retrieved, a proof alone cannot reconstruct the full state.
Still wondering about Linea finality?
Can a Failed Transaction Still Reach Linea Hard Finality?
A transaction that reverts during execution can still belong to a block that reaches hard finality. The receipt's status reports execution failure; finality reports settlement of that recorded outcome. Proof verification confirms correct execution, including a valid revert. It does not convert the failed call into a successful transfer or refund the gas consumed.
Does Raising a Transaction Fee Speed Up Hard Finality?
Raising a fee can affect a pending transaction's chance of inclusion, but it does not buy an individual proof-verification deadline. Once a transaction has entered a committed block, its batch proceeds through the coordinator and proving pipeline. A wallet's speed-up control targets pending inclusion. It does not shorten Ethereum's consensus finalization interval.
Why Does an RPC Endpoint Reject the Finalized Tag?
An endpoint can reject the tag when its client or exposed RPC configuration lacks Linea's settlement-aware finalized-block support. Linea Besu provides the Linea-specific integration; running another compatible execution client does not automatically provide that feature. The method must also accept a block parameter. A tag error describes that endpoint's capabilities and does not show that settlement stopped.
How Many Linea Confirmations Equal Ethereum Settlement?
No fixed count of later Linea blocks substitutes for Ethereum settlement. Additional local blocks show that the L2 chain has advanced; the covering proof may still await submission or verification. A confirmation-count rule can serve an application's local policy, but it cannot establish hard finality without the corresponding Ethereum-finalized state.
Is a Finalized Block Sufficient for an Old Account Balance Query?
A finalized block identifies a settled point in history, but the queried node must retain the state needed for the balance read. An archive node retains historical state across blocks; a node that keeps only recent state may not answer an older query. Missing historical data limits that endpoint's answer and does not undo the block's settlement.