Skip to main content

Consensus and Finality

OXN uses Byzantine Fault Tolerant (BFT) consensus. This gives it a very different finality model from Ethereum — one that indexers, bridges, and application developers should understand up front.

The short version​

  • Block time: a few seconds (check the block explorer for current values).
  • Finality: single-slot, deterministic. A block is either final or it doesn't exist. There is no probabilistic "wait N confirmations" model.
  • Reorgs: none. Once a block is produced, it cannot be rewritten.
  • Fork choice rule: not applicable — BFT consensus does not produce competing forks under honest majority.

What "final" means​

In Ethereum, when a block is added to the chain, it is tentatively final. There is a small but non-zero probability that a different fork gains majority hash rate (or validator votes) and the block is orphaned. Ethereum applications wait for 6, 12, or 32 confirmations to be reasonably sure a transaction is not rolled back.

OXN does not have this problem. BFT consensus requires that more than 2/3 of validators sign each block before it is proposed as final. If a block gets that signature threshold, it is final. If it doesn't, no block is produced at that slot. There is no scenario in which a block is produced and then later disappears.

The practical consequence: you can treat tx.status == 1 in the transaction receipt as truly final. No waiting for confirmations, no worrying about reorgs.

What this means for your app​

Wallets and dApps. As soon as tx.wait() returns, the transaction is durably included. You can show "confirmed" in the UI immediately.

Indexers. Every block you index is permanent — you don't need to maintain a rewritable window of recent blocks that might be reorged out.

Bridges. A bridge from OXN to another chain has stronger source-chain guarantees than a bridge from a probabilistic-finality chain. You still need to worry about the destination chain's finality, of course.

MEV protection. No mempool-based sandwich attacks. Encrypted calldata (see Confidentiality Model) means searchers cannot see transaction contents before they land in a block. Combined with instant finality, this closes the door on the most common MEV vectors.

What this does NOT protect against​

BFT finality guarantees liveness and safety under an honest majority of validators. If more than 1/3 of validator voting power is malicious or offline, the network:

  • Cannot produce new blocks (liveness failure) — but existing blocks are still final
  • In extreme cases (>2/3 malicious), could sign a fork — but this requires a supermajority collusion that is economically infeasible on mainnet, and is out of scope on the currently permissioned testnet

BFT does not protect against:

  • Bugs in individual smart contracts
  • Bugs in the runtime itself (SGX vulnerabilities, EVM implementation bugs)
  • Governance decisions by a supermajority to change the rules

Block time in practice​

Block time on OXN is fast — a few seconds — but is not zero. If you need lower latency (sub-second confirmation), OXN is not the right fit for that specific interaction; you would need an off-chain layer with its own security assumptions.

The current block time can be observed in real time on the block explorer. It may adjust as the network grows.

Comparison with Ethereum​

PropertyEthereumOXN
Consensus familyNakamoto + Casper FFGBFT
Block time~12s slotsA few seconds
Confirmations to trust6–32 (probabilistic)1 (deterministic)
Reorg possibilityYes, smallNo (under honest majority)
Finality latency~13 minutesSame block
Fork choice neededYesNo

Next steps​