Skip to main content

Finality design

This page describes application-level and settlement finality in a Lineth (formerly the Linea Stack) deployment. Timing and irreversibility depend on validator topology, consensus assumptions, proof generation and submission, and the selected finalization layer.

Application-level and settlement finality​

Finality is the point at which a transaction becomes immutable under the deployment's security assumptions. Instant finality means a block becomes final before the next block is produced, giving immediate application-level finality. For enterprise deployments, distinguish between:

  • Application-level finality: when a transaction is accepted as final by the configured network. With instant finality, this happens at block production.
  • Settlement finality: when the corresponding state commitment is verified and finalized on the selected finalization layer

Layer 2 (L2) blockchains bundle transactions and submit them to the layer 1 (L1) blockchain. Soft finality occurs when a block is confirmed and committed on the L2. Hard finality occurs when the L2 state that includes the transactions is confirmed and committed on the L1. On a network built on Lineth, block production provides fast L2 confirmation before settlement on the finalization layer.

Standalone Linea Enterprise​

In a standalone deployment, application-level finality depends on the configured validator model. A single-validator deployment has explicit operator trust assumptions. A multi-validator deployment can use Quorum-Based Byzantine Fault Tolerance (QBFT) consensus to finalize blocks among the authorized validators. For topology and latency trade-offs, see Multi-validator consensus.

L2 Linea Enterprise​

As an L2 blockchain, zk-SNARK proofs let the finalization layer verify committed L2 state without an optimistic-rollup challenge window. Settlement timing still depends on proof generation, proof submission, and finality on the selected finalization layer.

Finality time as an operator decision​

Soft finality is reached at the block boundary. The public network uses 1-second block times; operators can choose parameters that fit their own latency, throughput, and validator-topology requirements.

When running a single validator, block production depends on that validator's availability and operating environment. When running a validator set, network latency and validator performance affect block validation time, while the consensus protocol defines when a block is finalized by the validator set.

Next steps​

Was this page helpful?