> ## Documentation Index
> Fetch the complete documentation index at: https://docs.stablenet.network/llms.txt
> Use this file to discover all available pages before exploring further.

# 1-Second Finality

> Committed blocks on StableNet are irreversible — no confirmation waiting, no reorg handling required.

> Every block on StableNet is final the moment it is committed. There is no "probably final" state.

## What changes for you

On Ethereum mainnet, you wait for 12–64 block confirmations because blocks can be reorganized. On StableNet, Anzeon WBFT commits each block through a quorum of validators before it is ever written to the chain. Once committed, it cannot be reversed.

|                             | Longest-chain (PoW/PoS)   | Anzeon WBFT   |
| --------------------------- | ------------------------- | ------------- |
| Finality model              | Probabilistic             | Deterministic |
| Time to settlement          | Minutes (N confirmations) | \~1 second    |
| Reorg possible              | Yes                       | No            |
| Confirmation polling needed | Yes                       | No            |

## Practical implications

**No confirmation depth logic.**
You do not need to wait for 6 or 12 blocks before treating a transaction as settled. Block N is final as soon as `eth_getTransactionReceipt` returns a receipt for it.

```typescript theme={null}
// This is sufficient — no confirmation depth needed
const receipt = await provider.waitForTransaction(txHash);
console.log("Settled in block", receipt.blockNumber);
```

**No reorg handling.**
You do not need to listen for `eth_subscribe("newHeads")` to detect chain reorganizations or re-check old receipts. Once a block is in the chain, it stays.

**Payment flows are simpler.**
A transfer confirmed in block N can trigger downstream logic immediately — no hold period, no rollback risk.

## How finality is guaranteed

Each block goes through a two-phase BFT commit before it is added to the chain:

1. **PREPARE phase** — validators vote on a block proposal; `2f+1` votes advance to COMMIT
2. **COMMIT phase** — validators vote to finalize; `2f+1` votes seal the block permanently

Where `f = ⌊(n−1)/3⌋` is the maximum number of Byzantine validators the network can tolerate. A block sealed by `2f+1` COMMIT votes mathematically cannot be reversed — doing so would require more than `f` colluding validators.

## Developer benefits

* Call `eth_getTransactionReceipt` once — no retry loop for confirmation depth
* No reorg event handling in your indexer or backend
* Single-block settlement enables real-time payment confirmation

## Related

* [Consensus](/en/v0.3/learn/consensus) — how PREPARE and COMMIT phases work in detail
* [Architecture Overview](/en/v0.3/learn/architecture-overview) — full transaction lifecycle