Version history

A correction found by a review of the published text; the cryptography the document describes did not change.

• The block rate in the abstract. The abstract said blocks are produced every half second, the configured target; it now gives about 0.62 s measured against a 0.5 s target, the figure the summary has given since 2.1.309.

Corrections found by a review of the published text; the cryptography the document describes did not change.

• What the block hash covers, in the roadmap. The first ordered item of section 9.3 said the certificate is bound by the same hash that binds the rest of the header, and that the identity of the block depends on it. It now says the certificate itself is not hashed, its digest is: a certificate detached or swapped no longer matches the digest and a node that validates the header refuses the anchor, while the block hash does not change.
• The finality figure in the summary. The page description, the consensus card and one list item gave 0.5-second blocks and finality, the configured target; they now give about 0.62 s measured against a 0.5 s target.

Corrections found by a review of the published text; the cryptography the document describes did not change.

• What the block hash covers. Two paragraphs that said the block hash covers a post-quantum certificate now say it covers the digest of that certificate: the 32-byte digest sits in the hashed part of the header, so a seal changed or removed makes the certificate disagree with the digest and the anchor fails validation, while the block hash itself does not change.
• Five precompiles, four verifiers. The live note called all five post-quantum precompiles verifiers; four of them verify signatures (Falcon-512, Falcon-1024, ML-DSA-44, SLH-DSA-128s) and the fifth, SHAKE256, is a hash function.
• The finality figure. A figure caption gave 0.5 s finality, the configured target; it now gives about 0.62 s, the measured figure.

Corrections found by a review of the published text; the cryptography the document describes did not change.

• Who enforces the anchor rule. Two sentences that said every node enforces the minimum of seals on an anchor block, or that an anchor without its certificate is rejected, now say the validators do, and that a node started from the published node package lowers that count to one seal (aere-node SPEC.md section 6.4).
• The anchor at block 17,102,384. Three places (two paragraphs and a figure caption) that said every anchor from 2026-09-04 to 2026-09-29 also carried SLH-DSA seals now name the one exception: block 17,102,384, under a one-anchor step of the minimum to zero. (Corrected 2026-10-27: this entry said two places.)

Corrections found by a review of the published text; the cryptography the document describes did not change.

• Two clients. The sentence that said the network has one client implementation now says it runs on two: nine Besu-derived validators and, since 2026-09-11, one Nethermind-derived.
• Consensus messages. The sentence that said validators sign ordinary QBFT messages over secp256k1 now says they sign with secp256k1 keys and carry post-quantum seals of their authors on them, and that since block 24,300,000 (AIP-22 stage 4) every vote is attributed only through that seal.
• Anchor rule. The summary that said a node does not import an anchor block without its certificate now says a validator does not, and that a node started from the published node package lowers that count to one seal.
• Quorum. Twelve places that called the quorum of the nine-validator set "2f+1" now say "QBFT quorum" (at nine validators the quorum, six, is not 2f+1).

The consensus sentences that still described the chain before AIP-22 stage 4 were brought to what the clients do since block 24,300,000 (2026-10-25). The cryptography the document describes did not change.

• Consensus, since block 24,300,000. The sentences that said the validators' consensus signatures remain classical, or that consensus is secp256k1 ECDSA QBFT, now say that consensus is QBFT whose votes every validator attributes only through their verified post-quantum seals since that block, and that headers are still admitted on their ECDSA commit seals until AIP-22 stage 5.
• Two layers. The passages that compare the account layer with the consensus layer now say that consensus is a separate layer which has itself changed in steps (the post-quantum anchor from block 13,014,000, and the vote rule from block 24,300,000), instead of saying that consensus was left untouched.
• What did not change. The anchor certificate rules, the round-bound commit seal in force since block 24,148,752, and every measured figure of the chain.

The sentences about the anchor certificate were dated at AIP-22 stage R, in force on chain 2800 since block 24,148,752 (2026-10-24).

• Anchor certificate, since block 24,148,752. The sentences that said the seals of an anchor certificate prove that its signers signed the block, not that it was decided, now say that this was so below block 24,148,752, and that from that block a certificate that carries the quorum of one round proves the decision.
• What did not change. The anchor certificate rules (Falcon-512 every 32nd block, SLH-DSA every 128th, at least seven of ten seals per scheme) and every measured figure of the chain.

AIP-22 stage 4 took effect on chain 2800 at block 24,300,000 (2026-10-25): from that block every validator, on both clients, attributes a consensus vote only through its verified post-quantum seal. The consensus text of this document says so, dated; the cryptography it describes did not change.

• Consensus, since block 24,300,000. The sentences that said per-block finality rests on classical ECDSA now say that since that block a vote counts only through its verified post-quantum seal, that the header still carries the classical secp256k1 ECDSA commit seals until stage 5, and that a block is final on import as before, its post-quantum proof being the anchor certificate that covers it.
• Figures. The consensus algorithm field and its note (generated from the node configuration) carry the same dated statement; the rest of the figures are unchanged.
• What did not change. The anchor certificate rules (Falcon-512 every 32nd block, SLH-DSA every 128th, at least seven of ten seals per scheme), the round-bound commit seal in force since block 24,148,752, and every measured figure of the chain.

The heights of the next two AIP-22 stages on chain 2800, announced on 2026-10-22, are now in the text. Nothing else changed.

• Stage 4 height. Four sentences that said the second client applies the rule to proposal, prepare and round-change messages from AIP-22 stage 4, "whose height is not yet set on chain 2800", now say it does so from AIP-22 stage 4, at block 24,300,000 on chain 2800, a height announced on 2026-10-22. Stage 4 is not active until that block; the roadmap gives both heights (stage R at block 24,148,752).

No change to the writing. The number moved because the page around the text changed.

• A stricter content-security policy for the whole site moved the page's small scripts into files: the print button lost its inline handler and the theme switch now loads from a file. Not a sentence, figure, table or link of the document changed.
• The editorial hash then counted the bytes of the whole page, so this moved the version, against the rule at the top of this page. That is a defect of the hash, not a change of content, and it is corrected below under 2.1.300.

No change to the writing. Correction: two version numbers were moved by changes that touched no sentence.

• The site's shared header changed version, and the page's reference to its script changed with it (?v=v21 to ?v=v24). That single reference is the only difference outside the figures and the stamps, measured on the copies of the page kept before and after.
• The run that published it did not record the number, and no copy of the page under 2.1.300 was kept, so the date is given as the interval it falls in and no hash is published for this entry.
• Fixed on 2026-10-19: the editorial hash now counts what a reader reads, the text, the order and nesting of the document and the target of every link, and no longer the page's scripts, style sheets or presentation attributes. At the change of definition the version is carried forward, not moved. From now on a change of the site's header or of its security policy does not create a version.

Present-tense statements brought to the measured state of 2026-10-15.

• Block interval: the paper gave 0.557 s, measured on 2026-08-01, beside "0.5-second blocks". Re-measured on 2026-10-15 across the last 100,000 blocks the mean is 0.620 s against the 0.5-second target; the paper now says target and measurement apart, and keeps the August figure as history.
• Consensus clients: "Hyperledger Besu QBFT" in the Phase 1 description now names both client implementations; the Nethermind-derived client has been the tenth validator since 2026-09-11.
• Validator roadmap: "twelve admissions from 9 to 21" became "eleven admissions from 10 to 21".
• Post-quantum scope: the risk item opened with "the post-quantum property is at the application and execution layer, not consensus" and then described the post-quantum rules of consensus. It now says per-block finality rests on classical ECDSA and that the post-quantum property is partial in consensus.
• Onboarding paymaster: the paper said it sponsors operations; measured on 2026-10-15 it holds no deposit in either entry point, so it sponsors nothing until it is funded, and the paper says so.

Correction: the version number moved on a schedule between 2026-08-09 and 2026-10-15.

• From 2026-08-09 to 2026-10-15 the version number also moved at every scheduled refresh of the figures, four times a day, without any change of content. The header and the footer of the page carry the version and the date; the generator writes them, and the editorial hash counted them, so every run saw the previous version printed in the page, found a different hash and moved the number. That is how the document reached 2.1.298 while the last change of content listed here is 2.1.277.
• So, for the published numbers of that period, two statements of this page were not true: that refreshing a measured figure does not create a new version, and that the editorial hash moves only on a written change. The versions listed on this page are the ones whose content changed; every other number in that range differs from the one before it only in the measured figures, in those two stamps and in the verification block.
• Fixed on 2026-10-15: the editorial hash no longer counts the page's own version and date stamps, which is what the rule above says. 2.1.298 is the last number moved that way, and its content is that of 2.1.277; from now on the number moves only when the writing changes, and each such version is listed here.

Post-quantum message enforcement stated per client.

• Two passages said that every consensus message is refused without a post-quantum seal on every validator. Corrected with a dated note: every validator refuses a commit without one, and the nine validators of the primary, Besu-derived client refuse any of the four QBFT message types without one; the second, Nethermind-derived client, a validator since 2026-09-11, refuses an unsealed commit from block 18,131,633 and applies the other three types from AIP-22 stage 4, whose height is not yet set on chain 2800.
• The same correction was made on the same day in AIP-20, AIP-22, the node specification, the documentation and the site pages. The enforcement heights of the primary client are unchanged.

Anchor certificate seals described by what they prove.

• Wherever the text said that a certificate carries the full quorum of seals, it now says as many as the quorum: the post-quantum commit seals sign the block without the consensus round, so they prove that those validators signed the block, not that it was decided (AIP-22 erratum of 2026-10-01). The first mention says this in full.
• The enforced minimums, heights and dates are unchanged. Descriptions of the isolated test network are history and were not changed.

The consensus chapter brought to the AIP-22 stages active on chain 2800 (post-quantum seals and validator identities as measured on chain; per-block finality remains classical).

• Stage 1 (block 20,715,632, 2026-09-29): the enforced minimum of the anchor certificate rose from six to seven seals per scheme of the ten validators.
• Stage 2 (block 20,746,736, 2026-09-29): Falcon-512 seals at every 32nd block, SLH-DSA-SHA2-128s seals as well at every 128th; the 128-block grid of 2026-09-05 to 2026-09-29 is dated history.
• Stage 3 (block 20,836,228, 2026-09-30): validators are named in consensus by post-quantum ids. Stages 4 and 5 are not active and the text does not say they are.

Direction, stated 2026-09-27: one dated paragraph added at the opening of chapter 9 (Governance, Roadmap, and Limitations). No claim about the chain changed; the paper still claims only what is live.

• Chapter 9, opening. AERE started as a public EVM Layer 1 with half-second finality, and that is what chain 2800 is today; the chain is the vehicle, not the destination. The paragraph names the eight components being built on it (settlement, consensus with post-quantum seals, post-quantum transactions, verifiable execution, proofs and notarization, cryptographic infrastructure for organisations, identity and machine payments, verification tools for everyone) and points to the dated table at aere.network/vision.html, where each component is marked live, building or end state, with the block, date or endpoint behind every live line.
• What is not claimed. Nothing "universal" in the present tense; no per-block finality on post-quantum signatures; no independent operators; no external audit. Those are building or end-state lines on the direction page, not statements of this paper.
• Method. One exact, counted insertion (whitepaper-sursa/repara-directia-2026-09-27.py), applied to the publisher's template with a copy kept beforehand; the version block, hashes and the anchor were regenerated by the publisher and verified from the internet.

Correction, dated 2026-09-27: the second client (an independently implemented Nethermind fork) has been the tenth validator of chain 2800 since 2026-09-11 and proposes and seals blocks. Eight sentences that still described, in the present tense, a mainnet with one producing client are now dated; what the document claims and refuses to claim is stated below.

• Chapter 2, limits. The paragraph on producing clients no longer ends with the sentence denying mainnet block production by the second client; it says the second client reached QBFT consensus with Besu first on an isolated testnet and, since 2026-09-11, on chain 2800 itself.
• Boundary on client diversity. "Besu remains the sole producer of every block" is dated ("until 2026-09-11"); the founder-supervised admission of the second client is recorded as taken on 2026-09-11 after extended soaking and review.
• Chapter 9, roadmap. "Hold an honest one-client posture until a shadow-net interop run proves otherwise" becomes "keep the client posture honest: two implementations since 2026-09-11, Besu-dependent liveness until no client holds more than two-thirds of the set"; the sentence describing a mainnet with one producing client on Besu is dated the same way.
• Limits, last chapter. "One producing client" becomes "Two producing clients, Besu-dependent liveness", with the follower phase kept as history (as of 2026-08-10).
• What is not claimed. Client diversity in the fault-tolerance sense: nine of the ten validators run Besu, so a consensus fault in Besu would still stop the chain. The phrase "full client diversity" remains unclaimed.
• Method. Exact, counted replacements (whitepaper-sursa/repara-al-doilea-client-2026-09-27.py); the version block, hashes and the anchor were regenerated by the publisher and verified from the internet. A sentence-level gate now fails the build if any public page says at present tense that the second client does not produce.

Three audit adjectives removed. Nothing that was measured changed; three things we could not cite stopped being asserted.

• The wrapped library. The post-quantum precompile chapter used to attach the adjective audited to the native library the precompiles wrap. That library is Bouncy Castle. Aere ships bcprov-jdk18on, which is not a FIPS validated cryptographic module and for which no published third-party review is known to us. It now reads a maintained native library. The evidence in the rest of that sentence is untouched: bit-for-bit agreement with the same NIST KAT and ACVP vectors the on-chain Solidity verifiers pass, 41 of 41 accept and reject cases.
• AereDelegate7702V2. The same adjective was attached to this contract, called the audited replacement for the earlier V1. That is our own contract, and this project has had no third-party security audit; the sentence now reads the corrected replacement, which is what the paragraph above it already said in full.
• webauthn-sol. The port we build on was described with the same adjective, this time about someone else's work. An audit of someone else's library is still a claim, and we carry no link to it, so the adjective is gone. What the port does is stated as before.
• Why it took this long. The check that has guarded this wording since July looked for the two words side by side. All three sentences put something in between, so it passed them for weeks. The check now reads the whole sentence, in both orders, and covers the production sources as well as the published copies.

The validator set grew from nine to ten, and the tenth validator runs a different client; the document now says so in every place that counted validators.

• Ten validators, f=3, quorum 7 of 10, since 2026-09-11. The tenth validator was admitted by the usual header vote (six of nine) and produces blocks in the normal rotation. It runs Nethermind, so mainnet blocks are now produced by two independent clients (nine Besu validators, one Nethermind validator); until this date the second client only validated and followed. All ten keys remain operated by the Foundation, so the honest counterweight about a single operator is unchanged.
• What the anchor certificate now is. Its enforced minimum stays six seals. At nine validators that was a full 2f+1 quorum; at ten it is above f+1 but below the new quorum of seven, and the document says so instead of keeping the old sentence. Raising the minimum is a separate, coordinated change and is not claimed here.
• Dated history kept. Sentences about earlier heights and dates keep their numbers and gain "of that time"; sentences about the present were changed to ten.

The anchor interval changed on chain, and the document now says so wherever it described the anchor.

• Every 128th block, from block 17,225,968 (2026-09-05). Until that height the post-quantum anchor certificate was carried by every 32nd block; from it, by every 128th. The certificate itself is unchanged: Falcon-512 and SLH-DSA-SHA2-128s seals of at least six of the nine validators, bound under the block hash. The ten places that said "every 32nd block" now say "every 128th block (every 32nd block until block 17,225,968, on 2026-09-05)"; sentences dated to earlier events keep their dates.
• Why. Each hybrid certificate adds about 53 KB to its header (six SLH-DSA-SHA2-128s seals of 7,856 bytes each). Quartering the frequency divides that cost by four without touching the rule, the threshold or the schemes. The change was rehearsed on the public testnet first and is measured on mainnet by a published gate before this text was allowed to change.

Five places still said that consensus signatures are classical. They stopped being true in stages, and the document now says which stage is which.

• Consensus signatures: classical per block, post-quantum by layers. Per-block finality still rests on classical secp256k1 QBFT signatures. Since block 13,014,000 every anchor block also carries a post-quantum certificate of validator seals under its block hash (hybrid Falcon-512 and SLH-DSA-SHA2-128s since 2026-09-04). Since 2026-09-01 every QBFT message also carries a post-quantum seal of its author, and from blocks 17,250,000, 17,400,000, 17,550,000 and 17,700,000 (commit, proposal, round change, prepare; armed on all nine validators on 2026-09-05) a message without a valid seal is refused. The callout that said "Consensus signatures are classical", the figure caption, the diagram label and two sentences in the MEV chapter were rewritten to say this with dates.
• What did not change. The application-layer post-quantum verifiers, the anchor certificate and the whitepaper's other measurements; the correction of 2026-09-04 ("Consensus is classical" in the live note) had missed these five places, found by reading the published page for the word "classical".

Two statements the document still made had stopped being true, and both were found by reading the published page as an outsider would.

• Consensus is no longer described as classical. Since block 14,961,456 (2026-08-21) every 32nd block requires a certificate of at least six of the nine validators' Falcon-512 seals under the block hash, and since 2026-09-04 that certificate is hybrid: Falcon-512 and SLH-DSA-SHA2-128s seals, two independent mathematics in one certificate. The live note, the structured-data description and the audit list now say so; every block in between is still sealed with secp256k1 ECDSA under QBFT, and the document says that too.
• The 273,000 TPS figure is withdrawn everywhere it appeared, not merely labelled a ceiling. The site's about page had withdrawn it on 2026-08-19 because its stated derivation does not reach that number; the document kept calling it a design ceiling in five places. It is now withdrawn in all five, kept only where the block-space arithmetic can be checked.

Chapter 9 gained a section. The roadmap already said what runs and what is gated; the new section says in what order the remaining engineering work is taken, and why that order is what it is.

• Added Section 9.3, "Engineering direction: distinct before fast". It publishes the single criterion that orders the engineering programme: work that makes AERE distinct outranks work that makes AERE faster, because the second kind can be built by anyone with money and engineers and the first kind cannot. The reasoning is written out rather than asserted, so a reader can argue with it and can check later whether it was followed.
• Named the three pieces of work ordered first. Binding the post-quantum seal quorum into the block header commitment, the move from an L1 EVM to an L1 execution kernel with consensus and the state model declared immovable in advance, and a cryptographic abstraction layer that puts an interface between the protocol and any single algorithm.
• Published the rest of the queue in the same two piles, with no dates. An ordering is not a schedule, and the section says so in its own text. Nothing in it is presented as shipped; Section 9.2 remains the account of what exists.
• Restated the scope line rather than softening it. AERE mainnet consensus signs classical secp256k1 ECDSA. Post-quantum verification is available as on-chain precompiles and application-layer verifiers, not as the consensus mechanism. The new section repeats that in the one place where a reader might otherwise infer the opposite.
• Renumbered "Risks and limitations" from 9.3 to 9.4 and updated the single cross-reference in Chapter 3 that pointed at it, so no reference in the document points at a section number that no longer means what it did.
• Fixed which entry the auto-filled hash row decorates. The three cells that fetch the current published hashes were attached to the 2.1.1 entry, so a historical entry displayed today's values. They now sit on the current entry, and 2.1.1 states plainly that its own hashes are not recorded on this page rather than borrowing someone else's.

A sweep of factual corrections after a measured audit of the document against the live chain. Every item below was re-read from a public node before it was written, and the corrections run in both directions.

• Corrected both hard-fork activation heights. The document gave Pectra at block 2,075,363 and Fusaka at 2,106,606. Both forks are gated by timestamp, so the height must be read off the chain, and both published figures were too high, by 22 and 9 blocks. The measured heights are 2,075,341 and 2,106,597, re-derived twice over: 2,075,341 is the first block carrying a requestsHash header field and also the first whose timestamp reaches pragueTime, and 2,106,597 is the first whose timestamp reaches osakaTime.
• Withdrew "every Ownable contract is Foundation-owned". Of the 191 addresses in the canonical registry, 71 answer owner(); 57 return the Foundation account and 14 return an operational deployment account awaiting transfer. The word "every" was false and the count is now published in its place.
• Withdrew "the route owner cannot forge a verification". Each concrete verifier is immutable, but the route owner chooses which contract a selector resolves to, and the routes in use are not frozen, so the guarantee holds against the verifier a route already points at rather than against the owner of the route.
• Corrections that run in our favour, stated as plainly as the ones that do not. The canonical RISC Zero route is live rather than awaiting a signature; the over-18 program is registered on chain with a non-zero authorized root rather than pending; the Governor and Timelock are deployed, with the 48-hour minimum delay reading back from the chain, so what is missing is the ownership transfer and not the code.
• Deprecated addresses now travel with their replacements. The passkey factory, the intent pair, the storage-proof verifier, the aggregator and the Ethereum light client were each cited as current while our own registry marks them superseded. Each now carries what is wrong with it and the live replacement.
• Published the supply position instead of only the allocation. The six genesis wallets hold 2,239,999,990.70 AERE against the 2,800,000,000 cap, and the difference is accounted for rather than left as a gap a reader discovers by adding up the table.
• The same re-stamp failure as last time, caught and closed again. The corrections of 2026-08-01 were applied to the page without re-running the version block, so for a period the published verification command again did not reproduce the published hash. It has been re-stamped and both reader commands were replayed against the exact bytes on disk before this entry was written.

A factual correction, and a repair to the verification scheme itself, recorded together with the failure that prompted it.

• Corrected the sub-second transition height. The document said the transition to sub-second blocks activated at block 2,138,451. The measured height is 2,137,652: the mean block interval over the 200 blocks before it is 1.100 s and over the 200 blocks after it is 0.575 s, which anyone can recompute from public block bodies. All five occurrences were corrected.
• The failure, stated plainly. That correction was applied to the page on 2026-07-20 after the version block had been generated, and the re-stamp was missed. From then until this version was published, the published verification command did not reproduce the published hash, so a reader who followed our own instructions was in effect told the page had been tampered with. It had not been; it had been corrected without being re-stamped. The distinction matters and the process now enforces it.
• Added the content hash as the primary verification: it covers a delimited region holding the measured figures, the table of contents and the nine chapters, so an edit to the surrounding page cannot invalidate it, while any edit to the claims still does. The exact-bytes document hash remains published alongside it.
• Publishing now refuses a mismatched hash. The publish pipeline replays both reader commands over the exact bytes about to be shipped and refuses to publish unless each reproduces, so this class of failure can no longer reach the site.
• Rewrote the block-interval note so it stays true in degraded periods: the measured mean is published against the 500 ms target even when an outage pushes it well above the target, and the note now says exactly that instead of assuming the gap is small.

First version published under provable versioning. The document gained machinery rather than argument: its chain-derived figures stopped being typed by hand and started being generated.

• Added a version block carrying the semantic version, the date content last changed, both hashes, and the block height the measured figures were read at.
• Added a Measured on chain panel whose values are generated from a read-only RPC at a single pinned block height, so the figure set is internally consistent rather than assembled from readings taken minutes apart.
• Precompile liveness is now proved by measurement instead of asserted. Presence is established by gas differential against a control address holding no code. This proves the five mainnet precompiles are live and independently proves 0x0AE6 and 0x0AE7 are not on mainnet, matching their testnet-only status.
• Burn rate and burn cap are now read from the live splitter contract rather than quoted from a design document, and are cross-checked against the burn vault balance.
• Stated plainly, from measurement, that AERE is not deflationary today: lifetime burn is a rounding error against the 2.8 billion supply because validator coinbase revenue is effectively zero.
• Corrected the stated scale of the burn. While building the generator, the share of supply burned was computed in parts per billion and labelled as a percentage, which overstated it by a factor of ten million. The correct figures are published: 0.049 parts per billion of supply, which is 0.0000000049 percent. The error was caught before publication and is recorded here rather than quietly fixed, because a correction nobody can see is not a correction.
• Published the measured block interval next to the configured 500 ms target rather than in place of it. The long-run measured mean runs a few percent above the target, and the document now says so instead of quoting the target as though it were an observation.
• Labelled the 273,000 TPS figure as an architectural ceiling wherever it is generated, never as a measured rate.
• Restated that consensus is classical secp256k1 ECDSA QBFT, and that post-quantum cryptography on this chain is at the account and application layer.

The version 2 whitepaper. Date and version taken from the status line the document carried in its own cover metadata, which is self-reported and was not independently recorded at the time.

• What specifically changed between version 1 and version 2 is unknown. No changelog was kept and the file was not under version control, so any list here would be reconstruction presented as record.
• An archived copy of the version 1 document is retained at whitepaper-v1-archive.html.
• No hash is published for this entry. None was recorded at the time, and the file has been edited since.

An earlier revision, retained at whitepaper-v1-archive.html.

• Publication date unknown. The archived file's modification timestamp records when it was last touched on disk, not when it was published, so it is not quoted here as a publication date.
• Revision history within version 1 is unknown.