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.
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
| Protocol | Base | Key difference |
|---|
| QBFT | BFT | Permissioned validators, no staking |
| WBFT | QBFT | Adds staking, diligence scoring, slashing |
| Anzeon WBFT | WBFT | Removes staking and block rewards; validators managed by GovValidator |
Consensus properties
| Property | Value |
|---|
| Block time | ~1 second (BlockPeriodSeconds) |
| Fault tolerance | f = ⌊(n−1)/3⌋ Byzantine validators |
| Finality | Immediate, deterministic — no rollback |
| Epoch length | 10 blocks (default, configurable) |
| Proposer selection | Round-robin (default) |
| Signature scheme | BLS12-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
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:
- The consensus engine reads the current validator list from the GovValidator contract (
0x…1001)
- A new
EpochInfo is constructed and embedded in the first block header of the epoch
- 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.
WBFT metadata is RLP-encoded in the block header’s Extra field:
| Field | Purpose |
|---|
Round | Which consensus round produced this block |
EpochInfo | Validator set for this epoch (epoch blocks only) |
GasTip | Governance-enforced minimum priority fee |
PreparedSeal | Aggregated BLS signatures from PREPARE phase |
CommittedSeal | Aggregated 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
