Consensus Layer

Anzeon WBFT is the consensus layer that orders blocks and guarantees finality on StableNet. It is derived from WBFT (an enhanced QBFT) and purpose-built for a permissioned, stablecoin-centric chain.

​

Core properties

​

How WBFT works

Every block goes through a two-phase commit protocol. Validators exchange signed messages in PREPARE and COMMIT phases, using BLS aggregated signatures for efficiency. If a round fails (e.g. the proposer is offline), validators trigger a ROUND-CHANGE to advance to the next round with an increased timeout. Timeouts grow exponentially but never exceed the configured maximum.

​

Validator set

Validators are managed on-chain through the GovValidator system contract — not through token staking.

• Permissioned — validator membership is governed by on-chain votes, not economic stake
• No block rewards — there is no inflationary issuance; validators earn only transaction fees distributed based on diligence metrics
• Epoch-based rotation — the active set is stable within each epoch (10 blocks by default) and updated only at epoch boundaries
• Epoch transition — at each epoch block, the consensus engine reads the latest validator list from GovValidator and activates it for the next epoch

This design keeps the quorum size predictable for the duration of an epoch and ensures validator changes take effect cleanly.

​

Performance

Block production is consensus-driven: the worker assembles a candidate only when the node is selected as proposer. There is no timer-based polling or unnecessary re-assembly.

​

Security guarantees

• Safety — no conflicting blocks can be finalized as long as fewer than ⌊(n−1)/3⌋ validators are Byzantine
• Liveness — the protocol requires a supermajority of validators online to continue producing blocks
• No reorgs — committed blocks are never reversed; there is no longest-chain fork-choice rule
• Permissioned validator set — governance-controlled membership limits the attack surface compared to open, stake-based networks

​

Developer implications

• No confirmation polling — treat a transaction as final the moment it appears in a block. You do not need to wait for N confirmations or track confirmation depth.
• No reorg handling — committed blocks are never reversed. You do not need rollback logic or reorganization detection in your contracts, indexers, or backend services.
• Predictable block time — 1-second blocks give your application a consistent settlement SLA. Time-sensitive workflows (payments, order matching) can rely on this cadence.
• Full EVM compatibility — finality guarantees apply to all standard Ethereum transaction types. No chain-specific contract changes are required.
• Epoch-aware integrations — if your application monitors the validator set, note that changes take effect only at epoch boundaries (every 10 blocks by default).

​

Next steps