AERE Network · Whitepaper
Version history
Every version of the whitepaper, the date its content changed, the SHA-256 hash you can recompute yourself, and what changed. Back to the whitepaper.
The rule this list follows. The version changes only when the content changes. It is not a date stamp and is never incremented on a schedule. A number that moves every day whether or not anything was written tells you nothing; a number that moves only on substance, and that you can check by hashing the document, tells you everything.
Refreshing a measured on-chain figure does not create a new version. It changes the content and document hashes, because the bytes changed, and it changes the block height the figures were read at. It leaves the version number alone, because the argument did not change. That is why three hashes are published per entry.
The three hashes
| Hash | What it answers | When it moves |
| Content | Are the whitepaper's claims the ones AERE published? | When anything inside the delimited content region changes: the measured figures, the table of contents or the chapters. Edits to the surrounding page cannot move it. This is the hash to check first. |
| Document | Am I reading the exact bytes AERE published? | Whenever anything changes anywhere in the page, including a refreshed on-chain figure or a cosmetic edit outside the content. |
| Editorial | Has the argument, structure or claims changed? | Only on a written change. Generated figures are blanked before hashing, so chain movement cannot move it. This is the hash tied to the version number. |
Recompute the content hash of the live page. The command extracts the delimited content region and hashes exactly that:
curl -sL https://aere.network/whitepaper | sed -n '/<!--WP-CONTENT-START-->/,/<!--WP-CONTENT-END-->/p' | tr -d '\r' | sha256sum
Or recompute the stricter document hash. This command removes the version block first, so the hash cannot depend on itself:
curl -sL https://aere.network/whitepaper | sed '/<!--WP-VERSION-BLOCK-START-->/,/<!--WP-VERSION-BLOCK-END-->/d' | tr -d '\r' | sha256sum
Machine-readable figures, each with its provenance and the block height it was read at: whitepaper-figures.json.
History before 2026-07-20 was not tracked, and this page does not pretend otherwise. Hash-based versioning began on 2026-07-20. Before that date the whitepaper was not under version control in this repository: public/whitepaper.html was an untracked file, so no commit history exists to reconstruct from. The entries below dated earlier than 2026-07-20 are recorded from evidence that survives, namely the version and status strings the document carried in its own cover metadata and the modification dates of archived files. They carry no hash, because no hash was recorded at the time and computing one now from a file that has since been edited would prove nothing. Those entries are marked Not hash-tracked. An honest gap is worth more than a fabricated record.
Entries
2.1.2
2026-08-02
Hash-tracked
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.
Content hashb4fafd73f6738c87a1fa0fd87c4d689d31af27b7fcde7759a55381116fbffdc4
Document hashf122d28ba92f4b6e1623fc48aa431a05b100c382e0f7645f498562c4e2f92f3f
Editorial hash31b9cfbaf2263818492f58dd28a1b6e6ff65e8ba97b67254776d6edc5a7692a9
Figures measured at block11,747,884
2.1.1
2026-07-31
Hash-tracked
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.
Content hashsee /whitepaper-figures.json
Document hashsee /whitepaper-figures.json
Editorial hash733951f0a866b25a72563af2e82f43fc7ebe50901a4cbb9d7aa90fbf4b55254a
Figures measured at blocksee /whitepaper-figures.json
2.1.0
2026-07-20
Hash-tracked
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.
Document hash61bc05730cf86266e0768e801171845ea5309cc2ad260d791be8be14fc96f1a9 (as last refreshed under 2.1.0, at block 10,594,472; superseded)
Editorial hash7f837b5e92c73c892fbfd28627e98fe5ae32137e157785c86924d416901df03b
2.0
2026-07-11
Not hash-tracked
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.
1.x
date unknown
Not hash-tracked
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.
How an entry gets added
A new entry is added when, and only when, the editorial hash changes. That happens when someone edits the writing, the structure or a claim. It does not happen when a measured figure is refreshed from the chain, and it does not happen because a day passed.
The figures are regenerated on a schedule and checked for drift against the live chain continuously. That is what keeps the document current. The version number is deliberately not part of that loop, because a version that tracks the clock rather than the content is a signal with no information in it.