# AIP-16: PQ STARK-Verify Precompile (0x0AE8)

## Preamble

| Field | Value |
| --- | --- |
| AIP | 16 |
| Title | PQ STARK-Verify Precompile (0x0AE8) |
| Author | Aere Network Foundation |
| Type | Standards Track |
| Category | Core |
| Status | Draft (reference skeleton; verifies nothing; not live on any Aere network) |
| Created | 2026-07-19 |
| Requires | 7, 12 |
| Supersedes | None |
| Superseded-By | None |
| Ratification | Not ratified; prerequisite gated, external-audit gated, founder gated |

## Abstract

This AIP reserves precompile address `0x0AE8` for a post-quantum-sound
STARK-verify precompile that would verify a hash-based STARK on-chain, removing a
BN254 pairing check from Aere's zk paths. It is **Draft**. As of this date the
artifact is a reference skeleton that verifies nothing, and `0x0AE8` is not
activated on any Aere network.

## Motivation

Aere's zk interop and validity paths currently wrap proofs as Groth16 over BN254,
which is classical and Shor-breakable. A post-quantum-sound proof system (a
FRI-based STARK, hash commitments only, no pairing) would remove that assumption.
A native precompile is the natural home for STARK verification, matching the same
reasoning used for the post-quantum signature precompiles in AIP-7.

## Specification

Reserve precompile address `0x0AE8`. It is specified to activate under a new,
**forward-dated** milestone (PQ-3), never folded into an already-crossed
milestone, so that pre-activation history is byte-identical on old and new
binaries and the upgrade itself carries no fork risk.

**Scope correction (2026-07-19 research finding).** An earlier draft described
this as verifying "an SP1 inner-STARK (FRI over a Poseidon2 commitment)". That is
corrected here: the verifier skeleton built so far is a BabyBear + FRI STARK
verifier, conformance-confirmed against Plonky3 `0.4.3-succinct`, which targets
Aere's own Plonky3 circuits and **not** SP1 6.1.0. The pinned SP1 6.1.0 is a
Hypercube release (KoalaBear multilinear: BaseFold plus sumcheck-zerocheck plus
LogUp-GKR), so FRI does not apply to it and this skeleton does not verify SP1
6.1.0 proofs. Retargeting `0x0AE8` to the SP1 Hypercube stack is a separate
effort **estimated** at 22 to 32 person-weeks. See
`AERE-STARK-SP1-RECURSION-AIR-PORT-SPEC-SUMMARY.md`.

## Rationale

A forward-dated, non-retroactive milestone plus a rolling binary upgrade (the same
zero-liveness-risk posture proven for the base-fee floor in AIP-17 and the
in-place activation in AIP-15) means the address stays an empty account, and every
consumer adapter fails closed, until the announced activation time. A migrated
consumer can keep both the new `0x0AE8` path and the existing BN254 gateway during
a defense-in-depth window before dropping the classical path.

**Alternatives rejected.** Folding `0x0AE8` into the already-crossed
`futureEipsTime` milestone (block 9,189,161): every historical block that called
the currently-empty address would re-execute with different return data on the
upgraded binary, which is a state divergence and a consensus split. Also
rejected: presenting the current artifact as a working verifier, because it is
not one.

## Backwards Compatibility

None, by construction: the address is an empty account until a forward-dated
activation, so no historical execution changes.

## Security Considerations

**This is the load-bearing honesty statement of this record.** `0x0AE8` is not
activated on any Aere network. As of this date it is a reference skeleton that
fail-closes, returning EMPTY for every input. **It is not a working verifier and
must not be presented as one.** Mainnet 2800 has exactly five PQC precompiles,
`0x0AE1` to `0x0AE5`, live from block 9,189,161. The sibling ML-KEM-768 (`0x0AE6`)
and Falcon HashToPoint (`0x0AE7`) precompiles are testnet-only.
`AerePQStarkVerifier.sol` is a fail-closed adapter that denies every proof, safe
by construction. Consensus is untouched by all of this and remains classical
ECDSA QBFT.

**Prerequisites before activation can even begin.** The crypto core must be
ported from maintained references (Plonky3 FRI/Poseidon2/uni-stark, SP1 stark) or
a pinned native wrap must be built and reproducible; a real SP1 v6.1.0
inner-STARK vector corpus must exist, with the precompile accepting every valid
vector and rejecting every tampered or wrong-public-values vector, including
cross-agreement with the live BN254 gateway; a soundcalc receipt for the exact
pinned `FriConfig` must be recorded (no 128-bit claim without the receipt); and a
benchmark must confirm a real verify fits under the EIP-7825 2^24 per-transaction
gas cap.

**Gates beyond the prerequisites.** A specialist external STARK/FRI audit of the
consensus-critical crypto, a conformance gate green on the frozen artifact, an
isolated N = 7 soak across a simulated milestone crossing, and an explicit founder
GO. Until all hold, `0x0AE8` stays a skeleton.

## Reference Implementation and On-Chain Deployment

Not deployed. Design:
`aerenew/docs/PQ-STARK-VERIFIER-PRECOMPILE-2026-07-18.md`. Gated activation plan:
`aerenew/docs/PQ-STARK-VERIFIER-ACTIVATION-2026-07-18.md`. Fail-closed adapter:
`aere-contracts/contracts/zkverify/AerePQStarkVerifier.sol`.

## Copyright

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