aere-docs/AERE-EIP-COMPATIBILITY-MATRIX.md

Aere Network: Ethereum EIP Compatibility Matrix

Chain: Aere Network mainnet, chain ID 2800 (0xaf0). Execution client: Hyperledger Besu 26.4.0 with QBFT consensus (classical secp256k1 ECDSA, N=7 validators, f=2), approximately 0.5 second blocks. This document is a developer reference: it states, EIP by EIP, where Aere's EVM matches Ethereum mainnet and where it deliberately differs.

Aere tracks Ethereum's hard forks so that its EVM surface matches mainnet at the same addresses and opcodes: London and Shanghai apply from genesis, Cancun and Prague (Pectra) activated together at block 2,075,341, and Osaka (Fusaka) at block 2,106,597. A small set of deviations is intentional and disclosed here, because Aere is a QBFT chain with no separate beacon (consensus) layer and no blob data availability market. Anything not matching Ethereum is a design decision, not an oversight, and each is called out in the matrix and again in the deviations recap at the end.

How to read this

• Status is one of: Supported (matches Ethereum), Partial (present but materially limited on Aere), Not implemented (absent), No-op (present in the ruleset but neutralized, returns a defined zero/empty value under QBFT).
• Every row is intended to be literally true. Cells that could not be verified against the repository's genesis or fork configuration carry an explicit [VERIFY: ...] note. A [VERIFY] note is a permanent, deliberate disclosure that the named fact is NOT MEASURED. It is published as it stands, it does not block publication, and it is closed only by a measurement, never by deletion. The full rule is VERIFY-POLICY.md at the root of this repository.
• A figure taken from a spec or a config file is a price. A figure produced by querying the running chain is a measurement. Rows marked (measured 2026-07-19) were produced by read-only JSON-RPC against https://rpc.aere.network, and the method is stated in "How the measured gas figures were produced" at the end of this document. Nothing in this file was written by sending a transaction.

Second validation pass, 2026-07-19 (independent re-measurement)

This document was re-validated end to end against the running chain by an independent pass whose brief was to assume nothing in it was true. Every activation height was re-derived by binary search rather than read from this file; every price claim was re-measured with a freshly built and freshly calibrated probe; behavioural claims were driven with real eth_calls and compared byte for byte.

Result: the matrix held up. No gas figure, activation height, status, or economic claim in it was found to be wrong. Three open flags were closed, one was narrowed, and three points of imprecision were corrected:

• blobSchedule attribution (corrected). The EIP-7691 row said the raised schedule was set "in config". The values are right (live eth_config: target 6, max 9), but blobSchedule is absent from all four genesis files -- the schedule comes from Besu's built-in default for the active fork, not from Aere's genesis.
• Blob base-fee update fraction (corrected). The EIP-7516 row cited fake_exponential(1, 0, 3338477). 3,338,477 is the Cancun constant; the live chain reports 5,007,716, the Prague (EIP-7691) value. The 1 wei conclusion is unaffected.
• SHAKE256 figure (disambiguated). "A 160-byte input" was ambiguous between total input and data length; the row now states the fitted gas model and the packed encoding instead of a single point.

It also propagated a correction outward. AERE-PROTOCOL-SPECIFICATION.md was still carrying the superseded Pectra and Osaka heights (2,075,363 and 2,106,606) in nine places, including its normative activation predicates and its Appendix A fork table. Those were wrong by 22 and 9 blocks and have been corrected to the measured 2,075,341 and 2,106,597. The two documents now agree.

Measurement provenance for the 2026-07-19 pass

The gas figures, the two fork-boundary heights, and the blob base fee in this document were re-derived from the live chain on 2026-07-19 while diagnosing the Nethermind second client (see aerenew/cross-client-determinism/). That pass corrected four values that had been carried from specs rather than measured: the Pectra and Osaka activation heights, the P-256 precompile gas, and the blob base fee. Each correction is called out inline.

• "The fork" or "the AerePQC hard fork" refers to Aere's client-only Besu futureEips milestone (futureEipsTime = 1783820272), which activated at block 9,189,161 (2026-07-12) and bundled the native post-quantum precompiles, the EIP-2935 write path, and EIP-7939. No re-genesis was involved.

Fork timeline on chain 2800

Ethereum fork	Aere activation	Notes
London, Shanghai	Genesis (block 0)	londonBlock: 0, shanghaiTime: 0 in genesis config
Cancun + Prague (Pectra)	Block 2,075,341 (measured 2026-07-19)	cancunTime == pragueTime == 1780189051; Cancun and Prague share one activation instant on Aere
Osaka (Fusaka)	Block 2,106,597 (measured 2026-07-19)	osakaTime == 1780220351
AerePQC milestone (post-Osaka)	Block 9,189,161	Besu futureEipsTime == 1783820272; PQC precompiles + EIP-2935 write path + EIP-7939

Correction (2026-07-19). This table previously read 2,075,363 and 2,106,606. Both were wrong. The heights are gated by timestamp, not by block number, so they have to be read off the chain, and when they were, two independent signals agreed:

Block	Timestamp	requestsHash present
2,075,340	1780189050	no
2,075,341	1780189051 (pragueTime)	yes (sha256(""))
2,106,596	1780220350	yes
2,106,597	1780220351 (osakaTime)	yes

Block 2,075,341 is the first block whose timestamp reaches pragueTime, and it is also the first block to carry a requestsHash at all, which is an independent confirmation of the Pectra boundary. Block 2,106,597 is the first block whose timestamp reaches osakaTime. Both agree with the checkpoints the cross-client harness derived by binary search (aerenew/cross-client-determinism/). Block heights on this chain are not a stable API: they are an observation about when a timestamp was crossed, and they are recorded here only because they are useful for locating the boundary in an explorer.

AerePQC height 9,189,161: now re-derived (2026-07-19, second pass). This was previously flagged as carried from configuration rather than measured. It has since been confirmed by the same timestamp binary search used for the other two boundaries: block 9,189,160 has timestamp 1783820271 and block 9,189,161 has timestamp 1783820272, exactly futureEipsTime, making it the first block at or past the activation instant. Note the scope of that confirmation: it establishes the height at which the configured timestamp is first crossed, which is the same standard applied to Pectra and Osaka. It is not a behavioural probe of the precompiles at that height -- the public RPC prunes historical state, so eth_call at 9,189,161 still cannot be used to watch the band switch on. The precompiles are separately confirmed live at head by direct measurement (see the Aere additions table).

---

The Matrix

London and Shanghai era (active from genesis)

EIP	Name	Status	Difference from Ethereum
1559	Fee market (base fee, type-2 txs)	Partial	Fee-market mechanics present, plus a 1 Gwei base-fee floor live since block 10,141,734 (raised the real minimum from 7 wei). Floor boundary re-confirmed by direct measurement 2026-07-19: block 10,141,733 has baseFeePerGas = 7 wei and block 10,141,734 has baseFeePerGas = 0x3b9aca00 = 1,000,000,000 wei, and it holds at 1 Gwei at every later block sampled through head. eth_feeHistory at head likewise reports baseFeePerGas of 0x3b9aca00. Aere adds no consensus base-fee burn narrative: its "burn" is a separate validator-reward cut (see deviations). [VERIFY (narrowed 2026-07-19): base-fee disposal. Measurement rules out crediting to the coinbase (zero coinbase delta across a fee-paying block); burned-versus-routed-elsewhere is still open, see open flag 2.]
3198	BASEFEE opcode	Supported	Returns the current base fee, which is floored at 1 Gwei (see EIP-1559).
3529	Reduction in refunds	Supported	Matches Ethereum.
3541	Reject contract code starting with 0xEF	Supported	Matches Ethereum. Reserves the 0xEF lead byte (the EOF prefix).
3651	Warm COINBASE	Supported	Matches Ethereum.
3855	PUSH0 instruction	Supported	Matches Ethereum.
3860	Limit and meter initcode	Supported	Matches Ethereum.
4895	Beacon chain push withdrawals as operations	No-op	Withdrawal-operation ruleset present, but Aere has no beacon layer to originate withdrawals, so none are produced.

Istanbul-era precompiles and pricing (active from genesis)

Aere starts at London, so every earlier fork is folded into genesis and these are all live. They are listed explicitly because they are priced rules, not feature flags: a client that carries the opcode but the wrong price produces a different gasUsed and forks. That is not hypothetical. Both EIP-1108 and EIP-152 were missing from the Nethermind second client's chainspec on 2026-07-19, which made it charge pre-Istanbul alt_bn128 prices and halt (see aerenew/cross-client-determinism/LIVE-BESU-VS-NETHERMIND-2026-07-19.md).

EIP	Name	Status	Difference from Ethereum
196	alt_bn128 add and mul (0x06, 0x07)	Supported	Matches Ethereum. Verified live: ecAdd and ecMul both return 64 bytes for the standard generator inputs.
197	alt_bn128 pairing check (0x08)	Supported	Matches Ethereum. Verified live for k = 0, 1, 2 and 4 pairs.
1108	Reduce alt_bn128 precompile gas costs	Supported	Matches Ethereum. Post-1108 prices confirmed by measurement, not by config. Measured 2026-07-19 against the live chain: ecAdd 150, ecMul 6,000, ecPairing 45,000 + 34,000 per pair. The pre-1108 schedule (500 / 40,000 / 100,000 + 80,000 per pair) is ruled out by a margin of 34,000 gas on ecMul alone and 239,000 gas on a 4-pair ecPairing, far outside any measurement noise. This is the pricing an on-chain BN254 Groth16 verifier depends on; a client on the pre-1108 schedule starves such a verification of gas.
152	Blake2b F compression function (0x09)	Supported	Matches Ethereum. Present and fail-closed: probed with a malformed (zero-length) input, it consumes all forwarded gas and reports failure, which is the behavior EIP-152 specifies for an input that is not exactly 213 bytes. Per-round price now measured on a well-formed 213-byte input (measured 2026-07-19): rounds = 12 costs exactly 12 gas and rounds = 100 costs exactly 100 gas, that is, cost == rounds, the EIP-152 schedule.
198	Big integer modular exponentiation (0x05)	Supported	Matches Ethereum at Osaka pricing. Closed by measurement 2026-07-19, and the answer distinguishes the repricing generation. A minimal 1-byte base/exponent/modulus call (b=8, e=9, m=10) costs 500 gas. EIP-2565's floor is 200 and EIP-7883's is 500, so the measurement rules out EIP-2565-only pricing and confirms EIP-7883 (Osaka) modexp repricing is live on chain 2800. This was open flag 5; a client still on the EIP-2565 schedule would undercharge modexp by 300 gas at the floor and diverge.

Cancun (block 2,075,341)

EIP	Name	Status	Difference from Ethereum
1153	Transient storage (TLOAD / TSTORE)	Supported	Matches Ethereum. Confirmed live by execution (measured 2026-07-19): a state-override eth_call running TSTORE(0, 0x42); TLOAD(0) returns 0x..42.
4844	Shard blob transactions	Partial	Type-3 blob transactions are present in the EVM and the Cancun blob header fields are carried (blobGasUsed and excessBlobGas are present and both read 0x0 on live blocks), but Aere runs no blob data-availability market, so no blob is ever included and the blob fee never leaves its floor. See EIP-7516.
4788	Beacon block root in the EVM	No-op	The beacon-root ring buffer returns 0x0: a QBFT chain has no separate beacon/consensus layer to expose a root from. Live blocks carry parentBeaconBlockRoot = 0x00..00.
5656	MCOPY instruction	Supported	Matches Ethereum. Confirmed live by execution (measured 2026-07-19): a state-override eth_call using MCOPY to copy a word from offset 0 to offset 32 returns the copied value.
6780	SELFDESTRUCT only in same transaction	Supported	Matches Ethereum.
7516	BLOBBASEFEE opcode	Supported (pinned at the floor)	Corrected 2026-07-19: this previously read "No-op, returns 0". That was wrong. The opcode is live and returns 1 wei, the EIP-4844 MIN_BASE_FEE_PER_BLOB_GAS, not 0. Live blocks carry excessBlobGas = 0x0, and blob_base_fee = fake_exponential(1, 0, 5007716) = 1. Correction (2026-07-19): this previously cited an update fraction of 3,338,477. That is the Cancun BLOB_BASE_FEE_UPDATE_FRACTION; the live chain's eth_config reports baseFeeUpdateFraction = 5007716, the Prague (EIP-7691) value. The result is 1 wei either way because excessBlobGas is 0 and fake_exponential(1, 0, k) = 1 for every k, so the conclusion was right, but the constant quoted for the active fork was wrong. Confirmed by eth_feeHistory on chain 2800, which reports baseFeePerBlobGas: ["0x1", "0x1"]. Because Aere runs no blob market, excessBlobGas never rises, so the value is permanently pinned at the floor of 1 rather than being absent or zero. See the caveat on probing this opcode in "How the measured gas figures were produced".

Prague / Pectra (block 2,075,341)

EIP	Name	Status	Difference from Ethereum
2537	BLS12-381 curve precompiles	Supported	Matches Ethereum. Prices confirmed by measurement, not by config (measured 2026-07-19): BLS12_G1ADD (0x0b) 375, BLS12_G2ADD (0x0d) 600, BLS12_MAP_FP_TO_G1 (0x10) 5,500, BLS12_MAP_FP2_TO_G2 (0x11) 23,800 -- each exactly the EIP-2537 schedule. All seven BLS addresses 0x0b..0x11 are listed in the live eth_config precompile set.
2935	Save historical block hashes in state	Supported	Standard 8191-block history-storage ring buffer at 0x0000F90827F1C53a10cb7A02335B175320002935, written by consensus. Nominally listed at Pectra but the system contract was not populated on mainnet until the AerePQC fork (block 9,189,161) added the write path; from that block eth_getCode returns the canonical runtime and the 8191-block window is live.
6110	Supply validator deposits on chain	Partial	The deposit-request ruleset is part of the Pectra parity Aere tracks, but Aere has no beacon layer to consume deposits, so a deposit does not create or fund a QBFT validator (the validator set is QBFT-managed). CLOSED by measurement 2026-08-01 (head block 11,810,041, https://rpc.aere.network): eth_getCode returns 0 bytes at the EIP-6110 deposit contract 0x00000961Ef480Eb55e80D19ad83579A64c007002, at the EIP-7251 consolidation contract 0x0000BBdDc7CE488642fb579F8B00f3a590007251, and at 0x000F3df6D732807Ef1319fB7B8bB8522d0Beac02. The live header carries requestsHash = 0xe3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855, which is the SHA-256 of the empty string, and parentBeaconBlockRoot = all zeros. So: none of the request system contracts is populated, and the header requests list is empty. That is exactly what "ruleset present, no beacon layer" predicts, and it is now measured rather than flagged. (Contrast EIP-2935 in the row above, which is populated, at 83 bytes.)
7002	Execution-layer triggerable withdrawals/exits	Partial	Withdrawal-request ruleset present, but no beacon layer consumes exits, so it does not affect the QBFT validator set. CLOSED by measurement 2026-08-01 (head block 11,810,041, https://rpc.aere.network): eth_getCode returns 0 bytes at the EIP-6110 deposit contract 0x00000961Ef480Eb55e80D19ad83579A64c007002, at the EIP-7251 consolidation contract 0x0000BBdDc7CE488642fb579F8B00f3a590007251, and at 0x000F3df6D732807Ef1319fB7B8bB8522d0Beac02. The live header carries requestsHash = 0xe3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855, which is the SHA-256 of the empty string, and parentBeaconBlockRoot = all zeros. So: none of the request system contracts is populated, and the header requests list is empty. That is exactly what "ruleset present, no beacon layer" predicts, and it is now measured rather than flagged. (Contrast EIP-2935 in the row above, which is populated, at 83 bytes.)
7251	Increase MAX_EFFECTIVE_BALANCE (consolidations)	Partial	Consolidation-request ruleset present, but no beacon layer to act on it under QBFT. CLOSED by measurement 2026-08-01 (head block 11,810,041, https://rpc.aere.network): eth_getCode returns 0 bytes at the EIP-6110 deposit contract 0x00000961Ef480Eb55e80D19ad83579A64c007002, at the EIP-7251 consolidation contract 0x0000BBdDc7CE488642fb579F8B00f3a590007251, and at 0x000F3df6D732807Ef1319fB7B8bB8522d0Beac02. The live header carries requestsHash = 0xe3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855, which is the SHA-256 of the empty string, and parentBeaconBlockRoot = all zeros. So: none of the request system contracts is populated, and the header requests list is empty. That is exactly what "ruleset present, no beacon layer" predicts, and it is now measured rather than flagged. (Contrast EIP-2935 in the row above, which is populated, at 83 bytes.)
7549	Move committee index outside signature	Not implemented	Beacon consensus-layer change only, with no execution-layer/EVM surface. It has no applicability under QBFT.
7623	Increase calldata cost	Supported	Matches Ethereum (calldata floor-cost accounting).
7685	General purpose execution layer requests	Partial	The requests framework (the umbrella for 6110/7002/7251) exists in the ruleset, but Aere has no beacon layer to consume the requests. CLOSED by measurement 2026-08-01 (head block 11,810,041, https://rpc.aere.network): eth_getCode returns 0 bytes at the EIP-6110 deposit contract 0x00000961Ef480Eb55e80D19ad83579A64c007002, at the EIP-7251 consolidation contract 0x0000BBdDc7CE488642fb579F8B00f3a590007251, and at 0x000F3df6D732807Ef1319fB7B8bB8522d0Beac02. The live header carries requestsHash = 0xe3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855, which is the SHA-256 of the empty string, and parentBeaconBlockRoot = all zeros. So: none of the request system contracts is populated, and the header requests list is empty. That is exactly what "ruleset present, no beacon layer" predicts, and it is now measured rather than flagged. (Contrast EIP-2935 in the row above, which is populated, at 83 bytes.)
7702	Set EOA account code (delegation)	Supported	Matches Ethereum. This is the EOA-delegation primitive Aere carries (and the reason EIP-3074 is not needed). Delegation resolution confirmed live (measured 2026-07-19): an account whose code is set to the designator (0xef0100 followed by a 20-byte target address) executes the target's code when called, while the same account given a non-designator 0xEF-prefixed blob (0xef9900 followed by the same address) is rejected with Invalid opcode: 0xef. So the 0xef0100 prefix is honored as a delegation indicator and no other 0xEF form is executable, which is exactly the EIP-7702 plus EIP-3541 combination.
7691	Blob throughput increase	Partial	The active blob schedule is target 6, max 9, baseFeeUpdateFraction 5,007,716 -- the EIP-7691 raised schedule -- confirmed by reading eth_config on the live chain (measured 2026-07-19). With no blob data-availability market the increase has no practical effect. Correction (2026-07-19): this row previously said the schedule was set "in config". That was wrong as to source. blobSchedule is absent from all four genesis files (aere-genesis-current.json, aere-genesis-pectra.json, aere-genesis-fusaka.json, aerenew/genesis.json); none of them declares one. The schedule the chain actually runs comes from Besu's built-in default for the active fork, not from Aere's genesis. The values are correct; the attribution was not. A reimplementer must therefore hardcode the EIP-7691 schedule rather than expect to read it out of Aere's genesis, and a client that defaults to the Cancun schedule (target 3, max 6, fraction 3,338,477) would carry a different blob-fee curve.

Fusaka / Osaka (block 2,106,597) and the post-Osaka milestone

EIP	Name	Status	Difference from Ethereum
7951	secp256r1 (P-256) signature verification at 0x100	Supported	Matches Ethereum's Osaka. Live and verified on chain 2800 (measured 2026-07-19). See the 0x100 row under "Aere additions" for the measured gas and semantics. Activated with the Osaka ruleset at osakaTime = 1780220351, block 2,106,597. This is the precompile Aere's passkey/WebAuthn accounts sit on, so it is load-bearing rather than decorative.
7825	Transaction gas limit cap (2^24 = 16,777,216)	Supported	Matches Ethereum; the per-transaction gas cap is enforced on chain 2800 (real transactions have executed under it). Note this is a per-transaction cap; the live block gas limit reads 0x1fffffffffffff (2^53 - 1).
7939	Count leading zeros (CLZ) opcode	Supported	Present. On Aere it activated at the post-Osaka AerePQC milestone (block 9,189,161), which the live EIP-2124 fork-id folds in. [VERIFY: activation height for 7939 specifically, confirmed against the live fork schedule.]
7594	PeerDAS (peer data availability sampling)	Not implemented	No active role under QBFT: Aere runs no blob data-availability market, so there is no data-availability sampling role to perform.
7805	FOCIL (fork-choice enforced inclusion lists)	Not implemented	No-op under QBFT: there is no fork-choice or proposer-inclusion layer to enforce inclusion lists against.
7692	EOF (EVM Object Format) mega-set	Not implemented	Not activated under the current ruleset; the 0xEF prefix stays reserved by EIP-3541 (legacy behavior). [VERIFY: confirm the AerePQC futureEips protocol spec (futureEipsTime = 1783820272, block 9,189,161) does NOT enable the EOF opcode set or EIP-3540/3670 container validation. Corroboration that EOF is off: the served genesis config and the Nethermind live-sync fork-id mirror both carry no EOF transition, and the engineering spec states EOF is not activated. The one residual risk is that this milestone rides Besu's futureEips key, which in stock Besu is EOF's staging ground, so the fork build's spec definition should be inspected to confirm EOF was not pulled in.]

Superseded

EIP	Name	Status	Difference from Ethereum
3074	AUTH / AUTHCALL (sponsored EOA actions)	Not implemented	Deliberately absent. It was superseded by EIP-7702, which Aere carries as its EOA-delegation primitive.

---

Aere additions beyond Ethereum

These are callable addresses that are not part of the base Ethereum mainnet precompile set. The post-quantum band 0x0AE1..0x0AE5 is genuinely Aere-specific and live on mainnet; 0x0AE6..0x0AE8 are not on mainnet; the secp256r1 precompile at 0x100 is a shared RIP that Ethereum is standardizing in Osaka (listed here because it sits outside the classic precompile set).

Address	Name	Status	Notes
0x0AE1	Falcon-512 signature verify	Live on mainnet	Activated at block 9,189,161 (AerePQC fork). Thin wrapper over Bouncy Castle 1.83; NIST KAT verified. Gas 40,000, measured on the live chain 2026-07-19 and matching the committed schedule Falcon512VerifyGas = 40_000.
0x0AE2	Falcon-1024 signature verify	Live on mainnet	Activated at block 9,189,161. NIST KAT verified. Gas 75,000 (measured), matching the committed FALCON1024_VERIFY_GAS = 75000.
0x0AE3	ML-DSA-44 signature verify (FIPS 204)	Live on mainnet	Activated at block 9,189,161. ACVP verified. Gas 55,000 (measured).
0x0AE4	SLH-DSA-SHA2-128s signature verify (FIPS 205)	Live on mainnet	Activated at block 9,189,161. ACVP verified. Gas 350,000 (measured).
0x0AE5	SHAKE256 (FIPS 202)	Live on mainnet	Activated at block 9,189,161. Variable cost by input and output length. Full gas model re-derived on the live chain across 10 input shapes (measured 2026-07-19), fitting with zero residual: gas = 60 + 12 * ( ceil(len(data)/32) + ceil(min(outLen, 65536)/32) ), where the packed input is outLen (32-byte big-endian word) followed by data. Three properties are load-bearing and all three are measured, not assumed: (1) the two word counts are rounded up separately, not combined -- outLen=33, data=33 costs 108 gas (4 words), where a combined ceil((33+33)/32) model predicts 3 words and 96 gas; (2) outLen saturates at MAX_OUTLEN = 65536 -- outLen=100000, data=32 costs 24,648, identical to what 65,536 would cost; (3) the outLen framing word is not itself charged as data. Clarification (2026-07-19): this row previously read "a 160-byte input returning 65,536 bytes measured 24,684 gas", which was ambiguous. 24,684 gas corresponds to 128 bytes of data (a 160-byte total input, of which the first 32 bytes are the outLen framing word). A call with 160 bytes of actual data costs 24,696. The figure was right under one reading of "input" and wrong under the other, so it is now stated as the model plus the encoding. This independently reconfirms the separate-rounding correction made to aerenew/eips/eip-draft-shake256-precompile.md.
0x0AE6	ML-KEM-768 encapsulation (FIPS 203)	Testnet only	Built and ACVP-verified (25/25) on an isolated QBFT testnet. NOT on mainnet 2800: re-confirmed 2026-07-20 by gas differential, a mainnet STATICCALL to 0x0AE6 charges 0 gas against a codeless control, versus 40,000/75,000/55,000/350,000/24,648 for the live 0x0AE1..0x0AE5. Decisive because gasRequirement is a flat 60,000 for every input, so an active 0x0AE6 would bill it even while returning empty. Note the empty return by itself proves nothing: 0x0AE5 is live and also returns empty for a short input. Founder- and audit-gated.
0x0AE7	Falcon HashToPoint (SHAKE256 sampler)	Testnet only	Built and KAT-verified (12/12) on isolated testnet. NOT on mainnet 2800, re-confirmed by the same measurement. Founder- and audit-gated.
0x0AE8	BabyBear/FRI STARK verify (skeleton)	Reference skeleton only	Non-working, fail-closed by construction (returns empty for every input). Not deployed on mainnet and explicitly must not be activated until the crypto core is ported. Scope caveat (2026-07-19 finding): the generic components confirmed so far verify BabyBear + FRI STARKs (Aere's OWN Plonky3 circuits), NOT SP1 6.1.0, which is Hypercube (KoalaBear multilinear); retargeting to SP1 6.1.0 is a separate ~22 to 32 person-week effort. See AERE-STARK-SP1-RECURSION-AIR-PORT-SPEC-SUMMARY.md.
0x100	P256Verify / secp256r1 (EIP-7951, formerly RIP-7212)	Live on mainnet	Native P-256 signature verification for passkeys/WebAuthn. Gas 6,900, measured on the live chain 2026-07-19. Corrected: this row previously read "about 3,450 gas". That was the original RIP-7212 price, which was doubled to 6,900 when the proposal was standardized into Ethereum's Osaka as EIP-7951. Active from the Osaka/Fusaka ruleset (osakaTime = 1780220351, block 2,106,597). Standards-aligned, not Aere-proprietary. Verified semantics: a valid signature returns a 32-byte 0x..01; an invalid one returns empty (not a zero word, which is how the 0x0AE1..0x0AE4 band fails), and the full 6,900 gas is charged either way. Signature malleability is not restricted: both the low-s and high-s forms of the same signature verify, matching the spec. Cross-client confirmed: the Nethermind second client returns byte-identical results and charges identical gas.

All post-quantum precompiles are signature/hash/KEM verifiers on the EVM path. None of them make Aere's consensus post-quantum: mainnet 2800 still seals blocks with classical secp256k1 QBFT.

Warm/cold note. The inherited Ethereum precompiles (0x01..0x0A) and the EIP-7951 verifier at 0x100 are pre-warmed under EIP-2929, so a call to them pays the 100 gas warm-access charge. The Aere-specific band at 0x0AE1..0x0AE5 is not in the pre-warmed set: a first call in a transaction pays the 2,600 gas cold-account charge on top of the verify price. Measured 2026-07-19. Budget for it when sizing a PQC-verifying transaction.

---

Deliberate deviations recap

The intentional differences from Ethereum, all a consequence of Aere being a QBFT chain with no beacon layer and no blob market:

1. Base fee floor plus a validator-reward burn, not a consensus base-fee burn. Aere applies a 1 Gwei EIP-1559 base-fee floor (live since block 10,141,734). Separately, Aere's "burn" is a cut of the validator coinbase block reward (37.5% under the current configuration, hard-capped at 50%), routed through the AereCoinbaseSplitterV2 splitter into immutable destinations. This must not be described as a base-fee burn.

   Burn parameters confirmed on chain 2026-07-19 by reading the deployed AereCoinbaseSplitterV2 at 0x8C1A48eFA57b66fEE743A00E3899c29ad3Fd27b4: burnBps() = 3750 (37.5%), MAX_BURN_BPS() = 5000 (the 50% ceiling), sinkBps() = 1500, MAX_SINK_BPS() = 3000, rebateBps() = 4750. Every figure matches the documented configuration exactly, and 3750 + 1500 + 4750 = 10000 closes.

   Two structural facts confirm the separation is real rather than editorial. First, the live block coinbase is a plain EOA with no code (eth_getCode on the block miner returns 0x), so nothing is deducted from the reward by consensus -- the split happens only when a forwarder sends the reward on to the splitter, which is application-layer wiring above consensus, exactly as described. Second, the base fee is separately confirmed not credited to that coinbase (open flag 2), so the two mechanisms do not touch. [MEASURE: AereCoinbaseSplitterV2.totalBurned() currently reads 0, while the older V1 splitter at 0xb4b0eCe9011613A5b84248a9B42a0f309E6F01Ec reads 137,352,594,046,167,719 wei burned. So V2 is deployed and correctly configured but has not yet received flow; the burn described here is live as a configuration and as a V1 flow, and the V2 path is not yet carrying volume. Confirm the forwarder's current target before describing V2 as the operative path.]

2. EIP-4844 blobs present, EIP-7516 BLOBBASEFEE pinned at 1 wei. Blob transactions exist in the EVM, but there is no blob data-availability market, so no blob is ever included, excessBlobGas never rises above 0, and the blob base fee sits permanently at the EIP-4844 floor of 1 wei. It is not 0 and the opcode is not neutralized. (Corrected 2026-07-19; this recap previously said 0.)

3. EIP-4788 parent beacon block root returns 0x0. A QBFT chain has no separate beacon/consensus layer to source a root from.

4. EIP-3074 not implemented, superseded by EIP-7702. EIP-7702 is the EOA-delegation primitive Aere carries.

5. PeerDAS (EIP-7594), FOCIL (EIP-7805), and EOF (EIP-7692) have no active role under QBFT. PeerDAS has no data-availability role (no blob market), FOCIL has no fork-choice/proposer-inclusion layer to enforce, and EOF is not activated under the current ruleset (0xEF stays reserved by EIP-3541).

6. Validator-lifecycle requests (EIP-6110/7002/7251/7685) have no beacon consumer. The requests ruleset is tracked for Pectra parity, but Aere's validator set is QBFT-managed, so deposits/withdrawals/consolidations do not drive it.

7. EIP-2935 became functionally live at the AerePQC fork (block 9,189,161), not at Pectra. The Pectra ruleset nominally listed it, but the history-storage contract was not populated on mainnet until the write path shipped in the AerePQC fork.

---

Closed by measurement on 2026-07-19

These were open [VERIFY] flags. They are now measurements, not prices.

1. Pectra/Fusaka block heights. Closed. Measured 2,075,341 and 2,106,597, by reading block timestamps either side of each activation instant and cross-checking against the first appearance of requestsHash. The previously published 2,075,363 and 2,106,606 were wrong and have been corrected throughout this document.
2. P256Verify gas. Closed, and the previous figure was wrong. Measured 6,900, not 3,450. The precompile is live, verifies correctly, fails closed with an empty return, and does not restrict signature malleability.
3. EIP-1108 alt_bn128 pricing. Closed. Measured ecAdd 150, ecMul 6,000, ecPairing 45,000 + 34,000 per pair, that is, the post-1108 schedule.
4. EIP-7516 blob base fee. Closed, and the previous claim was wrong. It is 1 wei (the EIP-4844 floor), not 0.

System contract population on mainnet (measured 2026-07-19)

eth_getCode at latest on chain 2800. This closes most of what was open flag 4.

Contract	Address	Code on mainnet
EIP-2935 history storage	0x0000F90827F1C53a10cb7A02335B175320002935	83 bytes (populated)
EIP-7002 withdrawal requests	0x00000961Ef480Eb55e80D19ad83579A64c007002	none
EIP-7251 consolidation requests	0x0000BBdDc7CE488642fb579F8B00f3a590007251	none
EIP-6110 deposit contract	0x00000000219ab540356cBB839Cbe05303d7705Fa	none
EIP-4788 beacon roots ring buffer	0x000F3df6D732807Ef1319fB7B8bB8522d0Beac02	none

Live mainnet block headers do carry requestsHash, and it is always sha256("") = 0xe3b0c442...b7852b855, the empty-requests hash. Besu computes that hash without executing the absent predeploys. This exact combination (a requestsHash in the header, but no code at the request predeploys) is what halted the Nethermind second client on 2026-07-19; see the cross-client write-up.

Because the EIP-4788 ring buffer has no code, a call to it succeeds with empty returndata rather than returning a zero word. Consumers that decode the result as a bytes32 will see 0x00..00, which is why the EIP-4788 row above is described as returning 0x0, but the distinction matters to a contract that checks returndatasize.

Open [VERIFY] flags: facts published as NOT MEASURED

Second validation pass, 2026-07-19 (independent re-measurement). All five flags below were re-attacked directly against the live chain. Three are now closed by measurement, one is narrowed, and one remains genuinely open. The instrument was re-calibrated from scratch before any of it was trusted (see the method appendix).

1. EOF off under futureEips. CLOSED by measurement. This no longer rests on indirect corroboration. Executing candidate code at head through eth_call with a state override: the EOF v1 container magic 0xef0001... is rejected with Invalid opcode: 0xef (so EIP-3540 container validation is not parsing it), and the EOF-only opcodes RJUMP (0xe0), CALLF (0xe3) and EXTCALL (0xf8) are each rejected as Invalid opcode (so the EOF opcode set is not enabled). Five independent probes, all fail-closed. EOF is not activated, and 0xEF stays reserved by EIP-3541 legacy behavior. This was the highest-risk open item because the milestone rides Besu's futureEips key; it is settled.
2. EIP-1559 base-fee disposal. Narrowed, still open. Ruled out: the base fee is not credited to the coinbase. Measured on block 10,487,561 (1 transaction, gasUsed 22,474, effectiveGasPrice 1 Gwei, i.e. equal to baseFeePerGas, so the priority tip was zero): the coinbase balance delta across that block was exactly 0 wei, where crediting the base fee would have moved 22,474,000,000,000 wei. Because the tip was zero, this cannot by itself separate "protocol-burned" from "routed elsewhere" -- both models predict a zero delta. Closing it needs a block with a nonzero priority tip and unpruned state. The chain is currently quiet (no logs in the last 5,000 blocks), and the one tipped transaction located, 0xb659...9ec1 at block 9,200,542 (tip 0.1 Gwei), sits below the public RPC's pruning horizon so its balances cannot be read. Either run the check on the archive node or read the client source.
3. EIP-2935 contract bytes. CLOSED by measurement, two ways. (a) Byte level: the 83 bytes at 0x0000F90827F1C53a10cb7A02335B175320002935 are byte-for-byte the canonical EIP-2935 runtime 0x3373...fffe14604657602036036042575f35600143038111604257611fff81430311604257611fff9006545f5260205ff35b5f5ffd5b5f35611fff60014303065500. Disassembly confirms the two jump targets are the JUMPDEST at 0x42 (revert path) and the JUMPDEST at 0x46 (the SSTORE path taken when caller == SYSTEM_ADDRESS), and the length is exactly 83 bytes. (b) Functional level, which is stronger: calling the contract with the block number of head - 100 returns that block's hash, byte-identical to eth_getBlockByNumber. The ring buffer is not merely populated, it is serving correct history.
4. EIP-7939 activation height. Partially closed. The opcode itself is confirmed live and correct at head (measured): PUSH1 0x01; CLZ returns 255 and PUSH0; CLZ returns 256. Only the boundary remains unverified -- whether CLZ turned on at the AerePQC milestone (block 9,189,161) or at Osaka (block 2,106,597) -- and that is still not probeable by eth_call because the public RPC has pruned state at both heights. Needs the archive node or a source read.
5. EIP-198 / EIP-2565 / EIP-7883 modexp pricing. CLOSED by measurement, and the answer is specific. A minimal b=8, e=9, m=10 modexp call costs 500 gas. EIP-2565's floor is 200 and EIP-7883's is 500, so EIP-7883 (Osaka) modexp repricing is live and EIP-2565-only pricing is ruled out. The concern that motivated this flag was well founded in kind: a client left on the EIP-2565 schedule undercharges modexp by 300 gas at the floor and would diverge on any modexp-using transaction.

Newly measured in this pass and previously unstated: EIP-2537 BLS12-381 prices (G1ADD 375, G2ADD 600, MAP_FP_TO_G1 5,500, MAP_FP2_TO_G2 23,800, all exactly the spec schedule); EIP-152 blake2f per-round price (cost == rounds, verified at 12 and 100 rounds); EIP-7702 delegation resolution (the 0xef0100 designator executes the target, non-designator 0xEF forms are rejected); EIP-1153 and EIP-5656 confirmed by execution rather than by ruleset membership; and the complete 0x0AE5 SHAKE256 gas model fitted across 10 shapes with zero residual.

How the measured gas figures were produced

Every gas figure marked (measured) came from the same read-only technique, and it is worth stating because the obvious techniques do not work here.

What does not work. eth_estimateGas returns a binary-search result with a small buffer (it reported 66,845 where the true cost is 66,000), and EIP-7623's calldata floor can mask a precompile's price entirely: a 160-byte call to 0x100 costs the same whether or not the precompile exists, because the floor dominates. Neither is precise enough to distinguish a 3,450 gas price from a 6,900 gas one.

What works. An eth_call with a state override that installs a small bytecode probe at a scratch address. The probe reads GAS, performs a STATICCALL to the target, reads GAS again, and returns the difference along with the call's success flag and RETURNDATASIZE. Inside the EVM there is no calldata floor, so the difference is the true charged cost plus a fixed harness overhead. That overhead is then calibrated away using two precompiles whose prices are fixed by spec and cannot drift: ecRecover at a flat 3,000 and the identity precompile at 15 + 3 per word. Both calibrations agreed on an overhead of 127 gas (100 warm-access plus 27 of probe opcodes), and the identity precompile then read back its spec price of 30 exactly. Residual noise is under 15 gas, from memory expansion inside the measured window, which is far below the margins being distinguished.

A trap worth recording. The BASEFEE opcode returns 0 inside eth_call on this chain, even though the block header and eth_feeHistory both report 1 Gwei. Besu simulates calls against a zero base fee. So eth_call is not admissible evidence about BASEFEE or BLOBBASEFEE, and the blob base fee in this document was established from eth_feeHistory and the header's excessBlobGas instead, not from the opcode. Any future probe of a fee-context opcode needs the same caution.

Recalibration note (2026-07-19, second pass). The method reproduces, but the overhead constant is a property of the probe, not of the chain, and should not be treated as a checkable figure. The second pass rebuilt the probe independently -- CALLDATACOPY, a pre-warming STATICCALL, GAS, STATICCALL, GAS, SWAP1, SUB, MSTORE, RETURN -- and calibrated to a fixed overhead of 117 gas (100 warm-access plus 17 gas of probe opcodes), not the 127 recorded above, because it uses a slightly shorter opcode sequence between the two GAS reads. The calibration itself was exact in a way worth stating as the acceptance bar: against the identity precompile at 15 + 3 * ceil(len/32) the implied overhead was 117 at every input length tested (0, 32, 64, 96, 128 and 160 bytes) with no drift, an empty-address control read exactly 117, and ecRecover read back its flat spec price of 3,000 exactly. Residual noise was zero, not merely small. Anyone rebuilding the probe should calibrate their own constant the same way and only trust the instrument once the control and a spec-fixed price both come back exact -- the number to reproduce is the measured price after subtraction, not the overhead.

The probe scripts are throwaway and were not committed. What is reproducible is the method plus the calibration constants above; anyone can rebuild the probe and should get the same numbers against https://rpc.aere.network.