aere-network/aere-research
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
main
aere-research/aips/AIP-4.md
Aere Network 4a0b48588c Initial public release 
Aere Network public source. Everything here can be checked against the live
chain (chain id 2800, https://rpc.aere.network).

Scope note, stated up front rather than buried: consensus on chain 2800 is
classical secp256k1 ECDSA QBFT. The post-quantum work in this repository is at
the signature, precompile, account and transport layers. Nothing here makes the
consensus post-quantum, and no document in it should be read as claiming so.
2026-07-20 01:02:30 +03:00

12 KiB
Raw Permalink Blame History

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.