# AIP-4: On-Chain Post-Quantum Signature Verification Suite ## Preamble | Field | Value | | --- | --- | | AIP | 4 | | Title | On-Chain Post-Quantum Signature Verification Suite | | Author | AERE Foundation | | Type | Standards Track | | Category | Interface | | Status | Final | | Created | 2026-07-11 | | Requires | None | | Ratification | Foundation-ratified (pre-decentralization) | ## Abstract This AIP documents AERE's suite of on-chain post-quantum signature verifiers, implemented in pure Solidity and validated against official NIST Known-Answer-Test (KAT) and ACVP vectors. The suite covers hash-based schemes (WOTS+, XMSS, SPHINCS+/SLH-DSA) and lattice schemes (Falcon-512, Falcon-1024, ML-DSA-44), plus the account-layer primitives that turn Falcon-512 verification into a usable wallet. It is a retro-filed record of contracts already live on chain 2800. It is explicit that this is an application and account layer capability today; AERE consensus is not post-quantum. ## Motivation A cryptographically relevant quantum computer would break the secp256k1 ECDSA signatures that secure ordinary EVM accounts. The migration path the ecosystem will eventually need is on-chain verification of NIST post-quantum signature schemes, so that accounts and applications can require a quantum-resistant signature. AERE's goal was to make those verifiers real and correct on a live EVM chain, validated bit-for-bit against the official test vectors, rather than described in a whitepaper. There is a real scope boundary here that this AIP states plainly, because getting it wrong would be a false claim: verifying a post-quantum signature inside a contract is an application-layer capability. It does not make the chain's consensus post-quantum. Validators on AERE still sign classical QBFT. ## Specification ### The verifier suite (live on chain 2800) Each verifier is a pure-Solidity contract validated against official vectors. Whether a verifier can record a result in a state-changing transaction, versus only answer as a `view` via `eth_call`, is decided by the EIP-7825 per-transaction gas cap of 16,777,216 (2^24). Schemes whose full verify fits under the cap expose a state-changing `verifyAndRecord`; schemes whose full verify exceeds the cap in pure Solidity are `view`-only until a native precompile exists (see below). | Scheme | Contract | Address | On-chain mode | Evidence | | --- | --- | --- | --- | --- | | WOTS+ (hash-based, one-time) | AerePQCVerifier | `0x1cE2949e8cE3f1A77b178aF767a4455c08ec6F82` | records on-chain | hash-based, well under the cap; exact standalone gas to be measured (bounded above by the XMSS figure below, which contains a WOTS+ verify) | | XMSS-SHA2_10_256 (RFC 8391, many-time) | AereXmssVerifier | `0x77b14E264D0bb08d304d4e0E527F0fCdFc88B112` | records on-chain | `verifyAndRecord` gasUsed 1,561,963 < 16,777,216 | | SLH-DSA-SHA2-128s / SPHINCS+-SHA2-128s-simple (FIPS 205, stateless) | AereSphincsVerifier | `0xAfFc9F8d950969b46b54e77758BbFf7e000c87e6` | records on-chain | `verifyAndRecord` gasUsed 1,812,066 < 16,777,216 | | Falcon-512 (NIST level 1 lattice) | AereFalcon512Verifier | `0x4E8e9682329e646784fB3bd01430aA4bA54D8fFC` | records on-chain | verify fits under the cap; demonstrated inside a full ERC-4337 userOp (gasUsed 10,278,313) and hybrid auth (gasUsed 10,299,873), both < 16,777,216 | | Falcon-1024 (NIST level 5 lattice) | AereFalcon1024Verifier | `0xF0aFA59BaB2058e4B6e6B424b7f76750F1F66e36` | records on-chain (via precompile) | in this pure-Solidity contract `verifyAndRecord` is about 21.7M gas and EXCEEDS the 16,777,216 cap, so its `verify()` is a pure view; the scheme now records on-chain through the native Falcon-1024 precompile at `0x0AE2`, live on mainnet since block 9,189,161 (AIP-7) | | ML-DSA-44 / Dilithium2 (FIPS 204 lattice) | AereMLDSA44Verifier | `0xf1F7A6Acd82D5DAf9AF3166a2F736EE52C5F85AE` | records on-chain (via precompile) | a full verify in this pure-Solidity contract is about 52.9M gas and EXCEEDS the cap, so its `verify()` is a pure view; the scheme now records on-chain through the native ML-DSA-44 precompile at `0x0AE3`, live on mainnet since block 9,189,161 (AIP-7) | | Falcon/Dilithium-family lattice core (ring arithmetic, norm), n=64 demo | AereLatticeVerifier | `0x60c06E6A3CC201B46A16650be096C6E45424dfD9` | building block | supports the Falcon verifiers | Validation vectors used, as repo fixtures: - Falcon-512: `contracts/test/falcon512_kat0.json` (official NIST KAT). - Falcon-1024: `contracts/test/falcon1024_kat0.json` (official round-3 KAT). - XMSS: `contracts/test/fixtures/xmss-sha2_10_256-kat.json` (xmss-reference vectors). - ML-DSA-44: `contracts/test/fixtures/mldsa44-acvp-tg8.json` (NIST ACVP ML-DSA-sigVer, 15/15 cases reproduce NIST's expected results). - SPHINCS+/SLH-DSA: `contracts/test/fixtures/sphincs-sha2-128s-acvp-tg31.json` (NIST ACVP SLH-DSA-sigVer, 14/14 cases reproduce NIST's expected results). ### Account-layer primitives (live on chain 2800) - **AerePQCAccountFactory** at `0xd5315Ea7caa60d320c4f34b1bEd70dd9cc02CE58`. A CREATE2 factory that deploys an ERC-4337 v0.7 smart account whose sole owner is a Falcon-512 public key (897 bytes), with no classical ECDSA fallback. Both `validateUserOp` and EIP-1271 `isValidSignature` are decided by the live AereFalcon512Verifier. - **AerePQCAccount_sample** at `0xa42a5e7F72E46BadC11367650Ec34D676194326f`. A sample account owned by a real Falcon-512 key, used to prove the EIP-1271 accept path (`0x1626ba7e`) and a full userOp through the EntryPoint. - **AereHybridAuth** at `0xc20390C9656ECe1AE37603c84E395bC898b3FAA1`. Authorizes only if BOTH a secp256k1 ECDSA signature AND a Falcon-512 signature verify over the same 32-byte hash. This is the pragmatic migration primitive: classical and post-quantum in series, so an account is safe as long as either scheme holds. ### Standing of the suite Across hash-based and lattice families, with each verifier validated against the official NIST KAT/ACVP vectors and demonstrated on a live EVM chain: we are not aware of any other public chain that verifies all of these on-chain. ## Rationale Pure-Solidity verifiers were built first because they run on the live chain today with no client change and are auditable by anyone with an EVM. The design splits cleanly along the EIP-7825 gas cap: the hash-based schemes and Falcon-512 fit under the cap and can therefore record a verification result on-chain, which is what an account or an application actually needs. Falcon-1024 and ML-DSA-44 are too expensive to record in pure Solidity, so they are offered as `view` verifiers (useful for off-chain-anchored checks and for correctness demonstration) until a native precompile makes recording them feasible. Hybrid ECDSA-plus-Falcon authorization (AereHybridAuth) was chosen as the first account-facing product because it is the safest migration posture: it never weakens the classical guarantee while adding the post-quantum one. ### Native precompile (live on mainnet chain 2800 since block 9,189,161) Moving Falcon-1024 and ML-DSA-44 to record-on-chain, and making Falcon-512 and SPHINCS+ far cheaper, requires a native precompile for SHAKE256 and for the Falcon, ML-DSA, and SPHINCS verify routines. That work was implemented and KAT-validated on an isolated Besu 26.4.0 scratch fork (source tag 26.4.0, commit `d2032017`, chain 28099), which adds five native precompiles wrapping the audited Bouncy Castle 1.83 BCPQC verifiers already on the client classpath (Falcon-512, Falcon-1024, ML-DSA-44, SLH-DSA-SHA2-128s, SHAKE256), plus a native EIP-2935 8191-block lookback, with zero new dependencies and zero hand-rolled cryptography. All NIST KAT and ACVP vectors pass in both directions, positive and negative (15/15 ML-DSA-44 cases, 14/14 SLH-DSA cases). Measured full verify-and-record gas on that fork: Falcon-512 86,336; Falcon-1024 145,496 (0.87% of the 16,777,216 cap); ML-DSA-44 351,050 (2.09%); SLH-DSA-SHA2-128s 558,276; SHAKE256 21,470. This moves Falcon-1024 (about 21.7M gas in pure Solidity) and ML-DSA-44 (about 52.9M gas) from view-only to record-on-chain with wide margin. That fork is now LIVE on mainnet chain 2800, activated at block 9,189,161 (2026-07-12) as the AerePQC hard fork: a coordinated, client-only, flag-day activation with no re-genesis and no state migration, which adds the five native precompiles at the address band `0x0AE1`..`0x0AE5` (Falcon-512, Falcon-1024, ML-DSA-44, SLH-DSA-SHA2-128s, SHAKE256) and the native EIP-2935 8191-block lookback. The pure-Solidity AereFalcon1024Verifier and AereMLDSA44Verifier contracts remain view-only, but the Falcon-1024 and ML-DSA-44 schemes now record on-chain through the precompiles at `0x0AE2` and `0x0AE3`, demonstrated end-to-end by a real Falcon-1024 attestation recorded through AerePQCAttestation (`0x465d9E3b476BF98Aa1393079e240Db5D2a9bEA6A`, attestation tx `0xb659…9ec1`, block 9,200,542, status 1). The activation is filed as its own Core AIP, AIP-7; the mechanism is specified in `research/aip-draft-pqc-precompiles.md`. The precompiles carry an internal self-audit only; an external audit is still pending before they should secure material value. ## Backwards Compatibility None. The verifiers and account primitives are additive contracts. They do not change the EVM ruleset, existing accounts, or consensus. Ordinary secp256k1 accounts continue to work unchanged. ## Security Considerations The single most important honesty point: **this is an application and account layer capability, not post-quantum consensus.** AERE validators still sign classical QBFT, so a quantum adversary that could forge validator signatures is not addressed by these contracts. Do not read this AIP as a claim that AERE consensus is post-quantum. It is not. Further honest caveats: - **Pure-Solidity view versus precompile record.** The pure-Solidity AereFalcon1024Verifier and AereMLDSA44Verifier cannot record a result on-chain because a recording transaction exceeds the 16,777,216 gas cap; their `verify()` over `eth_call` is only as trustworthy as the node answering it. Since the AerePQC hard fork (block 9,189,161, AIP-7), the Falcon-1024 and ML-DSA-44 schemes do record on-chain through the native precompiles at `0x0AE2` and `0x0AE3`, which are consensus-anchored. Falcon-512, WOTS+, XMSS, and SPHINCS+ also record on-chain. - **XMSS statefulness.** AereXmssVerifier verifies a signature but does not enforce the signer's one-time-per-leaf state. Callers that rely on XMSS's many-time security must track leaf usage off-chain. WOTS+ is one-time by construction and must not be reused across messages. - **Cost.** Falcon-512 verification is heavy (roughly 10.3M gas inside a full userOp). It fits under the cap but is expensive; the native precompile is the path to making it cheap. - **Unaudited.** These verifiers have not had an external security audit. Their assurance today rests on bit-for-bit agreement with the official NIST KAT/ACVP vectors and on cross-checks against independent reference implementations, which is strong evidence of correctness on the tested vectors but is not a substitute for an audit. ## Reference Implementation and On-Chain Deployment Verifier sources are under `contracts/contracts/` (glob for the PQC, Falcon, XMSS, ML-DSA, and SPHINCS verifiers). All addresses in the tables above are copied verbatim from `sdk-js/src/addresses.ts`. Each verifier is live and answerable via `eth_call` on `https://rpc.aere.network` (chain ID 2800): official vectors return true, tampered inputs return false. The recording transactions cited (XMSS, SPHINCS+, the Falcon-512 account userOp, and the hybrid auth) are on-chain and under the EIP-7825 cap. ## Copyright Released to the public domain (CC0). No rights reserved.