# 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.

## Copyright

Released to the public domain (CC0). No rights reserved.