> ## 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.

# Consensus

> How Anzeon WBFT produces and finalizes blocks using a two-phase BFT commit and BLS12-381 signature aggregation.

> 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 |

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

| 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.

```text theme={null}
[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:

| 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

## Related

* [1-Second Finality](/en/v0.3/learn/1-second-finality) — developer impact of deterministic finality
* [Governance Overview](/en/v0.3/learn/governance-overview) — how validators are added and removed
* [Gas and Fees](/en/v0.3/learn/gas-and-fees) — how the gas tip flows from GovValidator to transactions