Consensus

Chain 2800 runs QBFT, a Byzantine fault tolerant consensus protocol, with ten validators on two clients: a Besu-derived client at nine of them and, since 2026-09-11, a Nethermind-derived client at the tenth (corrected 2026-10-27: this line named the engine from Hyperledger Besu alone).

Parameters

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: for a validator one confirmation is final. From block 25,080,000 (AIP-22 stage 5) a node that does not take part in consensus, such as the public RPC endpoints, admits a header between anchors on the Falcon-512 seal of its proposer alone, so until the next anchor the blocks above its finalized block, including blocks it has already shown, can be replaced by a branch that the key of a single validator builds (such a node keeps the total-difficulty fork choice of the upstream client; the rule that never leaves a decided block runs on the validators only); for settlement, read the finalized or safe block, which moves only on an anchor certificate that the key of one validator cannot produce (derived from the code; measured on the rehearsal network 28099 with a classical-only fork, AIP-22 record of 2026-09-27: such a node followed the fork up to the block before the next anchor and moved to the anchored chain once linked to an honest validator; not measured: the same with a post-quantum key from stage 5, and whether a node started from the published package, with its seal ceiling at 1, answers these tags the same way).

What header validation checks

A node validating a header on chain 2800 checks the ordinary Ethereum rules, the QBFT seal rules (from block 25,080,000, AIP-22 stage 5, the Falcon-512 seal of the proposer on every header instead of the ECDSA commit seals), 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.

The hash does not cover the seals, and below block 25,080,000 (AIP-22 stage 5) each node assembled the final header locally. Two honest neighbours could therefore store different extraData for the same block, legally; from that block element 4 is empty, so nodes that committed a block in the same round store the same bytes, and only the round (element 3) and the proposer seal of that round (element 6) can still differ under the same hash, for a block that nodes committed in different rounds (a value locked in one round and proposed again in a later one); a node that imports the block stores the form of the node that served it. 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 since block 24,300,000 (AIP-22 stage 4, 2026-10-25). (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.

Each of the four layers is a Falcon-512 seal of the author on every message of its type; the layers were armed one at a time so that each step could be observed on the live chain before the next (Enforcement heights). The hash-based scheme is a separate matter: a 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), so the SLH-DSA seal rides only on the commit of the parent of an anchor whose certificate carries SLH-DSA seals.

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.