> For the complete Linea documentation index, see [llms.txt](/llms.txt). > Agents can fetch this page as Markdown at [https://docs.linea.build/stack/deployment/fast-finality.md](https://docs.linea.build/stack/deployment/fast-finality.md). # 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](/stack/deployment/distributed-sequencing). ## 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](/network/overview) 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 - Learn about [soft vs. hard finality](/network/overview/transaction-finality) - Learn more about how [deployment options impact finality](/stack/deployment/data-availability-finalization#finality-design-options)