The non-custodial EVM Layer 1 for settlement

AERE is a public EVM Layer 1 (Chain ID 2800) whose economics are immutable by code, a sealed 37.5% base-fee burn with no admin, no proxy, and no withdrawal path, paired with an on-chain compliance-and-privacy verification layer: a sanctions-enforcing privacy pool, zero-knowledge KYC attributes, and Travel Rule tooling. Every capability below maps to a contract address you can call. 0.5-second deterministic finality (QBFT). Fixed 2.8B supply, zero insider unlocks. The chain no one can rug.

Download the PDF canonical document at aere.network/whitepaper.pdf

00 · OverviewAbstract

AERE is a public EVM Layer 1 (Chain ID 2800) whose economics are immutable by code, a sealed 37.5% base-fee burn with no admin, no proxy, and no withdrawal path, paired with an on-chain compliance-and-privacy verification layer: a sanctions-enforcing privacy pool, zero-knowledge KYC attributes, and Travel Rule tooling. Every capability below maps to a contract address you can call. The chain finalises in 0.5 seconds with deterministic QBFT (no probabilistic re-orgs), fixes supply at 2.8B with zero insider unlocks, and ships at full Pectra + Fusaka parity with Ethereum mainnet, the RIP-7951 secp256r1 precompile at 0x100 enabling native account abstraction via WebAuthn + ERC-4337 v0.7 + MultiOwnable recovery + EIP-1271 signature validation.

On throughput: the chain delivers 0.5-second deterministic finality and sub-cent fees today. The 273,000 TPS figure is a QBFT-architecture testnet benchmark, a ceiling the multi-layer roadmap scales toward, not a current mainnet rate (full methodology on /benchmarks). Consensus runs on 3 Foundation validators today, with a public path to 7 and then 21.

AERE supply is fixed at 2,800,000,000 at genesis with no further minting possible. The protocol's economic engine is the AereFeeBurnVault: an immutable sealed contract that burns 37.5% of every transaction fee on confirmation, with no admin, no withdraw, no proxy. Combined with the AereSink three-bucket router for protocol revenue (BURN / BUYBACK-AND-BURN / STAKER-YIELD, percentages set at deploy and never changeable) and sAERE (an ERC-4626 receipt token we structure as a receipt instrument, consistent with the SEC's August 5 2025 staking-receipt guidance, our position, not settled law), AERE compounds toward measurable supply contraction at scale.

Cross-chain rails ship via standard Warp Routes (USDC.e / USDT.e / USDe.e / EURC.e sequence through 2026), ERC-7683 intents, pull-oracle price feeds, and verifiable randomness. Settlement-grade primitives shipping through 2026: AereProof v0 (verifiable on-chain compliance primitives, OFAC sanctions registry, Travel Rule SDK, Forta detection bots, all read-only, all public), AERE402 (agentic settlement layer for machine-to-machine payments on Lightning channels), and the 3 → 7 validator transition. Engineered as the chain no one can rug, immutable, admin-less economics independent of validator count.

01 · ChapterIntroduction

1.1 What the chain has to do

Institutional settlement requires three things at the same time: finality that is mathematical (not statistical), execution that is fully Ethereum-compatible (so the existing engineering surface ports without rewrites), and economics that are immutable (so the protocol's monetary policy cannot be changed by a privileged operator with a multisig and a press release).

Most public Layer 1 networks deliver at most two of those three. Probabilistic-consensus chains (Nakamoto-style proof-of-work and most proof-of-stake L1s) trade determinism for openness, every transaction is rewindable until enough blocks have stacked on top to make the rewind economically painful. Permissioned BFT chains deliver determinism but at the cost of EVM compatibility and a static, operator-controlled validator set. Custodial wrappers (centralised settlement layers, tokenised-deposit ledgers) wrap the determinism around a custodian, and a custodian is a single point of permission, capture, and political risk.

1.2 How AERE solves it

AERE pairs Hyperledger Besu QBFT consensus (deterministic finality, no probabilistic re-orgs, sub-second confirmation) with the full Pectra + Fusaka EVM ruleset (every Ethereum mainnet opcode, every precompile, every account-abstraction primitive). The result is an EVM L1 that institutional teams can adopt without rewriting any contract, while end-users get finality fast enough to feel like a card swipe.

• 0.5-second deterministic finality. QBFT consensus on Hyperledger Besu. Every confirmed block is final the moment it lands, no probabilistic waiting, no settlement risk windows, no MEV-driven re-orgs by construction. Throughput scales toward a 273k TPS testnet benchmark (methodology on /benchmarks); 3 Foundation validators today, public path to 7 → 21.
• Full Pectra + Fusaka EVM parity. RIP-7951 secp256r1 precompile at 0x100, EIP-7702 EOA delegation, EIP-2537 BLS12-381, EIP-2935 historical block hashes, full Cancun opcode set. Foundry, Hardhat, viem, ethers, every Ethereum tool works day one.
• Immutable 37.5% per-tx burn. AereFeeBurnVault is a sealed contract, no admin, no withdraw, no upgrade proxy. 37.5% of every transaction fee is burned on confirmation. Monetary policy is enforced by code, not by a multisig with discretion.
• Passkey-native account abstraction. ERC-4337 v0.7 + MultiOwnable recovery + EIP-1271 signature validation. WebAuthn keys live in Touch ID, Face ID, Windows Hello, YubiKey, FIPS 186-4 ECDSA on the NIST P-256 curve (secp256r1), the same curve standard used in government/PIV smart cards.
• Cross-chain Warp Routes. Bytecode-identical bridged stablecoins (USDC.e, USDT.e, USDe.e, EURC.e) ship through 2026. ERC-7683 intents settle in seconds across 30+ chains. Pull-oracle price feeds; threshold-BLS verifiable randomness.

02 · ChapterTechnical architecture

2.1 Key equations

The AERE architecture rests on a handful of explicit relations. They are stated here so a technical reader can check the claims rather than take them on faith.

Transaction throughput (single-chain QBFT)

TP = transactions per second; B = effective transactions per block (gas-limit / avg-tx-gas); Tblock = block time (0.5s on AERE). AERE executes on a single QBFT chain, there is no sharding. Higher throughput surfaces are delivered via L2 rollups (§2.4), not base-layer shards.

Gas calculation

Gtotal = total gas; Gbase = base gas (21,000 for a standard transfer); Gdata = gas per data byte; Size = data size in bytes; Gexec = contract-execution gas. Gas costs match the Pectra + Fusaka schedules.

Staking reward (fee-share, no emission)

Rstaker = staker reward over the epoch; S = individual stake; Stotal = total stake in the sAERE pool; Tf = fees routed through AereSink during the epoch; β = STAKER-YIELD bucket share of Tf (set immutably at AereSink deploy time). AERE has no block subsidy, staking yield is paid entirely from fee flow.

Network security threshold

Tsecurity = maximum Byzantine validators the network tolerates; n = total validators. With n = 3 today, tolerance is 0 faulty nodes; the transition to 7 validators raises it to 2.

2.2 Consensus mechanism

AERE runs Hyperledger Besu QBFT (Quorum Byzantine Fault Tolerance), a BFT consensus with immediate finality and 0.5-second block production. QBFT is chosen for its predictable latency and deterministic finality (no probabilistic confirmations), the property that makes it suited to settlement, where a transaction must not be rewindable once confirmed. AERE runs 3 Foundation-operated validators today, with a public path to 7 and then 21 (§6). The network is not yet decentralised; this is stated plainly, not implied away.

• 0.5s deterministic finality: transactions reach immediate, deterministic finality in 0.5 seconds, no probabilistic confirmations, no reorgs. Suited to settlement and real-time payments.
• Energy profile vs proof-of-work: QBFT consumes orders of magnitude less energy than proof-of-work chains. Throughput scales toward a 273k TPS testnet benchmark, the architectural ceiling, not the current mainnet rate; sustained mainnet throughput under real load is publicly observable via the live indexer. See /benchmarks for methodology.
• Byzantine fault tolerance (f < n/3): QBFT tolerates up to ⌊(n−1)/3⌋ Byzantine validators. With 3 validators today, the network tolerates 0 faulty nodes; the transition to 7 validators raises tolerance to 2.
• Validator set and economics: 3 Foundation-operated validators today, public path to 7 and then 21. The network is Foundation-operated at consensus level and not yet decentralised, the immutable economics (§3.3) are what make it rug-proof today, independent of validator count. Validators are compensated from coinbase rewards routed through the AereCoinbaseSplitter (62.5% validator / 37.5% AereFeeBurnVault). There is no block emission; rewards are purely fee-based.

2.3 Single-chain QBFT execution

AERE is a single-chain QBFT network, there is no base-layer sharding, no beacon chain, no parallel shard execution. All transactions execute on one canonical chain with deterministic 0.5-second finality. Higher aggregate throughput targets are addressed via Layer-2 anchors (§2.4 / §6.3), not by partitioning the base layer. This is intentional: shared single-chain state composes natively with EVM tooling, removes cross-shard atomicity edge cases, and matches the settlement use case AERE targets.

2.4 Multi-layer scaling architecture (forward-looking targets)

AERE's scaling roadmap stacks Layer-2 systems above the QBFT base chain. The list below is a forward-looking target stack with explicit per-line dates; current deployments are tracked in §6. See /benchmarks for methodology behind the up-to-273,000 TPS aggregate test result.

• Base Layer (QBFT, live): single-chain execution, 0.5-second deterministic finality, throughput bounded by per-block gas limit.
• Optimistic Rollups (target Phase 3, Q2, Q4 2027): chainIds 28001-28008 with AereRollupVerifier + ZK finality gates per rollup.
• ZK-Rollups (target Q4 2027): scale-out to 15 operators with Groth16 validity proofs; one production AereZKRollup8 anchor live today.
• State Channels (target Q4 2027): scale to 7,500 active channels; AereLightningChannels primitive live today.
• Plasma Chains (target Phase 3, Q2, Q4 2027): AerePlasmaRootV2, sparse Merkle UTXO tree (depth 16, 65,536 UTXOs).

2.5 EVM compatibility

AERE ships full Pectra + Fusaka EVM parity. Solidity, Vyper, and any EVM-compatible language compile and execute identically to Ethereum mainnet, with no source modifications required for existing contracts. Compatible with Foundry, Hardhat, Remix; full integration with web3.js, ethers.js, viem, and all Ethereum client libraries; native support for MetaMask, Ledger, Trezor, WalletConnect, and every major Ethereum wallet.

Pectra-activated EIPs (block 2,075,363):

• EIP-7702, EOA delegation to smart-contract code (native account abstraction; complements ERC-4337).
• EIP-2537, BLS12-381 curve precompiles at 0x0b, 0x11 for cheap on-chain BLS signature verification (~70× cheaper than Solidity).
• EIP-2935, historical block hashes (up to 8,192 blocks back) via system contract; enables trustless cross-chain state proofs.
• EIP-1153, transient storage opcodes (TSTORE/TLOAD); gas-efficient reentrancy guards and callbacks.
• EIP-5656, MCOPY opcode for efficient memory operations.
• EIP-6780, scoped SELFDESTRUCT semantics.
• EIP-7516, BLOBBASEFEE opcode (returns 0 on AERE; no consensus-layer blob market).

Fusaka-activated additions:

• RIP-7951, secp256r1 / P-256 signature-verification precompile at address 0x100. Verifies signatures from Apple Face ID / Touch ID, Apple Secure Enclave, Windows Hello, Android biometric APIs, YubiKey, TPM 2.0, EMV cards, and the EU Digital Identity Wallet at ~3,500 gas, versus ~250,000 gas required to verify the same signature via Solidity. Foundational primitive for passkey-based wallet UX on AERE.

QBFT-specific notes: EIP-4788 parent_beacon_block_root is set to zero on every block (AERE has no separate consensus-layer beacon chain). EIP-4844 blob header fields are present but no blob transactions are produced or accepted; the point-evaluation precompile at 0x0A is present and is used by the on-chain KZG opening verifier (§5.7). Fusaka EIPs that are consensus-layer-only or rollup-only (PeerDAS, FOCIL, EOF) are no-ops on QBFT.

03 · ChapterTokenomics & burn engine

3.1 AERE token overview

AERE is the native token of chain 2800 and the only token on the chain, there is no wrapped stablecoin, no governance token, no liquidity-mining token. AERE pays gas, secures stake, and earns variable staking yield from protocol fee flow. AERE has no mining, no proof-of-work, and no block subsidy on QBFT. Total supply is fixed at 2.8 billion at genesis; no further minting can occur. Distribution is fully transparent on-chain, every AERE sits at one of six genesis-allocated reserve addresses, queryable via eth_getBalance.

• Maximum supply: 2.8 billion AERE (fixed at genesis, no further minting possible).
• Token standard: native chain-2800 token; ERC-20 wrapper (WAERE) available for DEX integration.
• Block subsidy: none. QBFT validators earn transaction fees only. No PoW emission, no inflation.

3.2 Token distribution

The 2.8 billion supply was allocated at genesis-v2 (2026-05-07) to six reserve addresses, all visible on-chain and queryable in real time on the public RPC.

• Reserve (scheduled distribution) · 1.4B AERE (50%), released exclusively through the AereMiningSubscription contract (its on-chain name; the mechanism is not proof-of-work mining, there is no block subsidy on QBFT). A transparent, scheduled, contract-mediated distribution from an existing reserve. Reserve 0x038f…fFB8.
• Ecosystem Reserve · 560M AERE (20%), developer grants, ecosystem partnerships, liquidity provisioning on AERE-native DEX venues, cross-chain-registry integration incentives. Reserve 0xB6a3…1C75.
• Team Reserve · 420M AERE (15%), contributing team and advisors, subject to multi-year linear vesting. Reserve 0x7968…CCdf.
• Foundation Treasury · 180M AERE (6.43%), validator hosting, infrastructure, contract deployments, paymaster funding for onboarding, ongoing development. Available from day 1. Address 0x0243…f3C3.
• Airdrop Reserve · 140M AERE (5%), community distribution events, ambassador programs, retroactive contributor rewards, milestone-triggered airdrops. Reserve 0x2619…28B1.
• Strategic Allocation · 100M AERE (3.57%), distributed off-chain to strategic backers who funded early development; fully unlocked at genesis as part of the 280M initial circulation. Address 0xaee2…1311.

Verification: all six reserve addresses are listed on docs.aere.network and balances can be queried via eth_getBalance on rpc.aere.network at any block. The supply math is verifiable to the wei: total of all six reserves + burns + circulating EOAs = exactly 2,800,000,000 AERE.

3.3 Burn engine + sAERE flywheel

AERE's monetary policy is enforced by immutable on-chain contracts, not by a multisig with discretion. Every transaction fee that lands in the protocol passes through these contracts on confirmation; the percentages are set at deploy and cannot be changed by any operator, validator, or Foundation address. The Foundation cannot pause them, withdraw from them, or upgrade them, they have no admin role, no upgrade proxy, and no rescue function.

• AereFeeBurnVault, 37.5% per-transaction burn. A sealed contract that receives 37.5% of every transaction fee at block confirmation and burns it by transferring to 0x000…dEaD. No admin, no withdraw, no upgrade. Verifiable on the explorer at every block: burnVault.balance increases monotonically with network activity. Deployed 0x696a…B2c6.
• AereSink, three-bucket immutable router. A second immutable router that routes protocol-level revenue (sAERE staking flow, DEX swap fees, lending interest, agentic settlement) into three fixed buckets, BURN / BUYBACK-AND-BURN / STAKER-YIELD, split 15 / 40 / 45. Percentages are set at deploy and never changeable. No admin, no upgrade. Deployed 0x6958…1676.
• sAERE, ERC-4626 receipt token. Stakers deposit AERE and receive sAERE, a non-rebasing ERC-4626 receipt token. We structure sAERE as a receipt instrument, consistent with the SEC's August 5 2025 staking-receipt guidance (the analysis applied to stETH). This is our position, not settled law. sAERE accrues protocol revenue via AereSink's STAKER-YIELD bucket. No insider unlock, no privileged emission, no governance discretion. Deployed 0xA212…50b0.
• Reserve release schedule (not a PoW halving). The AereMiningSubscription contract distributes from the 1.4B scheduled-distribution reserve on a step-down schedule. This is a transparent, scheduled, contract-mediated distribution from an existing reserve, not a proof-of-work emission. There is no QBFT block subsidy and no new minting, total supply remains 2.8B fixed.

04 · ChapterDAO governance

4.1 Governance model

AERE's target governance design is a token-weighted DAO framework that lets AERE holders propose, vote on, and execute protocol-level changes. Decisions are bound by on-chain timelocks and supermajority thresholds rather than off-chain coordination. Votes are weighted by sAERE balance at snapshot block; holders may delegate voting power to a representative address, revocable per-block. Approved proposals are executed by the governance contract automatically after the 48-hour timelock expires, with no manual operator step. Security rests on NIST-grade cryptographic primitives (FIPS 186-4 ECDSA P-256, FIPS 180-4 SHA-256) plus mandatory timelock delays.

4.2 Governance parameters (target design)

• Proposal threshold: 100,000 AERE to submit an on-chain proposal.
• Voting window: 7 days.
• Execution delay: 48-hour timelock before an approved proposal deploys.
• Quorum: 10% of staked tokens must participate.
• Approval threshold: 66% supermajority for protocol changes.

Note: the governance surface is scoped to protocol parameters. It cannot alter the immutable burn/router economics (§3.3), those contracts have no admin path, by design.

05 · ChaptersAERE · AereProof · AERE402

5.1 sAERE flywheel, non-custodial staking receipt

sAERE is the canonical staking receipt for AERE. Stakers deposit AERE and receive sAERE at deposit time; the conversion ratio drifts upward as protocol revenue accrues through AereSink. sAERE follows ERC-4626, the standard for tokenised vault shares. We structure it as a receipt instrument, consistent with the SEC's August 5 2025 staking-receipt guidance (the analysis applied to stETH); this is our position, not settled law. It is the one approved exception to the AERE-only-token rule.

5.2 AereProof v0, verifiable on-chain compliance

AereProof v0 is a stack of verifiable on-chain compliance primitives, positioned as a public good and operated by the Foundation as a read-only service. The goal is to make institutional compliance integration verifiable from the chain itself, without requiring a centralised attestor or custodian intermediary.

• AereSanctionsRegistry Production, a read-only registry of OFAC SDN-listed addresses, updated by Foundation-operated cron pulling the official SDN list. Any contract or front-end can read it to check whether a counterparty is sanctioned. Public, auditable, no fee. Deployed 0xb7d2…Cacf.
• Chainalysis oracle wrapper Production, wraps Chainalysis's free sanctions oracle for on-chain reads. Deployed 0x1B7B…f85c.
• Notabene Travel Rule SDK Production, FATF Travel Rule message exchange for institutional transfers above threshold, plus an on-chain Travel-Rule hash registry (0xcF0E…4c84).
• Forta detection bots Production, real-time detection bots monitor for suspicious-flow patterns and emit on-chain alerts. Open-source; the alert stream is read-only and public.
• AereZKScreen, zero-knowledge compliance screening Production, a privacy-preserving screening anchor on the SP1 zkVM. A user proves, in zero knowledge, that they belong to a Foundation-authorised allow-list (KYC, accredited-investor, or eligible-jurisdiction set) without revealing their identity or which entry is theirs, no personal data ever touches the chain. The proof is verified on-chain by the SP1 v6.1.0 Groth16 verifier, and the program binds a Foundation-set authorised root, so a proof only counts against the official list. dApps gate access with isCleared(user, program, minTimestamp). Proven end-to-end on 2026-07-07: a real SP1 Groth16 proof cleared an address on chain 2800 (0x3A09…C2f1) with no PII revealed. Designed as necessary-not-sufficient, consuming applications combine it with a live sanctions check and a freshness window.
• AereCompliancePool, compliant privacy pool Production, a Privacy-Pools construction (Buterin et al.) with a Travel-Rule hook. Fixed-denomination deposits; withdrawals require an association-set proof so an OFAC-sanctioned address cannot exit. This is a sanctions-enforcing privacy primitive, the opposite of an evasion mixer, deployed on chain 2800 (0x7973…D41d) with a real SP1 circuit verification key. It gives users lawful financial discretion while keeping the compliance guarantees regulators require.
• AereAIProof, AI model-output attestation Production, an EIP-712 attestation log for AI model outputs. A registered model's signer attests (modelId, inputHash, outputHash, requesterHash) so an output's provenance is tamper-evident without revealing prompts or completions. Deployed 0xFf92…97e6.
• Zero-knowledge attribute family Experimental, beyond allow-list membership, AereZKScreen defines distinct SP1 attribute programs, each a separate verification key bound to a Foundation-authorised issuer root: over-18 (proves an issuer-attested birth year means age ≥ 18 without revealing the date of birth), EU-jurisdiction (proves the attested jurisdiction is one of the 27 EU member states without revealing the country), and accredited-investor (proves attested net worth ≥ $1,000,000 under the US Reg D test without revealing the amount). The over-18 program has a real Groth16 proof generated end-to-end and is pending a single Foundation authorising signature on-chain; the EU-jurisdiction and accredited-investor programs are specified against the same circuit pattern and not yet proven on-chain.
• Recursive proof aggregation Production, real recursion that folds three distinct real inner SP1 proofs (zkscreen, over-18, and zkml-mnist), each generated from its exact on-chain production ELF and verified in-zkVM via verify_sp1_proof, into one 356-byte Groth16 proof that is gateway-verified on chain 2800. Deployed AereProofAggregator (0x6a26…84C5). Honest scope: bounded to N=3 inner proofs per run today; the guest and the contract accept any N, so the limit is prover time and memory, not the design.

5.3 AERE402, agentic settlement and AI infrastructure

AERE402 extends HTTP 402 (Payment Required) into a production settlement primitive for machine-to-machine economic interactions. Where REST APIs today rely on out-of-band API keys and centralised billing, AERE402 lets any HTTP-402 client or autonomous agent pay per call directly on-chain, with sub-second confirmation and the same execution guarantees as settlement, a standard payment interface, not a partnership with any specific model provider. The companion AereAgent runtime provides a Lightning-channel-style payment-channel layer for sub-cent settlement of high-frequency agent interactions. Off-chain ticks net to on-chain settlement at channel close, preserving full atomicity and dispute resolution. Deployed: AERE402Facilitator (0xbA6e…4E56), AereAgent (0xE963…3536).

Around that payment rail, AERE ships an agent-trust and AI-accountability layer, additive registries with no new token:

• AereAgentBond Production, a slashable bond an AI agent posts in WAERE. Misbehaviour slashes the bond and the slashed WAERE flushes irreversibly to the AereSink burn router. The slashing oracle is the Foundation multisig. Deployed 0x32E0…B86A.
• AereAIReputation Production, a composable 0-10000 reputation score layered over AereAgentBond; the attestor is the Foundation multisig. Deployed 0x781e…feBF.
• AereAgentMemoryVault Production, portable, user-owned agent memory: the user owns the namespace, agents read and write per-slot only under explicit permission, and the payload blobs stay off-chain. No admin path. Deployed 0x309b…D641.
• AereInferNet, AI inference-log compliance oracle Production, an on-chain commitment layer aligned to EU AI Act Article 12 logging: an inference provider commits a Merkle root of its inference logs per epoch and anyone can later prove a specific record was included. The chain stores commitments only, no prompts, no completions, no PII. Permissionless, no admin. A reference off-chain batcher daemon builds and posts the roots. Deployed 0xba76…f856.

5.4 Post-quantum cryptography suite

AERE runs an unusually broad set of NIST post-quantum signature verifiers directly on-chain. We are not aware of any other public chain that verifies all of these signature schemes on-chain; we state this as a hedge, not an unqualified "world first". The honest distinction throughout is recording (a state-changing verifyAndRecord transaction fits under the L1 EIP-7825 per-transaction gas cap of 2²⁴) versus view-only (verification is correct and demonstrable through eth_call, but a recording transaction would exceed that per-tx cap). View-only does not mean simulated: each view-only verifier is validated bit-for-bit against official NIST vectors and returns true for valid signatures and false for tampered ones via eth_call on chain 2800.

• Falcon-512 Production · recording, AereFalcon512Verifier (0x4E8e…8fFC), a spec-complete NIST Falcon-512 verifier: full NTT-512 negacyclic arithmetic over q=12289 plus SHAKE256 HashToPoint and the short-vector norm check, on-chain in about 10.5M gas, validated against the official NIST round-3 Known-Answer-Test (KAT) vectors. Honest scope: verification only, not key generation or signing. It supersedes the earlier reduced-parameter n=64 AereLatticeVerifier core.
• Falcon-1024 View-only, AereFalcon1024Verifier (0xF0aF…6e36), the higher-security Falcon parameter set, KAT-validated (valid→true, tampered→false via eth_call). Its verify() is a pure view; a recording call is about 21.7M gas and exceeds the L1 per-tx gas cap, so it is intentionally view-only.
• WOTS+ (hash-based) Production · recording, AerePQCVerifier (0x1cE2…6F82), a Winternitz one-time hash-based signature verified natively in Solidity. Security rests on keccak pre-image resistance, which quantum computers do not break. Live valid-verify and forged-reject demonstrated.
• XMSS (RFC 8391) Production · recording, AereXmssVerifier (0x77b1…B112), a many-time hash-based scheme (WOTS+ leaf plus an h=10 SHA-256 Merkle authentication path to the long-term root), the honest many-time extension of the WOTS+ verifier. Validated against the official xmss-reference KAT; verifyAndRecord used about 1.56M gas, well under the per-tx cap. Honest scope: it verifies a signature; it does not enforce the signer's one-time-per-leaf state.
• ML-DSA-44 / Dilithium2 (FIPS 204) View-only, AereMLDSA44Verifier (0xf1F7…85AE), a full module-lattice verifier (ExpandA via SHAKE128 rejection sampling, the NTT over Z_q with q=8380417, SampleInBall, UseHint, and the norm bound), validated bit-for-bit against the official NIST ACVP ML-DSA sigVer vectors, all 15 cases (3 valid, 12 crafted-invalid). A full verify is about 52.9M gas and exceeds the per-tx cap, so it is view-only like Falcon-1024.
• Hybrid ECDSA + Falcon-512 authorization Production · recording, AereHybridAuth (0xc203…FAA1) authorizes an action only if BOTH a secp256k1 ECDSA signature AND a NIST Falcon-512 signature verify over the same 32-byte hash (the Falcon leg calls the live Falcon-512 verifier). This is a migration primitive: classical and post-quantum assurance at once. Demonstrated live, an accepted authorize transaction used about 10.3M gas, under the per-tx cap; the view rejects a tampered Falcon leg or a wrong ECDSA leg.

5.5 Confidential compute via threshold MPC

AereConfidentialCompute (0x2120…c287) anchors a threshold multi-party-computation layer that evaluates an agreed arithmetic circuit over parties' private inputs. It uses real Shamir secret sharing over the BN254 scalar field and a real BGW multiplication gate (local degree-2d product, then re-share and reduce back to degree-d with the public Lagrange reduction vector), so no single node, and no colluding minority below the reconstruction threshold, ever learns any input; only the agreed public outputs are revealed. The deployed committee is 5 nodes with MPC reconstruction threshold 3 and an on-chain signature quorum of 4.

5.6 Parallel execution, rollup validity, and token-bound accounts

Block-STM parallel executor. AERE ships a real Block-STM optimistic-concurrency parallel executor, written from scratch in Rust with no external crates (multi-version memory, dynamic dependency detection, abort and re-execute, keccak256 state root). It is benchmarked at about 8.6x to 9.3x on 16 cores for low-to-medium-conflict batches, and its correctness is proven: across 1200 randomized batches run at 1/2/4/8/16 threads, the parallel result equals sequential execution in every case. Honest scope: this does not make AERE's Layer-1 base execution parallel. The L1 runs Hyperledger Besu and executes transactions sequentially; parallelizing Besu itself is a Java execution-client fork and is out of scope. The executor is wired into the rollup sequencer instead: a rollup batch is a pure, well-defined, parallelizable workload, and the sequencer refuses to emit a state root unless the parallel and sequential runs agree. An opt-in read/write slot-hint registry for the scheduler, AereBlockSTMRegistry (0x98E2…8A28), is deployed on-chain (advisory only, no admin over others).

Rollup validity proof (proof of concept). AereRollupValidity (0x3877…7fbd) is the on-chain settlement anchor for SP1 Groth16 validity proofs of the rollup executor. Epoch 0 was recorded from a real SP1 v6 Groth16 proof, verified through the SP1 verifier gateway on-chain (submission under the per-tx gas cap), and its post-state root is byte-identical to the production Block-STM executor's root for the same batch. Honest scope: this is a proof of concept that proves the current bounded-VM executor (Transfer, Sweep, Increment, AmmSwap over a balance and storage map), not a full-EVM validity rollup. The contract has no owner; the verifier, program key, and genesis root are immutable, and epoch submission is permissionless, gated only by the zk proof and prevRoot continuity. The honest next step toward a full validity rollup is replacing the guest VM with a full EVM (revm), a separate multi-quarter effort.

ERC-6551 token-bound accounts. A canonical ERC-6551 registry (0x7fFd…EF68) and token-bound-account implementation (AereTokenBoundAccount 0xBc5e…F9E2) are live: an AereNFT can own a smart-contract wallet that holds assets, signs via EIP-1271, and executes calls (also ERC-4337 through the V2 EntryPoint). These are account and registry primitives, not tokens.

Verified contract source. Contract source is published and verified Sourcify-style: 34 contracts are source-verified, browsable on a public verified-contracts page, so anyone can match on-chain bytecode to the exact source and compiler settings.

5.7 Modular accounts, interoperability v3, and application-level building blocks

Modular ERC-7579 smart accounts (session keys and social recovery). A modular account factory, AereModularAccountFactory (0xE3f4…440E), deploys ERC-7579-style accounts with pluggable validator modules. Two modules are live: AereSessionKeyValidator (0x6e03…0D26) authorizes scoped, time-bounded session keys (a delegated key limited to specific targets and selectors, with an expiry), and AereSocialRecoveryModule (0x0775…D812) rotates the account owner through guardians behind a 48-hour timelock. Proven live: a userOp signed only by a scoped session key executed through the live AereEntryPointV2.

Hyperlane v3 interoperability with a working quoteDispatch. A real Hyperlane v3 deployment is live on the AERE side: a Mailbox (0x7BF1…605a) and an InterchainGasPaymaster (0x5e4B…744c), both owned by the Foundation multisig. quoteDispatch returns a real interchain gas quote and dispatch is wired end-to-end, upgrading the earlier Mailbox-compatible AereMessenger / AereIGP bus.

USDC.e Warp Route on Hyperlane v3. AereWarpRouteV3 (0x1f44…E098) rides the v3 mailbox above. Honest scope, stated plainly: the AERE side is live and proven (deployed, wired, reserve invariant tested end-to-end), while the Ethereum L1 leg still needs an L1 deployment and real ETH gas, so cross-chain flow is pending that bring-up. The two legs are separate.

Multi-prover ZK substrate (KZG and Halo2). Alongside the SP1 (Groth16 + Plonk) and RISC Zero routes, AereKZGVerifier (0x6596…C862) verifies a KZG polynomial-commitment opening by calling the live EIP-4844 point-evaluation precompile at 0x0A, and AereHalo2Verifier (0x414C…dC55) is a real on-chain Halo2 (PLONKish, KZG-backed) verifier. Recursion has been demonstrated at scale: the AereProofAggregator flow has folded 8 or more real SP1 child proofs into one Groth16 proof, gateway-verified on-chain; the guest and contract accept any N, so the limit is prover time and memory, not the design.

06 · ChapterDevelopment roadmap

6.1 Phase 1: Foundation, completed (May, Jul 2026)

• Mainnet on QBFT consensus, Chain ID 2800, 0.5-second blocks (transitioned from 1s at block 2,138,451).
• Pectra EVM ruleset activated (2026-05-31): EIP-7702, EIP-2537, EIP-2935, full Cancun opcode set, functional parity with Ethereum mainnet.
• Fusaka EVM ruleset activated (2026-05-31): RIP-7951 secp256r1 / P-256 precompile at 0x100.
• Multi-Paymaster stack live: EntryPoint plus OnboardingPaymaster, TokenPaymaster, StakeQuotaPaymaster, and a permissionless AppPaymasterFactory.
• Cross-chain messaging layer live: AereMessenger (Mailbox-compatible bus) + AereIGP (Interchain Gas Paymaster).
• Intent-based cross-chain UX live: AereSpokePool (ERC-7683-compatible) + AereERC7683 (IOriginSettler).
• IPyth-interface pull oracle live: AerePyth + AereOracleAdapter.
• Verifiable randomness beacon live: AereRandomnessBeacon + AereDrandConsumer (threshold-BLS-12-381).
• Deflationary fee-burn flow live: AereCoinbaseSplitter routes 37.5% of every validator coinbase sweep to AereFeeBurnVault (permanently destroyed), 62.5% back to the validator. burnVault.balance publicly readable.
• MEV-resistant batch-auction DEX live: AereSettlement (CoW-style batch settlement), AereVaultRelayer, AereSolverRegistry.
• Developer fee monetization live: AereFeeMonetization, registered contracts earn a share of the gas fees users pay to them.
• Sub-second block time activated (2026-05-31): QBFT block period dropped 1s → 0.5s at block 2,138,451.
• Universal Login deployed (2026-06-01): AerePasskeyAccountFactoryV2 (0x5FFa…34fdA) + AereEntryPointV2 (0x8D6f…aF770). Multi-owner accounts, real ERC-4337 validateUserOp + EIP-1271, recovery via owner-self-add.
• Passkey wallets via Touch ID / Face ID (2026-06-01): AerePasskeyAccountFactory (0xfB0e…30739). secp256r1 ECDSA verified on-chain in ~6,900 gas via RIP-7951.
• Native zk-proof verification (2026-05-31): SP1 v6.1.0 + RISC Zero zkVM verifier contracts deployed via the upstream gateway/router pattern. First real application-level proof followed 2026-07-07: AereZKScreen cleared an address through a genuine privacy-preserving compliance screen.
• zkML MNIST classifier Production (2026-07-07): a 784→256→10 MLP runs integer inference inside SP1 and proves a classification while the input image stays fully private; 97.98% accuracy on the full 10,000-image MNIST test set, real Groth16 proof verified on-chain (AereZKMLVerifier 0xf1BF…783c). Honest scope: MLP not CNN, accuracy measured off-chain over 10k, one image proven on-chain per proof.
• Recursive proof aggregation Production (2026-07-07): AereProofAggregator (0x6a26…84C5) folds three distinct real inner SP1 proofs (zkscreen, over-18, zkml-mnist), each from its exact on-chain production ELF, into one 356-byte Groth16 proof verified on-chain. Honest scope: bounded to N=3 per run today; the guest and contract accept any N, so the limit is prover time and memory, not the design.
• Post-quantum hash-based signature verification Production (2026-07-07): AerePQCVerifier verifies WOTS+ signatures natively in Solidity.
• Post-quantum Falcon-512 verifier Production (2026-07-07): AereFalcon512Verifier (0x4E8e…8fFC) is a spec-complete NIST Falcon-512 verifier, validated against the official NIST round-3 KAT vectors, running full NTT-512 plus SHAKE256 verification on-chain in about 10.5M gas. Honest scope: verify-only, not keygen or signing, and Falcon-512 not 1024. Supersedes the earlier n=64 AereLatticeVerifier.
• DePIN compute marketplace Production (2026-07-07): AereComputeMarketV2 (0x33E3…ca32) plus a real reference provider daemon; 3 real jobs posted, claimed, run, and settled end-to-end on-chain. Honest scope: the rail is operational and anyone can run the daemon to earn, but large-scale GPU supply is adoption-gated as hardware operators choose to join.
• Post-quantum cryptography suite Production (2026-07-10): added on-chain verifiers for Falcon-1024 (view-only), WOTS+, XMSS / RFC 8391 (recording, ~1.56M gas), ML-DSA-44 / Dilithium2 FIPS 204 (view-only, NIST ACVP-validated), a hybrid ECDSA+Falcon-512 authorizer, and a Falcon-512 finality-attestation layer that runs alongside QBFT (not consensus PQC). See §5.4.
• Confidential compute via threshold MPC Production (2026-07-10): AereConfidentialCompute (0x2120…c287), real Shamir + BGW MPC, on-chain threshold-signed result verification. Semi-honest threat model; TEE path not built (no attestation hardware). See §5.5.
• Agent-trust + AI-accountability layer Production (2026-07-10): AereAgentBond, AereAIReputation, AereAgentMemoryVault, and the AereInferNet inference-log compliance oracle (EU AI Act Article 12, no PII). See §5.3.
• Block-STM parallel executor wired into the rollup sequencer + a real SP1 Groth16 rollup-validity proof of concept Production (2026-07-10): AereRollupValidity (0x3877…7fbd), epoch 0 recorded. Honest scope: L1 stays Besu-sequential; this parallelizes L2 batches and proves a bounded-VM executor, not a full-EVM rollup. See §5.6.
• ERC-6551 token-bound accounts Production (2026-07-10): registry (0x7fFd…EF68) + AereTokenBoundAccount. Contract source verified Sourcify-style (34 contracts).
• Cancun opcode set proven live on-chain Production (2026-07-10): AereCancunCanary (0x8DbF…5498) demonstrates TSTORE/TLOAD (incl. cross-tx auto-reset), MCOPY, PUSH0, and BLOBHASH / BLOBBASEFEE returning correct values. See §2.5.
• Modular ERC-7579 accounts with session keys + social recovery Production (2026-07-10): AereModularAccountFactory (0xE3f4…440E) + AereSessionKeyValidator (0x6e03…0D26) + AereSocialRecoveryModule (0x0775…D812, 48h guardian timelock). Proven live: a userOp signed only by a scoped session key executed through the live EntryPointV2. See §5.7.
• Hyperlane v3 interoperability with a working quoteDispatch Production (2026-07-10): live Hyperlane v3 Mailbox (0x7BF1…605a) + InterchainGasPaymaster (0x5e4B…744c), Foundation-multisig-owned. USDC.e AereWarpRouteV3 (0x1f44…E098) rides it: AERE side live and proven, Ethereum L1 leg pending. See §5.7.
• Multi-prover ZK substrate expanded Production (2026-07-10): AereKZGVerifier (0x6596…C862, uses the live EIP-4844 precompile at 0x0A) + a real Halo2 verifier AereHalo2Verifier (0x414C…dC55), alongside SP1 (Groth16+Plonk) and RISC Zero; recursion demonstrated at scale (8+ SP1 child proofs folded into one). See §5.7.
• Threshold-encrypted mempool PoC Application-level PoC (2026-07-10): AereShutterMempoolV2 (0x1351…9310), an opt-in, app-level anti-MEV commit/reveal. NOT a protocol-level QBFT feature; not wired into consensus. See §5.7.
• Storage-proof canonicity anchor Bounded window (2026-07-10): AereStateRootAnchor (0x78b4…57cb). Canonicity via the 256-block BLOCKHASH window (~128s); EIP-2935 is not deployed on chain 2800, so there is no extended lookback. See §5.7.
• Live block explorer at explorer.aere.network; public RPC at rpc.aere.network (TLS) and WebSocket at wss.aere.network.

6.2 Phase 2: Expansion (Jun 2026, Q1 2027), in progress

• Cross-chain bridge contract deployed (federated 2-of-N, ready for counterparties).
• Staking live: stake AERE for sAERE (ERC-4626 receipt) earning variable STAKER-YIELD from protocol fee flow. AERE is QBFT, so there is no mining, no hashpower, and no promised or fixed return.
• DeFi suite: yield farms, oracle feeds, payment channels, NFT marketplace, faucet.
• Lending engine live and proven end-to-end (2026-07-07) using existing sAERE/WAERE, no new token. Note: AereUSD/AereUSDC was retired per the AERE-only-token rule; stablecoin settlement is via USDC.e Warp Route (§6.4).
• Vote delegation + locked staking tiers (30/90/180/365-day) live.
• Validator set expansion to 7 nodes (tolerates 2 Byzantine per ⌊(n-1)/3⌋), pending capacity.

6.3 Phase 3: Innovation (Q2, Q4 2027), base-layer anchors live, scaling out

This tier distinguishes shipped contract from planned network. Live today: the base-layer anchor contracts, one production ZK-rollup anchor, one reference ZK system, and the Lightning / state-channel primitives. The multi-instance networks (8 optimistic rollups, 6 plasma chains, a full Lightning routing mesh, 15-operator ZK scale-out) are not yet built; they are §2.4 forward-looking targets with per-line dates, not a claim they run at target scale in production today.

• Live · Layer-2 anchor contracts deployed: AereRollupVerifier, AerePlasmaRootV2, AereShardCoordinator, base-layer primitives that L2 systems anchor to.
• Live · one production ZK-rollup anchor: AereZKRollup8 (depth-3 Poseidon Merkle state, Groth16 transfer proofs). One reference ZK system: circom 2 Poseidon preimage circuit + Groth16 on BN254 (/zk.html), browser-generated, verified on-chain.
• Live · Lightning / payment-channel primitives: AereHTLC, AereChannelRegistry, AereLightningChannels reference contracts with in-channel HTLCs and a 1-day dispute challenge window. These are building-block primitives, not a production-scale routing mesh.
• Live · parallel L2 execution + validity anchor: a real from-scratch Rust Block-STM executor is wired into the rollup sequencer (parallel result proven equal to sequential), and AereRollupValidity anchors a real SP1 Groth16 validity proof of the executor (epoch 0). Honest scope: the L1 base stays Besu-sequential; this is L2-batch parallelism and a bounded-VM validity proof of concept, not a full-EVM validity rollup. See §5.6.
• Planned / not yet built (target Q2, Q4 2027): 8 optimistic rollups (chainIds 28001-28008), each with sequencer + L1↔L2 bridge and a ZK finality gate.
• Planned / not yet built (target Q2, Q4 2027): 6 plasma child chains, each with its own AerePlasmaRootV2 and a sparse Merkle UTXO tree (depth 16, capacity 65,536 UTXOs).
• Planned / not yet built (target per §2.4): scale-out to 15 ZK-rollup operators + 7,500 state channels, and multi-shard committees on AereShardCoordinator.

6.4 2026 roadmap

• sAERE flywheel: ERC-4626 receipt token + AereSink 3-bucket immutable router (BURN / BUYBACK-AND-BURN / STAKER-YIELD).
• USDC.e cross-chain Warp Route: EU/UK BaaS rail, institutional default settlement currency.
• AereProof v0: verifiable on-chain compliance primitives, sanctions registry + Chainalysis wrapper + Notabene Travel Rule SDK + Forta detection bots.
• AereSettlementHub: institutional rails for tokenized assets (BUIDL, USDY, OUSG, LBTC, SolvBTC, pumpBTC).
• AereBugBountyVault: bug bounty paid in AERE; Code4rena / Cantina / Sherlock contest outreach.

6.5 Q4 2026, agentic + cross-chain

• AERE402 + AereAgent (shipped early, live): agentic settlement layer (HTTP 402 / x402) with a 25 bps flywheel cut to AereSink; AereStateChannels provides the Lightning-EVM payment-channel runtime.
• USDT.e / USDe.e / EURC.e Warp Routes: emerging-markets, synthetic-dollar, and EUR settlement rails.
• AereDelegate7702 (shipped early, live): EIP-7702 delegation target with passkey challenge binding for advanced wallet UX.
• Threshold-encrypted mempool + Timeboost auction: anti-MEV ordering at the protocol layer.
• Collateral Wave 1 bridged: BUIDL, USDY, OUSG, LBTC, SolvBTC, pumpBTC live on AereSettlementHub.

6.6 Q1 2027, scale + decentralisation

• 3 → 7 validator transition (public path to 21): expansion to community-operated verification nodes; the network is Foundation-operated at consensus level today and this is the decentralisation path, not a claim it is already decentralised.
• Native perp DEX: native order-book + AMM hybrid execution venue.
• ML-DSA precompile (FIPS 204): the on-chain ML-DSA-44 verifier is already live (view-only, ACVP-validated, §5.4); promoting it to a native precompile so recording fits the per-tx gas cap is the roadmap step.
• CCRI Climate Rating certification: verified ~99% less energy than proof-of-work.
• External audit contests: Code4rena, Cantina, Sherlock, paid in AERE.
• AereProof v1 production: hardened compliance primitives, third-party-audited.

07 · ClosingConclusion

AERE is an EVM Layer 1 with 0.5-second deterministic QBFT finality, full Pectra + Fusaka parity, passkey-native account abstraction via the RIP-7951 secp256r1 precompile, and an immutable 37.5% per-transaction burn enforced at the protocol layer. Total supply is fixed at 2,800,000,000 AERE at genesis with no further minting possible. Distribution flows transparently through the scheduled, contract-mediated release of the reserves, ecosystem grants from the 560M AERE Ecosystem Reserve, team vesting, and airdrops, every reserve address is on-chain and queryable via the public explorer.

Through 2026 and into 2027, AERE ships the settlement-grade primitives that turn a fast EVM L1 into a public settlement layer with verifiable on-chain compliance: sAERE (an ERC-4626 receipt token we structure as a receipt instrument, consistent with the SEC's August 5 2025 staking-receipt guidance, our position, not settled law), AereSink (the immutable three-bucket revenue router), AereProof v0 (verifiable on-chain compliance primitives operated as a public good), cross-chain Warp Routes for USDC.e / USDT.e / USDe.e / EURC.e, and AERE402 (the agentic settlement layer for machine-to-machine payments).

08 · DisclosuresRisk factors & forward-looking statements

This whitepaper and all marketing communications referencing AERE Network contain forward-looking statements regarding the network's architecture, performance targets, validator decentralisation, custody model, ecosystem partners, and product roadmap. These statements reflect current expectations as of the date of publication and are subject to risks, uncertainties, and assumptions. Actual outcomes may differ materially. AERE Foundation undertakes no obligation to update forward-looking statements except as required by applicable law.

8.1 Current network state

• As of publication, the QBFT consensus validator set comprises 3 Foundation-operated nodes. Expansion to 7 and then 21 is a forward-looking item per §6.
• Performance figures (up to 273,000 TPS) reflect QBFT-architecture testnet benchmarks under specified conditions; sustained mainnet throughput under real load varies and is publicly observable via the live indexer.
• Layer 2 systems referenced in §6 (rollups, plasma chains, ZK rollups, Lightning channels, ERC-4337 stack) are either deployed, in development, or in design at varying stages. The canonical list of deployed contracts is at docs.aere.network#contracts.

8.2 Custody model

AERE Network itself is a non-custodial settlement layer. The chain does not custody user assets; AERE balances and contract state are controlled exclusively by private-key holders. Applications built on AERE may offer additional services, including custodial fiat services such as IBAN accounts, through licensed third-party partners (e.g. EMI-licensed BaaS providers). Where applicable, custodial services are subject to the partner's own authorisations and disclosures. Bank28 (a non-custodial neobank application built on AERE) is independently branded and operates under its own terms.

8.3 Regulatory status

AERE Network is a permissionless EVM Layer 1 blockchain. The AERE token is the network's native utility and gas token. Nothing in this whitepaper constitutes investment advice, an offer to sell, or the solicitation of an offer to buy any security or financial instrument. Token holders should independently verify the legal status of AERE in their jurisdiction before acquiring, holding, or transacting. For European users, AERE is communicated in accordance with Regulation (EU) 2023/1114 (MiCA); for UK users, communications follow the FCA's Cryptoasset Financial Promotions regime. AERE Foundation does not solicit users in jurisdictions where the offering or promotion of AERE would be prohibited.

8.4 Technology risks

• Smart-contract risk: deployed contracts have passed internal review, and a published Slither static-analysis report (Trail of Bits' analyzer, 14 core contracts, solc 0.8.23) found zero genuine high-severity issues (see /slither-audit). That is automated analysis, not a named third-party human audit; no named human audit (Code4rena, Cantina, Sherlock, or a firm engagement) is published yet. It is a roadmap item (§6.6); the live adversarial mechanism today is the bug bounty.
• Validator-set risk: a permissioned QBFT consensus with a small validator count concentrates trust in the Foundation; the expansion roadmap is described in §6.
• Oracle risk: AereOracle is a multi-reporter median oracle; in single-reporter periods, AERE- and FX-denominated quotes are subject to single-reporter risk.
• Bridge risk: cross-chain settlement is migrating from the legacy federated AereBridge to standard cross-chain Warp Routes (USDC.e Q3 2026, others following). Warp Routes use configurable Interchain Security Modules (ISMs); the trust assumption is the chosen ISM committee.
• Upgrade risk: hardfork rulesets (Pectra, Fusaka) are activated via coordinated validator restart. Past upgrades have been zero-downtime; future upgrades carry standard chain-upgrade risk.

8.5 Updates & contact

Material updates to this whitepaper, the contract registry, the validator set, and the custody model are published at aere.network/legal. Inquiries regarding regulatory status, audit reports, or partnership disclosures may be directed to the AERE Foundation at [email protected].

AppendixDeployed contract addresses (chain 2800)

Canonical mainnet addresses. All Ownable contracts are owned by the Foundation 0x0243A4f47D44b40b65D33f20329dE20D00c6f3C3. The immutable economic contracts (AereFeeBurnVault, AereSink) have no admin role, no upgrade proxy, and no withdrawal path by construction. Source of truth: docs.aere.network. Every address below is queryable on rpc.aere.network and explorer.aere.network.

Genesis reserves

Core & immutable economics

Compliance & privacy (AereProof v0)

Post-quantum and frontier cryptography

Confidential compute, parallel execution & token-bound accounts

zk-verifier stack (multi-prover)

Account abstraction & paymasters

Cross-chain, oracle & randomness

DeFi, settlement & agentic

© 2026 AERE Network · Whitepaper v2.0 · Foundation domiciled in Seychelles · Chain ID 2800 · RPC rpc.aere.network · This document contains forward-looking statements; see §8.

← Interactive whitepaper  ·  Open explorer  ·  LLM reference (llms-full.txt)  ·  Source on GitHub