Transaction Finality Explainer

pages/stack/transactions/_meta.json

@@ -1,7 +1,8 @@
 {
-    "fees": "Transaction Fees",
-    "transaction-flow": "Transaction Flow",
-    "deposit-flow": "Deposit Flow",
-    "withdrawal-flow": "Withdrawal Flow",
-    "forced-transaction": "Forced Transaction"
+    "fees": "Transaction fees",
+    "transaction-flow": "Transaction flow",
+    "transaction-finality":"Transaction finality",
+    "deposit-flow": "Deposit flow",
+    "withdrawal-flow": "Withdrawal flow",
+    "forced-transaction": "Forced transaction"
 }

pages/stack/transactions/transaction-finality.mdx

@@ -0,0 +1,92 @@
+---
+title: Transaction Finality
+lang: en-US
+description: Learn about finality in OP Stack and the steps to achieve transaction settlement.
+---
+
+import Image from 'next/image'
+import { Callout } from 'nextra/components'
+
+# Transaction finality
+
+This guide explains how transaction finality works in the OP Stack and addresses common misconceptions around transaction finality and the Fault Proof System.
+
+The OP Stack derives its security from Ethereum by utilizing Ethereum's consensus mechanism. Instead of running an entirely separate consensus protocol, the OP Stack derives a layer 2 blockchain by reading the finalized state on Ethereum.
+
+## Transaction finality states
+
+In the OP Stack, transaction finality progresses through three key stages:
+
+1.  **Unsafe:** The sequencer creates a block containing the transaction, but the transaction data has not yet been posted to Ethereum (L1). The block is circulated within the L2 network for speed.
+
+2.  **Safe:** The batcher posts the transaction data to L1. At this point, any L2 node can derive the transaction.
+
+3.  **Finalized:** Transactions are finalized once more than 65 Ethereum blocks (approximately 10-15 minutes) have passed, ensuring that the L1 data is secure and cannot be reorganized.
+
+<Image src="/img/op-stack/protocol/tx-finality.png" alt="Transaction Finality Diagram." width={0} height={0} sizes="100vw" style={{ width: '100%', height: 'auto' }} quality={100} />
+
+### Transaction validity
+
+When a transaction is submitted to the network, it is either valid or invalid. If the transaction is valid, the sequencer puts it in a block. If it is invalid, the transaction is discarded. There is no way the sequencer can write an invalid transaction to a new block.
+
+## Sequencer trust assumptions
+
+The sequencer operates with the following trust assumptions:
+
+*   It can temporarily withhold transactions.
+*   It may attempt to reorder transactions before L1 publication.
+*   Once transactions are published on L1, the sequencer cannot modify or censor them.
+*   The sequencer cannot affect finalized transactions.
+
+## Common misconceptions
+
+The biggest misconception about transaction finality is that a transaction needs to wait for the entire challenge window to become finalized. 
+The reality is the OP Stack transaction finality takes minutes, not over a week. This section explains transaction finality and the Fault Proof System's challenge mechanism.
+
+### Reorgs and finality
+Once a transaction is included in a finalized Ethereum block, it cannot be reorganized. 
+
+If an Ethereum reorganization (reorg) occurs:
+
+1.  L2 nodes detect the L1 reorg.
+2.  Affected `safe` L2 blocks revert to an `unsafe` status.
+3.  The sequencer typically republishes the same transactions.
+4.  The system returns to a consistent state after reprocessing.
+
+### The role of proof system
+
+The Fault Proof System is designed to ensure the accuracy of certain claims about the transaction state on the L2. It provides a way to prove messages from L2 to L1 are correct. It does not have to do with transaction finality.
+
+A claim in the context of OP Stack is a statement asserting the state of the system at a specific block height. For instance, a claim might assert that at block 1,000,000 a certain address has all of the ether on the entire L2. If other participants believe this claim to be incorrect, they can challenge it.
+
+Challenges focus on proving whether a given claim is valid. The outcome of a challenge does not impact the underlying chain. For example, if a claim about a certain address owning all the ether on the L2 is proven wrong, that address would not be able to move the ether from L2 to their address on L1.
+
+The challenge period provides time for challenges to be raised and resolved.
+Although OP Stack finalizes transactions quickly (within 20 minutes), the 7-day challenge window serves two critical purposes:
+
+1.  It allows time to dispute the correctness of output state roots posted to Ethereum by the proposer.
+2.  It provides a security period for withdrawal processing, ensuring the integrity of cross-chain operations.
+
+### Withdrawal delays vs. finality
+
+One common misconception is confusing withdrawal delays with transaction finality:
+
+*   Transaction finality occurs in approximately 20 minutes.
+*   Withdrawal delays (often 7 days) are separate from transaction finality.
+*   Withdrawal delays are application-level security features.
+*   These delays affect only L1 withdrawals, not L2 transaction finality.
+
+### Bridge independence
+
+Key aspects of bridge systems include:
+
+*   Bridges are application-level constructs.
+*   They operate independently of the core OP Stack protocol.
+*   Bridge security does not affect the validity of L2 transactions.
+*   Bridge failures do not cause L2 reorgs or state changes.
+
+For example, a custom bridge might be developed to allow ERC-20 tokens to move between layers. However, this bridge is application-level and not native to the OP Stack. If there is an issue with the bridge, such as incorrect proof validation, it does not impact the protocol itself but affects the subjective value of the bridged assets.
+
+## Conclusion
+
+Transaction finality in the OP Stack relies on Ethereum's consensus mechanism. The OP Stack inherits Ethereum's finality guarantees, while the proof system adds a layer of validation for app-level functionality.

words.txt

@@ -16,6 +16,7 @@ Arweave
 authrpc
 Badgeholder's
 Badgeholders
+badgeholders
 basefee
 BGEZ
 BGTZ
@@ -169,7 +170,6 @@ leveldb
 lightkdf
 logfile
 logfmt
-marketshare
 MAXAGE
 maxage
 MAXBACKUPS
@@ -204,7 +204,6 @@ MTHI
 MTLO
 MULT
 multiaddr
-Multichain
 multichain
 multiclient
 multisigs
@@ -303,7 +302,7 @@ replayability
 reproven
 REQUIREDBLOCKS
 requiredblocks
-Rollouts
+rollouts
 Rollups
 rollups
 Routescan