aere-docs/AERE-PQ-FINALITY-CERTIFICATE.md

Aere Network Post-Quantum Finality Certificate

Status: on-chain certificate verifier and attestation-key registry BUILT and TESTED against a mock SP1 gateway. The off-chain XMSS / leanSig aggregation zkVM circuit is NOT implemented, [MEASURE], and is novel research-frontier work.

Scope: ADDITIVE post-quantum finality attestation. This changes nothing about Aere Network consensus, which stays classical ECDSA QBFT. Validators keep signing ECDSA committed seals for consensus and ALSO sign a hash-based attestation over each finalized block. The certificate proves the second, additive quorum. It does not replace, gate, or flip consensus, it needs no re-genesis, and PQ finality is not live. Aere consensus is not post-quantum, and nothing here claims it is.

Contracts:

• contracts/contracts/pqfinality/AerePQAttestationKeyRegistry.sol
• contracts/contracts/pqfinality/AereFinalityCertificateVerifier.sol
• Test: contracts/test/AerePQFinalityCertificate.test.js (12 passing)

---

1. What a Post-Quantum Finality Certificate is

A Post-Quantum Finality Certificate is ONE succinct proof that a quorum of Aere Network validators attested to a finalized block using their HASH-BASED (post-quantum) attestation keys. Anyone, a light client, a bridge, an L2, or an AI agent, can verify with a SINGLE on-chain verifyProof call, at a cost independent of the validator count N, that an Aere block reached post-quantum finality, WITHOUT trusting the classical ECDSA seals and WITHOUT any change to the base QBFT consensus.

The certificate is what a relying party checks when it wants a finality signal that survives a quantum adversary. The classical path (the ECDSA committed-seal quorum, proven by AereZkQbftLightClient) is trust-minimized but NOT quantum-safe: the seals are secp256k1 ECDSA, and the Groth16 wrap is over BN254, both Shor-breakable. The certificate is the additive, quantum-durable finality signal layered on top of the same live blocks.

---

2. Architecture: validators dual-sign, a zkVM aggregates, one on-chain verify

2.1 Validators dual-sign every finalized block

Each Aere validator holds two independent keys:

• an ECDSA (secp256k1) CONSENSUS key, used exactly as today to sign the QBFT committed seal that finalizes a block. This is unchanged. Consensus is untouched.
• a HASH-BASED ATTESTATION key (Winternitz-XMSS / leanSig style), registered in AerePQAttestationKeyRegistry, used ONLY to sign an additive post-quantum attestation over each finalized block.

The attestation message is domain-bound so it cannot be replayed to another chain or purpose: msg = keccak256(abi.encode(attestationDomain, blockHash, blockHeight)), where attestationDomain = keccak256(DOMAIN_PREFIX, chainId, registry). Because the ECDSA seal and the hash-based attestation are separate signatures over separate keys, a quantum adversary that can forge ECDSA still cannot forge the hash-based leg.

Hash-based signatures (XMSS, WOTS+, leanSig, SLH-DSA) are ONE-TIME or FEW-TIME: a given key can sign only a bounded number of messages before its security degrades. The registry therefore treats attestation keys as ROTATING: each validator advances a monotonic keyEpoch as it registers a successor key, and the append-only history retains every key ever used.

2.2 The off-chain zkVM aggregates the quorum into one proof ([MEASURE])

An off-chain aggregator collects the validators' hash-based attestations for a finalized block and runs an aggregation guest program inside a zkVM (the SP1 zkVM in the reference design) with:

• PRIVATE witness: the enrolled validators' attestation public keys, and the hash-based signatures over the domain-bound block message.
• The circuit MUST, inside the zkVM:
  1. recompute the validatorSetRoot from the witnessed keys and their epochs (and abort if it does not match the committed root),
  2. verify each counted attestation as a valid hash-based signature against a DISTINCT committed key over msg,
  3. never double-count a validator,
  4. count the DISTINCT valid attestations and require the count to reach ceil(2N/3),
  5. output the public values below.
• PUBLIC output (the fixed 192-byte layout the on-chain verifier decodes): abi.encode(bytes32 blockHash, uint256 blockHeight, bytes32 validatorSetRoot, uint256 validatorSetSize, uint256 quorumCount, bytes32 attestationDomain).

The proof is succinct: its size and its on-chain verification cost are fixed by the SP1 verifier, independent of N and of how many attestations the circuit checked internally.

THIS CIRCUIT IS NOT IMPLEMENTED IN THIS REPOSITORY. It is real, novel cryptographic engineering and is the [MEASURE] research component. See Section 6.

2.3 The on-chain half verifies one proof (BUILT and TESTED)

AerePQAttestationKeyRegistry:

• The owner (Aere Foundation, later the Timelock) enrolls the validator addresses that count toward the quorum, mirroring how QBFT consensus enrollment is curated off-chain via the Foundation Ledger and QBFT extraData. Enrollment fixes each validator's position in the root ordering.
• Each validator registers its OWN hash-based attestation key (the owner cannot forge a validator's PQ key). Rotation is the same call again: it appends a new record, marks the predecessor superseded, and advances the key-epoch. Append-only, fail-closed, no silent rewrite.
• validatorSetRoot() is a deterministic commitment to the current set and their current keys: leaf_i = keccak256(abi.encode(validator_i, keyEpoch_i, keyHash_i)), and root = keccak256(abi.encode(leaf_0, ..., leaf_{N-1})) in enrollment order. Any rotation bumps an epoch and changes a key hash, so the root changes, and a certificate proven against the old root stops matching automatically. A Merkle tree is a drop-in alternative if inclusion proofs are wanted; a flat commitment suffices because the circuit witnesses the whole set.

AereFinalityCertificateVerifier:

• verifyCertificate(publicValues, proof) binds the proof's public values to the LIVE registry (current root and size), enforces the quorum threshold, and makes a SINGLE verifyProof call to the deployed SP1 gateway. It is fail-closed: it rejects unless ALL hold:
  • the registry validator set is non-empty,
  • publicValues.validatorSetRoot == registry.validatorSetRoot() (a rotation invalidates old certificates),
  • publicValues.validatorSetSize == registry.validatorCount(),
  • publicValues.attestationDomain == attestationDomain (blocks cross-chain / cross-purpose replay),
  • publicValues.quorumCount >= ceil(2N/3),
  • publicValues.blockHash != 0,
  • the SP1 proof verifies against the pinned circuit vkey (verifyProof REVERTS on an invalid proof).
• assertFinalizes(claimedBlockHash, claimedHeight, publicValues, proof) additionally requires the proof to finalize EXACTLY the claimed block, so a certificate for a different block cannot be substituted. This is the call a bridge uses when releasing funds for a specific block.
• recordCertificate(publicValues, proof) verifies (strict) and records the certificate keyed by block hash. isFinalPQ(blockHash) then returns true, which is the gate a consumer contract checks. Recording is permissionless: any prover can submit a valid certificate.

The circuit is pinned. PROGRAM_VKEY is fixed at construction, so no caller can substitute a different circuit. The deployed SP1 verifier gateway on Aere Network mainnet (chain 2800) is the canonical Succinct gateway at 0x9ca479C8c52C0EbB4599319a36a5a017BCC70628, the same gateway the parallel-execution validity contracts and the zk light clients already call.

---

3. Why it is additive: no consensus flip, no re-genesis

The certificate reads the chain; it does not change how the chain is produced.

• No consensus change. Block production and finalization remain Besu QBFT over classical ECDSA committed seals. The certificate is computed from an ADDITIONAL signature validators produce off the hot path. If the aggregator is down, or no certificate is ever produced, consensus is unaffected: blocks still finalize on ECDSA exactly as today. The certificate is "permissionless but not automatic", the same property the zk light clients already have.
• No re-genesis. The attestation keys live in an ordinary contract, and the certificate is verified by an ordinary contract. Adding this feature is a contract deployment plus validators registering keys. It touches no genesis state and no client fork rule. This is a strictly weaker requirement than the blocking hybrid consensus path (which the in-place activation work showed can itself now be armed WITHOUT a re-genesis via a contract-anchored fork activation; the certificate needs even less, because it never gates a block).
• Separation of concerns. The blocking hybrid ECDSA-plus-Falcon consensus path (formally proven no-worse-than-ECDSA in aerenew/formal-consensus/falcon_hybrid_dualquorum_smt.py, with in-place activation proven in the PQ-INPLACE-ACTIVATION work) makes CONSENSUS itself refuse a block without a post-quantum quorum. The certificate is the READ side: it lets external parties verify a post-quantum finality quorum without waiting for, or depending on, the consensus flip. The two compose: a chain running the blocking hybrid can ALSO emit certificates, and a chain not yet running it can emit certificates today as an attestation-only signal.

---

4. The quantum-safety argument

The certificate is Shor-resistant end to end, which is precisely what the classical finality path is not.

• The attestation legs are HASH-BASED signatures. XMSS, WOTS+, leanSig, and SLH-DSA derive their security from the collision and preimage resistance of a hash function ALONE. There is no lattice and no discrete-log assumption. Grover's algorithm gives at most a square-root speedup against a hash, which is answered by doubling the output size; there is no known quantum attack that breaks a well-parameterized hash-based signature. This is the most conservative post-quantum assumption available, weaker than the lattice assumptions behind Falcon or ML-DSA.
• The aggregation proof is a HASH-BASED STARK. Its soundness rests on hashing, not on pairings, so the proof itself is Shor-resistant. (Scope note, 2026-07-19 finding: the underlying zkVM proof systems are hash-based, but the pinned SP1 6.1.0 is a Hypercube / BaseFold multilinear system, not a FRI-based STARK; the hash-based hence Shor-resistant reasoning is unchanged, only the "FRI" label is corrected. The on-chain BabyBear + FRI verifier skeleton at 0x0AE8 verifies Aere's OWN Plonky3 aggregation STARK, not an SP1 6.1.0 proof.) This is the crucial difference from a Groth16 SNARK over BN254: BN254 pairings are Shor-breakable (Assumption A-9 in the engineering security spec is explicit that the BN254 verifiers stand only until a hash-based STARK verifier replaces them). A certificate whose proof is a native STARK does not carry a classical cryptographic leg.

Contrast with the classical path. AereZkQbftLightClient proves the ECDSA committed-seal quorum; the seals are secp256k1 (Shor-breakable) and the on-chain proof is Groth16 over BN254 (Shor- breakable). Under a cryptographically-relevant quantum adversary, that path offers no guarantee. The certificate is designed so that neither the attestation nor the proof has that weakness.

HONESTY on this claim. The quantum-safety property is a property of the DESIGN and of the [MEASURE] circuit ONCE IT IS REAL. The on-chain contract alone does not establish it: today the contract is verified against a mock gateway, and if the certificate were wrapped to Groth16 (an SP1 option) instead of proven as a native STARK, it would reintroduce a BN254 leg and lose the end-to-end property. The Shor-resistant claim holds only for a native hash-based STARK proof over a correctly implemented hash-based aggregation circuit. The direct hash-based STARK verifier on Aere (the AerePQStarkVerifier line of work) is the on-chain counterpart that keeps even the proof verification quantum-safe.

---

5. Consumer use cases

The certificate is a finality oracle a relying party gates on. In every case the consumer calls isFinalPQ(blockHash) (or assertFinalizes for a specific block) and acts only on a recorded, proof-backed post-quantum quorum.

• LIGHT CLIENT. A trust-minimized client of Aere finality that wants a quantum-durable signal advances its view only on certificates, so its finality assumption reduces to "a quorum of Aere validators held their hash-based keys", with no dependence on ECDSA or BN254 staying unbroken.
• BRIDGE. A bridge out of Aere releases funds for block X only after assertFinalizes(X, ...) succeeds, so a future quantum adversary that forges the ECDSA seals still cannot forge a finality certificate and cannot trick the bridge into releasing against a non-final block.
• L2 / ROLLUP. An L2 that settles to Aere, or reads Aere as a data or finality layer, gates its own state transitions on the post-quantum certificate, inheriting Aere finality without inheriting its classical cryptographic assumptions.
• AI AGENT. An autonomous agent that acts on Aere state (an x402 / AERE402 settlement agent, a treasury bot) checks isFinalPQ before treating a payment or state change as settled, so its actions rest on a quantum-safe finality signal rather than on a classical seal it cannot itself audit.

The on-chain verification cost is independent of the validator count N: the verifier does no per-validator work, it compares six words of public values against the registry and makes one verifyProof call. A larger validator set does not raise the consumer's gas.

---

6. Honest status and the research frontier

BUILT and TESTED (this repository):

• AerePQAttestationKeyRegistry.sol: governed validator enrollment, self-custodied per-validator hash-based attestation keys, append-only key history with monotonic key-epochs and rotation, a deterministic validatorSetRoot, and fail-closed views.
• AereFinalityCertificateVerifier.sol: the public-input binding scheme, the ceil(2N/3) quorum threshold, fail-closed strict / non-reverting / claimed-block verification, permissionless certificate recording, and the isFinalPQ consumer gate. The pinned circuit vkey and the domain binding are fixed at construction.
• 12 passing Hardhat tests against MockSp1Verifier, the same deployed-gateway test double used by AerePQAggregate and the zk light clients. Its verifyProof REVERTS on an invalid proof, so the fail-closed path is exercised exactly as against the production gateway. Tests cover: a 7-validator set with hash-based keys registers and the quorum threshold is 5; a valid certificate with quorum 5 records and isFinalPQ returns true; a below-quorum certificate rejects; a wrong validator-set root, wrong size, and wrong domain reject; a wrong block (and wrong height, and zero block hash) rejects; an invalid proof rejects fail-closed; key rotation changes the set root and an old-root certificate no longer matches while a fresh one records; and an empty validator set fails closed.

NOT implemented, [MEASURE], research frontier:

• The OFF-CHAIN XMSS / leanSig aggregation zkVM guest circuit. Verifying N hash-based signatures against the validator-set root inside a zkVM and emitting the public values is real, NOVEL cryptographic engineering that is NOT in this repository. The on-chain verifier is proven against a mock gateway that asserts the bound public values; a real end-to-end system additionally needs the real circuit and a real SP1 proof.
• Which hash-based scheme is the tractable first target is itself a research question. Stateful XMSS verification is hash-heavy but has no floating point, which is friendlier to a zkVM than Falcon's FFT and Gaussian sampling. leanSig (the hash-based signature line behind Ethereum's Lean Consensus direction) is designed for exactly this aggregation setting and is the natural target. An ML-DSA-in-zkVM approach (integer arithmetic, FIPS 204) is a lattice alternative that trades the most-conservative hash-only assumption for an easier circuit; it is a valid target but is not hash-based, so it does not carry the hash-only quantum-safety argument of Section 4.
• The real end-to-end proving cost and latency, and the real-gateway on-chain verify gas, are [MEASURE] and depend on the circuit implementation and the proof system (native STARK vs Groth16 wrap).

LIVE-FIRST framing. Aere Network can ship this ahead of Ethereum's Lean Consensus (targeted around 2027) precisely BECAUSE N is small. With a 7-validator set the aggregation circuit verifies at most 7 hash-based signatures per certificate, a tractable proving workload, whereas Ethereum's hundreds of thousands of validators make the same aggregation a far larger circuit and a longer research runway. The small validator set that makes Aere's honest-quorum premise an operator assumption is the SAME property that makes post-quantum finality aggregation buildable now. This is stated as a capability of the design, not a claim that the [MEASURE] circuit is finished.

Do NOT claim the certificate works end-to-end, and do NOT imply Aere consensus is post-quantum. The claim this repository supports: the on-chain certificate verifier and the attestation-key registry are built, fail-closed, and tested against a mock gateway; the design is additive and needs no consensus flip and no re-genesis; and the quantum-safety argument holds for the design and for the [MEASURE] circuit once it is real.

---

7. References

• On-chain SP1 gateway pattern: contracts/contracts/mpc/AerePQAggregateVerifier.sol, contracts/contracts/interop/AereZkQbftLightClient.sol (the CLASSICAL ECDSA finality light client this certificate is the post-quantum counterpart to).
• Registry pattern: contracts/contracts/pqc/AerePQCKeyRegistry.sol, contracts/contracts/validators/AereValidatorManifest.sol.
• Consensus-side backing: aerenew/formal-consensus/falcon_hybrid_dualquorum_smt.py (hybrid dual-quorum proven no-worse-than-ECDSA), the PQ-CONSENSUS-STEP2 and PQ-INPLACE-ACTIVATION work (blocking hybrid consensus with in-place, no-re-genesis activation).
• Quantum scope boundary: aerenew/docs/AERE-ENGINEERING-SECURITY-SPEC.md (signatures and accounts can be post-quantum; consensus and the BN254 zk verifiers are classical; the chain as a whole is not post-quantum).
• Direct hash-based STARK verifier line: contracts/contracts/zkverify/AerePQStarkVerifier.sol.