AIP-13: Post-Quantum Signatures: Falcon and ML-DSA Together, not a Single Lattice Family

Note added 2026-10-27 (consensus). Where this document says that consensus remains classical (validators sign secp256k1 QBFT), read it as the statement it was until block 24,300,000 (AIP-22 stage 4, 2026-10-25). Since that block every validator attributes a consensus vote only through its verified post-quantum seal, and a commit still carries the ECDSA commit seal of its validator as an additional check; headers are still admitted on their ECDSA commit seals until AIP-22 stage 5, and Aere does not claim post-quantum consensus. The decision this document records, two lattice families plus hash-based schemes, is unchanged.

Note added 2026-10-28 (to the note above). The note above ends the statement that consensus remains classical at block 24,300,000, but post-quantum layers were already part of consensus before that block, each dated in AIP-22: since 2026-08-14 every anchor block must carry a certificate of validator post-quantum seals under its hash, and since 2026-09-05 (block 17,250,000) the Besu-derived validators (nine of the ten since 2026-09-11) refuse a commit without a valid Falcon-512 seal of its author, and since 2026-09-08 (block 17,700,000) any consensus message without one, while the second client enforced that seal on commit messages only until block 24,300,000 (the dates in this clause corrected later on 2026-10-28: it dated the refusal of every message type to 2026-09-05, the date of the commit layer alone). Read that statement as the per-block statement it was on the date of this document. That validators sign secp256k1 in QBFT is still true after block 24,300,000: every commit carries the ECDSA commit seal of its validator, as an additional check, and every consensus message the ECDSA envelope of the wire format, while a vote is attributed only through its verified post-quantum seal.

Preamble

Field	Value
AIP	13
Title	Post-Quantum Signatures: Falcon and ML-DSA Together, not a Single Lattice Family
Author	Aere Network Foundation
Type	Informational
Category	(none)
Status	Final
Created	2026-07-19
Requires	4, 7
Supersedes	None
Superseded-By	None
Ratification	Foundation-ratified (pre-decentralization)

Abstract

This AIP records the decision to support multiple post-quantum signature schemes across two distinct lattice families (Falcon and ML-DSA) plus hash-based schemes, rather than standardizing on one. It backfills a decision already live on chain 2800. The normative mechanism is in AIP-4 (contract suite) and AIP-7 (precompile activation); this record captures the decision framing.

Motivation

Aere verifies post-quantum signatures on-chain at both the contract layer (AIP-4) and, since block 9,189,161, the native precompile layer (AIP-7). A choice of scheme family is a bet on a mathematical assumption, and betting on one is a single point of cryptographic failure.

Specification

Supported families:

Falcon (Falcon-512, Falcon-1024): NTRU lattices.
ML-DSA (Dilithium2 / ML-DSA-44): module lattices with Fiat-Shamir-with-aborts.
Hash-based: SLH-DSA, XMSS, WOTS+.

Live mainnet precompiles occupy 0x0AE1..0x0AE5: Falcon-512 0x0AE1, Falcon-1024 0x0AE2, ML-DSA-44 0x0AE3, SLH-DSA-SHA2-128s 0x0AE4, SHAKE256 0x0AE5 (measured, live from block 9,189,161). 0x0AE6 (ML-KEM-768) and 0x0AE7 (Falcon HashToPoint) are testnet-only and not live on chain 2800.

Rationale

Cryptographic-risk diversification. Supporting both lattice families means a cryptanalytic break or a standardization flaw in one does not, by itself, remove Aere's ability to verify post-quantum signatures: accounts and settlement authorization can migrate to the surviving family. This mirrors the hybrid AereHybridAuth account, which requires both a classical ECDSA and a Falcon-512 signature, so that neither a broken curve nor a broken lattice alone suffices to forge.

Alternatives rejected. Standardizing on a single lattice scheme (ML-DSA alone as the NIST primary, or Falcon alone for its compact signatures). The cost of supporting several schemes is more verifier surface to implement, validate, and eventually audit; that cost is accepted deliberately rather than betting the network's post-quantum future on a single assumption.

Backwards Compatibility

None. Additive.

Security Considerations

Scope boundary (binding). This is post-quantum at the signature, account and application layer only. Consensus remains classical: validators sign secp256k1 QBFT. The zk verification path is also classical (BN254 Groth16, Shor-breakable). Aere never claims post-quantum consensus.

The verifiers and precompiles carry an internal self-audit only. An external audit is pending before they should secure material value. Their assurance today rests on bit-for-bit agreement with official NIST KAT and ACVP vectors and on cross-checks against independent reimplementations.

Reference Implementation and On-Chain Deployment

Contract suite: AIP-4. Precompile activation and addresses: AIP-7. Chain ID 2800.

Errata

Erratum 1 (2026-10-30). The Security Considerations describe consensus as classical, with validators signing secp256k1 QBFT, and say that Aere never claims post-quantum consensus. For when the first held, see the notes of 2026-10-27 and 2026-10-28 at the top of this document, which date it; that validators sign secp256k1 in QBFT stays true, since every commit carries the ECDSA commit seal of its validator as an additional check. Since block 25,080,000 (AIP-22 stage 5) headers no longer carry ECDSA commit seals, each carrying the Falcon-512 seal of its proposer instead, and, since block 24,300,000 (AIP-22 stage 4), every vote counts only with the verified post-quantum seal of its author, and a commit still carries the ECDSA commit seal of its validator as an additional check, which Aere calls post-quantum consensus, with three limits: the transport between nodes is still authenticated by secp256k1, the ten validators are run by one operator, and no third party has audited it yet. The statement that Aere never claims post-quantum consensus, and what the note of 2026-10-27 says about the headers, describe chain 2800 below block 25,080,000. The decision this AIP records, two lattice families plus hash-based schemes, is unchanged. The original text is left exactly as published, per AIP-1 section 5.

6.5 KiB Raw Blame History