Chain 2800 runs QBFT, the Byzantine fault tolerant engine from Hyperledger Besu, with ten validators.
Parameters
| Parameter | Value |
|---|---|
| Engine | QBFT |
| Validators | 10 |
| Quorum | 7 of 10 |
| Fault tolerance | f = 3 |
| Block period | 0.5 s configured |
| Finality | Deterministic. A committed block is not reorganised. |
| Proposer selection | Round-robin, deterministic |
Seven of ten must agree for a block to commit, so the chain tolerates three faulty or offline validators and stops at four. There is no probabilistic settlement: one confirmation is final.
What header validation checks
A node validating a header on chain 2800 checks the ordinary Ethereum rules, the QBFT seal rules, the AERE base fee floor from block 10,141,734, and, at anchor heights, the post-quantum certificate.
Two behaviours are worth knowing because they surprise client authors:
The block hash is not keccak over the raw header. Seals are stripped and the round is set to zero before hashing. An exporter that compares a re-encoded header hash with the one the node reports will disagree from block 1 if it hashes the header as it stands.
Each node assembles the final header locally, and the hash does not cover the seals. Two honest neighbours can therefore store different extraData for the same block, legally. If you are measuring the effect of a configuration change, read it from the node you changed, not from a public endpoint.
Consensus messages under post-quantum seal
Beyond the anchor, the QBFT message layers themselves were moved under post-quantum seals one layer at a time, each armed at a block height. Every validator refuses a commit without a valid post-quantum seal of its author, and nine of the ten refuse a message of any of the four types without one: the nine that run the AERE client (Besu-derived, see Client diversity), since block 17,700,000 (2026-09-08). The tenth validator runs the independent second client, which refuses a commit without a seal since block 18,131,633 (2026-09-11) and applies the rule to the other three types from AIP-22 stage 4, whose height is not yet set on chain 2800. (Corrected 2026-10-09: until that date this paragraph said that since block 17,700,000 a message of any of the four types without a valid seal is refused, without the second client's exception.) See Enforcement heights for the height of each layer.
The reason it was one layer at a time, rather than all at once, is cost: a hash-based signature costing seconds cannot go on every message of a sub-second chain. Measured, putting SLH-DSA-SHA2-128s on every commit took a test network from 0.5 to 4 seconds per block. The seal therefore rides only on the messages that the next anchor's certificate actually needs.
Two properties an operator should know
- A node keeps the post-quantum seals it hears for its chain head and persists them across restarts
in a node-local file, which is not consensus data (aere-node SPEC, section 3.5); a node that starts without them has nothing to contribute to the next certificate until it has taken part in a commit.
- The anchor rules are delivered as node options, and a node judging headers with a different build
can interpret the same option differently. A rule change therefore ships as the same build to every node that validates headers, and the check compares the build stamp rather than the options.