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

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

Note added 2026-08-19. Statements in this document that consensus on chain 2800 is (or remains) classical secp256k1 ECDSA QBFT were written before the post-quantum header anchor went live, and remain true for block-by-block finality. Since block 13,014,000 every 32nd block also carries, under its block hash, a certificate of validator Falcon-512 seals, and since block 13,034,000 a node rejects such an anchor block with fewer than three valid seals (f+1 of nine; eight or nine are carried in practice). That is a post-quantum checkpoint about every 16 seconds, not a per-block quorum: the claim published on 2026-08-15 that from block 14,050,000 no block finalizes without a post-quantum quorum was wrong (the per-block rule armed at that height is retired in the shipped code in favour of the anchor rules) and was withdrawn on 2026-08-19. Details: https://aere.network/quantum.html and the aere-node repository, anchor/README.md.

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. We are equally explicit about priority: AERE is not the first public chain to verify a post-quantum signature on-chain. Algorand shipped a native Falcon-1024 verifier roughly ten months earlier and places Falcon inside its own state proofs, deeper than AERE places it; Section 8 gives that prior art with sources and dates, and Section 9 states what remains of our claim.

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 aere-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 aere-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 aere-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 aere-contracts/test/mldsa44Verifier.test.js.

SLH-DSA-SHA2-128s. The fixture aere-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 aere-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 aere-contracts/test/xmssVerifier.test.js.

WOTS+. Validated in aere-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 aere-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 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 aere-research/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. Related work: post-quantum signature verification on other public chains

An earlier revision of this paper carried no related-work section at all, and closed on a sentence about what we were "not aware of". A novelty claim with no prior art behind it is not a modest claim, it is an unmeasured one: it reports the state of our attention rather than the state of the field. This section is that measurement. It is written against primary sources a reader can open, and it concedes the places where another chain arrived first, or placed the same primitive deeper in the stack than we have.

8.1 Algorand

Algorand is the most important prior art for this paper, and it precedes AERE on both axes this paper cares about.

Falcon inside consensus, through State Proofs. Algorand's state proofs are built on a Merkle signature scheme whose leaf signer is Falcon. In algorand/go-algorand, the file crypto/merklesignature/committablePublicKeys.go declares its key material with the concrete types crypto.FalconSigner and crypto.FalconVerifier. That places a Falcon signature inside Algorand's own protocol-level attestation of chain history, which is a strictly deeper placement than anything AERE has on mainnet. As Section 7 states, AERE's consensus signatures are classical secp256k1 and nothing in this paper changes that. Source: https://github.com/algorand/go-algorand/blob/master/crypto/merklesignature/committablePublicKeys.go. [VERIFY: the consensus version and mainnet activation date of Algorand state proofs are NOT MEASURED here. What is measured is only the present source-level use of Falcon types in that scheme.]

Falcon-1024 as a native AVM opcode. Algorand exposes falcon_verify, opcode 133 (0x85), introduced in AVM version 12. Read from the canonical language specification data/transactions/logic/langspec_v12.json in algorand/go-algorand, it takes data, a deterministic Falcon-1024 compressed-format signature of variable length up to 1423 bytes, and a 1793-byte public key; it returns a boolean and costs 1700. The same opcode is absent from langspec_v11.json, which is the positive confirmation that v12 is where it lands rather than an inference from its presence alone. Sources: https://github.com/algorand/go-algorand/blob/master/data/transactions/logic/langspec_v12.json and https://github.com/algorand/go-algorand/blob/master/data/transactions/logic/langspec_v11.json.

The dating carries the whole of the claim, so it is given in full. The opcode was proposed in algorand/go-algorand PR #5599, "AVM: Adding sumhash and falcon_verify", opened 2023-07-24 and merged 2024-01-05. It was wired into a shipping AVM version by PR #6416, "AVM: Prepare for falcon_verify in v12", merged 2025-08-21. Consensus version v41, which sets LogicSigVersion = 12, was merged as PR #6422 on 2025-08-26, and the notes on the accompanying release PR #6423 for go-algorand 4.3.0-beta state that v41 "enables the falcon_verify opcode". The 4.3.0-stable release PR #6437 merged 2025-09-10. AERE's own precompiles activated at block 9,189,161, timestamp 2026-07-12T01:37:52Z. Taking the latest and most conservative of the Algorand dates, a stable release carrying the opcode preceded AERE's activation by roughly ten months. [VERIFY: the exact Algorand mainnet round and date on which consensus v41 became effective is NOT MEASURED here. The ordering above rests on merge and release dates in the source repository, which bound the question from one side only; they cannot be later than mainnet activation, so the ordering conclusion survives, but the interval does not.]

What is left of AERE's contribution, stated narrowly. Algorand's falcon_verify covers one scheme, Falcon-1024, in a deterministic Falcon variant rather than the randomized NIST round-3 submission whose KAT response files this paper validates against (Section 4). It is an AVM opcode, so it is not reachable from Solidity and does not compose with the ERC-4337 and EIP-1271 surfaces of Section 3. Separately, the pure-Solidity verifiers of Section 3 are a different kind of artifact from any native opcode: they are ordinary contract bytecode, so a reader can audit the verification logic itself on-chain without trusting a client binary or a hard-fork process. Those are real distinctions, and none of them is priority. We do not claim priority for Falcon verification on a public chain, and this paper should not be read as claiming it.

8.2 The scope of this survey, and what it does not cover

This section is not a complete survey of post-quantum verification across public chains, and it should not be read as one. It covers Algorand because Algorand is the case where we were measurably wrong to say nothing. Other chains and projects with post-quantum signature work, including but not limited to the Quantum Resistant Ledger, Abelian, and the post-quantum direction of Ethereum research, are NOT MEASURED in this document. Their absence below is an absence of measurement on our part, not evidence that nothing exists there. [VERIFY: a systematic prior-art survey across public chains has not been performed. Until it is, the only safe reading of any comparative sentence in this paper is the narrow one given in Section 9.]

9. 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, the narrowest defensible comparative statement is this, and we make no wider one. We are not the first public chain to verify a post-quantum signature on-chain, and we do not claim to be. Algorand shipped a native Falcon-1024 verifier, the falcon_verify AVM opcode, in a stable release roughly ten months before AERE's precompiles activated, and places Falcon deeper in the stack than AERE does, inside the state proofs that attest its own chain history, where AERE's consensus remains classical secp256k1. Section 8 sets out that prior art with its sources and dates. What we have not found another chain doing is verifying all six of these schemes on-chain, across both the hash-based and lattice families, from EVM contract bytecode that a reader can audit directly; and Section 8.2 records honestly that a systematic survey behind even that narrower sentence has not been performed.

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 aere-research/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

• aere-contracts/test/falcon512_kat0.json (Falcon round-3 falcon512-KAT.rsp, SHA-256 dd75c946...b5cd)
• aere-contracts/test/falcon1024_kat0.json (Falcon round-3 falcon1024-KAT.rsp, SHA-256 036a0bf5...b20d)
• aere-contracts/test/fixtures/xmss-sha2_10_256-kat.json (xmss-reference @ 171ccbd)
• aere-contracts/test/fixtures/mldsa44-acvp-tg8.json (NIST ACVP ML-DSA-sigVer-FIPS204, TG8)
• aere-contracts/test/fixtures/sphincs-sha2-128s-acvp-tg31.json (NIST ACVP SLH-DSA-sigVer-FIPS205, TG31)
• Test harnesses: aere-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