# AIP-9: Consensus Mechanism: QBFT, not HotStuff

## Preamble

| Field | Value |
| --- | --- |
| AIP | 9 |
| Title | Consensus Mechanism: QBFT, not HotStuff |
| Author | Aere Network Foundation |
| Type | Informational |
| Category | (none) |
| Status | Final |
| Created | 2026-07-19 |
| Requires | 3 |
| Supersedes | None |
| Superseded-By | None |
| Ratification | Foundation-ratified (pre-decentralization) |

## Abstract

This AIP records the decision to run QBFT as Aere's consensus protocol rather
than HotStuff or a pipelined HotStuff variant. It backfills a decision that is
already live on chain 2800. It is a decision record: it explains why a shipped
choice was made and mandates nothing new.

## Motivation

Aere is a settlement layer whose core promise is deterministic, single-slot
finality at a sub-second cadence, running a small permissioned validator set:
seven validators today, with a roadmap target in the 9 to 21 range. The consensus
choice determines whether that promise is deliverable at all, and it was taken
without being written down anywhere citable.

## Specification

Aere runs QBFT, the Byzantine-fault-tolerant IBFT-family protocol as implemented
in Hyperledger Besu, producing deterministic single-block finality.

- Validator count N = 7 (**measured**, all Foundation-operated).
- Fault tolerance f = 2, commit quorum 2f + 1 = 5-of-7 (**spec**).
- Target block period 500 ms (**spec**, see AIP-3); measured mean interval
  516.4 ms.
- Validator seals are classical secp256k1 ECDSA. **Consensus is not
  post-quantum** and no part of this record implies otherwise.

## Rationale

At Aere's validator-set size, QBFT's O(N^2) message complexity is negligible in
absolute terms: a 5-of-7 quorum verify costs on the order of a few milliseconds
per block, a small fraction of the 500 ms slot. Against that non-cost, QBFT gives
three concrete advantages. It provides deterministic instant single-block
finality, which is the exact settlement guarantee the network sells. It is mature
and already integrated in Besu, so there is no new-protocol implementation risk.
And Aere's post-quantum consensus research, second-client work, and zk finality
proofs are all built against QBFT, so changing it would invalidate that work.

**Alternatives rejected.** HotStuff and its pipelined variants, whose linear
per-round communication complexity is engineered to scale BFT to hundreds of
validators. That scaling regime is one Aere does not operate in and does not plan
to enter under this design, so HotStuff's headline benefit is unavailable, while
adopting it would add the risk and integration cost of a protocol less
battle-tested in the chosen client.

## Backwards Compatibility

None. This records the existing protocol.

## Security Considerations

At N = 7 the fault tolerance against node outages is real, but **all seven
validators are Foundation-operated**, so the effective Nakamoto coefficient is 1.
Decentralization, not the consensus mechanism, is the binding trust assumption on
this chain. A reader should not read "Byzantine fault tolerant" as "trustless".

Consensus seals are secp256k1 ECDSA and are therefore classically breakable by a
cryptographically relevant quantum computer. Work on a hybrid post-quantum
consensus path is recorded in AIP-15 and is **not live**.

## Reference Implementation and On-Chain Deployment

Chain ID 2800. Configuration lives in the Besu QBFT genesis and chain config; the
block period transition is documented in AIP-3. There is no contract address for
a consensus choice.

## Errata

**Erratum 1 (2026-09-12).** Every validator count in this document is a
measurement of 2026-07-19, the day it was written, and none of them carries that
date in its own sentence, so a sentence quoted on its own reads as a claim about
today. Read them as dated: "seven validators today" in the Motivation,
"Validator count N = 7 (**measured**)" and "commit quorum 2f + 1 = 5-of-7" in the
Specification, and "At N = 7 ... all seven validators are Foundation-operated" in
the Security Considerations were all true on 2026-07-19. Measured 2026-09-12 on
the live chain: N = 10, f = 3, commit quorum 7-of-10, and one of the ten runs a
different client implementation. The decision this AIP records, QBFT rather than
HotStuff, is unaffected, and so is the Nakamoto argument in the Security
Considerations: the set grew, the operator count did not. The original text is
left exactly as published, per AIP-1 section 5.

## Copyright

Released to the public domain (CC0). No rights reserved.