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

None.

5.2 KiB Raw Blame History