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,363, and Osaka (Fusaka) at block 2,106,606. 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 for a human to confirm before publication.
• "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,363	cancunTime == pragueTime == 1780189051; Cancun and Prague share one activation instant on Aere
Osaka (Fusaka)	Block 2,106,606	osakaTime == 1780220351
AerePQC milestone (post-Osaka)	Block 9,189,161	Besu futureEipsTime == 1783820272; PQC precompiles + EIP-2935 write path + EIP-7939

[VERIFY: block heights 2,075,363 and 2,106,606. The genesis config gates Cancun/Prague/Osaka by timestamp (1780189051 / 1780189051 / 1780220351), not by block number, so these heights are the observed first-block-past-timestamp and should be confirmed against the live chain's head history.]

---

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). Aere adds no consensus base-fee burn narrative: its "burn" is a separate validator-reward cut (see deviations). [VERIFY: base-fee disposal on chain 2800, whether the 1559 base fee is protocol-burned as on Ethereum or credited.]
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.

Cancun (block 2,075,363)

EIP	Name	Status	Difference from Ethereum
1153	Transient storage (TLOAD / TSTORE)	Supported	Matches Ethereum.
4844	Shard blob transactions	Partial	Type-3 blob transactions are present in the EVM, but Aere runs no blob data-availability market, so blobs carry no fee and are not served/persisted as on Ethereum. 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.
5656	MCOPY instruction	Supported	Matches Ethereum.
6780	SELFDESTRUCT only in same transaction	Supported	Matches Ethereum.
7516	BLOBBASEFEE opcode	No-op	Returns 0: there is no blob market, so there is no blob base fee.

Prague / Pectra (block 2,075,363)

EIP	Name	Status	Difference from Ethereum
2537	BLS12-381 curve precompiles	Supported	Matches Ethereum.
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). [VERIFY: whether the deposit system contract is actually populated on mainnet 2800; EIP-2935's contract was not populated until block 9,189,161, so this must be checked directly.]
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. [VERIFY: system contract populated on mainnet; header requests handling.]
7251	Increase MAX_EFFECTIVE_BALANCE (consolidations)	Partial	Consolidation-request ruleset present, but no beacon layer to act on it under QBFT. [VERIFY: system contract populated on mainnet.]
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. [VERIFY: whether mainnet block headers carry a non-empty requests hash and the request system contracts are populated.]
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).
7691	Blob throughput increase	Partial	The blob schedule is raised at Prague (target 6, max 9) in config, but with no blob data-availability market the increase has no practical effect.

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

EIP	Name	Status	Difference from Ethereum
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).
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.
0x0AE2	Falcon-1024 signature verify	Live on mainnet	Activated at block 9,189,161. NIST KAT verified.
0x0AE3	ML-DSA-44 signature verify (FIPS 204)	Live on mainnet	Activated at block 9,189,161. ACVP verified.
0x0AE4	SLH-DSA-SHA2-128s signature verify (FIPS 205)	Live on mainnet	Activated at block 9,189,161. ACVP verified.
0x0AE5	SHAKE256 (FIPS 202)	Live on mainnet	Activated at block 9,189,161.
0x0AE6	ML-KEM-768 encapsulation (FIPS 203)	Testnet only	Built and ACVP-verified (25/25) on an isolated QBFT testnet. NOT on mainnet 2800; a mainnet staticcall hits an empty account and returns empty. Founder- and audit-gated.
0x0AE7	Falcon HashToPoint (SHAKE256 sampler)	Testnet only	Built and KAT-verified (12/12) on isolated testnet. NOT on mainnet 2800. 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 (RIP-7212 / RIP-7951)	Live on mainnet	Native P-256 signature verification for passkeys/WebAuthn at a fixed cost of about 3,450 gas. Active from the Osaka/Fusaka ruleset. Note: this is a shared Rollup Improvement Proposal being standardized into Ethereum's Osaka, so it is standards-aligned rather than Aere-proprietary.

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.

---

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.
2. EIP-4844 blobs present, EIP-7516 BLOBBASEFEE returns 0. Blob transactions exist in the EVM, but there is no blob data-availability market, so the blob base fee is 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.

---

Open [VERIFY] flags for the human before external publication

1. Pectra/Fusaka block heights (2,075,363 / 2,106,606). Genesis gates these by timestamp, not block number. Confirm the heights against the live chain's head history.
2. EOF off under futureEips. Confirm the AerePQC futureEips protocol spec (futureEipsTime = 1783820272, block 9,189,161) does not enable the EOF opcode set / EIP-3540/3670 container validation. Served genesis, the Nethermind fork-id mirror, and the engineering spec all indicate EOF is off; inspect the fork build's spec definition to close the loop, since the milestone rides Besu's futureEips key (EOF's usual staging ground in stock Besu).
3. EIP-1559 base-fee disposal. Confirm whether the 1559 base fee is protocol-burned (as on Ethereum) or credited on chain 2800. The documented Aere "burn" is a separate validator-reward cut, so the base-fee disposal itself should be stated precisely.
4. Validator-lifecycle request contracts (6110/7002/7251/7685). Verify whether the deposit/withdrawal/consolidation system contracts are actually populated on mainnet (EIP-2935's contract was not populated until block 9,189,161) and whether mainnet block headers carry a requests hash. Regardless of the outcome, no beacon layer consumes these requests, so the "Partial" status and the no-effect-on-validator-set caveat hold.
5. EIP-7939 activation height. Confirm CLZ activated at the post-Osaka AerePQC milestone (block 9,189,161) rather than at Osaka (block 2,106,606); the Nethermind live-sync mirror maps it to the post-Osaka boundary.
6. P256Verify framing. Confirmed at 0x100, about 3,450 gas, from the Osaka/Fusaka ruleset (RIP-7212 / RIP-7951). Noted as standards-aligned rather than Aere-proprietary; keep that framing if publishing under an "additions" heading.