aere-docs/AERE-ARCHITECTURE-MAP.md

Aere Network Architecture Map

Aere Network is a public, EVM-compatible Layer 1 (chain ID 2800). One diagram replaces pages of prose here: the architecture is best read as a layered stack (Consensus at the bottom, then Execution, Accounts, and Applications on top) with a set of cross-cutting concerns (post-quantum cryptography, zero-knowledge verification, and crypto-agility) that traverse every layer rather than sitting in any single one. This is deliberately not one linear top-to-bottom column: the layers stack, and the transversal concerns cut across all of them.

The single most important honesty point, stated up front: consensus today is classical ECDSA (secp256k1) QBFT. Only signatures, accounts, and precompiles are post-quantum. There is no post-quantum consensus live on mainnet, and the on-chain zero-knowledge verifiers are classical BN254 (Shor-breakable) today. Everything below is marked LIVE (on mainnet 2800) or "(roadmap)" (built and tested, but not activated on mainnet).

Diagram

flowchart TB
  classDef live fill:#e7f6ec,stroke:#1a7f37,color:#0b2b16;
  classDef road fill:#fff3e0,stroke:#b26a00,color:#3d2600,stroke-dasharray:5 3;
  classDef cross fill:#eaeefb,stroke:#3b46c4,color:#1a1f5c;

  legend["Legend. Green solid, LIVE on mainnet 2800. Orange dashed, roadmap (built and tested, not yet live). Blue, cross-cutting concern. Suffix (roadmap) also marks any not-yet-live item inside a label."]:::cross

  subgraph APP["Applications layer"]
    direction TB
    app_defi["DeFi. lending, sAERE staking, AereSink burn"]:::live
    app_settle["Settlement. SettlementHub, state channels, AERE402 machine payments"]:::live
    app_bridge_l["Bridge and interop. Hyperlane-compatible bus, zk light clients inbound and outbound"]:::live
    app_bridge_r["ERC-7683 intent settlement route (roadmap)"]:::road
    app_id_l["Identity and compliance. ZKScreen, compliant privacy pool, AereProof registry"]:::live
    app_id_r["zk-KYC and over-18 attribute proofs (roadmap)"]:::road
    app_ai_l["AI agents. AgentDID, AIReputation, agent bond, InferNet audit log"]:::live
    app_ai_r["AI runtime and zk proof of inference (roadmap)"]:::road
  end

  subgraph ACC["Accounts layer"]
    direction TB
    acc_eoa["EOA"]:::live
    acc_pk["WebAuthn P-256 passkey accounts"]:::live
    acc_4337["ERC-4337 v0.7 smart accounts"]:::live
    acc_7702["EIP-7702 EOA delegation"]:::live
    acc_falcon["Falcon-512 and hybrid ECDSA plus Falcon accounts"]:::live
    acc_thr["t-of-n PQC threshold accounts"]:::live
    acc_note["Note. flawed originals superseded, some V2 redeploys founder-gated"]:::cross
  end

  subgraph EXE["Execution layer"]
    direction TB
    exe_evm["EVM. Pectra plus Fusaka parity"]:::live
    exe_pqc["PQC precompiles 0x0AE1 to 0x0AE5"]:::live
    exe_pqc2["PQC precompiles ML-KEM-768 and HashToPoint, 0x0AE6 to 0x0AE7 (roadmap)"]:::road
    exe_stm["Parallel execution, Block-STM (roadmap)"]:::road
    exe_zk["zk validity rollup, revm in SP1 (roadmap)"]:::road
  end

  subgraph CON["Consensus layer"]
    direction TB
    con_qbft["QBFT, classical ECDSA secp256k1"]:::live
    con_besu["Hyperledger Besu producer, N equals 7"]:::live
    con_fin["about 0.5s deterministic finality"]:::live
    con_nm["Nethermind 2nd client, validate and follow"]:::live
    con_nmp["Nethermind live block producer (roadmap)"]:::road
  end

  subgraph XC["Cross-cutting concerns, span all layers"]
    direction TB
    x_pqc["PQC. precompiles, accounts, signatures LIVE. Consensus PQC (roadmap)"]:::cross
    x_zk["ZK verify. on-chain BN254 Groth16 via SP1, Halo2, RISC Zero, all classical LIVE. PQ STARK verifier (roadmap)"]:::cross
    x_agile["Crypto-agility. schemes addressable and swappable by the calling contract"]:::cross
  end

  APP -->|builds on| ACC
  ACC -->|builds on| EXE
  EXE -->|builds on| CON

  XC -.spans.-> APP
  XC -.spans.-> ACC
  XC -.spans.-> EXE
  XC -.spans.-> CON

Layer-by-layer map

Consensus (LIVE)

Aere Network runs QBFT (Istanbul BFT family) with a Hyperledger Besu block producer, signing blocks with classical ECDSA over secp256k1. The live validator set is N=7 (f=2, commit quorum 5 of 7), all Foundation-operated, at a 500 ms target block period with sub-second deterministic finality. A second execution client, a patched Nethermind 1.39.0, is LIVE as a client-diversity cross-check: it peers with the Besu validators over devp2p and independently validates and follows the live chain (verification-layer diversity). Nethermind producing live QBFT blocks is roadmap: block production and adversarial recovery are proven on isolated testnets and via offline import (Besu imports Nethermind-sealed blocks byte-for-byte), but it is not yet a live producing validator on mainnet. Consensus is classical today, not post-quantum.

Execution (LIVE base, frontier roadmap)

The EVM is at Pectra plus Fusaka parity with Ethereum mainnet (Prague/Cancun activated at block 2,075,341; Osaka at block 2,106,597), including EIP-7702, EIP-2537 BLS12-381, EIP-2935 historical block hashes, transient storage, and the RIP-7951 P-256 precompile at 0x100. Five native post-quantum precompiles are LIVE on mainnet since block 9,189,161 (Falcon-512, Falcon-1024, ML-DSA-44, SLH-DSA-128s, SHAKE256 at 0x0AE1 through 0x0AE5), NIST KAT-validated on-chain. Roadmap execution items, all built and tested but not activated on mainnet: two further precompiles (ML-KEM-768 at 0x0AE6 and Falcon HashToPoint at 0x0AE7, KAT-verified on isolated testnet); parallel execution via a Block-STM engine (correctness proven bit-identical to sequential, near-linear execution-phase scaling, but no end-to-end throughput win claimed and not enabled on L1); and a full-EVM zk validity rollup (revm in the SP1 zkVM), which is verified on-chain as a proof-of-approach on small real blocks, not yet a production-throughput rollup.

Accounts (LIVE, some V2 redeploys founder-gated)

Aere supports the full modern account spectrum: plain EOAs; WebAuthn / P-256 passkey accounts (backed by the native 0x100 precompile); ERC-4337 v0.7 smart accounts (AereEntryPointV2 live); EIP-7702 EOA delegation; a Falcon-512 post-quantum account whose sole owner is a Falcon public key; hybrid ECDSA plus Falcon authorization; and non-custodial t-of-n post-quantum threshold accounts (AereThresholdAccountFactory V2 at 0x69734E4044B1C5943B9256A73De41B101BFA2633, each committee leg verified by the live PQC precompiles).

Correction of 2026-08-01, because this line and AERE-POST-QUANTUM-GOVERNANCE.md in this same publication bundle contradicted each other. This map said the V2 factory was "live on mainnet"; the governance document said of the same address "not on mainnet, treated here as not deployed". Two public documents in one bundle cannot say opposite things about one address. Measured at head block 11,810,041: the address carries 6,835 bytes of code, against 6,717 at V1, so this map was closer to the truth and the governance document has been corrected. But neither was fully honest, and the accurate status is narrower than either: deployed, code present, build identity NOT MEASURED. The repository artifact is 7,407 bytes and reproduces neither version, so we cannot yet assert from bytecode that the deployed runtime is the duplicate-key-guard build. Do not cite it as the fixed factory until that is reproduced. Honest caveat: several first-generation account contracts had audited defects and were superseded by fixed V2 redeploys that hold zero value; some corrected factories are deployed inert and the live migration of any funds-bearing path is founder-gated.

Applications (mixed LIVE and roadmap)

• DeFi (LIVE): an isolated-market lending engine (AereLendingMarket, proven end-to-end with real supply/borrow/repay), the sAERE staking-receipt vault, and the immutable AereSink burn-and-buyback router. On AereSink, one word of that is not currently earned: the buyback. Measured at head, AereSink.DEX_ROUTER() is 0x0000000000000000000000000000000000000001 and ORACLE() is the zero address, both immutable, so the 40% buyback bucket cannot execute for a non-AERE token and the documented oracle-derived minimum-output floor is not active. The burn path and the AERE/WAERE flow work as described. Read it as a burn router that is wired, plus a buyback leg that is not. Note that sAERE has a corrected V2 whose migration is founder-gated.
• Settlement (LIVE): AereSettlementHub, AereStateChannels (24h challenge window), and AERE402 machine-to-machine payments (AereAgentV2 plus AERE402FacilitatorV2). The settlement hub is deployed in a bootstrap state holding no value pending a founder-supervised migration.
• Bridge and interop: Hyperlane-compatible message bus (AereMessenger) is LIVE, as are the inbound zk Ethereum light client and the outbound zk QBFT-finality light client (both proven live end-to-end, trust-minimized, classical BN254). ERC-7683 intent settlement (SpokePool path) is roadmap: the corrected contracts exist but are deployed inert, so no live intent route is enrolled.
• Identity and compliance: ZKScreen v3 sanctions screening is LIVE, as is a compliant, sanctions-gated privacy pool (deposit/withdraw circuit proofs are still being generated) and the AereProof proof-anchoring registry. zk-KYC and the over-18 attribute proof are roadmap (proofs generated, pending a Foundation registration signature).
• AI agents: AgentDID (Falcon-rooted decentralized identity), AIReputation, the slashable agent bond, and the InferNet inference-audit-log commitments (EU AI Act style) are LIVE. A general AI runtime and a zero-knowledge proof-of-inference (zkML) verifier are roadmap.

Cross-cutting: PQC (transversal)

Post-quantum cryptography is not a layer, it runs through the stack. LIVE: the execution-layer PQC precompiles, the PQC accounts, and application-layer PQC signature verification (for example AerePQCAttestation, proven usable end-to-end on mainnet). Roadmap: post-quantum consensus. A hybrid ECDSA plus Falcon dual-quorum design, an on-chain Falcon registry, and in-place activation without re-genesis are all proven on isolated testnets and formally analyzed as no-worse-than-ECDSA, but they are not activated on mainnet and remain audit-plus-founder gated. Consensus stays classical ECDSA QBFT today.

Cross-cutting: ZK verification (transversal)

Aere exposes a multi-prover verification surface. The on-chain verifiers that are LIVE today are all classical BN254: the SP1 Groth16 gateway, a Halo2 PLONK-over-BN254 (KZG) verifier, and a RISC Zero Groth16 verifier. These underpin ZKScreen, the privacy pool, the zk light clients, and the zk validity rollup anchors. Because BN254 pairings are Shor-breakable, this surface is not post-quantum. A post-quantum STARK verifier is roadmap. Scope caveat (2026-07-19 finding): the 0x0AE8 verifier skeleton built so far is a BabyBear + FRI STARK verifier, conformance-confirmed against Plonky3 and targeting Aere's OWN circuits; it does NOT yet verify SP1 6.1.0 proofs, because the pinned SP1 6.1.0 is a Hypercube (KoalaBear multilinear) system, a different stack. Replacing the SP1 BN254 Groth16 path is a separate ~22 to 32 person-week retarget (AERE-STARK-SP1-RECURSION-AIR-PORT-SPEC-SUMMARY.md), not done or imminent.

Cross-cutting: crypto-agility (transversal)

Signature and proof schemes are addressable and swappable by the calling contract rather than hard-wired. AereCryptoRegistry (live) maps scheme identifiers to concrete precompiles or verifiers, with additional reserved scheme slots and a governance rotation runbook, so applications can migrate primitives (for example add or rotate a PQC scheme) without redesigning the stack.

---

Convention recap: plain / green means LIVE on mainnet chain 2800; "(roadmap)" / orange dashed means built and tested but not yet activated on mainnet. Consensus is classical ECDSA QBFT; PQC is signatures, accounts, and precompiles only; on-chain ZK verifiers are classical BN254.