aere-research/research/specs/spec-zk-stack.md

AERE Network: Zero-Knowledge Verification Stack

Chain: AERE Network mainnet, chain ID 2800 (Hyperledger Besu QBFT). Status date: 2026-07-11. Source of truth for addresses: sdk-js/src/addresses.ts. Contract source: contracts/contracts/. Scope: the on-chain proof-verification layer. This covers SP1 (Groth16 / Plonk), RISC Zero, KZG / EIP-4844, Halo2, recursive proof aggregation, zkML, zk-KYC / zk-compliance, and the storage-proof coprocessor.

This document describes what each verifier proves, the exact on-chain path a proof takes to be accepted, and the honest trust boundary of each. It is deliberately conservative about claims: every capability is marked either live (deployed and demonstrated with an on-chain transaction recorded in the repo) or roadmap / in development.

---

0. Honesty preamble (read this first)

Four points frame everything below.

1. This is an application / account-layer proof stack, not a consensus feature. AERE's validators sign classical QBFT; none of the verifiers here change how blocks are produced or finalized. The verifiers are ordinary EVM contracts that any account can call. They add verifiable computation on top of the chain, not inside consensus.

2. The network is small and centralized today. AERE runs seven QBFT validators operated by a single operator, on a single client (Besu). There is no external security audit of the AERE-authored contracts. On-chain usage of these verifiers is thin (single-digit proof records for most of them). None of this is hidden; it is the baseline against which the engineering below should be judged.

3. Address-citation discipline. Addresses are printed verbatim only when they appear in the canonical registry sdk-js/src/addresses.ts. Several verifiers in this stack (KZG, Halo2, the recursive aggregator, the zkML verifier, the state-root anchor) are deployed and demonstrated on chain 2800 but are not yet promoted into that registry. For those, this spec points to the repo deployment artifact (contracts/deployments/*.json) that records the address and on-chain transaction, and deliberately does not reproduce the raw hex here. Treat any such contract as deployed-but-pending-canonical-registration. This is a hygiene choice: the SDK registry is the single source of truth, and anything not in it should not be integrated against as if it were canonical.

4. We do not claim uniqueness beyond what is demonstrable. Where a superiority framing is tempting, the honest statement is narrow: AERE hosts a multi-prover verification surface (SP1 plus RISC Zero plus a raw KZG precompile path plus a generated Halo2 verifier) behind a route-by-selector gateway, with a permissionless attestation registry on top. That is unusual to have all in one place; it is not a claim that no other chain can verify any one of these.

---

1. Architecture: route-by-selector, verify-then-record

Every proof system in the stack follows the same two-layer shape.

Layer 1, the verifier. A concrete verifier (SP1 Groth16, SP1 Plonk, a RISC Zero Groth16 verifier, a generated Halo2 verifier, or the EIP-4844 precompile) takes proof bytes plus public inputs and either returns cleanly or reverts. The canonical SP1 and RISC Zero verifiers follow the Succinct / RISC Zero convention: verifyProof / verify returns nothing and reverts on an invalid proof. AERE's wrapper contracts consistently try/catch that revert and translate it into a typed InvalidProof() error, so a caller never mistakes empty return-data for a failure.

Layer 2, routing and attestation. Concrete verifiers sit behind routers keyed on the first 4 bytes of the proof (a version selector):

• SP1VerifierGateway routes an SP1 proof to the correct SP1 verifier version by its leading selector, refusing frozen routes.
• RiscZeroVerifierRouter routes a RISC Zero seal by its leading selector to the matching zkVM-version verifier.

Because routing is by selector, a new prover version is added with a single addRoute / addVerifier call on the router. Downstream application contracts that hold only the router address need no migration when a new prover version ships. AERE's application verifiers (storage proof, zk-KYC, zkML, rollup validity, aggregator) all hold the SP1 gateway address, not a concrete verifier, exactly for this reason.

On top of the routers, AereProofRegistry records each successful verification as a permanent, event-indexed attestation, with permissionless program registration.

---

2. SP1 (Succinct Labs): Groth16 and Plonk

Contracts (canonical, in addresses.ts):

• SP1VerifierGateway: 0x9ca479C8c52C0EbB4599319a36a5a017BCC70628
• SP1VerifierGroth16_v6_1_0: 0xb5456d48bFdA70635c13b6CBE1Ad0310Dc0171aD (current production)
• SP1VerifierGroth16_v6_0_0: 0xa9BD3020bC9a9614F9e2BC1618153c9fB1890ca6 (prior production, retained)
• SP1VerifierPlonk_v6_1_0: 0x24a7a85E6D9A2b120F2730880bE7283dFB14d29B

What it proves. SP1 is a RISC-V zkVM. A guest Rust program is compiled to an ELF; its verification key (programVKey, a bytes32) binds that exact ELF. A proof attests that the guest ran to completion on some private witness and committed a specific publicValues byte-string. Groth16 gives constant-size (roughly 260 to 356-byte) proofs at about 300k gas to verify; Plonk avoids a per-circuit trusted setup at a somewhat higher verification cost. Both are routed by the same gateway.

Verification path. SP1VerifierGateway.verifyProof(programVKey, publicValues, proofBytes) reads bytes4(proofBytes[:4]) as the selector, looks up routes[selector], reverts RouteNotFound / RouteIsFrozen on a bad route, and otherwise delegates to the concrete verifier's verifyProof. The Groth16 route selector on chain 2800 is 0x4388a21c (the leading 4 bytes of the v6.1.0 Groth16 verifier's VERIFIER_HASH 0x4388a21c687fdd5f...); the Plonk verifier hash is 0x5a093a2f.... The gateway is Ownable (Foundation), so only the Foundation can add or freeze routes; it cannot forge a verification, because the actual cryptographic check happens in the immutable concrete verifier the route points at.

Notes. A legacy v4.0.0-rc.3 SP1 verifier and registry were deployed on 2026-05-31 (recorded in contracts/deployments/zkverify-stack.json) and retain a historical Fibonacci fixture proof (registry proof id 0). Production traffic uses the v6.1.0 gateway above. Every AERE application verifier in this spec that says "SP1" routes through this one gateway.

---

3. RISC Zero zkVM: Groth16 receipts

Contracts (canonical, in addresses.ts):

• RiscZeroVerifierRouter: 0x3f7015BC3290e63F7EC68ecF769b00aB296a249C (Foundation-owned)
• RiscZeroGroth16Verifier_DEPRECATED: 0x95cB30f3bdb3187f39203A9907bf707Aef07a1FD (do not use)
• RiscZeroGroth16Verifier: 0xb6fD00D88Bf8B08d6371d2D98E0e239B89Ab5B9D (corrected)
• RiscZeroVerifierRouter_Corrected: 0x62b96F7211F832f47d8Fc0D8317D5867B0Af43E5
• AereProofRegistry_Corrected: 0x174F616E2048A71408E2491791ef77cd6913bbEf

What it proves. RISC Zero is a second RISC-V zkVM. A receipt attests that a guest with a given imageId produced a journal whose digest is journalDigest. RiscZeroVerifierRouter.verify(seal, imageId, journalDigest) routes by the seal's leading selector to the concrete Groth16 verifier, which checks the seal against RISC Zero's CONTROL_ROOT / BN254_CONTROL_ID circuit-binding constants (ControlID.sol) for a specific zkVM release (VERSION = "5.0.0-rc.1").

A real bug, honestly recorded. The originally deployed RISC Zero verifier (0x95cB...a1FD) was bootstrapped with a non-canonical control root (0xb1f640...488167) that matches no released risc0 version. That wrong root computes selector 0xc27d1bc0, so the router could never route a genuine risc0 5.0.0-rc.1 receipt (which carries selector 0xef6cb709): every real seal reverted SelectorUnknown. The fix, recorded in contracts/deployments/risc0-verifier-fix.json, deployed a corrected verifier (0xb6fD...5B9D) with the genuine control root 0x4ec911...bde5b04 and selector 0xef6cb709.

Why there is a "corrected" self-owned stack. The canonical RiscZeroVerifierRouter and AereProofRegistry are Foundation-owned, and the registry's risc0Router reference is immutable. The deployer key that built the fix cannot addVerifier on the Foundation router. So a self-owned corrected router (0x62b9...43E5) and registry (0x174F...bbEf) were deployed to record a real RISC Zero proof today: a risc0 5.0.0-rc.1 Groth16 factorization proof (guest proves knowledge of a nontrivial factorization of n = 11,917,497,200) was registered and recorded (submit tx 0xf9269dde...396e629, record id 0), with independent public-RPC read-back confirming accept-on-valid and VerificationFailed() on tampered journal or seal.

Roadmap item (pending Foundation signature). For the canonical Foundation-owned AereProofRegistry to record RISC Zero proofs, the Foundation must run one addVerifier(0xef6cb709, 0xb6fD...5B9D) on the canonical router 0x3f70...249C. That transaction is staged (calldata recorded in the fix artifact) but not yet executed. Until it is, canonical R0 recording is roadmap, and the self-owned corrected stack above is the live path.

---

4. Multi-prover attestation registry

Contract (canonical): AereProofRegistry: 0x0A9b09677DbE995ACfC0A28F0033e68F068517Ee (Foundation-owned).

Purpose. A single log that verifies and records proofs from both SP1 and RISC Zero. Its design goals:

• Verify then record. submitSP1Proof calls ISP1Verifier(sp1Gateway).verifyProof(...) (reverts on invalid), then writes a ProofRecord and emits ProofVerified with the program key indexed. submitRiscZeroProof does the same through IRiscZeroVerifier(risc0Router).verify(...). Off-chain consumers subscribe to ProofVerified filtered by their program of interest.
• Permissionless program registration. Anyone registers their own SP1 vkey or R0 imageId with a human-readable name plus URL (registerSP1Program / registerRiscZeroProgram). The Foundation can disableProgram a malicious program but cannot disable a legitimate one, and disabling never retroactively invalidates already-recorded proofs.
• Free verdicts. verifySP1Only / verifyRiscZeroOnly are view functions that give the verdict (revert-on-invalid) without writing a record, for dApps that need the answer but not a permanent attestation.

Both immutables sp1Gateway and risc0Router are set at construction. Because the registry holds the gateway/router (not a concrete verifier), SP1 v7 or a new R0 verifier plug in upstream with no registry migration. The AereProofRegistryV2.sol source in the repo is an equivalent multi-prover registry design; the canonical live registry is the address above.

---

5. KZG / EIP-4844 point-evaluation verifier

Contract: AereKZGVerifier, deployed, not yet in addresses.ts (address plus KAT plus on-chain verify tx recorded in contracts/deployments/kzg-verifier.json). Treat as pending-canonical-registration.

What it proves. That a blob polynomial P committed to by a 48-byte KZG commitment evaluates to y at point z, that is P(z) == y, using the EIP-4844 point-evaluation precompile at address 0x0A. This is the primitive underlying blob-data availability and any KZG-commitment scheme.

Verification path. verifyPointEvaluation(bytes input) forwards the raw 192-byte precompile input (versioned_hash(32) | z(32) | y(32) | commitment(48) | proof(48)) to 0x0A via staticcall. On a valid proof the precompile returns exactly 64 bytes: uint256(FIELD_ELEMENTS_PER_BLOB = 4096) | uint256(BLS_MODULUS). The contract enforces both the success flag and that canonical 64-byte return (rejecting any other length or constants), then records (sender, versionedHash, z, y, block, time) append-only. checkPointEvaluation is the gas-cheap view twin. Because precompiles have no code, the contract deliberately does no extcodesize check; correctness is enforced by the strict canonical-constant return, which no empty account or stray contract can satisfy by chance.

Live evidence. EIP-4844 blob support is active on chain 2800: the precompile was confirmed against the official go-ethereum known-answer vector (pointEvaluation1), and an on-chain verify transaction is recorded (gasUsed about 255,719 per the artifact). No owner, no admin, append-only.

Honest scope. This verifies a KZG opening; it does not by itself prove that a particular blob was posted for a particular transaction. QBFT produces no blobs (BLOBBASEFEE returns 0), so this is a verification primitive available to applications, not a data-availability layer the chain itself uses.

---

6. Halo2 (bn254 / KZG) verifier plus anchor

Contracts: AereHalo2CubicVerifier (generated verifier) and AereHalo2ProofAnchor (record), deployed, not yet in addresses.ts (addresses, proof hash, on-chain verify tx recorded in contracts/deployments/halo2-cubic.json). Pending-canonical-registration.

What it proves. The bound circuit is a real 4-row standard-PLONK circuit proving knowledge of a private x with x^3 + x + 5 == out, where out is the single public instance (demonstrated with out = 35). The verifier is generated by privacy-scaling-explorations/halo2-solidity-verifier (bn254 / KZG commitments, Bdfg21 / SHPLONK batch opening) with the verifying key embedded in bytecode.

Verification path. AereHalo2ProofAnchor.verifyAndRecord(proof, instances) calls IHalo2Verifier(VERIFIER).verifyProof(proof, instances); the generated verifier returns true and reverts on an invalid proof. On success the anchor records (sender, keccak256(proof), keccak256(instances), block, time) append-only. The verifier address is immutable; no owner, no admin. Per the artifact, on-chain verify gas is about 449,517 (proof 1152 bytes, revm gas about 300,144), with valid-accept and tampered-reject both demonstrated.

Honest scope: the SRS is a dev setup, not a ceremony. The KZG structured reference string was generated locally on the AERE build server (ParamsKZG::setup), not from a public trusted-setup ceremony. That is fine for demonstrating that AERE can host and verify a real Halo2 proof on-chain; it is not production-grade for a value-bearing circuit, where a multi-party ceremony SRS would be required. This is the single most important caveat on the Halo2 path and is stated plainly in the artifact.

---

7. Recursive proof aggregation

Contract: AereProofAggregator, deployed, not yet in addresses.ts (address, aggregation vkey, inner-program mappings, and both on-chain records in contracts/deployments/proof-aggregator.json and proof-aggregator-scale.json). Foundation-owned. Pending-canonical-registration.

What it proves. One SP1 Groth16 "proof of proofs." An aggregation guest recursively verified N inner SP1 proofs inside the zkVM via verify_sp1_proof, and committed a single composite digest binding all N (innerVKeyDigest, innerPublicValuesHash) pairs:

composite = sha256( u32_be(n) || (innerVKeyDigest_0 || innerPvHash_0) || ... || (innerVKeyDigest_{n-1} || innerPvHash_{n-1}) )

innerVKeyDigest_i is the KoalaBear (SP1Field) verifying-key digest the recursion verifier actually checked. Binding that (rather than the BN254 on-chain vkey) is what makes the on-chain check maximally sound.

Verification path. recordAggregation(aggVKey, innerVKeyDigests[], innerPvHashes[], publicValues, proof):

1. requires aggVKey is a Foundation-registered aggregation program;
2. recomputes composite from the supplied inner arrays byte-for-byte with the guest and requires it equals the 32-byte publicValues;
3. verifies the Groth16 proof through the SP1 gateway (selector 0x4388a21c);
4. counts how many folded inner programs are recognized (registered via registerInnerProgram, which cross-maps each KoalaBear digest to its published on-chain BN254 vkey and a label) and records the aggregation.

Live evidence. Two real aggregations are recorded on chain 2800: a 3-proof fold (inner programs zkscreen, over18, zkml-mnist; record tx 0xde4c102a..., gasUsed about 387,858) and a 10-proof scale fold of distinct statements (record tx 0xd1fd4d60..., block 8930005, gasUsed about 393,844, recognized = 10/10). Note the gas to verify the aggregate on-chain is roughly flat (about 390k) whether folding 3 or 10 inner proofs; that constant-verification-cost property is the point of recursion. The proving side is not free: the scale artifact records about 526s to produce the aggregation Groth16 and about 988s of inner proving (measured, off-chain). Tampering (mutated proof or a dropped child) reverts.

---

8. zkML: private machine-learning inference

Contract: AereZKMLVerifier, deployed, not yet in addresses.ts (address, model vkey/hash, accuracy, on-chain verify tx recorded in contracts/deployments/zkml-mnist-verifier.json). Foundation-owned model registry. Pending-canonical-registration.

What it proves. That a registered ML model classified a private input without revealing that input. The reference model is a genuinely trained, quantized MNIST digit classifier (784 to 256 to 10 integer MLP, ReLU, argmax). The forward pass runs inside the SP1 zkVM on a private 28x28 image; only the predicted digit is made public.

Model binding. Each model is registered by the Foundation with programVKey (binds the exact guest ELF, which embeds the quantized weights), modelHash (keccak256 of the weight blob, recomputed inside the zkVM so a verifier knows the classification came from this model), numClasses, and a measured accuracyBps. The reference model's measured accuracy is 97.98% (9798 of 10000 correct on the MNIST test set; float baseline 98.01%), recorded on-chain for transparency.

Verification path. submitInference(programVKey, publicValues, proof) requires the model is registered, requires publicValues is exactly 128 bytes = abi.encode(chainId, user, modelHash, predictedClass), verifies the SP1 proof through the gateway, then binds chainId == block.chainid, user == msg.sender, modelHash == registered model, and predictedClass < numClasses, and records the user's latest verified prediction. verify(...) is a stateless view twin. Per the artifact, the reference inference verified on-chain at gasUsed about 326,492; the guest runs about 5.22M cycles using the SP1 keccak precompile to hash the 407,592-byte weight blob (24.5M cycles without it).

Honest scope. This proves inference integrity for one small, quantized model on one dataset. It is a real, measured classifier, not a toy with hand-picked weights (it supersedes an earlier 4-to-8-to-3 toy). It is not a general zkML framework and makes no claim about large models.

---

9. zk-KYC / zk-compliance

Three related contracts implement "prove a compliance property without putting PII on-chain."

9.1 AereZKScreen (canonical)

Contract: AereZKScreen: 0x3A097A459FD26aC79573aCB5adB51430e473C2f1 (v3; Foundation-owned).

What it proves. That a user passed an off-chain compliance screen (sanctions check, residency / accredited-investor / MiCA-jurisdiction attestation) inside an SP1 zkVM, anchoring only a boolean-style clearance. dApps gate access with isCleared(user, programVKey, minTimestamp); no PII touches the chain.

Verification path plus the critical soundness fix. submitProof(programVKey, publicValues, proof) requires the program is registered, requires publicValues is exactly 128 bytes = abi.encode(chainId, user, attestedAt, extraDataHash), verifies the SP1 proof, then enforces: chainId matches, user == msg.sender, attestedAt <= now, and the anti-downgrade rule attestedAt > clearedAt[user][program]. The root-binding check is the soundness core: each program binds a Foundation-set authorizedRoot, and the proof's extraDataHash must equal that root. Without it, a prover could prove membership in an allowlist of their own making (an "allowlist" containing only themselves), a total break of the compliance claim. The version history in addresses.ts records that earlier deployments had exactly this class of hole (v1 0xE9da9c... dead; v2 0x140572... had a self-clear hole); v3 (the address above) is the root-binding fix, and adds owner setAuthorizedRoot rotation and per-user revoke.

Consumer obligations (documented in-source). dApps MUST pass a real minTimestamp (for example now - freshnessWindow), never 0, and MUST treat clearance as necessary-not-sufficient, AND-ing it with a live sanctions check for sanctions-sensitive flows.

9.2 AereCompliancePool SP1 verifier (canonical)

Contracts: AereCompliancePoolSP1Verifier: 0xE2D3fa91b680E835c971761ba75Fde0204AEF95E; consumed by AereCompliancePoolV2: 0xB144c923572E5Ac1B6B961C4ccfec36917173465.

What it proves. A Privacy-Pools-style compliant withdrawal: that a note is a member of a deposit Merkle root and an approved association root, with a spent-nullifier, recipient, fee, and refund, all without linking the deposit to the withdrawal. The SP1 guest lives at zk-circuits/compliance-pool/program; its vkey is the verifier's immutable PROGRAM_VKEY (0x00aa183a... per addresses.ts).

Verification path. verify(bytes proof, uint256[8] pubs) re-abi-encodes the 8 public inputs [poolId, depositRoot, associationRoot, nullifierHash, recipient, feeRecipient, refund, fee] into the exact struct the guest commits, then staticcalls ISP1Verifier.verifyProof(PROGRAM_VKEY, publicValues, proof) and returns the success bool to fit the pool's IPrivacyPoolVerifier interface. It is a drop-in production replacement for the test MockPrivacyPoolVerifier. The pool itself (AereCompliancePoolV2) is sanctions-gated plus Travel-Rule-bound and, per addresses.ts, currently holds 0 deposits (fresh).

9.3 AereAIProof (provenance, not zk)

Contract: AereAIProof: 0xFf92c669AbF4C1DAE31eBFCC017764036d9D97e6.

Included here for completeness because it is often grouped with the compliance/attestation set, but it is signature-based, not zero-knowledge. Providers register a modelId with a signing key and anchor EIP-712-signed (modelId, inputHash, outputHash, requesterHash, timestamp, nonce) statements. Only hashes are stored (no raw prompts or completions). It gives tamper-evident AI-inference provenance (useful for agentic AERE402 flows and regulated AI audit logs) with a per-model monotonic nonce, a rotate-invalidates-old-nonce-space watermark, and ECDSA.recover against the current signer. It proves who signed what, not a hidden computation.

---

10. Storage-proof coprocessor

Contracts: AereStorageProofVerifier: 0xF9a1A183bEb3147D88dA5927301683fEbFb9362E (canonical, immutable, no owner). Companion AereStateRootAnchor, deployed, not yet in addresses.ts (contracts/deployments/state-root-anchor.json); pending-canonical-registration.

What it proves. That, at a given state root R, an account A's storage slot S held value V. The SP1 guest (aere-storage-proof-program) RLP-decodes and hash-chains the real eth_getProof account-proof and storage-proof nodes of AERE's Merkle-Patricia state trie: it walks stateRoot to storageRoot, then storageRoot to value, panicking on any node whose keccak256 does not match its parent reference. No Foundation-seeded side tree is involved.

Verification path. Public values are exactly 192 bytes = abi.encode(chainId, blockNumber, stateRoot, account, slot, value). submitProof verifies through the SP1 gateway (PROGRAM_VKEY = 0x0015e599...b659), enforces chainId == block.chainid, and records keccak256(blockNumber, account, slot) to {stateRoot, value, at}. submitProofWithExpectedRoot additionally reverts unless the proof's stateRoot == expectedStateRoot, moving the canonicity check to the call site. verify is a stateless view twin.

Live evidence. A first real proof is recorded: AereTreasury (0x687933...6119) slot 0 (its owner) equals the Foundation (0x0243A4...f3C3) at block 8915939, against canonical state root 0x515fce04...4a92f3 (confirmed equal to eth_getBlockByNumber(8915939).stateRoot); submit tx 0xe541c52b...6c54, gasUsed 348,345 (under the EIP-7825 per-tx cap of 16,777,216). Tampered proof or public values revert.

Honest scope: the canonicity gap, and how the anchor closes it. The verifier alone proves "V is slot S of A in the trie whose root is stateRoot"; it does not prove that stateRoot is the canonical root of blockNumber (blockNumber is metadata). The consumer must establish canonicity independently. AereStateRootAnchor is the first building block for that: it recovers a canonical block hash strictly from the BLOCKHASH opcode (never a caller argument), checks a caller-supplied RLP header against it, and records the header's state root as an anchored, trust-minimized value. The artifact honestly notes chain-2800 constraints probed on-chain: BLOCKHASH is live but serves only the last 256 blocks (about 128s at 0.5s block time), and the EIP-2935 history contract is not deployed on chain 2800, so the extended roughly 8191-block window is unavailable. A block-hash-anchor oracle for older blocks is a separate follow-on and is explicitly roadmap.

---

11. Rollup validity anchor

Contract: AereRollupValidity: 0x38772063572DF94E90351e44ccbBEefD5F497fbd (immutable, no owner).

What it proves. An SP1 Groth16 validity proof that AERE's deterministic rollup executor transitioned prevRoot to postRoot by applying a batch committed as batchHash. Unlike an optimistic rollup with a challenge window, an epoch recorded here is final the instant the proof verifies.

Verification path. Public values are exactly 160 bytes = abi.encode(chainId, prevRoot, postRoot, batchHash, numTxns). submitEpoch(publicValues, proof) verifies through the SP1 gateway (PROGRAM_VKEY = 0x00c39737...84ad, selector 0x4388a21c), binds chainId, enforces canonical-chain continuity prevRoot == latestRoot, then records the epoch and advances latestRoot. Immutables SP1_VERIFIER, PROGRAM_VKEY, GENESIS_ROOT are fixed at deploy; submission is permissionless and gated only by the proof plus continuity, so anyone can advance the tip and no one can fork it. Epoch 0 is recorded from a real proof (submit tx 0xd4f8d858...12a4b0, block 8880188; latestRoot = 0x256fa277...25e3ac, epochCount = 1), verified against the production aere-block-stm executor's state root for the same 5-tx batch.

Honest scope. This proves the state transition of AERE's current bounded-VM executor: a fixed transaction set (Transfer / Sweep / Increment / AmmSwap over a balance/storage map), not arbitrary EVM bytecode. It is a real validity proof of that executor. The honest next step toward a full validity rollup is replacing the guest VM with a real EVM (revm) inside the zkVM, a separate multi-quarter effort. Nothing built on this should imply it proves a full EVM.

---

12. Consolidated status and address table

Canonical (verbatim from sdk-js/src/addresses.ts):

Subsystem	Contract	Address	Status
SP1 routing	SP1VerifierGateway	0x9ca479C8c52C0EbB4599319a36a5a017BCC70628	Live
SP1 Groth16 (prod)	SP1VerifierGroth16_v6_1_0	0xb5456d48bFdA70635c13b6CBE1Ad0310Dc0171aD	Live
SP1 Groth16 (prior)	SP1VerifierGroth16_v6_0_0	0xa9BD3020bC9a9614F9e2BC1618153c9fB1890ca6	Live, retained
SP1 Plonk	SP1VerifierPlonk_v6_1_0	0x24a7a85E6D9A2b120F2730880bE7283dFB14d29B	Live
RISC Zero routing	RiscZeroVerifierRouter	0x3f7015BC3290e63F7EC68ecF769b00aB296a249C	Live (repoint pending)
RISC Zero Groth16 (corrected)	RiscZeroGroth16Verifier	0xb6fD00D88Bf8B08d6371d2D98E0e239B89Ab5B9D	Live
RISC Zero Groth16 (bad root)	RiscZeroGroth16Verifier_DEPRECATED	0x95cB30f3bdb3187f39203A9907bf707Aef07a1FD	Deprecated, do not use
RISC Zero corrected router	RiscZeroVerifierRouter_Corrected	0x62b96F7211F832f47d8Fc0D8317D5867B0Af43E5	Live
Multi-prover registry	AereProofRegistry	0x0A9b09677DbE995ACfC0A28F0033e68F068517Ee	Live (R0 recording pending Foundation repoint)
Corrected registry	AereProofRegistry_Corrected	0x174F616E2048A71408E2491791ef77cd6913bbEf	Live (recorded R0 proof id 0)
Storage-proof coprocessor	AereStorageProofVerifier	0xF9a1A183bEb3147D88dA5927301683fEbFb9362E	Live
zk-KYC screen	AereZKScreen	0x3A097A459FD26aC79573aCB5adB51430e473C2f1	Live (v3, root-binding)
Compliance-pool SP1 verifier	AereCompliancePoolSP1Verifier	0xE2D3fa91b680E835c971761ba75Fde0204AEF95E	Live
Compliance pool	AereCompliancePoolV2	0xB144c923572E5Ac1B6B961C4ccfec36917173465	Live (0 deposits)
AI-inference provenance (signed, not zk)	AereAIProof	0xFf92c669AbF4C1DAE31eBFCC017764036d9D97e6	Live
Rollup validity anchor	AereRollupValidity	0x38772063572DF94E90351e44ccbBEefD5F497fbd	Live (bounded VM)

Deployed but NOT yet in the canonical registry (address in the named artifact; hex omitted here by policy):

Subsystem	Contract	Artifact	Status
KZG / EIP-4844	AereKZGVerifier	contracts/deployments/kzg-verifier.json	Deployed, pending registry
Halo2 verifier	AereHalo2CubicVerifier	contracts/deployments/halo2-cubic.json	Deployed, dev SRS
Halo2 anchor	AereHalo2ProofAnchor	contracts/deployments/halo2-cubic.json	Deployed, pending registry
Recursive aggregation	AereProofAggregator	contracts/deployments/proof-aggregator*.json	Deployed (3- and 10-proof folds)
zkML	AereZKMLVerifier	contracts/deployments/zkml-mnist-verifier.json	Deployed, 97.98% MNIST
State-root anchor	AereStateRootAnchor	contracts/deployments/state-root-anchor.json	Deployed, 256-block window

---

13. Roadmap summary (explicit "not done yet")

• Canonical RISC Zero recording: one Foundation addVerifier(0xef6cb709, 0xb6fD...5B9D) on router 0x3f70...249C to route real seals through the Foundation-owned AereProofRegistry. Staged, unsigned.
• Promote KZG / Halo2 / aggregator / zkML / state-root-anchor into sdk-js/src/addresses.ts so integrators have a single canonical source.
• Halo2 production SRS: replace the local dev SRS with a multi-party ceremony SRS before any value-bearing Halo2 circuit.
• Historical-state canonicity: a block-hash-anchor oracle to extend storage-proof canonicity beyond the 256-block BLOCKHASH window (EIP-2935 is not deployed on chain 2800).
• Full validity rollup: replace the bounded-VM executor guest with revm inside the zkVM.
• Decentralization baseline: the honest gating context for all of the above remains seven validators, one operator, one client, no external audit, and thin usage.

---

Every address printed above is verbatim from sdk-js/src/addresses.ts. Contracts deployed but absent from that registry are referenced by their repo deployment artifact and are not reproduced as hex, pending canonical registration. Performance figures (gas, cycles, accuracy, proving times) are quoted from repo deployment artifacts and are measured single-run values, not benchmarked averages.