Back to top
Published on -
June 28, 2023
Written by:

All You Need to Know About Layer 1 (and 2) Transaction Finality

We dive into the concept of transaction finality and examine how the speed of transactions influences different protocols.

On May 18, 2023, the Ethereum blockchain briefly stopped finalizing transactions. What does that mean? Finality is the point at which transactions on a blockchain are considered immutable and cannot be altered, reversed, or canceled after they are completed. In this article we will explore the relationship between finality and consensus mechanisms, what chain reorganizations are, and how finality is measured in Layer 2 protocols. Finally, we will dive into the data and compare the time to finality of crypto networks, crypto exchanges, cross-chain transactions, and test networks.

Table of Contents

  1. What are Consensus Mechanisms?
  2. What are Chain Reorganizations?
  3. Finality and Layer 2s
  4. Crypto Exchanges and Time to Finality (TTF)
  5. Cross-chain Bridge Transaction Finality
  6. Finality on Testnets
  7. Conclusion

What Are Consensus Mechanisms?

Consensus mechanisms are used in blockchain networks to achieve agreement and consistency among multiple participants or nodes in the network. A consensus mechanism refers to an algorithm that combines a Sybil resistance mechanism, an approach to protect the network from an attacker seeking to gain control by amassing a majority of the network’s voting power, with a chain selection rule (aka fork choice rule)1. In situations where multiple blocks occupy the same position, a fork choice rule enables nodes to select a single correct block at the head of the chain.

The level and speed of transaction finality are determined by the underlying rules of the consensus method. When is a transaction considered final? How long does it take to generate a new block? What is the network latency? Is the priority speed of transaction finality or security of the network? The answers to these questions are determined within the consensus mechanism as shown in Table 1 (Konstantopoulos, Buterin, 2021)2.

Table 1. Time to finality, chain reorganization (reorg) frequency and fork choice rules based on algorithm





Nakamoto (eg. PoW Ethereum / Bitcoin)



Longest chain

GASPER (eg. PoS Ethereum)

Every 2-epochs (~12 min)

Very occasional

Chain with strongest support after last finalized block


Single block (~1-10s)


Only finalized blocks

Table from Ethereum Reorgs After The Merge (July, 2021) by Georgious Konstantopoulos and Vitalik Buterin.

Finality in the Nakamoto PoW algorithm is never guaranteed but becomes increasingly certain as more blocks are added. Since the fork-choice rule selects the longest chain, there is always the possibility that, for any given block, someone will create a longer chain that started some time before the latest block in the current chain4.

On the other hand, Ethereum 2.0's GASPER offers almost immediate finality. This consensus protocol also incorporates a fire alarm mechanism known as the “inactivity leak”. Its purpose is to “recover finality in the event of permanent failure of a large number of validators” by imposing penalties on inactive validators and gradually reducing their stakes until at least ⅔ of the active validators resume finalizing. Inactivity leak is a particularly important engineering solution in the case of censorship resistance. For example, the recent sanctions of the United States Treasury’s Office of Foreign Assets Control (OFAC) on Tornado Cash sparked a debate regarding the shift in power on the Ethereum blockchain. Since the Merge and the transition from PoW to PoS, a significant concentration of power is observed among crypto exchanges because they possess the largest amount of coins for staking. If OFAC were to pressure crypto exchanges to censor and refuse to attest the blocks containing transactions that OFAC has banned, it would imply that the crypto exchanges are acting as inactive validators. Following the rule of inactivity leak, these inactive validators would be penalized, potentially resulting in large fines for major crypto exchanges that possess significant inactive pools. As a result, the act of staking in the Ethereum network would lose its purpose for these exchanges.

Practical Byzantine Fault Tolerance (pBFT)-based consensus, like Tendermint, has absolute instant finality. The transaction is finalized the moment it is executed. To achieve consensus, pBFT employs a multi-round voting process. Tendermint-based blockchains have a small number of validators which makes this process fast and efficient.

What Are Chain Reorganizations?

Chain reorganizations (reorgs) occur when multiple miners or validator nodes simultaneously create blocks with similar difficulty. Validator nodes in the network receive both blocks and track two different versions of the blockchain, resulting in a fork. When a miner adds the next block, they must choose which side of the fork is correct based on the output of the fork choice rule function calculated by the client.

Short 1-2 block reorgs happen daily on Ethereum due to network latency or unintentional block production race conditions. In Bitcoin's history, one of the most significant chain reorganization events occurred in 2010 when an attacker exploited a value overflow vulnerability, granting themselves 186 billion BTC. To fix this issue, 53 blocks were reverted. The switch to PoS on Ethereum after the Merge reduced the chance for chain reorgs. Despite this, on May 26th, 2022 Ethereum PoS experienced a 7 block chain reorg. Deep chain reorganizations have consequences such as costs associated with user experience degradation, uncertainty, and increased vulnerability to 51% attacks.

An example of a significant chain reorganization event in terms of scale is the Ethereum Classic (ETC) reorg that took place in August 2020. Initially thought to be a potential 51% attack, later reports indicated that the reorganization might have resulted from the offending miner losing internet access while mining. This reorganization persisted for approximately 15.4 hours, affecting a considerable number of blocks. During this event, a miner mined approximately 3,500 blocks while being offline for about 12 hours. When the miner came back online, a substantial chain reorganization occurred, starting at block 10,904,147. The Parity / OpenEthereum nodes were unable to handle the reorganization, causing them to fall out-of-sync with the network and resulting in a temporary chain split.

Finality and Layer 2s

Layer 2 protocols (L2s) have emerged as solutions for scalability and transaction speed. Since they are built on top of Layer 1 blockchains (L1s), in order to calculate the time to finality, we would need to consider the time needed to finalize the transaction on both Layer 2 and the underlying Layer 1. Consider Polygon, a scaling solution built on Ethereum that operates with its own consensus mechanism. It uses a PoS commit chain, which offers faster transaction confirmation times but does not provide the same level of finality as Ethereum's PoS. In Polygon's PoS commit chain, validators create blocks and periodically commit them to the Ethereum mainnet. However, the commit chain does not have the same finality guarantees as Ethereum's PoS, which means there is a possibility of chain reorganizations or block reversions, especially in situations where conflicting blocks are proposed.

The following table compares finality across a number of different L1s and L2s.

Table 2. Comparing crypto network’s time to finality (TTF)


Median Time-To-Finality Range (descending order)

Number of Full Nodes (lower bound)

Ethereum (current)

13-20 minutes (64-95 slots)

5471 per Ethernodes

Zk Rollups

~20 min proof generation time + 13-20 min ETH L1 time 

Centralized sequencers w/ plans to decentralize

Optimistic Rollups

2-8 batch commit time + 13-20 min ETH L1 time

Centralized provers w/ plans to decentralize

Ethereum (single-slot finality)

12s (not live as of writing)

N/A (single slot finality not live, node count at that time unknown)

Cosmos Eco (Hub + Canto)

6-7s single block finality

100-175 in active set per mintscan, Canto docs 

537 total in Cosmos hub


6s probabilistic finality via BABE; 12-60s deterministic finality via GRANDPA 

297 in active set, 939 total


2-3s (theoretical, Sui not live as of writing)




59 per Bscscan


~2s (128 blocks)

128 per Polygonscan


1-2s median, can get up to 60-90s at extremes

2932 per Solana Compass


1-1.5s median, 3-4s in times of high activity



0.7-1s probabilistic transaction finality; 2-2.2s block finality

1182 per Avascan





0.5s (theoretical, Sei not live as of writing)


Adapted from Introductory Analysis of Finality Times in Crypto Networks report by Messari.

Understanding the time to finality in various crypto networks requires consideration of the CAP theorem, which states that in a distributed system, you can only achieve two out of three properties: consistency, availability, and partition tolerance.

Consistency refers to the guarantee that all nodes in a distributed system will see the same data at the same time. In terms of blockchain finality, consistency means that once a block is considered finalized, all nodes will agree on its validity.

Availability ensures that the blockchain network remains operational, and nodes can participate in the consensus process to agree on new blocks.

Partition tolerance is the system's ability to continue functioning even in the presence of network partitions or communication failures. For example, let's consider a situation where a massive earthquake occurs, causing severe damage to undersea cables that connect different regions. As a result, the network communication between these regions is completely cut off, leading to a partition in the blockchain network. Despite this partition, the blockchain network should continue to function independently in each region, allowing nodes within each partition to finalize transactions and reach consensus. Once the network connectivity is restored after the earthquake, the partitions can reconcile and synchronize their respective blockchain states.

Crypto Exchanges and Time to Finality (TTF)*

Exchanges typically wait for a specific number of block confirmations before reflecting deposits or withdrawals in the user's wallet. The number of confirmations can vary significantly based on the risk analysis of whether a specific blockchain will undergo a reorganization. Let's take the exchange bitFlyer as an example: for Bitcoin, it requires 3 block confirmations, while for Ethereum Classic, it requires 20,000 block confirmations. This is on-chain to off-chain (and vice versa) transaction finality, and is related to how designers of cross-chain bridges think about finality, as we shall see in the next section.

Table 3. Comparing crypto exchanges’ time to finality



Number of Block Confirmations to Finality


Bitcoin (BTC)

1 for deposits and 2 for withdrawals**

Ethereum (ETH) & ERC20 tokens 





ETH & ERC20 


Ethereum Classic (ETC)


Litecoin (LTC)



Bitcoin (BTC)



Bitcoin (BTC)


ETH & ERC20 


Ethereum Classic (ETC)


Litecoin (LTC)


Bitcoin Cash (BCH)


Polkadot (DOT)


Stellar (XLM)


*The data is sourced from official documentation and announcements. Please refer to the link attached to the exchange name.

**The number of confirmations for deposit and withdrawals are the same if not explicitly stated otherwise.

Cross-chain Bridge Transaction Finality

Cross-chain bridges are protocols that facilitate the exchange of data or assets across diverse blockchain networks. When it comes to these bridges, ensuring finality is of utmost importance. This means that the bridge should only provide confirmations regarding the state of the source chain on the destination chain when it is certain that the state is secure and will not be reversed.

Defining finality in a universal and standardized way is challenging because different consensus models and blockchain networks have their own variations of finality, but these challenges open new design opportunities in the bridge ecosystem. Some of the possible creative solutions can be customizing finality for different uses. For example, high-value asset transfers might require stronger finality, while non-value messages can be more flexible in terms of finality. Another idea is to create mechanisms where users can find liquidity providers willing to complete bridge transactions before finality is reached as written here. This decentralized approach shifts the risk to the liquidity provider and enables faster withdrawals, reducing transaction times.

Table 4. Cross-chain transaction finality between protocols



Number of Block Confirmations to Finality

Approximate Time

Polygon Bridge 

Ethereum (ETH)

64-95 slots (possible blocks)

~5 min to deposit;

~45 min to 3 hours to withdraw (PoS bridge);

~7 days (Plasma bridge)

Optimism Bridge

Ethereum (ETH)

64-95 slots (possible blocks)

~20 min to deposit; ~20 min to withdraw (third-party bridge); 

~7 days (official bridge)

USDC Bridge

Algorand (USDC)



Avalanche (USDC)



Bitcoin (BTC)


~40 min

Ethereum (USDC, EUROC, ETH)


~3 min

Flow (USDC)



Hedera (USDC)



Polygon PoS (Bridged USDC)


~20 min

Solana (USDC)



Stellar (USDC)



Tron (USDC)


~1 min

*The data is sourced from official documentation and announcements as well as Etherscan, Polygon Bridge Explorer and Multichain Scan.

Finality on Testnets

Public testnets are networks used by protocol developers and smart contract developers to test protocol upgrades and potential smart contracts in a production-like environment before deploying them to the corresponding mainnet blockchain. Most testnets initially employed a permissioned proof-of-authority (PoA) consensus mechanism. In PoA, transaction finality is achieved through a limited number of trusted validators who have the authority to validate and finalize blocks. Since ETH on testnets has no real value, most people obtain testnet ETH from faucets.

Two testnets currently maintained by client developers are Goerli and Sepolia. Sepolia is now recommended as Goerli is being deprecated. Sepolia is relatively new, but block finalization occurs approximately every 12-24 seconds. Goerli, on the other hand, is an established testnet but will soon be deprecated. It achieves block finality approximately every 12 seconds. Regarding L2 testnets, Arbitrum achieves block finality every ~1-2 seconds, while Optimism Goerli finalizes blocks every ~2 seconds. Read more about testnets here.


In this article, we covered the trade-offs of consensus protocols between transaction finality and other design factors, as well as the frequency of chain reorganizations. We explored the time to finality on different L1s and L2s, crypto exchanges, bridges, and testnets. There is a great deal of complexity in the concept of finality but because of Ethereum's conservative approach, the May 18th stoppage had no severe consequences. Since the event, researchers are still unsure what triggered the finalization issues.