Why deterministic finality matters
Most proof-of-work and longest-chain protocols give you probabilistic finality: a block becomes more certain over time as more blocks are built on top of it, but it can always be reversed by a longer chain. This means your application must track confirmation depth and handle reorganizations. Anzeon WBFT uses Byzantine Fault Tolerant (BFT) consensus, which gives you deterministic finality: a block that has been committed is permanently final. There is no “probably final” state, no waiting for additional confirmations, and no risk of reorgs.| Probabilistic (PoW/PoS longest-chain) | Deterministic (BFT) | |
|---|---|---|
| Settlement time | Minutes to hours (N confirmations) | ~1 second |
| Rollback possible | Yes | No |
| Reorg handling required | Yes | No |
How WBFT works
Anzeon WBFT runs a two-phase commit protocol for every block. Validators exchange signed messages in two phases — PREPARE and COMMIT — using BLS12-381 aggregated signatures for efficiency. Consensus properties| Property | Value |
|---|---|
| Block time | 1 second (configurable) |
| Finality | Deterministic, immediate |
| Fault tolerance | Up to f = ⌊(n−1)/3⌋ Byzantine validators |
| Signature scheme | BLS12-381 (aggregated) |
| Quorum required | 2f + 1 signatures per phase |
PREPARE
The proposer broadcasts a candidate block. Each validator verifies the block and broadcasts a PREPARE-VOTE. Once
2f + 1 PREPARE-VOTEs are collected, the block is “prepared.”GovValidator contract. The active set is stable within each epoch (default: 10 blocks) and updated only at epoch boundaries, so the quorum size is predictable for the duration of an epoch.
Developer benefits
- No confirmation polling — you can treat a transaction as final as soon as it appears in a block. There is no need to wait for N confirmations.
- No reorg handling — committed blocks are never reversed. You do not need to implement rollback logic or reorganization detection in your contracts or indexers.
- Consistent 1-second latency — block time is governance-configured at
1second, giving your application a predictable settlement SLA rather than variable finality windows. - Full EVM compatibility — finality guarantees apply to all standard Ethereum transaction types. No chain-specific changes to your contracts are required.
Deterministic finality holds as long as fewer than
⌊(n−1)/3⌋ validators are Byzantine. On StableNet, validators are permissioned through governance, which limits the attack surface compared to open networks.