# Spec 4: Aere Network Post-Quantum Finality Certificate

Built the flagship ADDITIVE post-quantum finality feature: one succinct proof that a quorum of
Aere validators attested to a finalized block with HASH-BASED (post-quantum) keys, verifiable
on-chain in ONE call, WITHOUT changing QBFT consensus and WITHOUT a re-genesis.

## Deliverables (all new, no deployed contract modified)

1. `aerenew/contracts/contracts/pqfinality/AerePQAttestationKeyRegistry.sol`
   - Per-validator hash-based attestation public key (XMSS / WOTS+ / leanSig / SLH-DSA / XMSS^MT),
     SEPARATE from the ECDSA consensus key. This is the PQ finality key.
   - Maps validator -> current key + monotonic keyEpoch. One-time/few-time keys rotate: registering
     again appends a new record, marks predecessor superseded, bumps epoch. Append-only history,
     fail-closed, no silent rewrite.
   - Governed membership (Ownable enrollValidator = the N=7 set + root ordering), self-custodied
     keys (validator registers its OWN key; owner cannot forge it).
   - Deterministic `validatorSetRoot()` = keccak over (validator, keyEpoch, keyHash) leaves in
     enrollment order. Any rotation changes the root.

2. `aerenew/contracts/contracts/pqfinality/AereFinalityCertificateVerifier.sol`
   - Verifies ONE SP1 proof via the live gateway (0x9ca479C8...70628), pinned PROGRAM_VKEY.
   - Public values (192 bytes): blockHash, blockHeight, validatorSetRoot, validatorSetSize,
     quorumCount, attestationDomain.
   - Fail-closed: binds root+size to the LIVE registry, binds attestationDomain (chainId+registry),
     requires quorumCount >= ceil(2N/3) = 5 of 7, rejects zero block, then one verifyProof (reverts
     on bad proof). Cost independent of N.
   - `isFinalPQ(blockHash)` consumer gate + `recordCertificate` + `assertFinalizes(claimedBlock)`
     for bridges confirming a specific block.

3. `aerenew/contracts/test/AerePQFinalityCertificate.test.js` - 12 passing (MockSp1Verifier).
   Covers all required cases: 7-validator set registers (threshold 5); valid quorum-5 cert records +
   isFinalPQ true; below-quorum rejects; wrong root rejects; wrong block/height/zero-block rejects;
   invalid proof fail-closed; key rotation changes root and old-root cert no longer matches; empty
   set fails closed; append-only + owner-gated enroll + self-register.

4. `aerenew/docs/AERE-PQ-FINALITY-CERTIFICATE.md` - architecture (dual-sign ECDSA+hash-based,
   off-chain zkVM aggregates into one STARK/SP1 proof, on-chain one verify), why additive (no flip,
   no re-genesis), quantum-safety argument (hash-based sigs + hash-based FRI STARK are Shor-
   resistant vs classical ECDSA seals + BN254 Groth16), consumer use cases (light client/bridge/
   L2/AI agent), live-first framing (ships ahead of Ethereum Lean Consensus ~2027 because N small),
   honest [MEASURE] status.

## REAL test result
`npx hardhat test test/AerePQFinalityCertificate.test.js` from aerenew/contracts: 12 passing (2s),
0 failing. Contracts compile under solc 0.8.23 (repo config).

## Honesty flags
- [MEASURE] / NOT implemented: the off-chain XMSS/leanSig aggregation zkVM guest circuit (verify N
  hash-based sigs against the root inside the zkVM, emit public values). Novel research. leanSig or
  XMSS-in-zkVM is the target; ML-DSA-in-zkVM is a lattice alternative (loses the hash-only argument).
- On-chain verifier + registry are REAL and tested against a MOCK SP1 gateway. NOT proven end-to-end.
  Do NOT claim PQ finality is live.
- [VERIFY]/design-only: the Shor-resistant end-to-end claim holds for a NATIVE hash-based STARK proof;
  a Groth16 wrap would reintroduce a BN254 leg. Stated in the doc.
- Scope boundary kept: base QBFT consensus is STILL classical ECDSA. This is additive attestation ON
  TOP; it never flips or gates consensus and is not live.