# AIP-7: AerePQC Hard-Fork Activation (Native PQC Precompiles and Extended EIP-2935 Lookback) ## Preamble | Field | Value | | --- | --- | | AIP | 7 | | Title | AerePQC Hard-Fork Activation (Native PQC Precompiles and Extended EIP-2935 Lookback) | | Author | AERE Foundation | | Type | Standards Track | | Category | Core | | Status | Final | | Created | 2026-07-16 | | Requires | 4 | | Ratification | Foundation-ratified (pre-decentralization) | ## Abstract This AIP documents the AerePQC hard fork, a coordinated, client-only activation on mainnet chain 2800 at block 9,189,161 (2026-07-12) that added two Core changes: five native post-quantum verification precompiles at the address band `0x0AE1`..`0x0AE5` (Falcon-512, Falcon-1024, ML-DSA-44, SLH-DSA-SHA2-128s, and SHAKE256), and the native EIP-2935 8191-block historical-block-hash lookback. It is a retro-filed record of a change already live on chain 2800. It is explicit that this fork changed only the execution layer; AERE consensus is still classical secp256k1 ECDSA QBFT and is not post-quantum. ## Motivation AIP-4 documents AERE's pure-Solidity post-quantum verifier suite. Two of those schemes, Falcon-1024 and ML-DSA-44, cannot record a verification result in a state-changing transaction in pure Solidity, because a recording transaction exceeds the EIP-7825 per-transaction gas cap of 16,777,216 (2^24). Their verification is correct but was reachable only as a read-only `eth_call` view, which is only as trustworthy as the node answering it and is not consensus anchored. The other schemes that do fit under the cap (notably Falcon-512, at roughly 10.5M gas inside a full userOp) are correct but expensive. The fix that removes both limits is a native precompile: the dominant cost inside every one of these verifiers is SHAKE / Keccak-f[1600] streaming plus lattice ring arithmetic, and moving that into audited native code, wrapped as an EVM precompile, reduces each verification by more than an order of magnitude. This is the same approach Ethereum uses for other heavy primitives (RIP-7951 for native P-256, EIP-2537 for native BLS12-381). Bundling the native EIP-2935 write path into the same fork gave the network extended trustless block-hash lookback in one scheduled activation instead of two. The goal was to make Falcon-1024 and ML-DSA-44 record on-chain within the same 16,777,216 per-transaction cap AERE keeps as a functional peer of Ethereum L1, to make the schemes that already fit far cheaper, and to do so as a client-only fork with no re-genesis and no state migration. ## Specification ### Activation point The AerePQC hard fork activated on mainnet chain 2800 at **block 9,189,161** (2026-07-12). It is configured as a Besu `futureEips` milestone with activation timestamp `futureEipsTime = 1783820272` (2026-07-12 01:37:52 UTC). Activation added precompile behavior and the EIP-2935 write path only. It did NOT change how blocks are proposed, signed, or committed: blocks are still produced and committed by the QBFT validator set signing classical secp256k1 ECDSA committed seals. ### Native PQC precompiles The fork registers five native precompiles that wrap the audited Bouncy Castle 1.83 BCPQC verifiers already present on the client classpath, behind a dedicated classloader-isolation boundary so that Bouncy Castle 1.83 cannot collide with the older Bouncy Castle that Besu bundles. There is zero new hand-rolled cryptography. | Address | Precompile | Standard | Output | | --- | --- | --- | --- | | `0x0000000000000000000000000000000000000AE1` | Falcon-512 verify | NIST round-3 Falcon | valid / invalid | | `0x0000000000000000000000000000000000000AE2` | Falcon-1024 verify | NIST round-3 Falcon | valid / invalid | | `0x0000000000000000000000000000000000000AE3` | ML-DSA-44 verify | FIPS 204 (internal interface) | valid / invalid | | `0x0000000000000000000000000000000000000AE4` | SLH-DSA-SHA2-128s verify | FIPS 205 (internal interface) | valid / invalid | | `0x0000000000000000000000000000000000000AE5` | SHAKE256 | FIPS 202 XOF | requested output bytes | Each verify precompile is a pure function of its input bytes: it parses a packed, length-prefixed public key, signature, and message; reverts deterministically on malformed structure; and otherwise returns a valid/invalid decision. SHAKE256 returns the requested number of output bytes. Because a precompile result feeds a consensus-critical state transition, every node MUST return byte-identical output for identical input; the verify paths used are deterministic and integer-only (Falcon verification never touches the floating-point signing path). The full input encodings, per-scheme parameters, revert-versus-`0x00` semantics, and gas model are specified in `research/aip-draft-pqc-precompiles.md`. Gas figures below are the values measured on the pre-activation scratch fork (chain 28099) and carried to mainnet. | Scheme | Marginal verify-op gas | Full verify-and-record tx gasUsed | Share of 16,777,216 cap | | --- | --- | --- | --- | | SHAKE256 | 60 + 12/word | 21,470 | 0.13% | | Falcon-512 | 40,000 | 86,336 | 0.51% | | Falcon-1024 | 75,000 | 145,496 | 0.87% | | ML-DSA-44 | 55,000 | 351,050 | 2.09% | | SLH-DSA-SHA2-128s | 350,000 | 558,276 | 3.33% | These figures move Falcon-1024 (about 21.7M gas in pure Solidity) and ML-DSA-44 (about 52.9M gas) from view-only to record-on-chain, and drop Falcon-512 from about 10.49M gas to 86,336. ### Native EIP-2935 (extended block-hash lookback) The fork also activates the native EIP-2935 history-storage system contract at the canonical address `0x0000F90827F1C53a10cb7A02335B175320002935`, a ring buffer of the last 8191 block hashes. At the start of every block, the parent block hash is written into slot `(number - 1) % 8191` by a consensus system call, before any user transaction runs. There is no keeper, relayer, or Foundation key involved; the write is a condition of block validity. Contracts read a hash by `STATICCALL` with the 32-byte block number; a query outside the served window `[number - 8191, number - 1]` reverts. At AERE's 0.5-second block time, 8191 blocks is roughly 68 minutes of trustless lookback, against the roughly 128 seconds the 256-block `BLOCKHASH` opcode gives. The system contract's runtime bytecode is byte-identical to Ethereum's Pectra deployment and was deployed post-genesis via the canonical keyless "Nick's-method" transaction, so the block-0 state root is unchanged. ## Rationale Native precompiles rather than more Solidity optimization: the pure-Solidity verifiers are already heavily optimized (hand-written Keccak-f assembly) and the remaining cost is intrinsic. Only native code removes it, which is the same reasoning that justified RIP-7951 and EIP-2537 on Ethereum. Wrapping a maintained, audited native library (Bouncy Castle) rather than hand-rolling the verify keeps the security boundary at a reviewed implementation plus a thin parsing adapter. The classloader-isolation boundary exists because Besu bundles an older Bouncy Castle, and a naive classpath addition risks silently binding the wrong implementation. A single coordinated hard fork with no re-genesis was chosen over a chain restart so the network kept its entire history, state, and validator keys, consistent with the same discipline applied in AIP-3. Bundling EIP-2935 into the same activation gave the network extended lookback and post-quantum verification in one scheduled event. Keeping the same 16,777,216 per-transaction gas cap as Ethereum L1, rather than raising a local gas limit, is deliberate: it is why the native precompile, not an unbounded gas budget, is the correct fix. The precompiles were placed at the `0x0AE1`..`0x0AE5` band already used on the scratch fork, above the Ethereum standard precompiles, the EIP-2537 BLS12-381 range, and the RIP-7951 P-256 precompile at `0x100`, so upstream precompile allocations do not collide. If upstream Ethereum later allocates into this band, AERE will re-evaluate to preserve equivalence. ## Backwards Compatibility None that breaks existing contracts. Before activation the five band addresses were empty accounts and the EIP-2935 system address had no code; a call to any of them behaved as a call to an empty address. After block 9,189,161 they behave as precompiles and as the consensus-written history ring buffer. The pure-Solidity verifiers documented in AIP-4 remain deployed and unchanged; contracts MAY migrate to the precompiles for lower gas but are not required to. Integrators SHOULD gate precompile use on chain height (past the activation block), not on probing. Because AERE runs all validators under one operator and one client today, activation was a flag-day upgrade of the client build across the validator set at the fork block. A node that had not upgraded would compute different results for calls into the band and fork off, so the upgrade was mandatory for all validators and archive/RPC nodes at the fork block. ## Security Considerations **This fork does not make AERE consensus post-quantum.** Validators continue to sign classical secp256k1 QBFT committed seals. The precompiles are an application and account layer capability. Any claim of post-quantum consensus on the basis of this fork would be false and must not be made. Isolated-testnet work on a Falcon quorum certificate and a second execution client is separate R&D and is not live on chain 2800. **Single operator, one client.** Chain 2800 runs seven QBFT validators (f=2, quorum 5-of-7), all Foundation-operated, on a single execution client (Hyperledger Besu). Even at f=2, the validators are one operator and one client, so a consensus bug in a precompile is not caught by client diversity, because there is no second live client. This raises, not lowers, the bar for an external audit and for extensive differential testing. **Determinism and gas agreement.** Every node must compute the identical accept/reject and the identical gas charge. The verify paths are deterministic and integer-only, and the adapter reads no chain state or block context. Gas is priced from native microbenchmarks so a precompile call cannot consume disproportionate wall-clock time for its gas; malformed input reverts and consumes all supplied gas, so it cannot be used as a cheap probe. **A valid signature is not authorization.** A valid decision from a verify precompile establishes only that the signature is valid for the given public key and message. It does not establish freshness, ordering, replay protection, or key ownership; consuming contracts (for example AerePQCAttestation) add their own nonce and domain separation. For hash-based schemes with one-time-per-leaf state (XMSS, WOTS+), a valid verification does not prove the signer has not reused a leaf. **External audit pending.** The fork, the five precompiles, and the consuming contracts carry an internal self-audit only. They have not undergone an external security audit. Their assurance today rests on bit-for-bit agreement with the official NIST KAT and ACVP vectors, cross-checks against independent reimplementations (including a second execution client that runs the precompiles byte-identically on an isolated testnet), and an on-chain end-to-end attestation. They should not secure material value until an external audit lands. ## Reference Implementation and On-Chain Deployment This is a client and chain-configuration change, so the precompile band and the EIP-2935 system contract have no per-scheme deployment artifact of their own; the authoritative artifact is the AERE Besu fork (base `hyperledger/besu:26.4.0`, gold binary SHA-256 `7c5c0743088e9fa765d54c745814601b3c7a27a892e396156f88092b34c80772`) and the chain history from block 9,189,161 onward. On-chain evidence: - **AerePQCAttestation** at `0x465d9E3b476BF98Aa1393079e240Db5D2a9bEA6A` (verbatim from `sdk-js/src/addresses.ts`) is a permissionless, no-custody attestation registry that verifies through the live precompiles. A real Falcon-1024 signature (Bouncy Castle 1.83) was verified through the `0x0AE2` precompile and recorded on mainnet: attestation tx `0xb659…9ec1`, block 9,200,542, gasUsed 692,206, status 1. A transaction success alone proves the live precompile returned valid, because the contract reverts `PQCVerificationFailed` otherwise. - **AereCryptoRegistry** at `0xaE6fC596bb3eCcbf5c5D02D67B0Ef065b3Afbaa5`, a crypto-agility registry over the five live precompiles. - **AerePQCKeyRegistry** at `0x1eCa3c5ADcBD0b22636D8672b00faC6D89363691` (proof-of-possession; `precompileFor(1) == 0x0ae1` confirmed on-chain), and **AereThresholdPQCRegistry** at `0x9a6096F6FB3a7E54cF70DE12Cb3903Ae79D1C213` (t-of-n post-quantum authorization via the precompiles). - **EIP-2935 history contract** at `0x0000F90827F1C53a10cb7A02335B175320002935`, deployed via the canonical keyless transaction `0x67139a552b0d3fffc30c0fa7d0c20d42144138c8fe07fc5691f09c1cce632e15` (mined at block 9,182,379, status 1); `eth_getCode` returns the canonical Pectra runtime, which encodes the 8191-block (`0x1fff`) ring buffer. All addresses above are copied verbatim from `sdk-js/src/addresses.ts`. The live precompile band, its activation block, and the EIP-2935 window are verifiable on `https://rpc.aere.network` (chain ID 2800): the current head is well past block 9,189,161, `eth_getCode` at the EIP-2935 address returns the 8191-block runtime, and the recorded Falcon-1024 attestation is retrievable at block 9,200,542. The design and gas model are specified in `research/aip-draft-pqc-precompiles.md`; the pure-Solidity verifier suite that the precompiles accelerate is documented in AIP-4. ## Copyright Released to the public domain (CC0). No rights reserved.