aere-research/research/pqc-onchain-verification.md

On-Chain Post-Quantum Signature Verification on an EVM Layer-1 (AERE, Chain 2800)

Abstract

We describe a suite of post-quantum signature verifiers deployed and running on AERE Network, an EVM-compatible Layer-1 (chain ID 2800, Hyperledger Besu QBFT). Each verifier reproduces, in plain Solidity executing on the chain's own EVM, the reference verification algorithm of a NIST-standardized or NIST-round-3 signature scheme: the hash-based schemes WOTS+, XMSS-SHA2_10_256 (RFC 8391), and SLH-DSA-SHA2-128s (FIPS 205, the standardized form of SPHINCS+); and the lattice schemes Falcon-512, Falcon-1024 (NIST round-3), and ML-DSA-44 (Dilithium2, FIPS 204). Every verifier is validated bit-for-bit against official Known-Answer-Test (KAT) or ACVP fixtures, and the fixtures are committed to the repository. We then analyze the interaction between full on-chain verification and the Fusaka hard fork's EIP-7825 per-transaction gas cap of 2^24 (16,777,216) gas. Four of the six schemes fit under the cap and record their result in an ordinary transaction; two (Falcon-1024 and ML-DSA-44) exceed it in pure Solidity and are therefore verifiable only as read-only eth_call views today. We then describe a native-precompile path, developed and KAT-validated on an isolated Besu 26.4.0 scratch fork (chain ID 28099) and now live on mainnet 2800, that moves every scheme under the cap: a full Falcon-1024 verify-and-record transaction costs 145,496 gas (0.87% of the cap) and ML-DSA-44 costs 351,050 gas (2.09%), both comfortably recordable. These five precompiles are LIVE on AERE mainnet 2800 at the address band 0x0AE1..0x0AE5, activated at block 9,189,161 (2026-07-12) as the AerePQC hard fork, a coordinated client-only activation with no re-genesis; the Falcon-1024 and ML-DSA-44 schemes that were view-only in pure Solidity now record on-chain through the precompiles. We are candid about the system's real limitations: the post-quantum property is at the application and account layer, not consensus; the network runs seven validators under a single operator, one client, and has not yet undergone an external audit.

1. Motivation

1.1 Harvest-now, decrypt-later

The threat that justifies deploying post-quantum verification today is not a cryptographically relevant quantum computer (CRQC) that exists today. It is the asymmetry between when data is captured and when it can be attacked. A public blockchain publishes, permanently and to everyone, the two artifacts an attacker most wants: account public keys and the signatures made under them. Elliptic-curve signatures such as secp256k1 ECDSA derive their security from the hardness of the discrete-logarithm problem, which Shor's algorithm solves in polynomial time on a sufficiently large quantum computer. An adversary who records the chain today can, at any later date when a CRQC becomes available, recover private keys from exposed public keys and forge transactions against any account whose key material is already public. This is the harvest-now, decrypt-later posture, and for an immutable public ledger the "harvest" step is free and already happening.

Hash-based signatures (WOTS+, XMSS, SLH-DSA) rest only on the pre-image and collision resistance of their underlying hash function. Shor's algorithm does not break these; the best known quantum attack is Grover's algorithm, which yields only a quadratic speedup that is absorbed by standard parameter sizing. Lattice signatures (Falcon, ML-DSA) rest on the hardness of structured-lattice problems for which no efficient quantum algorithm is known. Making a chain able to verify these schemes natively is the precondition for users to migrate account and settlement authorization onto quantum-resistant keys well before a CRQC arrives.

1.2 Why the account and settlement layer first

Post-quantum security can be introduced at two very different layers. Changing consensus so that validators sign blocks with a post-quantum scheme is invasive: it touches the client, the gossip and finality protocols, and every operator. Changing the account and settlement layer is additive: a contract that verifies a Falcon or SLH-DSA signature can be deployed like any other contract, and a smart account can bind its authorization to a post-quantum key with no protocol change at all. AERE takes the additive path. The verifiers described here are ordinary immutable contracts; the post-quantum smart account (Section 3.4) is an ERC-4337 account whose sole owner is a Falcon-512 public key. This gives users a usable quantum-resistant primitive today while leaving consensus untouched. We state plainly, in Section 7, that this means consensus signatures on AERE remain classical.

2. Deployment context

AERE runs Hyperledger Besu with QBFT consensus, 0.5-second blocks, sub-second finality, and seven validators. The EVM ruleset is Pectra plus Fusaka, targeting functional parity with Ethereum mainnet. Two Fusaka features matter directly here:

• EIP-7825, which caps the gas usable by any single transaction at 2^24 = 16,777,216 gas, independent of the block gas limit. This cap is the central constraint analyzed in Section 5.
• The SHA-256 precompile at address 0x02, used by the hash-based verifiers, and RIP-7951, the secp256r1 (P-256) precompile at 0x100, which is relevant as precedent for the native-precompile proposal in Section 6.

Every verifier discussed here is deployed with no owner, no admin, and no upgrade path. They are pure verification logic: given a public key, a message, and a signature, they return the same accept or reject decision that the corresponding reference implementation returns. All other Ownable contracts on the network are owned by the Foundation account 0x0243A4f47D44b40b65D33f20329dE20D00c6f3C3; the verifiers themselves have no such owner to name.

3. The schemes AERE verifies on-chain

The deployed suite spans both families that NIST is standardizing for signatures: stateless and stateful hash-based schemes, and structured-lattice schemes. The table below lists each verifier with its live address on chain 2800, the parameter set, and the artifact sizes that drive its gas cost. All addresses are copied verbatim from the canonical SDK registry (aerenew/sdk-js/src/addresses.ts).

Scheme	Contract	Address (chain 2800)	Family	Key params	Sizes
WOTS+ (one-time)	AerePQCVerifier	0x1cE2949e8cE3f1A77b178aF767a4455c08ec6F82	Hash (keccak256)	n=32, w=16, len=67	67 chain elements
XMSS-SHA2_10_256	AereXmssVerifier	0x77b14E264D0bb08d304d4e0E527F0fCdFc88B112	Hash (SHA-256)	n=32, w=16, h=10, len=67	WOTS+ leaf + 10-node path
SLH-DSA-SHA2-128s	AereSphincsVerifier	0xAfFc9F8d950969b46b54e77758BbFf7e000c87e6	Hash (SHA-256)	n=16, d=7, h'=9, a=12, k=14, len=35	pk 32 B, sig 7856 B
Falcon-512	AereFalcon512Verifier	0x4E8e9682329e646784fB3bd01430aA4bA54D8fFC	Lattice (NTRU)	q=12289, n=512	pk 897 B, comp sig 615 B
Falcon-1024	AereFalcon1024Verifier	0xF0aFA59BaB2058e4B6e6B424b7f76750F1F66e36	Lattice (NTRU)	q=12289, n=1024	pk 1793 B, comp sig 1229 B
ML-DSA-44 (Dilithium2)	AereMLDSA44Verifier	0xf1F7A6Acd82D5DAf9AF3166a2F736EE52C5F85AE	Lattice (module)	q=8380417, n=256, (k,l)=(4,4)	FIPS 204 encoded

Two composite primitives build on these verifiers: a hybrid classical-plus-post-quantum authorizer, AereHybridAuth at 0xc20390C9656ECe1AE37603c84E395bC898b3FAA1, and a post-quantum ERC-4337 smart account created by AerePQCAccountFactory at 0xd5315Ea7caa60d320c4f34b1bEd70dd9cc02CE58. A precursor lattice core, AereLatticeVerifier at 0x60c06E6A3CC201B46A16650be096C6E45424dfD9, implements ring arithmetic at a reduced degree (n=64) and is a demonstration core only; it is superseded for real use by the spec-complete Falcon-512 verifier.

3.1 Hash-based schemes

WOTS+ (AerePQCVerifier). This is the one-time building block on which the stateful and stateless hash schemes are built. The 256-bit message hash is split into 64 base-16 digits plus a three-digit checksum, giving 67 hash chains. Verification advances each supplied signature element to the end of its keccak256 chain and checks that the hash of all 67 chain-ends equals the committed public key. The checksum defeats the obvious forgery: raising any message digit lowers the checksum, which would require inverting keccak256. WOTS+ is one-time, meaning a key may sign exactly one message safely; it exists on-chain both as a standalone verifier and as the leaf primitive inside XMSS and SLH-DSA.

XMSS-SHA2_10_256 (AereXmssVerifier). XMSS is the honest many-time extension of WOTS+. A signature carries a WOTS+ one-time leaf plus a Merkle authentication path from that leaf to a long-term public root, for parameter set OID 0x00000001 (n=32, w=16, tree height h=10, SHA-256). The verifier reproduces the RFC 8391 verification path exactly: compute the message digest M' = H_msg(R, root, idx, M), recover the WOTS+ public key from the signature, L-tree-compress it to a leaf, walk the height-10 authentication path to a candidate root, and accept if that root equals the published root. All hashing uses the RFC 8391 keyed, address-domain-separated toolbox (F, H, H_msg, PRF with padding_len = n = 32) over the SHA-256 precompile at 0x02.

SLH-DSA-SHA2-128s (AereSphincsVerifier). This is the FIPS 205 standardization of SPHINCS+, in its smallest-signature parameter set (n=16, h=63, d=7, h'=9, a=12, k=14, len=35; public key 32 bytes, signature 7856 bytes). Unlike XMSS it is stateless: a few-times FORS layer selects a hypertree leaf pseudo-randomly, so one key signs an effectively unbounded number of messages with no signer state. The verifier implements FIPS 205 Algorithm 20 (slh_verify_internal) end-to-end: derive the digest and the tree and leaf indices via MGF1-SHA-256, recover the FORS public key with fors_pkFromSig, then verify the d=7 hypertree of WOTS+ layers and h'=9 Merkle paths up to the root. One subtlety is load-bearing: FORS indices are extracted with FIPS 205 base_2^12 big-endian decoding, not the round-3 SPHINCS+ LSB-first message_to_indices. That single change is what makes an otherwise round-3 implementation accept valid FIPS 205 signatures, and the repository's cross-check against the unpatched reference C isolates exactly it (Section 4).

3.2 Lattice schemes

Falcon-512 (AereFalcon512Verifier). Falcon is an NTRU-lattice, hash-and-sign scheme. The verifier performs the full Falcon-512 check on-chain: HashToPoint streams SHAKE256(nonce || message) and rejection-samples a challenge polynomial c in Z_q[x]/(x^512 + 1) with q = 12289; the 897-byte NIST public key (14-bit-packed coefficients) is decoded to h; the compressed signature is decoded to s2 with the reference comp_decode (sign bit, seven low bits, unary high bits, with strict rejection of "-0", overflow, and non-zero trailing bits); the verifier recomputes s1 by a negacyclic convolution s2 * h - c using an in-contract number-theoretic transform, centers the coefficients, and accepts if and only if the squared l2 norm of (s1, s2) is at most the acceptance bound 34,034,726. SHAKE256 is implemented from a hand-written Keccak-f[1600] permutation in assembly; the source notes the naive array version cost roughly 1.26M gas per permutation, which is why the assembly path exists and why hashing dominates the total cost.

Falcon-1024 (AereFalcon1024Verifier). Structurally identical to Falcon-512 at ring degree n=1024, q=12289, with a 1793-byte public key, a 1229-byte compressed signature, and an acceptance bound of 70,265,242. The larger ring roughly doubles the number-theoretic transform work and, as Section 5 shows, pushes a state-changing verification above the per-transaction gas cap.

ML-DSA-44 (AereMLDSA44Verifier). ML-DSA (Dilithium) is a module-lattice, Fiat-Shamir-with-aborts scheme. The verifier implements FIPS 204 Algorithm 8 (Verify_internal) for the smallest parameter set, ML-DSA-44 / Dilithium2: decode the public key into rho and t1; decode the signature into c-tilde, z, and the hint h (with strict HintBitUnpack validation); sample the 4x4 matrix A-hat directly in the NTT domain from rho via SHAKE128 rejection sampling; compute mu = H(H(pk) || M) and the challenge c = SampleInBall(c-tilde); form w-approx = NTT^-1(A-hat . NTT(z) - NTT(c) . NTT(t1 . 2^d)) in Z_q[x]/(x^256 + 1) with q = 8380417; apply UseHint; recompute c-tilde' and accept if it matches c-tilde and the infinity norm of z is below gamma1 - beta = 130,994. The NTT here uses a different modulus and different roots than Falcon's q = 12289, and the implementation replicates the pq-crystals/dilithium coefficient ordering so that the directly-sampled A-hat multiplies correctly against NTT(z).

3.3 Hybrid ECDSA plus Falcon-512

AereHybridAuth (0xc20390C9656ECe1AE37603c84E395bC898b3FAA1) authorizes an action only if both a secp256k1 ECDSA signature and a NIST Falcon-512 signature verify over the same 32-byte hash, with the Falcon leg delegated to the live Falcon-512 verifier at 0x4E8e9682329e646784fB3bd01430aA4bA54D8fFC. This is the conservative migration posture: an account stays as safe as classical ECDSA against today's adversaries while adding a post-quantum requirement, so that neither a broken curve nor a broken lattice alone suffices to forge. Its checkHybrid view is documented to return distinct diagnostics for a tampered Falcon leg versus a wrong ECDSA leg. The contract has no owner or admin and its registration is append-only.

3.4 Post-quantum smart account

AerePQCAccountFactory (0xd5315Ea7caa60d320c4f34b1bEd70dd9cc02CE58) is a CREATE2 factory that deploys an ERC-4337 v0.7 smart account whose sole owner is a NIST Falcon-512 public key (897 bytes), with no classical ECDSA fallback. Both the ERC-4337 validateUserOp path and the EIP-1271 isValidSignature path are decided by the live Falcon-512 verifier. A sample account owned by a real Falcon-512 key is deployed at 0xa42a5e7F72E46BadC11367650Ec34D676194326f; the signature material for its demonstrations is committed at aerenew/contracts/deployments/pqc-account.json. This turns the verifier suite from a set of read-only primitives into a wallet whose authorization is quantum-resistant end-to-end at the account layer.

4. Validation methodology: KAT and ACVP fixtures

A verifier is only as trustworthy as the vectors it is checked against. Each scheme is validated against official, externally sourced vectors, and the fixtures are committed to the repository so the claim is reproducible rather than asserted. The verification is bit-for-bit in both directions: the valid vectors must accept, and the crafted-invalid vectors (tampered message, signature component, or key) must reject with the exact accept/reject pattern the reference produces.

Falcon-512 and Falcon-1024. Vectors come from the Falcon round-3 NIST submission KAT response files. The Falcon-512 fixture aerenew/contracts/test/falcon512_kat0.json is drawn from falcon512-KAT.rsp (SHA-256 dd75c946...b5cd); vector 0 has a 33-byte message, an 897-byte public key, a 615-byte compressed signature, and a squared norm of 28,308,410 against the bound 34,034,726. The reference crypto_sign_open accepts it and the on-chain verifier returns the same. The Falcon-1024 fixture aerenew/contracts/test/falcon1024_kat0.json comes from falcon1024-KAT.rsp (SHA-256 036a0bf5...b20d), with an independent oracle (OpenSSL SHAKE256 plus schoolbook negacyclic convolution) matched bit-for-bit against the contract's assembly-keccak and NTT path.

ML-DSA-44. The fixture aerenew/contracts/test/fixtures/mldsa44-acvp-tg8.json is derived from the NIST ACVP ML-DSA-sigVer-FIPS204 vectors, test group 8 (ML-DSA-44, internal interface, externalMu = false): prompt.json SHA-256 2a9b7fcb..., expectedResults.json SHA-256 33e0ea7d.... All 15 cases (3 valid plus 12 crafted-invalid covering modified message, z, commitment, and hint) reproduce NIST's expected testPassed. A from-scratch Python FIPS 204 verifier written independently also matches all 15. The test harness is aerenew/contracts/test/mldsa44Verifier.test.js.

SLH-DSA-SHA2-128s. The fixture aerenew/contracts/test/fixtures/sphincs-sha2-128s-acvp-tg31.json is derived from the NIST ACVP SLH-DSA-sigVer-FIPS205 vectors, test group 31 (SLH-DSA-SHA2-128s, internal interface): prompt.json SHA-256 4e7beb12..., expectedResults.json SHA-256 259f5e2a.... All 14 cases (2 valid plus 12 crafted-invalid) reproduce NIST's expected results. The cross-check is instructive: a from-scratch Python FIPS 205 verifier matches 14/14, and the sphincs/sphincsplus reference C matches 14/14 only after correcting the FORS index extraction from the round-3 message_to_indices to the FIPS 205 base_2^b decoding. The unpatched reference matches only 12/14, failing exactly the two valid vectors, which isolates the single behavioral change between round-3 SPHINCS+ and FIPS 205 SLH-DSA and confirms the on-chain verifier implements the standardized form.

XMSS-SHA2_10_256. The fixture aerenew/contracts/test/fixtures/xmss-sha2_10_256-kat.json reproduces the deterministic reference vector from the XMSS reference implementation (github.com/XMSS/xmss-reference at commit 171ccbd26f098542a67eb5d2b128281c80bd71a6, test/vectors.c with oid=1, seed[i]=i, idx=2^(h-1)=512, message byte 0x25). The fed bytes reproduce the reference program's SHAKE128(., 10) known answers exactly (public-key hash 7de72d19..., signed-message hash 8b6cb278...), the reference xmss_core_sign_open accepts them, and independent from-scratch Python and JavaScript reimplementations of the RFC 8391 verify path recompute the identical root. The harness is aerenew/contracts/test/xmssVerifier.test.js.

WOTS+. Validated in aerenew/contracts/test/pqc-verifier.test.js using keys and signatures derived through the contract's own derivePublicKey helper and independent recomputation of the 67-chain structure.

The hybrid authorizer and the post-quantum account are exercised in aerenew/contracts/test/hybridAuth.test.js and the PQC-account deployment scripts, which drive the same live verifier the standalone tests use.

5. Gas versus the EIP-7825 per-transaction cap

5.1 The constraint

Fusaka's EIP-7825 caps any single transaction at 2^24 = 16,777,216 gas, regardless of how high the block gas limit is set. This is a per-transaction ceiling, so a verifier that records its result on-chain (a state-changing verifyAndRecord transaction) must complete the entire verification, plus the storage write and event emission, within 16,777,216 gas. A read-only eth_call is not a transaction and is not subject to this cap; a node can be asked to execute a view with a much higher gas allowance. The distinction is therefore precise: "records on-chain" means a full verification fits under the cap and can be mined as an L1 transaction; "view-only in pure Solidity" means the crypto is identical and callable for free via eth_call, but a state-changing verification would exceed the cap and cannot be mined.

5.2 Measured and estimated cost by scheme

The following costs are taken from the committed deployment records and test artifacts, not from projection. Recorded transactions carry a block and transaction hash in the deployment JSON; estimates are labeled as such.

Scheme	Cost	Under 16,777,216 cap?	Status	Source
WOTS+	dominated by <= 67 keccak256 chains of length <= 15	Yes	Records on-chain	pqc-verifier.test.js (structure)
XMSS-SHA2_10_256	1,561,963 gas recorded (estimate 1,575,527)	Yes	Records on-chain	deployments/xmss-verifier.json
SLH-DSA-SHA2-128s	1,812,066 gas recorded (estimate 1,827,615)	Yes	Records on-chain	deployments/sphincs-verifier.json
Falcon-512	10,492,455 gas recorded	Yes	Records on-chain	deployments/falcon-512-verifier.json
Falcon-1024	approx 21.7M gas (state-changing)	No	View-only (eth_call)	deployments/falcon-1024-verifier.json
ML-DSA-44	52,934,073 gas (local estimate)	No	View-only (eth_call)	deployments/mldsa-44-verifier.json

The two composite primitives inherit Falcon-512's cost and stay under the cap: the hybrid ECDSA-plus-Falcon-512 authorize transaction used 10,299,873 gas, and a full ERC-4337 user operation through the post-quantum account's handleOps used 10,278,313 gas. Both are recorded on-chain.

5.3 Why Falcon-1024 and ML-DSA-44 are view-only in pure Solidity

The pattern is explained by where the work is. The hash-based schemes are cheap because their cost is a bounded number of SHA-256 precompile calls (each fixed-cost) plus small Merkle walks: XMSS at 1.56M gas and SLH-DSA at 1.81M gas sit comfortably inside the cap even while recording. Falcon-512, at 10.49M gas, is dominated by SHAKE256 (implemented in-EVM, since there is no SHAKE precompile) inside HashToPoint, plus a degree-512 number-theoretic transform; it still fits under the cap. Falcon-1024 doubles the ring degree and the associated transform and SHAKE work, and a state-changing verification lands at roughly 21.7M gas, above 16,777,216. ML-DSA-44 is heavier still, at about 52.9M gas, because ExpandA rejection-samples a 4x4 matrix of degree-256 polynomials via SHAKE128 (again in-EVM) and the verifier runs many NTTs over q = 8380417. Both therefore exceed the per-transaction cap and are exposed as pure views: their verification is correct and demonstrated via eth_call against the same official vectors, but it cannot be mined as an L1 transaction in pure Solidity. This is a limitation of the execution budget, not of the cryptography, and the accept/reject behavior is identical to the recorded schemes.

6. The native-precompile path

The reason Falcon-1024 and ML-DSA-44 do not fit is almost entirely the cost of computing SHAKE and SHA-256-family sponge functions inside the EVM. Fusaka already demonstrates the fix for a different primitive: RIP-7951 exposes secp256r1 verification as a native precompile at 0x100 at a fixed cost of roughly 3,450 gas, versus roughly 250,000 gas for the same check in Solidity, a reduction of about two orders of magnitude. The same approach applied to the extendable-output functions and the lattice inner loops would move every scheme in this suite under the cap with wide margin.

That workstream is built, proven, and now live on mainnet. We forked Hyperledger Besu v26.4.0 (source tag 26.4.0, commit d2032017) and added five native precompiles that wrap the audited Bouncy Castle 1.83 BCPQC verifiers already present on the client classpath, introducing zero new dependencies and zero hand-rolled cryptography. The precompiles are exposed at 0x...0AE1 (Falcon-512), 0x...0AE2 (Falcon-1024), 0x...0AE3 (ML-DSA-44, FIPS 204 internal), 0x...0AE4 (SLH-DSA-SHA2-128s, FIPS 205 internal), and 0x...0AE5 (SHAKE256, FIPS 202). They were first validated on an isolated scratch chain (chain ID 28099) and are now LIVE on mainnet 2800: the AerePQC hard fork activated them at block 9,189,161 (2026-07-12), a coordinated client-only activation with no re-genesis, and the design is filed as a Core AIP (see aerenew/aips/AIP-7.md). All NIST KAT vectors including negatives pass. Validation runs the same official fixtures the pure-Solidity verifiers use, in both directions via eth_call: Falcon-512, Falcon-1024, and SHAKE256 pass positive and negative vectors, ML-DSA-44 reproduces all 15/15 ACVP cases (12 of them negative), and SLH-DSA-SHA2-128s reproduces all 14/14 ACVP cases (12 of them negative).

We measured real on-chain receipts on the scratch fork. A full verify-and-record transaction (the precompile verify plus a storage write and an event) has, in gasUsed: Falcon-512 86,336; Falcon-1024 145,496; ML-DSA-44 351,050; SLH-DSA-SHA2-128s 558,276; SHAKE256 21,470. The marginal gas charged by the precompile verify operation itself is Falcon-512 40,000; Falcon-1024 75,000; ML-DSA-44 55,000; SLH-DSA-SHA2-128s 350,000; and SHAKE256 60 gas base plus 12 gas per word.

Scheme	Scratch-fork precompile	Marginal verify-op gas	Full verify-and-record tx gasUsed	Share of 16,777,216 cap
SHAKE256 (FIPS 202)	0x...0AE5	60 + 12/word	21,470	0.13%
Falcon-512	0x...0AE1	40,000	86,336	0.51%
Falcon-1024	0x...0AE2	75,000	145,496	0.87%
ML-DSA-44 (FIPS 204)	0x...0AE3	55,000	351,050	2.09%
SLH-DSA-SHA2-128s (FIPS 205)	0x...0AE4	350,000	558,276	3.33%

The key result is the two schemes that were view-only in pure Solidity. Falcon-1024, roughly 21M gas and unrecordable as a pure-Solidity transaction, records on the fork in a 145,496-gas transaction, 0.87% of the 16,777,216 cap. ML-DSA-44, roughly 52.9M gas in pure Solidity, records in 351,050 gas, 2.09% of the cap. Both are now record-on-chain feasible with wide margin, and the schemes that already fit drop by more than an order of magnitude (Falcon-512 from 10.49M gas to 86,336).

We are deliberate about scope. This was first proven on an isolated scratch fork and is now LIVE on AERE mainnet chain 2800: the AerePQC hard fork activated at block 9,189,161 (2026-07-12), a coordinated client-only activation with no re-genesis and no state migration, adding precompile behavior at the previously-empty band 0x0AE1..0x0AE5. The scope boundary that remains accurate is the one in Section 7: this is application and account layer verification, not post-quantum consensus. The pure-Solidity AereFalcon1024Verifier and AereMLDSA44Verifier contracts of Section 5 are still view-only, but the Falcon-1024 and ML-DSA-44 schemes now record on-chain through the live precompiles at 0x...0AE2 and 0x...0AE3.

7. Limitations

We consider candor about weaknesses part of the contribution, because an on-chain post-quantum claim is easy to overstate.

The post-quantum property is at the application and account layer, not consensus. The verifiers, the hybrid authorizer, and the post-quantum smart account all live above consensus. AERE's validators still sign QBFT consensus messages with classical secp256k1 keys. Nothing in this paper makes consensus post-quantum, and we do not claim it does. Separately, and only on an isolated N=4 QBFT testnet, we have demonstrated a real gossiped >= 2f+1 Falcon-512 quorum certificate embedded in every block, verified by every node on import, and blocking after a fork block (a 229-block healthy run reproduced from a fresh genesis, 0 rejects; ECDSA committed seals remain the decisive seal; the block hash is byte-identical with or without the certificate; negative tests pass, including a correct post-fork halt when more than f validators present a bad Falcon seal). That is a testnet demonstration of a path to post-quantum finality, not a mainnet capability: on chain 2800 consensus is classical secp256k1 QBFT and this work does not change what mainnet validators sign.

Centralization. The network runs seven validators under a single operator, and all Ownable contracts are owned by the Foundation account (0x0243A4f47D44b40b65D33f20329dE20D00c6f3C3, a single-key Foundation-controlled account, not a deployed multisig). The verifiers themselves are ownerless and immutable, which limits the blast radius, but the chain's liveness and ordering are not decentralized today.

One client. AERE runs a single execution client (Besu). There is no client diversity, so a consensus-relevant client bug has no independent implementation to cross-check against at runtime.

No external audit yet. The verifiers are validated against official NIST KAT and ACVP vectors and cross-checked by independent from-scratch reimplementations, which is strong evidence of functional correctness, but they have not undergone a third-party security audit. KAT conformance establishes that the accept/reject decision matches the reference on the tested vectors; it does not by itself rule out implementation-level issues such as edge-case input handling or denial-of-service via malformed encodings, which an audit would target.

Thin usage. These are recently deployed primitives with limited real-world traffic. The demonstrations are genuine on-chain transactions and eth_call results, not production load.

Scheme-specific caveats. The XMSS verifier checks a signature against a given root and seed; it does not and cannot enforce the signer's one-time-per-leaf state, so signing security still depends on the off-chain signer never reusing a leaf index. Only the smallest parameter sets are implemented for ML-DSA (44 only) and SLH-DSA (SHA2-128s only); the larger sets and the SHAKE instantiations are not on-chain, and only the internal interfaces are verified, not the external-context or pre-hash wrappers. Falcon-1024 and ML-DSA-44 remain view-only in pure Solidity as described above. The AereLatticeVerifier core is a reduced-degree (n=64) demonstration and is not a spec-complete scheme.

8. Conclusion

AERE runs, on a live EVM Layer-1, a suite of post-quantum signature verifiers covering both families NIST is standardizing: the hash-based WOTS+, XMSS, and SLH-DSA-SHA2-128s, and the lattice-based Falcon-512, Falcon-1024, and ML-DSA-44. Each is validated bit-for-bit against official KAT or ACVP vectors that are committed to the repository, and four of the six record a full verification on-chain within the Fusaka EIP-7825 per-transaction gas cap of 16,777,216, while Falcon-1024 and ML-DSA-44 are verifiable today as read-only views whose only obstacle is the execution budget, an obstacle that a native precompile, now LIVE on AERE mainnet chain 2800 since block 9,189,161 (2026-07-12, the AerePQC hard fork; see AIP-7), removes (a full Falcon-1024 verify-and-record transaction uses 145,496 gas and ML-DSA-44 uses 351,050 gas, 0.87% and 2.09% of the cap). On top of these primitives sit a hybrid classical-plus-Falcon authorizer and a Falcon-512-owned ERC-4337 smart account, both recording on-chain. We have been explicit that this is application-layer and account-layer security, that consensus remains classical, and that the network is small, single-client, and not yet externally audited. With those caveats stated honestly, and to the best of our present knowledge, we are not aware of any other public chain that verifies all of these on-chain.

Appendix A: Live address registry (chain 2800)

All addresses copied verbatim from aerenew/sdk-js/src/addresses.ts.

• AerePQCVerifier (WOTS+): 0x1cE2949e8cE3f1A77b178aF767a4455c08ec6F82
• AereLatticeVerifier (n=64 demo core): 0x60c06E6A3CC201B46A16650be096C6E45424dfD9
• AereFalcon512Verifier: 0x4E8e9682329e646784fB3bd01430aA4bA54D8fFC
• AereFalcon1024Verifier: 0xF0aFA59BaB2058e4B6e6B424b7f76750F1F66e36
• AereXmssVerifier: 0x77b14E264D0bb08d304d4e0E527F0fCdFc88B112
• AereMLDSA44Verifier: 0xf1F7A6Acd82D5DAf9AF3166a2F736EE52C5F85AE
• AereSphincsVerifier: 0xAfFc9F8d950969b46b54e77758BbFf7e000c87e6
• AereHybridAuth: 0xc20390C9656ECe1AE37603c84E395bC898b3FAA1
• AerePQCAccountFactory: 0xd5315Ea7caa60d320c4f34b1bEd70dd9cc02CE58
• AerePQCAccount (sample): 0xa42a5e7F72E46BadC11367650Ec34D676194326f
• Foundation (owner of Ownable contracts): 0x0243A4f47D44b40b65D33f20329dE20D00c6f3C3 (single-key Foundation-controlled account, not a deployed multisig)

Native PQC precompiles, live on mainnet 2800 since block 9,189,161 (the AerePQC hard fork; see aerenew/aips/AIP-7.md):

• Falcon-512: 0x0000000000000000000000000000000000000AE1
• Falcon-1024: 0x0000000000000000000000000000000000000AE2
• ML-DSA-44 (FIPS 204 internal): 0x0000000000000000000000000000000000000AE3
• SLH-DSA-SHA2-128s (FIPS 205 internal): 0x0000000000000000000000000000000000000AE4
• SHAKE256 (FIPS 202): 0x0000000000000000000000000000000000000AE5
• AerePQCAttestation (records verifications through the precompiles): 0x465d9E3b476BF98Aa1393079e240Db5D2a9bEA6A

Appendix B: Committed validation fixtures

• aerenew/contracts/test/falcon512_kat0.json (Falcon round-3 falcon512-KAT.rsp, SHA-256 dd75c946...b5cd)
• aerenew/contracts/test/falcon1024_kat0.json (Falcon round-3 falcon1024-KAT.rsp, SHA-256 036a0bf5...b20d)
• aerenew/contracts/test/fixtures/xmss-sha2_10_256-kat.json (xmss-reference @ 171ccbd)
• aerenew/contracts/test/fixtures/mldsa44-acvp-tg8.json (NIST ACVP ML-DSA-sigVer-FIPS204, TG8)
• aerenew/contracts/test/fixtures/sphincs-sha2-128s-acvp-tg31.json (NIST ACVP SLH-DSA-sigVer-FIPS205, TG31)
• Test harnesses: aerenew/contracts/test/pqc-verifier.test.js, xmssVerifier.test.js, mldsa44Verifier.test.js, hybridAuth.test.js
• Deployment records with recorded gas and transaction hashes: aerenew/contracts/deployments/falcon-512-verifier.json, falcon-1024-verifier.json, xmss-verifier.json, mldsa-44-verifier.json, sphincs-verifier.json, pqc-verifier.json, pqc-account.json