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,363; Osaka at block 2,106,606), 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 live on mainnet, each committee leg verified by the live PQC precompiles). 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. 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.