Chain 2800 has a normative protocol specification. It is the authority; every other page in this documentation is the readable form of part of it.
Where it is
It ships inside the public node package as SPEC.md:
git clone https://git.aere.network/aere-network/aere-node.git
less aere-node/SPEC.mdWhat is in it
| Section | Subject |
|---|---|
| 0 | Conventions, and how every statement in the document is grounded |
| 1 | Chain parameters: identity, genesis header fields, EVM fork schedule, block period |
| 2 | Consensus: QBFT engine, quorum, the extraData structure with the AERE sixth element, decoder strictness, what header validation checks and one thing it does not |
| 3 | The post-quantum certificate anchor: the claim stated exactly, activation, the two pre-images and the certificate encoding, the validation rules, the Falcon registries |
| 4 | Precompiles: the five on mainnet, Falcon input framing, testnet-only ones, verification against the live chain |
| 5 | Fee rules: EIP-1559 with the AERE floor, what a follower must and must not enforce |
| 6 | Sync requirements: what a third-party client must implement to follow the chain |
| 7 | Formal models: what is proven, where, and the limits |
| 8 | Known divergences, historical windows and corrections. Normative. |
| 9 | What this specification cannot state from the published sources |
Two sections worth reading even if you read nothing else
Section 8, known divergences. It is normative and it records the windows where the chain did not behave the way the rest of the document describes, including the ones caused by our own mistakes. A specification without that section is a specification you cannot use to write a second client.
Section 9, what it cannot state. It lists the questions the published sources do not answer. We would rather publish the boundary of what we can ground than let a reader assume the document is complete.
How claims are grounded
Every factual statement in the specification carries its ground: either a source reference to a file in the package, or a MEASURED tag with a date and the method. A statement with neither is a statement the document does not make.
That convention is the reason the specification is useful to someone implementing a second client: you can tell, per sentence, whether you are reading code, a measurement, or an intention.
If you are writing a client
Read section 6 first. It is written for exactly that, and it includes the facts a syncing client will observe so that they are expectations rather than surprises.