aere-research/aips/AIP-7.md

# 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.