Skip to main content
Anzeon WBFT is a Proof-of-Authority BFT consensus engine derived from WBFT (an evolution of QBFT), adapted for StableNet’s stablecoin architecture.

​
Protocol lineage

ProtocolBaseKey difference
QBFTBFTPermissioned validators, no staking
WBFTQBFTAdds staking, diligence scoring, slashing
Anzeon WBFTWBFTRemoves staking and block rewards; validators managed by GovValidator
Anzeon WBFT removes staking and block rewards because StableNet validators are approved governance participants, not economic stakers. Validators earn only transaction fees (BaseFee distribution).

​
Consensus properties

PropertyValue
Block time~1 second (BlockPeriodSeconds)
Fault tolerancef = ⌊(n−1)/3⌋ Byzantine validators
FinalityImmediate, deterministic — no rollback
Epoch length10 blocks (default, configurable)
Proposer selectionRound-robin (default)
Signature schemeBLS12-381 aggregated

​
Block production flow

Anzeon WBFT replaces the timer-based mining loop with a consensus-event-driven loop. A new block is only produced when the previous block reaches finality. 
[Proposer selected]
       │
       ▼
PROPOSE ──► Proposer broadcasts signed block proposal
       │
       ▼
PREPARE ──► Validators verify proposal, broadcast PREPARE-VOTE
       │    (collect 2f+1 PREPARE-VOTEs)
       ▼
COMMIT  ──► Validators broadcast COMMIT-VOTE
       │    (collect 2f+1 COMMIT-VOTEs)
       ▼
FINALIZE ──► Block sealed, added to chain — permanently final
A round fails if RequestTimeoutSeconds elapses without quorum. The protocol advances to the next round with an exponentially increasing timeout (capped at MaxRequestTimeoutSeconds), and a new proposer is selected.

​
BLS signature aggregation

In each phase, validators sign with BLS12-381 keys. All 2f+1 signatures for a phase are aggregated into a single compact signature before being embedded in the block header. This reduces:
  • Network message size per phase
  • Verification cost at each node
The aggregated signatures are stored in the WBFTExtra field of the block header (PreparedSeal for PREPARE, CommittedSeal for COMMIT).

​
Validator set management

The active validator set is stored per epoch (default: 10 blocks). At each epoch boundary:
  1. The consensus engine reads the current validator list from the GovValidator contract (0x…1001)
  2. A new EpochInfo is constructed and embedded in the first block header of the epoch
  3. The new validator set activates for the next epoch
Changes to the validator set (additions, removals) take effect at the next epoch boundary — mid-epoch changes are not possible.

​
Gas tip synchronization

After each block, the worker queries GovValidator for the current gasTip value and updates the transaction pool filter. Transactions below the governance-enforced tip are rejected before they reach block inclusion.

​
Block header extra data

WBFT metadata is RLP-encoded in the block header’s Extra field:
FieldPurpose
RoundWhich consensus round produced this block
EpochInfoValidator set for this epoch (epoch blocks only)
GasTipGovernance-enforced minimum priority fee
PreparedSealAggregated BLS signatures from PREPARE phase
CommittedSealAggregated BLS signatures from COMMIT phase

​
Developer benefits

  • One block = final — no reorganizations occur under normal operation
  • No reorg handling needed — eth_getTransactionReceipt with any block number is authoritative
  • Validators are PoA — the validator set is controlled by governance, not open staking