Every AERE rule change, by block number. Standard Ethereum forks are on Chain parameters; this page is the AERE-specific ones.
The list
| Block | Change |
|---|---|
| 2,137,652 | Block period drops from 1.050 to 0.544 seconds, measured on timestamps. See the note on this height in Chain parameters. |
| 9,182,379 | The EIP-2935 history contract receives its code (standard deployment transaction, nonce 0 of the EIP's deployer). No per-block system call yet: see the window below. |
| 9,189,161 | The AERE EVM milestone: five post-quantum precompiles and EIP-2935 historical block hashes become active. |
| 10,141,734 | Base fee floor: the EIP-1559 base fee cannot fall below 1 Gwei. |
| 13,014,000 | Post-quantum anchor rules armed, minimum seals 0 (warm-up). |
| 13,034,000 | Anchor minimum 3 of 9 valid Falcon-512 seals, f+1. |
| 14,050,000 | Nothing changed. See the correction below. |
| 14,961,456 | Anchor minimum 6 of 9, as many as the 2f+1 quorum; the seals prove those validators signed the block, not that it was decided (AIP-22 erratum, 2026-10-01). |
| 17,047,600 | Anchor certificate format v2: hybrid Falcon-512 and SLH-DSA-SHA2-128s. |
| 17,225,968 | Anchor interval moves from 32 to 128, on a grid offset from that height. |
| 17,250,000 | QBFT commit messages require a post-quantum seal. |
| 17,400,000 | QBFT proposal messages require a post-quantum seal. |
| 17,550,000 | QBFT round-change messages require a post-quantum seal. |
| 17,700,000 | QBFT prepare messages require a post-quantum seal. |
| 18,083,404 | The validator set grows from nine to ten; the tenth validator runs the second, Nethermind-derived client. |
| 18,131,633 | The second client requires a post-quantum seal on QBFT commit messages; from this block every validator refuses a commit without one. 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. The four rows from 17,250,000 to 17,700,000 were set on the nine validators of the AERE client (Besu-derived), the whole set at the time. (Row added 2026-10-09.) |
| 19,900,000 | Native post-quantum transactions: type 0x50, authorized by an ML-DSA signature (AIP-20). |
| 20,715,632 | Anchor minimum 7 of 10 per scheme, as many as the 2f+1 quorum of the ten validators (AIP-22 stage 1). |
| 20,746,736 | Falcon-512 certificate at every 32nd block again; SLH-DSA-SHA2-128s seals at every 128th (AIP-22 stage 2). |
| 20,836,228 | Validators named by post-quantum ids in the header and in qbft_getValidatorsByBlockNumber (AIP-22 stage 3). |
Every row above is below the chain head as of 2026-10-02. Compare against the current height rather than trusting this table to be fresh.
The EIP-2935 window: blocks 9,182,380 to 9,189,160
EIP-2935 keeps the last 8,191 block hashes in a ring buffer inside a system contract at 0x0000F90827F1C53a10cb7A02335B175320002935. On AERE that contract received its code in block 9,182,379 (2026-07-12 00:39:47 UTC), but the AERE client performs the per-block system call that fills the ring only from block 9,189,161 (01:37:52 UTC), the EVM milestone above. For the 6,781 blocks in between, 9,182,380 to 9,189,160, the contract existed and nothing was written into it.
Consequence for anyone syncing the chain with their own client: an implementation that performs the EIP-2935 system call as soon as the contract has code, which is how the EIP reads, writes the ring during that window and computes a different state root for every block in it. It will reject block 9,182,380 as a state-root mismatch, with no error that names the cause. The AERE client, and the published node package, gate the system call on the milestone instead. A client that mirrors that activation syncs through the window.
Verifiable on any archive node, in two reads: eth_getStorageAt on the contract at slot 9,182,380 mod 8191 as of block 9,182,381 returns zero (nothing written), and at slot 9,189,161 mod 8191 as of block 9,189,162 returns the hash of block 9,189,161 (the ring is live). Measured on 2026-10-02; until then this page described the milestone but not the window.
The correction at 14,050,000
Until 2026-08-19, this project's website, whitepaper and press releases in seven languages stated that from block 14,050,000 no block finalises without a six-of-nine post-quantum quorum.
That was false. The property armed at that height is a per-block rule which the shipped code retires when the anchor rules activate. Reading the source and the deployed bytecode, and then the chain itself, settles it: between anchors, blocks carry zero Falcon seals, and a per-block rule would have rejected all of them.
Nothing changed at 14,050,000. The correction was published the same day, dated, in every language the original claim appeared in. The row is kept in this table rather than deleted, because a fork history that quietly loses a retracted entry is not a history.
How AERE rules activate
By block number, through per-node system properties, not through genesis. The consequences of that choice, including the one that bites, are on Enforcement heights.