# Aere Network - full site text for language models # Chain ID 2800. Public RPC: https://rpc.aere.network # Generated 2026-09-15 from 186 live pages. # Every technical claim on these pages is checkable against the chain itself. # AERE Account Abstraction, gasless transfers via ERC-4337 URL: https://aere.network/aa.html Fetched: 2026-09-15 AERE Account Abstraction, gasless transfers via ERC-4337 Account Abstraction · gasless UX Coming soon. This feature is built and on the AERE roadmap, its on-chain contracts are not yet deployed. Actions are disabled until launch. ERC-4337-style account abstraction for AERE, built and not yet deployed on chain 2800 (see the banner above). When it launches: create a smart account, sign a UserOperation with your wallet key, the Paymaster pays gas, you transfer AERE without holding any AERE for gas. This is the exact flow consumer apps use to give end users gasless transactions. Stack AereEntryPoint Not yet deployed SmartAccountFactory Not yet deployed Paymaster Not yet deployed Paymaster prefund (covers gas) , Your EOA , Your smart account , Smart account balance , Connect Wallet 1 · Compute & deploy your smart account Address is deterministic from your EOA + a salt. Deploys lazily via CREATE2. Salt (any string) Predict address Deploy on-chain , 2 · Fund your smart account Send some AERE to the smart account so it has balance for the inner transfer. Gas for THIS funding tx comes from your EOA, but every subsequent UserOp pays 0 gas (paymaster). Amount (AERE) Send to smart account , 3 · Send a gasless UserOperation Sign a UserOp with your EOA key (free, just a signature, not a tx). Then the bundler (this page acts as bundler) submits it via the EntryPoint. Paymaster pays gas on your behalf. Recipient Amount (AERE) Sign & submit UserOp (gasless) , How it works Browser (Privy/Magic/MetaMask key) EntryPoint contract Paymaster ───────────────────────────── ──────────────────── ────────── 1. Build UserOp { sender, nonce, callData, ┐ paymasterAndData: [Paymaster addr] } │ 2. getUserOpHash(op) ──────────────►│ returns hash bound to (chainId, EntryPoint) 3. Sign hash with EOA key │ 4. handleOps([op], beneficiary) ───────────►│ │ 1. Verify account.validateUserOp(op) │ 2. Verify paymaster has prefund │ 3. Execute account.execute(to, value, data) │ 4. Deduct gas cost from paymaster ──────►│ pays gas │ 5. Pay fees to bundler └ done · user paid 0 gas For a consumer app: end users sign UserOps via their embedded wallet. The app backend acts as the bundler (or pays a third-party bundler). The app tops up the Paymaster prefund weekly. End users never need to hold AERE for gas. --- # About Aere Network URL: https://aere.network/about.html Fetched: 2026-09-15 About Aere Network About Aere Network A public, verifiable, EVM-compatible Layer 1 blockchain, built to outlast today's cryptography. Aere Network is a public Layer 1 blockchain (Chain ID 2800) that runs the Ethereum Virtual Machine and is designed to be checked rather than trusted. It produces a block every half second with deterministic finality, charges a fraction of a cent for a typical transfer, and offers native, protocol-level verification of NIST-standardized post-quantum signatures at the account and application layer, live on mainnet. What Aere is Aere is a standalone Layer 1, not a rollup or a sidechain. It uses the QBFT consensus engine from Hyperledger Besu, exposes a standard Ethereum JSON-RPC API, and runs Solidity and Vyper contracts unchanged. Any tool that works against Ethereum, MetaMask, Hardhat, Foundry, ethers.js, viem, works against Aere with a chain-ID change. The network's defining feature is quantum readiness at the account layer: five native precompiles covering Falcon-512, Falcon-1024, ML-DSA-44 (FIPS 204), SLH-DSA-128s (FIPS 205), and SHAKE256 (FIPS 202) activated on mainnet on July 12, 2026 at block 9,189,161, and all five pass the official NIST Known-Answer Tests. Mainnet consensus is hybrid in a precise and limited sense: since 2026-08-14 every 128th block (every 32nd block until block 17,225,968, on 2026-09-05) on chain 2800 (an anchor block) does not finalize without a certificate of at least three valid Falcon-512 validator seals (f+1 of nine) (raised at block 14,961,456, August 21, 2026, to six seals, which was then a full 2f+1 quorum of nine; ten validators since 2026-09-11, so six is above f+1 and below the quorum of seven) bound under its block hash; classical secp256k1 ECDSA QBFT finalizes every block. An external audit of the post-quantum anchor layer is still ahead. (Correction 2026-08-19: the earlier statement that from block 14,050,000 every block required a six-of-nine post-quantum quorum to finalize is withdrawn; the per-block rule armed at that height is retired in the shipped code in favour of the anchor rules and changed no enforcement.) Chain ID 2800 (public EVM Layer 1) Consensus QBFT, ten Foundation-operated validators, deterministic finality (quorum seven of ten) Block time 0.5 seconds, no reorganizations on finalized blocks Token AERE, fixed supply of 2.8 billion set at genesis, no new minting Post-quantum Native NIST PQC verification live at the account layer on mainnet Throughput The previously published 273,000 TPS design ceiling has been withdrawn: its stated derivation does not reach that number, and no such rate has ever been measured on the live chain Who operates it Aere Network is operated by the Aere Foundation , which stewards the protocol, maintains the open-source codebase, funds builders through a public grants program, and supports on-chain governance. The Foundation operates the validator set today and publishes the decentralization path in the project roadmap and whitepaper. The protocol is built by a distributed group of protocol engineers, infrastructure operators and open-source contributors working in the open: the consensus patches, the node package, the anchor corpus and the verification tools are published as they are written, and every performance figure on this site carries the command that reproduces it. The network has not yet completed a third-party audit; the proofs and conformance tests published by the project are its own work, offered for anyone to re-run. The newsroom This site includes a newsroom that publishes original engineering updates, explainers, and official press releases about Aere Network. Every post is authored at the organization level and carries a visible publication date. The newsroom is available as an RSS feed and a JSON feed . How the newsroom sources, dates, and corrects its content is described in our editorial standards . Verify for yourself Read the chain directly on the block explorer . Add the network in one click at /addnetwork.html . Review the full technical design in the whitepaper . Inspect the published research record, proofs, and improvement proposals on Git . Editorial standards Contact Foundation Newsroom --- # AERE Academy, Learn to Build on AERE Network URL: https://aere.network/academy.html Fetched: 2026-09-15 AERE Academy, Learn to Build on AERE Network AERE Academy Reality check, added 2026-08-19. This course teaches the design. On chain 2800 today: no staking yield is payable (the staking contracts hold no reward balance, so the 8% figure is a parameter, not an income); the governance contracts (AereGovLockV2, AereGovernorV2) are deployed but own no protocol contract yet, so a vote cannot change fees, validators or funds and is advisory; there is no on-chain vesting contract (team, investor and Foundation allocations sit in plain accounts); and an unmodified upstream Hyperledger Besu cannot follow chain 2800, the node software is the aere-node fork with its published patches (post-quantum precompiles since block 9,189,161, the base-fee floor, the header anchor). Nine Foundation-run validators, commit quorum 6 of 9, blocks every ~0.5 s. Free, self-paced learning for builders and users of AERE Network. AERE Academy is an open curriculum, no sign-up, no cost, no certification fees. Every course is written by the AERE core team and covers real production patterns on chain ID 2800. Whether you are configuring your first wallet, shipping a smart contract, running a validator node, or researching the economics behind the AERE token, you will find a course that takes you from zero to working. Courses Beginner AERE Network Fundamentals ~1 hour · 5 modules What a blockchain is, how AERE works as an EVM Layer 1, QBFT consensus and instant finality, the AERE token, chain ID 2800, and how to add AERE to MetaMask. Start course → Beginner Deploy Your First Smart Contract ~2 hours · 6 modules Solidity basics, using Remix IDE, connecting MetaMask to AERE, writing and deploying a simple storage contract and an ERC-20 token, then verifying it on the block explorer. Start course → Intermediate Run an AERE Validator ~2 hours · 5 modules What validators do in QBFT, hardware and OS requirements, running a Hyperledger Besu node connected to AERE mainnet, the AereStaking delegated-staking model, and monitoring your node. Start course → Intermediate AERE Tokenomics & Governance ~1.5 hours · 4 modules The 2.8 billion max supply, the six allocation wallets, the staking design (an 8% APY parameter that pays nothing today), and how stake-weighted DAO governance works in practice on AERE Network. Start course → Corrections and additions to this course are welcome as an issue on aere-docs . --- # Add AERE Network to MetaMask URL: https://aere.network/addnetwork.html Fetched: 2026-09-15 Add AERE Network to MetaMask AERE Network Add AERE Network to your wallet One click to configure MetaMask, Rabby, OKX Wallet, Trust Wallet, or any EVM-compatible wallet. Network name AERE Network Chain ID 2800 (0xAF0) Native currency AERE (18 decimals) RPC URL https://rpc.aere.network RPC URL (backup) https://rpc2.aere.network WebSocket wss://wss.aere.network Block explorer https://explorer.aere.network Add to wallet Testnet name Aere Network Testnet Chain ID 28001 (0x6d61) Native currency tAERE (18 decimals, no value) RPC URL https://testnet-rpc.aere.network WebSocket wss://testnet-rpc.aere.network/ws Faucet aere.network/testnet.html The testnet runs the same node software as mainnet with hybrid post-quantum consensus (a Falcon-512 validator checkpoint under every 128th block (every 32nd block until block 17,225,968, on 2026-09-05) hash) and its enforcement switched on. Five validators run by the Foundation on two clients, four Besu and one Nethermind; it may be reset with notice. Add it from the testnet page . Need help? See the whitepaper or visit aere.network . --- # AERE, the native token of AERE Network URL: https://aere.network/aereusd.html Fetched: 2026-09-15 AERE, the native token of AERE Network AERE is the only token AERE Network has one native token: AERE. The network does not issue, operate, or endorse a separate stablecoin product. Tokenomics, supply, allocation and utility for AERE live on the AERE token page . For payments and savings products denominated in fiat currencies (EUR, USD), consumer applications built on AERE can integrate with regulated EMT-issuer partners (e.g. Circle EURC, Monerium EURe) under the EU MiCA framework, rather than minting a separate AERE-collateralised stablecoin. View AERE token → --- # AereAirdrop, Merkle airdrop claims URL: https://aere.network/airdrop.html Fetched: 2026-09-15 AereAirdrop, Merkle airdrop claims AereAirdrop Coming soon. This feature is built and on the AERE roadmap, its on-chain contracts are not yet deployed. Actions are disabled until launch. Generic Merkle airdrop distributor on AERE Network. Owners post a Merkle root over (recipient, amount) leaves; recipients claim by proof. Native AERE or any ERC-20. Multiple campaigns can run simultaneously. Distributor AereAirdrop Not yet deployed Active campaigns , Your address , Connect Wallet Campaigns Loading… Claim with Merkle proof If you have a claim, the campaign operator will give you the JSON below. Paste it and click claim. Claim payload (JSON: { campaignId, index, amount, proof }) Claim For campaign operators 1. Build the Merkle tree off-chain. Each leaf = keccak256(abi.encodePacked(index, account, amount)). 2. Compute root. 3. Approve the AereAirdrop contract for the total ERC-20 amount (or send the AERE with the tx). 4. Call createCampaign(root, token, endTime, totalAllocated), get campaign id. 5. Distribute the proofs to each recipient (off-chain, file, web2 backend, etc). 6. Recipients claim via claim(id, index, account, amount, proof). 7. After endTime, sweep unclaimed back to owner. Example uses: airdrops to all KYC-cleared users on launch month, validator rewards distributions, retroactive contributor rewards. --- # Architecture, live versus planned · Aere Network URL: https://aere.network/architecture.html Fetched: 2026-09-15 Architecture, live versus planned · Aere Network AERE NETWORK · CHAIN 2800 Architecture, live versus planned Every box on the left of the diagram resolves to a read-only call you can run against a public endpoint, with no wallet and no account. The right-hand plane holds two components that are live but were once shown as roadmap (each card carries its activation date) and two items that are not delivered ; it is drawn separately so that nothing on it can be mistaken for the measured layers on the left. Where a figure is a specification rather than a measurement, it says so on the diagram itself. Read this before you read the diagram. Chain 2800 carries almost no transactions. Re-measured 2026-09-10 at head 17,965,012: 120 headers sampled across the most recent 3,000 blocks carried one transaction in total , and txpool_status reported 0 pending and 0 queued. (First measured 2026-08-05 at head 12,469,045: zero transactions in the same kind of sample and 200 pending transactions that were not draining; that backlog is gone.) The sub-second block interval below is therefore a measurement of a timer, not of a system under load, and no throughput figure can be inferred from it; see verifiable-claims.json . Aere Network live architecture, chain 2800, with a separate plane for undelivered roadmap items Six delivered layers of chain 2800 on the left, each with a read-only call that verifies it, and each labelled with what it does not prove. On the right, a visually separated plane: the certificate anchor (live on mainnet, consensus-enforced at every anchor block since 2026-08-14, six seals since 2026-08-21 (of nine then; ten validators since 2026-09-11), hybrid since 2026-09-04, every 128th block since 2026-09-05) and Block-STM parallel execution (our own block processor, switched on on all nine Besu validators since 2026-09-05, with no measurable gain while blocks carry at most one transaction), plus two items that are NOT delivered: Adaptive QBFT, and the 273,000 TPS ceiling (withdrawn 2026-09-05). A banner across the top of the left plane records that the chain is idle, so the block interval measures a timer rather than throughput. Aere Network · Architecture, live versus planned Every box on the left resolves to a read-only call you can run. The right plane is not delivered , by design. MEASURED 2026-08-05 · HEAD BLOCK 12,469,045 CHAIN ID 2800 (0xaf0) · 11 PEERS METHOD FOR EVERY FIGURE: /verifiable-claims.json LIVE ON MAINNET, VERIFIABLE NOW PLANNED, NOT DELIVERED THE CHAIN IS IDLE. Sampled 2026-08-05: 120 headers across the most recent 3,000 blocks, 0 transactions in total, while 200 transactions sit pending. Nothing below is a throughput figure. 1 Public read surface Two independent public endpoints. No wallet and no account is needed to check anything below. rpc.aere.network · rpc2.aere.network · besu/openjdk-java-25 · 11 peers · eth_syncing false LIVE 2 Application layer · post-quantum verifiers as ordinary contracts Each has runtime bytecode you can hash, and a real transaction receipt on this chain with block and status. Falcon-512 0x4E8e…8fFC · Falcon-1024 · ML-DSA-44 · XMSS RFC 8391 · zkML Groth16 · ZKScreen SP1 LIVE 3 EVM execution, parallel engine on, nothing to parallelise Our own Block-STM-style block processor, switched on on all nine Besu validators since 2026-09-05, proven on real blocks with a negative control. Blocks carry at most one transaction, so no speed-up is claimed. LIVE 4 Native post-quantum precompile band 0x0AE1 to 0x0AE5 SHAKE256, Falcon-512, Falcon-1024, ML-DSA-44, SLH-DSA-128s, live since block 9,189,161. Proven by cost above a codeless control, calibrated on two costs the EVM specification fixes, not Aere: 0x04 and 0x02. LIVE 5 Consensus: QBFT signed with classical secp256k1 ECDSA 10 validators, quorum 7, f=3, all operated by the Foundation (ten since 2026-09-11). Mean header interval 0.5236 s over 100,000 blocks, on EMPTY blocks. Block signing is NOT post-quantum, and no chain here claims otherwise. LIVE 6 Fee rule and burn path · deployed, and not flowing today Base fee floor of 1 Gwei from block 10,141,734. The splitter stores a 37.5% rate under a 50% code ceiling, but the vault balance has not moved. The VAULT has no owner; the SPLITTER rate is settable by one key. LIVE Roadmap, drawn separately so it can never be read as running architecture. LIVE, CONSENSUS-BLOCKING Certificate anchor V2 Live on mainnet since 2026-08-14. Every anchor block (each 128th since 17,225,968) carries a validator certificate under its hash: 6 of 10 Falcon-512 seals since 2026-08-21, hybrid with SLH-DSA-SHA2-128s since 2026-09-04. ON L1 SINCE 2026-09-05, NO GAIN YET Block-STM parallel execution Our multi-version block processor runs on all nine Besu validators; correctness proven on real blocks, negative control recorded. Blocks carry 0-1 tx today, so nothing is parallelised and no L1 speed-up is claimed. See box 3. NO SUCH COMPONENT “Adaptive QBFT” A name on a slide. No code, no configuration flag and no measurement anywhere in the system. It is listed here so that nobody can mistake it for a layer that exists. WITHDRAWN, DERIVATION FAILS 273,000 TPS ceiling (withdrawn) Described as arithmetic from gas limit over block time. The live gasLimit is 2^53-1, a JavaScript artifact, so that arithmetic gives ~8e11, not 273,000. Never measured, and the stated derivation does not reach the number. VERIFY THIS DIAGRAM WITHOUT TRUSTING US eth_chainId proves box 1 0xaf0 chain 2800 eth_call 0x…0AE5 data 0x00…20 proves box 4 0x46b9dd2b0ba88d13…646ed5762f the NIST SHAKE256 answer eth_getBalance 0x696afDF4… at latest and latest-400 identical box 6, the burn is not flowing Every figure above carries its method, its block, and what it does NOT prove, in aere.network/verifiable-claims.json. Run them all at once with aere.network/verifiable-claims-check.py. Figure 1. Chain 2800 as it runs on 2026-09-10 (first drawn 2026-08-05; re-measured). The left plane is measured. On the right, the two live cards carry their activation dates, and the two other items are not delivered; the diagram says so on each card rather than leaving it to the reader. Why the roadmap is on a separate plane An architecture diagram that shows an undelivered component next to a running one is a false statement in visual form, and it is the kind an engineer disassembles in under a minute. Two items in particular have appeared in Aere material as if they were layers. Adaptive QBFT does not exist: there is no code, no configuration flag and no measurement of it anywhere in the system. Block-STM parallel execution exists in two places: a Rust executor benchmarked in isolation and used by the rollup sequencer, and, since 2026-09-05, our own multi-version block processor inside the Besu fork, switched on on all nine Besu mainnet validators and proven on real chain-2800 blocks with a recorded negative control. It stays on this plane because it buys nothing measurable while blocks carry at most one transaction, which is why box 3 says so in its first line rather than burying it. Run the diagram yourself These are the exact calls. They are read-only, they need no wallet, and they return the same answer from any node. If you script them, set a User-Agent header: the CDN in front of these endpoints answers HTTP 403 to the default Python urllib agent, which has nothing to do with the chain and has fooled people before. $ curl -s -X POST https://rpc.aere.network -H 'content-type: application/json' \ -d '{"jsonrpc":"2.0","method":"eth_chainId","id":1}' {"jsonrpc":"2.0","id":1,"result":"0xaf0"} $ curl -s -X POST https://rpc.aere.network -H 'content-type: application/json' \ -d '{"jsonrpc":"2.0","method":"eth_call","params":[{"to":"0x0000000000000000000000000000000000000AE5", "data":"0x0000000000000000000000000000000000000000000000000000000000000020"},"latest"],"id":1}' {"jsonrpc":"2.0","id":1,"result":"0x46b9dd2b0ba88d13233b3feb743eeb243fcd52ea62b81b82b50c27646ed5762f"} # compare against a value we cannot choose: $ python3 -c "import hashlib; print(hashlib.shake_256(b'').hexdigest(32))" 46b9dd2b0ba88d13233b3feb743eeb243fcd52ea62b81b82b50c27646ed5762f $ curl -s https://aere.network/verifiable-claims-check.py -o check.py && python3 check.py PASS 74 FAIL 0 What each box does not prove Box Proves Does not prove 1. Read surface An EVM endpoint exists, self-reports chain 2800 and is not syncing. Nothing about decentralization or control. One machine can answer all of it. 2. Verifiers Contracts have runtime bytecode and successful historical receipts. A successful receipt means execution did not revert, not that the cryptographic content was meaningful. 3. Sequential EVM Standard Besu execution semantics. Nothing about capacity. The chain is idle, so nothing here is stressed. 4. Precompiles Code executes at 0x0AE1 to 0x0AE5 at costs that are constants in the client source. Execution, not correctness. And the zero cost at 0x0AE6 and 0x0AE7 is consistent with absence, not proof of it; absence is asserted from the node's own eth_config enumeration. 5. Consensus 10 validators and 7 committed 65-byte seals (since 2026-09-11; 9 and 6 before), readable out of every signed header. That the 10 keys are held by independent parties. They are not. The effective Nakamoto coefficient is 1. 6. Burn path The contracts are deployed, the rate is on-chain, and the vault has no owner and no withdrawal path. That anything is being burned. The vault balance is unchanged, and the splitter's rate is settable by a single externally owned key. Sources Machine-readable claim layer, with the verification call, the limits and the refusals: /verifiable-claims.json . Runnable checker, standard library only: /verifiable-claims-check.py . Capability to on-chain evidence map: /claim-evidence.json . Grounding document for machines: /llms.txt . Measured 2026-08-05 against the public endpoints at head 12,469,045. Every number on this page was executed before it was written. Where a link in the chain of reasoning was not measured, the page says NOT MEASURED rather than filling the gap. About About Aere Foundation Roadmap Press & Newsroom Brand Kit Editorial Standards Build Developer Hub Documentation RPC Reference SDK Add Network Faucet Academy Grants Network Architecture Post-Quantum Stack Validators Run a Validator Network Status Audits Security Decentralization Solutions Payments DeFi Real-World Assets Infrastructure Gaming NFTs & Culture Explore Explorer Blocks Transactions Tokens Research & Papers Glossary Blog Legal Terms & Privacy Sanctions Compliance Aere Network. Chain ID 2800. Every claim on this site is checkable: rpc.aere.network --- # Benchmarks and methodology, AERE Network URL: https://aere.network/benchmarks.html Fetched: 2026-09-15 Benchmarks and methodology, AERE Network Engineering · Performance · Methodology Benchmarks, and how to reproduce them Every performance figure AERE publishes, each carrying an explicit scope label, its raw artifact, and a command you can run yourself. The headline throughput number is a design ceiling, not a mainnet measurement, and this page says so plainly. Live figures (block interval, finality, validators producing, real throughput, post-quantum anchor, RPC latency, state size, testnet) are measured every 30 minutes on the site host's own read node and published on the live benchmark page , each with its method and block. Capacity figures stay here, dated, with the command that reproduces them. Read the scope label before the number A performance figure is only honest when its scope is attached to it. AERE uses four labels throughout this page. The strong results are real; the boundaries are real too. Live mainnet Measured or verifiable on chain 2800 right now, over the public RPC or the block explorer. Isolated benchmark Measured on a throwaway machine with a reproducible harness. Not mainnet, not a network throughput number. Scratch fork Measured on an isolated fork of the client (a separate chain ID), staged for a supervised mainnet activation, not active on 2800 today. Design ceiling A theoretical maximum implied by the configuration under ideal conditions. Never observed, a roadmap target, not a rate the live network delivers. 1. Throughput: the 273,000 TPS figure, withdrawn Design ceiling Withdrawn: the 273,000 transactions-per-second figure that appeared across AERE materials was a design ceiling derived from block-space arithmetic under ideal conditions; its stated derivation does not reach that number, so it is withdrawn as a ceiling too, and is kept on this page only so the arithmetic below can be checked. It has never been a measured result on mainnet chain 2800, and it is not asserted as one here. Throughput and finality are separate axes: the sub-second finality claim in section 3 follows mechanically from QBFT plus the block period, while this ceiling is a capacity statement about block space. What kind of number it is (an illustrative decomposition) Block-space throughput obeys a simple identity: TPS = ( gas available per block / gas per transaction ) / block time A minimal native transfer costs the protocol floor of 21,000 gas, and the block period is 0.5 seconds. Sustaining 273,000 such transfers every second therefore implies processing on the order of: 21,000 gas / minimal transfer protocol floor 0.5 s block period live, section 3 ~2.87 B gas / block implied 273k × 21k × 0.5s ~5.7 B gas / second implied the real bottleneck A single sequential Hyperledger Besu node processes far less gas per second than that today. The genesis gas limit is configured high enough not to be the binding constraint, so the true limit is the client's execution throughput, not a configured cap. The 273,000 figure has been withdrawn (2026-09-05); it was at most a ceiling the multi-layer roadmap was built to approach (parallel execution, a native order-book precompile), not a rate the live network delivers now. Realized mainnet throughput today, live The honest counterpoint to the ceiling is what the chain actually carries. AERE is early and real usage is thin, so realized throughput is a tiny fraction of the ceiling. · Realized TPS (recent blocks) sampling live · Avg gas used / block idle chain, near zero 273,000 Withdrawn design ceiling (for scale) not observed, withdrawn Live sample on 2026-07-18 across 200 consecutive blocks: 2 transactions over a 103-second span, about 0.02 TPS , at an average of 336 gas used per block. The readout above re-samples the last 40 blocks from your browser against the public RPC, so it moves with real load. Provenance. Framing quoted from the AERE whitepaper (throughput chapter) and AERE-BENCHMARK-REPORT.md in aere-docs. Re-run script: none, and that is the point. No benchmark in this repository reproduces 273,000 TPS, because it is not a measured figure. The realized number above is reproducible by anyone sampling eth_getBlockByNumber over the public RPC. Sources: whitepaper (throughput framing) · AERE-BENCHMARK-REPORT.md · block explorer (live blocks) 2. Parallel execution: Block-STM 8.6x to 9.3x Isolated benchmark AERE ships a real, from-scratch Block-STM optimistic-concurrency parallel executor in Rust ( aere-block-stm , zero external dependencies). It executes a transaction batch across many cores and commits a keccak256 state root that is bit-identical to sequential execution . That serial-equivalence is the property that makes the parallel root a valid commitment, and it is proven over 6,000 randomized adversarial comparisons with zero mismatches (6 workload profiles, 200 batches each, at 1, 2, 4, 8, and 16 threads), including fully-conflicting adversarial cases. Honest boundary. AERE's Layer 1 (Besu) executes sequentially on mainnet today; nothing here changes that. These are single-machine microbenchmarks of the executor, not a TPS or network-throughput claim. The executor is wired into AERE's rollup sequencer, where batch execution is the parallelizable workload; base-layer parallelism remains a testnet demonstration, not mainnet-active. Execution-phase speedup versus single-threaded sequential (16-core reference box, 20,000-tx batches) Workload profile 2 thr 4 thr 8 thr 16 thr Low conflict (~2% hot-touch) 1.9x 3.6x 6.2x 8.6x Medium conflict (~15% hot-touch) 1.9x 3.7x 6.6x 9.3x High conflict (~80% hot-touch) 1.7x 3.1x 5.0x 4.6x Pathological (every tx, same slot) 0.9x 0.9x 0.8x 0.73x The pathological worst case is stated openly: when every transaction increments the same slot there is no parallelism to exploit, so Block-STM correctly serializes and runs slightly slower than sequential (about 0.73x) because it pays for aborted speculation. No correct parallel executor can beat sequential when there is nothing to parallelize. End-to-end pipeline (execution plus serial commit plus state root), 16-core reference box A block is not finished when execution finishes; it is finished when state is committed and a root is produced, and those tail phases are serial. Measured end-to-end at a simulated 80-gas-per-transaction weight, median of 7 runs: Designed conflict End-to-end speedup @16 End-to-end TPS @16 Abort % 0% 8.32x 247,444 0.3% 10% 9.07x 269,750 1.2% 50% 8.91x 254,686 16.6% ~100% (pathological floor) 4.89x 147,125 25.0% The measured ~247k to 270k TPS above lands coincidentally near the 273k design ceiling and must not be read as reaching or validating it. Two independent reasons. First, this TPS is entirely a function of the assumed per-transaction cost: the same harness reports about 416k to 502k TPS at a lighter 20-gas weight and about 115k to 143k TPS at a heavier 200-gas weight. Second, this is the rollup executor on a bounded balance-and-slot state model with a light keccak commit, not the full EVM and not the L1. The invariant deliverable is the speedup curve and its Amdahl bound, not the absolute TPS. Independent reproduction on this page's build machine The figures above were taken on a 16-physical-core reference box. Re-running the same harness fresh on an 8-physical-core Intel i7-10870H (16 logical threads) reproduces the correctness invariant exactly and shows positive scaling capped by the smaller core count: 7 / 7 cargo tests pass serial-equivalence 6,000 / 0 comparisons / mismatches correctness harness ~5.2x medium-conflict @16 thr 8 physical cores 140 / 0 end-to-end checks / mismatch state + root identical The absolute speedup is lower than the reference box's 8.6x to 9.3x precisely because this machine has 8 physical cores rather than 16, which is the honest and expected result. What reproduces exactly, independent of hardware, is that the parallel result equals the sequential result on every single run. Reproduce it yourself: git clone https://git.aere.network/aere-network/aere-research.git cd aere-research/parallel-executor cargo test --release # 7 serial-equivalence tests cargo run --release -- harness # 6,000-comparison serializability gate cargo run --release -- bench # execution-phase speedup curve cargo run --release -- endtoend # end-to-end pipeline, TPS + Amdahl bound Provenance. Speedup, 6,000-rep, end-to-end and gas-sweep figures are consolidated in AERE-BENCHMARK-REPORT.md in aere-docs, alongside the whitepaper parallel-execution chapter. The Block-STM executor is now published in full, and so are the raw, unedited run logs behind the tables above, so these figures can be checked against the machine output that produced them instead of being taken on trust. The log set covers each command in the box above: environment capture, the 7 serial-equivalence tests, the 6,000-comparison harness, the execution-phase sweep, and the end-to-end run at three gas weights. The design the executor implements is published as spec-parallel-execution.md . Sources: raw run logs, 2026-07-13 (unedited harness output) · parallel-executor source (aere-block-stm) · AERE-BENCHMARK-REPORT.md (end-to-end results) · spec-parallel-execution.md · AereBlockSTMRegistry (live hint registry) 3. Deterministic finality: 0.5 seconds Live mainnet AERE runs Hyperledger Besu with QBFT, a deterministic committee-based consensus. A block is final the moment a super-majority of the 10 Foundation-operated validators sign it, with no probabilistic confirmation window and no reorganizations. The block period was cut from one second to 0.5 seconds mid-chain at block 2,137,652. Consensus signing is classical secp256k1 ECDSA, not post-quantum. Live from the public RPC · Latest block chain 2800 · Avg block interval last 1,000 blocks · Validators quorum 6 of 9, f=2 · Gas price verified on-chain The configured target is 0.5 seconds and the realized mean is a little above it. An independent read-only sweep on 2026-08-02 measured 0.557 seconds per block, agreeing to 0.2 ms across five disjoint 20,000-block windows, which is what this page's live sample also reads. The earlier 0.506-second figure quoted here was a real sweep of blocks 2,200,000 to 5,001,000 and describes that stretch of chain, not the head; it is kept as history rather than presented as the current rate. The realized period has run about 3.3% above the 0.5-second target consistently since the mid-chain transition. Provenance. Block interval, validator count, and gas price are read live in your browser from https://rpc.aere.network via eth_getBlockByNumber , qbft_getValidatorsByBlockNumber , and eth_gasPrice . The 0.506-second sweep figure is from AERE-BENCHMARK-REPORT.md in aere-docs. Re-run script: the widget above is the reproduce path; the same calls run from any JSON-RPC client. Sources: live network status · block explorer · AERE-BENCHMARK-REPORT.md 4. Post-quantum precompile gas costs Live mainnet band Gas measured on scratch fork Five native NIST post-quantum verifier precompiles are live on mainnet in the reserved address band. The activating fork carries activationTime 1783820272, which you can read straight from the network with eth_config ; block 9,189,161 is the first block whose timestamp is at or after it. That block contains no transactions, because the activation was a fork configuration change and not a transaction, so its significance is its timestamp and not its contents. To confirm the precompiles are executing right now , measure gas rather than inspecting that block: see the verification page . They wrap the Bouncy Castle post-quantum verifiers already on the client classpath, introducing zero new dependencies and zero hand-rolled cryptography, and each is validated against the official NIST known-answer and ACVP vectors in both directions. The gas figures below were measured with full verify-and-record transactions on an isolated scratch fork (chain 28099), and are labelled accordingly; the precompiles themselves are live on 2800. Scheme Precompile Verify-and-record gas % of 16,777,216 tx cap SHAKE256 (FIPS 202) 0x0AE5 21,470 0.13% Falcon-512 0x0AE1 86,336 0.51% Falcon-1024 0x0AE2 145,496 0.87% ML-DSA-44 (FIPS 204) 0x0AE3 351,050 2.09% SLH-DSA-SHA2-128s (FIPS 205) 0x0AE4 558,276 3.33% Why this matters: Falcon-1024 and ML-DSA-44 cost roughly 21.7 million and 52.9 million gas respectively in pure Solidity, which exceeds the per-transaction gas cap, so on mainnet they are verifiable today only as read-only eth_call views. The precompiles move both schemes to record-on-chain with wide margin. The precompile gas schedule is a scratch-fork measurement staged for a supervised, audited mainnet fork activation; it is not a promise that a recording transaction against these two schemes lands within the cap on 2800 today. Provenance. Gas figures and vector counts from AERE-BENCHMARK-REPORT.md in aere-docs (isolated scratch fork chain 28099) and research/aip-draft-pqc-precompiles.md in aere-research. Precompile activation is verifiable from the network itself: eth_config returns activationTime 1783820272 and the active precompile set, and block 9,189,161 is the first block at or after that timestamp. Live execution is verifiable by gas measurement at latest , which is the proof that does not depend on pruned historical state. The application-layer pure-Solidity verifiers behind these schemes are live and address-listed in the whitepaper. Re-run script: the NIST vector suite is committed; reproducing the on-chain gas requires the fork binary, which is not published, so those numbers are cited from the artifact rather than runnable here. Sources: AERE-BENCHMARK-REPORT.md · aip-draft-pqc-precompiles.md · post-quantum security overview · verify the precompiles live 5. Post-quantum anchoring under load: robustness proven, cost below noise Isolated 4-node benchmark net Measured 2026-08-22. The question: what does the Falcon-512 anchor certificate at every 128th block (every 32nd block until block 17,225,968, on 2026-09-05) cost in throughput? The method is A/B on identical terrain: the same 4-node QBFT net at the 500ms block period, two modes started alternately (so cost cannot be confused with machine warm-up), nine runs each, 64,000 pre-signed transfers per run, and every figure reconstructed from the chain itself by RLP-decoding block headers and counting seals — the load driver only feeds, it does not measure. Control (anchoring off) Armed (anchoring as on mainnet) Runs, transactions included 9 × 64,000, zero lost 9 × 64,000, zero lost Sustained TPS, median 542 744 Sustained TPS, range 464–1,049 374–1,067 Anchor blocks below the seal threshold, under full load (not armed) 0 of 38 The honest reading, in the order the evidence supports it. First, the strong claim is robustness, not speed : in every armed run, every anchor block produced in the middle of a saturated chain carried its complete certificate, and none fell below the enforced seal threshold — the post-quantum certificate does not degrade when the chain is under maximum load this harness can generate. Second, on cost: the two ranges overlap completely, and the armed median even came out higher , which is noise, not a speed-up — so the defensible statement is that on this hardware, the throughput cost of post-quantum anchoring is smaller than the run-to-run noise between identical configurations . We publish the distribution rather than a single flattering number precisely so you can check that reading. One scope warning the numbers themselves force: this A/B terrain uses a different genesis than the sustained-throughput bench above, so its absolute TPS figures must not be compared across sections; A/B comparisons are only valid within the same genesis, which is why both modes ran on one. Reproduce it: the harness, methodology and raw per-block evidence CSVs are in the repository under banc-masuratori/ ( 08-ab-runda.sh N alternates the modes and writes the CSV). Chain-derived counting means re-running it answers you from block headers, not from our notes. The honesty baseline that applies to everything above AERE runs 9 QBFT validators under a single Foundation operator on one execution client (Hyperledger Besu). Consensus on mainnet is classical secp256k1 QBFT and is not post-quantum. The AERE-authored contracts and client changes have not had an external security audit. Real usage is thin. Every figure on this page sits on that foundation and is scoped against it. The 273,000 TPS figure has been withdrawn (2026-09-05). It was never measured on mainnet and no benchmark here reproduces it. The Block-STM speedups are single-machine microbenchmarks of a real executor and do not transfer to the L1. On the L1 base layer a separate Block-STM-style processor of our own has been switched on on all nine validators since 2026-09-05; with blocks carrying at most one transaction (sampled 2026-09-10) it has nothing to parallelise, so no L1 speed-up is claimed. The 0.5-second finality claim is live and verifiable, and it is about latency to irreversibility, not throughput. The post-quantum precompile gas costs are scratch-fork measurements; the precompiles are live on mainnet, the gas schedule is staged for a supervised, audited activation. See it live: block explorer · network status · whitepaper · security --- # Blocks · AERE Block Explorer URL: https://aere.network/blocks.html Fetched: 2026-09-15 Blocks · AERE Block Explorer. Every confirmed block on AERE Network, block number, age, transaction count, miner, and gas used. Chain ID 2800 · 0.5-second QBFT finality. --- # Add AERE Network to MetaMask in 60 Seconds, AERE Blog URL: https://aere.network/blog-add-to-metamask.html Fetched: 2026-09-15 Add AERE Network to MetaMask in 60 Seconds, AERE Blog Education Add AERE Network to MetaMask in 60 Seconds By AERE Network April 14, 2026 3 min read MetaMask doesn't list AERE Network by default, you have to add it manually. There are three ways to do this: a one-click page that handles everything automatically, a manual entry form inside MetaMask, and a JavaScript call for dApp developers who want to prompt users programmatically. All three take about a minute. Method 1: One-Click Add (Fastest) The quickest route is the network-add page at /addnetwork.html . Open it with MetaMask installed in your browser, click the button, and MetaMask will pop up a confirmation dialog with all fields pre-filled. Approve it and you're done. This method works in any browser that has MetaMask, Coinbase Wallet, or another injected EIP-1193 provider installed. Method 2: Manual Entry in MetaMask If you prefer to enter the details yourself, or if you're on a device where the one-click page can't reach an injected wallet, you can type the parameters directly into MetaMask's "Add a network" form. 1 Open MetaMask and click the network selector at the top of the popup (it usually shows "Ethereum Mainnet" or whatever chain you're currently on). 2 Scroll down and click "Add a network" , then "Add a network manually" . 3 Fill in the form with these exact values: Network name AERE Network New RPC URL https://rpc.aere.network Chain ID 2800 Currency symbol AERE Block explorer URL https://explorer.aere.network 4 Click "Save" . MetaMask will switch to AERE Network automatically. Chain ID mismatch? If MetaMask rejects the chain ID, double-check that you entered 2800 and not its hex equivalent 0xAF0 . MetaMask's manual entry form expects decimal. Method 3: Programmatic (For dApp Developers) If you're building a dApp that connects to AERE, you can prompt users to add the network using the wallet_addEthereumChain RPC method. This is the same call that the one-click page makes: await window.ethereum.request({ method: 'wallet_addEthereumChain', params: [{ chainId: '0xAF0', // 2800 in hex chainName: 'AERE Network', rpcUrls: ['https://rpc.aere.network'], nativeCurrency: { name: 'AERE', symbol: 'AERE', decimals: 18, }, blockExplorerUrls: ['https://explorer.aere.network'], }] }); Note that the programmatic API expects chain ID in hex ( 0xAF0 ), unlike the manual form which expects decimal. If the user already has AERE Network configured, MetaMask will simply switch to it without showing an "add" dialog. Verifying the Connection Once AERE Network is added, you should see "AERE Network" in your MetaMask network dropdown and your balance will show in AERE. You can verify you're on the right chain by checking the block explorer: Open explorer.aere.network , it should show live blocks ticking roughly every half-second. Your MetaMask address works identically on AERE as it does on Ethereum. No new seed phrase needed. Getting Your First AERE If you've just added the network, your balance will show zero and there is currently no public way to change that. The faucet at /faucet.html is deployed but holds a zero balance, so it cannot pay out, and there is no public sale or exchange listing. You can add the network and read the chain, but you cannot send a transaction until your address is funded. There is no exchange listing, no fiat on-ramp and no live bridge route today; the faucet is the only public source of small amounts. ← Back to Blog --- # AERE goes MEV-resistant, batch-auction DEX live, AERE Blog URL: https://aere.network/blog-batch-auction-dex.html Fetched: 2026-09-15 AERE goes MEV-resistant, batch-auction DEX live, AERE Blog Engineering · DEX AERE goes MEV-resistant, batch-auction DEX live By AERE Network May 31, 2026 6 min read On May 31, 2026 AERE Network deployed a batch-auction DEX on chain 2800. Three small contracts that together replace the worst part of crypto UX: getting sandwiched by MEV bots. Users sign EIP-712 orders off-chain (zero gas, zero front-running risk). An authorised solver collects open orders, finds a single uniform clearing price per token pair, and submits the whole batch atomically. Sandwich attacks become structurally impossible , the batch executes in one transaction, so no one can insert a tx between two orders. What this changes: AereSwap remains available for direct (immediate-fill) swaps. But the recommended path for any user-facing trade is now /swap.html once its MEV-protected mode ships (it is not in /swap.html today, which offers the direct AMM route only): a single signature instead of a pending transaction sitting in the mempool waiting to be sandwiched. Users get fair-market execution; solvers compete for the spread; bots can't profit from front-running. The three contracts Contract Address What it does AereSettlement 0x9C2957b1622567B4802E4AFd4c42FB2ec70dE875 Core batch-settlement contract. Solvers call settle(orders, signatures, executions) with arrays of pre-signed user orders + execution amounts. Contract verifies each EIP-712 signature, checks per-order deadlines and minBuy floors, atomically transfers sell tokens (via VaultRelayer) and buy tokens. Replay protection via per-order hash mapping. AereVaultRelayer 0x9FCA122e87E36D7cba20DbEA7b9b7354A4Cece91 Token allowance proxy. Users approve THIS contract once per token (typically MaxUint256); the settlement contract uses it to pull tokens during batch settlement. Lets us upgrade the settlement contract later without users having to re-approve. AereSolverRegistry 0xDBD29332a9993d2816EF0bD240288E03a8103f3B Permissioned solver allowlist for Phase 1. Foundation curates initial solver set; bootstrap solver address is the deployer (will be rotated to a dedicated cold/hot solver on Foundation infrastructure). Phase 2 (post-audit) opens permissionless bonded-solver entry, anyone posting an AERE bond can solve; bond slashable for misbehavior. Why batch-atomic clearing kills MEV The fundamental front-running attack on a normal AMM is the sandwich: User submits a swap transaction → goes to public mempool. Bot reads the pending tx, sees user wants to buy AERE. Bot front-runs with its own buy, pushing the AMM price up. User's tx executes at the new (worse) price. Bot back-runs with a sell, pocketing the spread. The whole attack relies on the bot being able to insert transactions between the user's mempool arrival and the user's tx execution. Batch settlement removes that surface: Users don't broadcast transactions, they sign off-chain orders that sit in an order book. The batch executes in one transaction . There is no "between" for the bot to insert into. Every order in the batch settles at the same uniform clearing price per token pair. The bot can't move price for one order and not another. If the solver tries to settle at an unfavourable price, the order's minBuyAmount constraint rejects the whole batch. Batch-auction settlement with a single uniform clearing price is a well-established primitive for neutralising sandwich MEV. Applied on AERE, it makes front-running structurally impossible rather than merely discouraged. The order flow Two user-facing steps. One on-chain transaction (paid by solver). // Step 1: User signs the order off-chain (no gas). order = { user: 0xUSER, sellToken: 0xUSDC, buyToken: 0xAERE, sellAmount: 1000_000000, // 1000 USDC minBuyAmount: 9800_000000000000000000, // ≥ 9800 AERE (slippage floor) validTo: now + 120, // valid for 2 minutes salt: random_uint256() // replay protection } signature = signTypedData(order) // EIP-712 // Step 2: Order posted to order book. Solver picks it up + matches with other orders. // Step 3: Solver submits batch (their tx, their gas). AereSettlement.settle( [order_1, order_2, order_3...], [sig_1, sig_2, sig_3...], [exec_1, exec_2, exec_3...] // each: executedBuyAmount per order ) // Step 4: Atomically, in one tx: // - Sigs verified // - sellToken pulled from each user → solver (via VaultRelayer) // - buyToken pushed from solver → each user (must satisfy each minBuyAmount) // - Trade events emitted What's still pending Foundation deploys the default solver Docker container to Foundation infrastructure. The solver: listens to an order-book endpoint, runs the clearing-price algorithm every ~10s, builds batches, submits via settle() . Uses AereSwapRouter for inter-batch liquidity routing when in-batch order matching isn't enough. Order book API backed by a Postgres schema in the existing aere-explorer-db . /swap.html UI update , toggle for "Direct swap" (legacy AereSwap, immediate fill) vs "Protected swap" (MEV-resistant intent). Default to Protected after solver is live. Phase 2: bonded permissionless solver entry. Audit pass. Slashing logic for misbehaviour. What this composes with Tier 1.3 paymasters , users signing intents pay zero gas; the solver pays settlement gas. The signed-order UX combines naturally with paymasters → fully gasless swaps. Tier 1.5 Across intents , same intent paradigm, different scope. Cross-chain + DEX intents compose: "I want X on AERE at the best price, from any chain" is a single signed object that an Across solver + AereSettlement solver can fulfil together. Tier 1.6 Pyth oracle , solvers reference Pyth prices for fair-clearing verification, preventing rogue solvers from settling at off-market rates. Tier 1.8 burn , the burn takes 37.5% of the validator reward, a Foundation-set rate hard-capped at 50%. It is not a cut of gas fees and not the EIP-1559 base fee, so higher swap volume does not by itself burn more AERE. The chain is not deflationary today. What's next Tier 1.10 adds Fee Monetization / Sequencer Fee Sharing , developers earn a share of the gas their contracts generate, a structural incentive for builders to deploy on AERE. Tier 1.11 tunes sub-second block times. Tier 1.12 adds Symbiotic-secured bridge economics. The DEX layer just got fair. The work continues. ← Back to all posts --- # AERE goes cross-chain, Hyperlane-compatible messenger live, AERE Blog URL: https://aere.network/blog-bridge.html Fetched: 2026-09-15 AERE goes cross-chain, Hyperlane-compatible messenger live, AERE Blog Engineering AERE goes cross-chain, Hyperlane-compatible messenger live By AERE Network May 31, 2026 6 min read On May 31, 2026 AERE Network deployed a Hyperlane-Mailbox-compatible cross-chain messaging layer on chain 2800. Two contracts, one purpose: stop being a closed island. Any application on AERE can now dispatch arbitrary messages to any registered chain, and conversely, accept inbound messages verified by ECDSA-multisig signatures from an Interchain Security Module. What this changes: the legacy AereBridge contract was a federated lock-and-release bridge with one Foundation signer, useful for the very first months of mainnet, never the long-term answer. AereMessenger replaces that with a Hyperlane-compatible message bus that can scale to 200+ chains with the same security configuration any modern L2 uses. The two contracts Contract Address What it does AereMessenger 0xe54c2329f0786CFE3420c566B646148D25477325 Cross-chain message bus. Outbound: dispatch(destDomain, recipient, body) emits a Hyperlane-compatible Dispatch event with a unique message ID. Inbound: process(signatures, origin, sender, recipient, body, nonce) verifies ECDSA-multisig signatures from a configured validator set, prevents replay, and calls IMessageRecipient.handle() on the recipient contract. AereIGP (Interchain Gas Paymaster) 0x61B48615F490A23945988c92835eF35fdD86E837 Receives AERE fees from outbound messages. Foundation/relayer calls claim() to sweep accumulated fees, which fund the gas paid on destination chains when delivering AERE-originated messages. Per-destination gas overhead and price quote are configurable. How it composes The contracts ship with no chain-specific assumptions baked in. Any of these flows is supported the moment counterparty contracts exist: Cross-chain token transfers via AereWarpRoute instances (Hyperlane Warp Route pattern). Each asset gets one deployment per chain: collateral mode on the source chain, synthetic mode on AERE. Cross-chain governance , vote on Ethereum, execute on AERE, via a relayed message. Cross-chain oracle data , push BTC/USD from a Pyth deployment on another chain to AereOracle on AERE. Cross-chain identity attestations , KYC issued by a BaaS partner's deployment on one chain, surfaced as an AereIdentity claim on AERE. Security model AereMessenger uses an ECDSA-multisig Interchain Security Module (ISM): inbound messages must carry signatures from at least threshold distinct validators in the configured validator set. Validators sign the message ID using the Ethereum-Signed-Message prefix, the same scheme Hyperlane uses, which means when AERE is added to the public Hyperlane registry, the same contracts will accept signatures from the global Hyperlane validator network without any redeploy or migration. Phase 1 (current): Foundation operates the bootstrap validator set during the initial ramp. Threshold is 1 of 1 during the bootstrap window. This is no worse than the legacy AereBridge 's 1-of-1 federation, while removing the single-point-of-failure architecture going forward. Phase 2 (when Hyperlane registry accepts AERE): swap to the public Hyperlane validator set via addValidator() / setThreshold(N) . Recommended threshold for production: 3-of-5 or higher. Each app can also deploy its own ISM if it wants stronger guarantees, for example a high-value consumer app's bridge requiring 5-of-7 with named operators. What's still pending for full cross-chain operation The on-chain layer is done. To make actual cross-chain transfers live in users' wallets, three follow-ups remain: Validator + relayer Docker containers running on Foundation infrastructure (or partner infrastructure). Both are small Rust services, the validator signs outbound messages, the relayer fetches signatures and delivers messages between chains. Open a PR to hyperlane-xyz/hyperlane-registry registering AERE chain 2800 with the Hyperlane Mailbox + IGP addresses. Once merged, every Hyperlane app on the planet auto-discovers AERE. Typical merge: 1-3 business days. Deploy AereWarpRoute per asset , USDC, USDT, WETH, cbBTC. Each is a small contract clone on AERE plus a counterparty deployment on the source chain (Ethereum, Polygon, Arbitrum, BSC). These ship as Foundation can prioritise demand. What this combines with Pectra (EIP-2537 BLS precompiles), Fusaka (RIP-7951 secp256r1), the paymaster stack, and now AereMessenger together give AERE the full modern interop stack: EIP-2537 enables cheap on-chain BLS signature verification, the cryptographic primitive Hyperlane uses for aggregated signatures on its higher-performance ISMs. RIP-7951 enables passkey signature verification, consumer-app users can sign cross-chain transfers with Face ID via a smart wallet. Paymaster stack covers gas, a consumer-app user paying Ethereum-side gas via their AERE-side paymaster is now a clean architectural pattern. AereMessenger is the bus on which all of this flows. What's next The bridge layer being on-chain unblocks two follow-up workstreams: the Hyperlane registry PR (1-3 business days BD), and the Across Protocol integration (Tier 1.5, intent-based one-click cross-chain deposits). Across already supports Hyperlane-compatible chains, so adding it on top of AereMessenger is incremental work, not a separate bridge architecture. Today AERE is a Layer 1 with Pectra + Fusaka parity, a working paymaster stack, and a Hyperlane-compatible message bus. The closed-island era is over. ← Back to all posts --- # Coinbase splitter live: 37.5% validator-coinbase burn sealed on chain 2800, AERE Blog URL: https://aere.network/blog-burn.html Fetched: 2026-09-15 Coinbase splitter live: 37.5% validator-coinbase burn sealed on chain 2800, AERE Blog Engineering · Tokenomics Coinbase splitter live: 37.5% validator-coinbase burn sealed on chain 2800 By AERE Network May 31, 2026 5 min read Correction, July 20, 2026. This post was originally published as "AERE goes deflationary" and that headline was wrong. Direct measurement since publication shows that validator coinbase revenue on chain 2800 is zero , for two independent reasons: genesis declares no blockreward , and the 1 Gwei base fee is destroyed by EIP-1559 rather than paid to the proposer. Because the 37.5% burn is a share of that reward, it burns effectively nothing. Lifetime burned is 0.1374 AERE against a 2,800,000,000 AERE supply. Aere is not deflationary today. The splitter and the burn vault are real, live, sealed and ownerless exactly as described below, and the mechanism will burn in proportion to real fee flow when there is real fee flow. The forward-looking passages in this post should be read as the intent they were, not as a description of what is happening now. We are correcting this in place rather than quietly deleting it. On May 31, 2026 AERE Network deployed AereCoinbaseSplitter , a tiny atomic contract that finally backs the whitepaper §3.3 claim with on-chain reality. Validator coinbase rewards route through it on a sealed 37.5% to permanent burn, 62.5% to the validator split. In practice that reward is currently zero, so the split has processed 0.1374 AERE over the chain's lifetime. The burn vault has no withdraw function, no admin escape, no upgrade path. What goes in stays burned forever. What this changes: The whitepaper has promised since launch a 37.5% burn (a Foundation-set rate, capped at 50%). Until today, that claim wasn't backed by on-chain mechanism. Now it is: AereCoinbaseSplitter routes 37.5% of every block's validator coinbase reward to the sealed burn vault, verifiable by anyone in 30 seconds via splitter.totalBurned() or the burn vault's balance on the explorer. The contract Contract Address What it does AereCoinbaseSplitter 0xb4b0eCe9011613A5b84248a9B42a0f309E6F01Ec Atomic 37.5% / 62.5% splitter. Validators call splitToSelf() (or splitAndDistribute(validatorAddr) ) with their accumulated coinbase as msg.value . Contract atomically forwards 3750/10000 of value to AereFeeBurnVault, remainder back to the validator's address. Emits Burned and Distributed events with cumulative totals. Burn rate is capped at 50% by contract code; Foundation can adjust within that ceiling. AereFeeBurnVault (already deployed) 0x696afDF4f814e6Fd6aa45CE14C498ed9375fB2c6 Permanent burn destination. Has no withdraw function. Has no admin. Has no upgrade path. Once AERE enters this contract, it is mathematically unreachable. Anyone can verify this by reading the bytecode. How the flow works Three layers, each transparent on chain: Validators produce blocks normally. Block rewards (gas fees + emissions) accumulate in the validator's coinbase address as usual. No change to Besu, no change to QBFT, no hard fork required. Each validator runs a small forwarder daemon. A ~80-line Python service watches the validator's coinbase balance. When it crosses a threshold (default 10 AERE), the daemon signs and sends a transaction that calls AereCoinbaseSplitter.splitToSelf() with the balance as msg.value . The splitter atomically burns and returns. The contract sends 37.5% to the burn vault (permanent), 62.5% back to the validator's address. Net result: the validator keeps the majority of their earnings while the chain's deflation accrues automatically. The forwarder daemon is the only off-chain component, and it's tiny: ~5 MB RAM, runs alongside the existing Besu node, with no new infrastructure required. Why this design (and not a Besu fork) The alternative, modifying Besu's block producer to enforce the split at consensus level, would have required forking Hyperledger Besu, maintaining the fork against every upstream release, and coordinating a hard-fork-style network upgrade for every parameter change. That's real engineering cost. The splitter-plus-daemon design is observationally identical from outside the chain. The on-chain math is the same. The cumulative burn is the same. The only difference is that it ships in days instead of months, costs nothing ongoing, and leaves Besu unchanged. The trade-off: validators technically could stop running the daemon and pocket 100% of fees. But there are 9 validators today (7 when this note was added on 2026-07-20), all Foundation-operated, and any divergence between coinbase receipts and splitter calls would be immediately visible on chain. Public accountability is the enforcement mechanism today. Phase 2 (post-audit, with hard-fork upgrade) can move this to consensus-level enforcement. What's measurable now Anyone can query in O(1): AereCoinbaseSplitter.totalBurned() , lifetime AERE burned through this contract AereCoinbaseSplitter.totalDistributed() , lifetime AERE returned to validators AereCoinbaseSplitter.burnedBy(addr) , per-validator burn contribution AereFeeBurnVault.balance , total locked AERE in the vault AereCoinbaseSplitter.burnBps() , current burn rate (3750 = 37.5%) The network status page now displays a live "Deflation tracker" card showing the lifetime burn in real time. The number is 0.1374 AERE and it is effectively static, because the daemons can only forward what the validator coinbase actually receives, which today is nothing. Tokenomics impact Correction to this section. As originally written this paragraph claimed a "per-block emission schedule from genesis" and a "slowly-inflating supply curve". Both are wrong. The canonical genesis for chain 2800 declares no blockreward key at all, so there is no emission schedule and never was one. Supply has been fixed at 2,800,000,000 AERE since genesis-v2 and cannot increase. AERE was never gas-inflationary. With the splitter active, the picture changes: Actual flow per block today: the EIP-1559 base fee (1 Gwei) is destroyed by the protocol, and the priority fee is zero, measured as effectiveGasPrice equal to baseFeePerGas on every recent transaction. Validator coinbase therefore receives nothing. What the splitter does with it: of whatever does reach the coinbase, 62.5% goes to the validator and 37.5% is permanently destroyed. That split is live, sealed and correct. It has processed 0.1374 AERE over the chain’s lifetime. There are no emissions to net against, so the supply curve is flat rather than inflating or deflating. Shipping more Tier-1 features (paymasters, cross-chain messaging, intent bridging, oracle updates, randomness submissions, consumer-app activity, dApp deployments) raises gas usage, but gas usage feeds the base fee, which is destroyed rather than paid to the proposer. It does not by itself feed the burn. This is the "ultrasound money" dynamic Ethereum got post-EIP-1559, and it is worth being exact about where Aere actually sits relative to it. Aere has not reached that crossover and is not near it. Reaching it requires validator coinbase revenue to be non-zero, which today it is not: genesis declares no blockreward , and the base fee is destroyed by EIP-1559 rather than paid to the proposer. There is a third fact that decides whether volume alone can close the gap, and it is worth stating precisely rather than hand-waving. Under EIP-1559 a validator's coinbase revenue comes from the priority fee, the tip, not from the base fee. Sampled directly on chain 2800, every recent transaction pays effectiveGasPrice exactly equal to baseFeePerGas , meaning a tip of zero. So while tips stay at zero, more dApps and more users do not move the crossover point, because 37.5% of zero is zero at any volume. Volume starts to matter only once transactions actually pay a priority fee, or once a block reward is introduced. The mechanism is live, immutable and correct; what it lacks is revenue to act on. Where this combines with the rest of the session's work Tier 1.3 Paymasters , every paymaster pays AERE gas → splits → burns. A high-volume paymaster like AereTokenPaymaster is a continuous deflation pump. Tier 1.4 Cross-chain messaging , every Hyperlane message dispatch pays AERE gas → burns. Tier 1.5 Across intents , every solver fill + every settlement message pays AERE gas → burns. Tier 1.6 Pyth oracle updates , every updatePriceFeeds call pays AERE gas → burns. Tier 1.7 drand submissions , every submitRound call pays AERE gas → burns. Each shipped feature isn't just a capability, it's a stream feeding the deflation flywheel. What's still pending Foundation deploys the forwarder daemon to each of the 7 validator hosts. The Dockerfile + Python script ship with this release; deployment is ops work, ~30 min total. Phase 2: move enforcement to consensus layer. Future Besu fork (or QBFT-extension proposal) where the chain itself splits coinbase per block. Removes the "validator could disable daemon" trust assumption. Until then, public accountability is the enforcement mechanism, and chain data is public. What's next Tier 1.9 ships batch-auction settlement on AereSwap for MEV-resistant trading. Tier 1.10 adds Fee Monetization / Sequencer Fee Sharing , developer revenue share, strong builder magnet. Tier 1.11 tunes sub-second block times. AERE's economic engine now points the right direction: the destruction path is built, sealed and pointed the right way. What it still needs is transaction volume, because the burn is proportional to validator reward and validator reward is currently zero. The flywheel is assembled; it is not yet turning. ← Back to all posts --- # Why EVM Compatibility Matters, AERE Blog URL: https://aere.network/blog-evm-compatibility.html Fetched: 2026-09-15 Why EVM Compatibility Matters, AERE Blog Editorial Why EVM Compatibility Matters By AERE Network May 3, 2026 5 min read When AERE Network describes itself as "EVM-compatible," it means something specific and consequential: every tool, library, wallet, and development framework built for Ethereum works on AERE without modification. This isn't a minor convenience, it's the difference between a chain that developers can use on day one and one that requires months of ecosystem-building before it becomes usable. This article explains what EVM compatibility actually means, which tools it covers, what "porting" a dApp to AERE actually involves, and why AERE chose to build on the EVM rather than a custom execution environment. What the EVM Is The Ethereum Virtual Machine is the standardized execution environment that runs smart contract bytecode on Ethereum. It defines a precise instruction set (opcodes), a memory and storage model, a gas accounting system, and a set of precompiles for common cryptographic operations. Every Solidity or Vyper contract compiles to EVM bytecode. Every Ethereum node runs that bytecode identically. Because the EVM is a published open standard, other chains can implement it independently. Any chain that executes the same instruction set and exposes the same JSON-RPC API is, from a tool perspective, indistinguishable from Ethereum. That's what AERE does. AERE runs Hyperledger Besu, one of the most battle-tested EVM implementations available, with chain ID 2800. The Tool Ecosystem You Get for Free The Ethereum development ecosystem has been built over nearly a decade. Every piece of it works on AERE: MetaMask Wallet connection, transaction signing, account management, add AERE as a custom network and everything works. Hardhat Professional Solidity development framework. Add AERE as a network in hardhat.config.js and deploy with the same scripts. Foundry Fast Solidity testing and deployment toolkit. forge test, forge script, cast send, all work against AERE's RPC endpoint. Remix Browser-based IDE. Select "Injected Provider" with MetaMask on AERE Network and deploy directly from the browser. ethers.js / viem The standard JavaScript libraries for blockchain interaction. Point them at https://rpc.aere.network and they work immediately. OpenZeppelin The standard library for Solidity, ERC-20, ERC-721, AccessControl, governance. Install and import as on Ethereum. The Graph Subgraph indexing infrastructure. AERE's indexer API at api.aere.network provides equivalent functionality natively. WalletConnect Mobile wallet bridge protocol. Any wallet that supports WalletConnect can connect to AERE dApps without custom integration. What "Porting" a dApp to AERE Actually Involves For most Ethereum dApps, deploying to AERE requires changing exactly one or two things: // hardhat.config.js, add this network block networks: { aere: { url: "https://rpc.aere.network", chainId: 2800, accounts: [process.env.DEPLOYER_PRIVATE_KEY], } } // Then deploy the same way you would to any network: npx hardhat run scripts/deploy.js --network aere The smart contract source code does not change. The ABI does not change. The frontend JavaScript does not change, except for updating the chain ID in the network configuration. The only exception is if your Ethereum contract depended on Ethereum-specific infrastructure that doesn't exist on AERE, like a specific oracle address or a bridge contract address, in which case you'd replace those with their AERE equivalents. Why Not Build a Custom VM? Some blockchains have chosen to build their own virtual machines and programming languages. There are legitimate reasons to do this, a custom VM can be optimized for specific performance characteristics or programming paradigms that the EVM wasn't designed for. But there's a cost: every developer who wants to build on your chain has to learn a new language, new tools, and new debugging techniques. The ecosystem you can offer is, for years, a fraction of what Ethereum offers. AERE's decision to build on the EVM is a deliberate prioritization of developer accessibility over VM customization. The Ethereum toolchain is what professional smart contract developers know. Being able to deploy an existing Ethereum project to AERE on the same afternoon a developer hears about it is a more valuable property than any custom VM feature would be at this stage. EVM Compatibility vs. EVM Equivalence There is a meaningful distinction between a chain that is "EVM-compatible" and one that claims "EVM equivalence." Equivalence implies behavior identical to the Ethereum mainnet EVM at the opcode level, including edge-case gas accounting behavior. Compatibility means the standard instruction set and API are supported and all common patterns work correctly. AERE runs Hyperledger Besu, which implements the EVM faithfully. Contracts that follow standard Solidity patterns and use standard libraries will behave identically on AERE as on Ethereum. Contracts that depend on very specific gas cost assumptions tied to Ethereum's fee market may need review, but such cases are rare in practice. The Bottom Line for Developers If you have an Ethereum dApp and want to run it on a chain with sub-second finality, negligible gas costs, and a hard-capped native token, AERE is a same-afternoon deployment. If you're starting a new project, you can write standard Solidity against the OpenZeppelin library, test with Hardhat or Foundry, and deploy to AERE without learning anything new. The developer documentation has the full RPC reference, SDK, and contract registry. The grants program funds projects that deploy to AERE. And this tutorial walks through deploying your first contract in ten minutes. ← Back to Blog --- # AERE pays developers, Fee Monetization live, AERE Blog URL: https://aere.network/blog-fee-monetization.html Fetched: 2026-09-15 AERE pays developers, Fee Monetization live, AERE Blog Engineering · Tokenomics AERE pays developers, Fee Monetization live Update, 2026-08-19. This article describes the fee design as built in June. On chain 2800 today the gas base fee (a 1 gwei consensus floor) is burned by EIP-1559 itself, priority fees are zero, and the coinbase splitter receives nothing, so no gas-fee share is flowing to developers, the treasury or validators; the burn contracts are live, immutable and currently burning nil (see /burn). The mechanisms are deployed; the flow they describe will start with real traffic and a non-zero priority fee. The solver registry is permissioned for Phase 1 and the intent bridge routes are deliberately inert (see the 2026-08-01 update on the intents article), so "all permissionless" below was true of the design, not of the network as it runs. By AERE Network May 31, 2026 5 min read On May 31, 2026 AERE Network deployed AereFeeMonetization , a contract that pays developers AERE for every transaction that touches their registered contracts. The dev-share right is an ERC-721 NFT: transferable, fractionalisable, collateralisable. Plus a fixed 5% of every gas fee on AERE flows to the AERE Foundation treasury, separately. On AERE, developers actually get paid for the work their code does. What this means: a popular dApp on AERE, say a games library, a DeFi protocol, or an NFT marketplace alternative, earns continuous AERE revenue from gas fees. A popular contract can earn meaningful, continuous AERE revenue from the gas its users generate. No grant application, no token launch, no surcharge on users. You build, users use it, AERE flows to your wallet. The contract Contract Address What it does AereFeeMonetizationV2 0xb560bdFB8b8B918012e6481e3bcF473c79c2a850 ERC-721 NFT registry + per-NFT pending balance + Foundation treasury slice. Developers call register(contractAddr, payoutAddr) and receive NFT tokenId. The off-chain distributor (Foundation-operated) parses block traces, attributes gas to top-level called contracts, looks up registered tokenIds, and calls distribute(tokenIds, amounts, treasuryAmount) per cycle. NFT owners call claim(tokenId) to withdraw their accumulated AERE. The fee distribution per gas fee After all session tiers ship, the gas-fee economic flow on AERE is: Slice Rate Recipient Source Burn 37.5% AereFeeBurnVault (permanent destruction) Tier 1.8 Developer share 20% Registered NFT owner (or validator if unregistered) Tier 1.10 (this) Foundation treasury 5% AERE Foundation (always) Tier 1.10 (this) Validator 37.5% Block validator coinbase Tier 1.0 baseline (All four rates are Foundation-tunable within hard caps: burn ≤ 50%, dev-share ≤ 30%, treasury ≤ 15%. Validator slice is the residual.) How a developer registers // One transaction. ~80k gas. Permissionless. AereFeeMonetizationV2 fm = AereFeeMonetizationV2(0xb560bdFB8b8B918012e6481e3bcF473c79c2a850); uint256 myTokenId = fm.register(MY_CONTRACT_ADDR, MY_WALLET); // Done. Now you earn 20% of all gas fees users pay to MY_CONTRACT_ADDR. // Check your balance any time: uint256 pending = fm.pendingRewards(myTokenId); // Withdraw when you want: fm.claim(myTokenId); // sends AERE to whoever currently owns the NFT Foundation pre-registered 37 contracts on deploy Every Foundation-deployed contract from this session, AereSwapRouter, AereYieldFarm, AereSettlement, AereMessenger, AereNFTMarketplace, all 5 paymasters, AerePyth, AereRandomnessBeacon, AereCoinbaseSplitter, and 27 more, is pre-registered with AERE Foundation as the NFT owner. Their fee-share flows back to Foundation automatically. External developers register their own contracts permissionlessly. There is no allowlist for the register() function; anyone can call it for any contract they want to earn from. (Yes, anyone could try to front-run a developer by registering their contract first. Honest answer: this is a known minor griefing surface. Phase 2 adds contract-owner verification via EIP-7201 storage or AdminRoles ABI introspection. For Phase 1, devs should register immediately on deploy, same tx, same block, to lock the NFT.) Why this matters strategically For users: nothing changes. Same gas costs, same UX. For developers: AERE becomes one of very few chains where building is financially rewarded. The economics work for indie devs: a contract doing 10k transactions/day at AERE gas levels, when gas pricing becomes meaningful, generates a steady AERE income stream. The NFT can be sold for a lump-sum if the developer wants to exit; or held for the recurring revenue. For AERE token economics: every Tier-1 feature shipped this session generates gas → 37.5% gets burned forever (price-supportive), 5% flows to Foundation treasury (operational sustainability), 20% creates a flywheel attracting more developers (more dApps → more gas → more burn). Three economic loops, all activated by ordinary transactions. For AERE Foundation specifically The 5% treasury slice + dev-share on the 37 pre-registered Foundation contracts means Foundation receives meaningful gas-fee revenue automatically as the chain grows. Combined with the existing Foundation revenue streams (validator coinbase, paymaster spreads, NFT marketplace fees, mining subscriptions, locked-staking penalties), AERE Foundation operates on a sustainable on-chain revenue model, without requiring grants, donations, or token sales. What's still pending Deploy aere-fm-distributor Docker container on Foundation infrastructure (next to coinbase-forwarder). Parses block traces, attributes gas per top-level called contract, batches calls to distribute(...) . developer-revenue.html page documenting the pattern for builders. Phase 2: contract-ownership verification. Today, anyone can register any contract. Phase 2 introduces optional dispute window where the contract owner can challenge wrongly-registered NFTs. What's next Tier 1.11 tunes sub-second block times. Tier 1.12 adds Symbiotic-secured bridge economics. Beyond that the work moves to consumer-app launches, MiCA EMT partnership, and the dApp ecosystem the Tier-1 stack is designed to support. The economic engine is complete: burn flow + dev share + treasury slice + MEV-resistant DEX + intent bridging + Pyth oracle + drand randomness + 5-paymaster gasless stack, all deployed on chain; permissionless by design, with the solver registry permissioned for Phase 1 and the intent routes inert today (see the update at the top). ← Back to all posts --- # Deploy Your First Smart Contract on AERE, AERE Blog URL: https://aere.network/blog-first-contract.html Fetched: 2026-09-15 Deploy Your First Smart Contract on AERE, AERE Blog Education Deploy Your First Smart Contract on AERE By AERE Network April 19, 2026 5 min read Deploying a smart contract to AERE Network is nearly identical to deploying one to Ethereum, because AERE is fully EVM-compatible. If you've used Remix before, you already know the workflow. If you haven't, this guide will walk you through it from scratch. By the end you'll have a live, verified contract on chain ID 2800. What You'll Need MetaMask installed in your browser with AERE Network configured (see Add AERE to MetaMask ) A funded address. This is currently a blocker: the faucet is deployed but holds a zero balance, and there is no other public way to obtain AERE today, so deploying to chain 2800 is not yet possible from a new address A browser, no local toolchain required That's it. Remix is a browser-based IDE; nothing needs to be installed locally. The Contract We'll deploy a simple Counter contract: it stores a number on-chain and lets anyone increment it. It's trivial by design, the goal here is to understand the deployment process, not the contract logic. // SPDX-License-Identifier: MIT pragma solidity ^0.8.20; contract Counter { uint256 public count; function increment() external { count += 1; } function reset() external { count = 0; } } Step-by-Step Deployment 1 Open Remix. Navigate to remix.ethereum.org in the same browser where MetaMask is installed. 2 Create a new file. In the File Explorer panel on the left, click the "New File" icon and name it Counter.sol . Paste the contract code above into the editor. 3 Compile. Click the Solidity Compiler icon in the left sidebar (it looks like the Solidity logo). Make sure the compiler version is set to 0.8.20 or newer, then click "Compile Counter.sol" . A green checkmark indicates success. 4 Switch MetaMask to AERE Network. Click the network selector in MetaMask and choose AERE Network. If you haven't added it yet, follow the guide at /blog-add-to-metamask.html first. 5 Open the Deploy tab in Remix. Click the "Deploy & Run Transactions" icon (an Ethereum diamond with an arrow). In the Environment dropdown, select "Injected Provider, MetaMask" . Remix will read your MetaMask connection and display your AERE address and balance. 6 Deploy. Make sure Counter is selected in the Contract dropdown, then click the orange "Deploy" button. MetaMask will pop up a transaction confirmation. The gas cost will be a tiny fraction of a single AERE. Note that this step assumes a funded address; as covered above, the faucet is currently unfunded, so deployment from a new address is not yet possible. Click "Confirm" . 7 Find your contract. After the transaction confirms (within 1-2 seconds on AERE), a deployed contract instance appears in the "Deployed Contracts" section at the bottom of the Deploy panel. You'll see its address and the available functions. Copy the address. 8 Verify on the explorer. Paste the contract address into explorer.aere.network . You'll see the deployment transaction, the contract bytecode, and, if you verify the source, the ABI and source code. Calling the Contract Back in Remix, expand the deployed contract. You'll see three buttons: count (a read call, free), increment , and reset . Click increment , MetaMask will ask you to confirm a transaction. After it lands, click count and you'll see the value is now 1. Congratulations: you have a live contract on AERE L1. Gas on AERE is negligible. QBFT consensus and a dedicated validator set mean block space is abundant. The deployment transaction and each function call costs a fraction of a cent at any realistic AERE price. The current constraint is not gas but funding: the faucet is deployed but unfunded, so a new address cannot yet obtain the AERE needed to run this exercise. Next Steps Once you're comfortable with Remix, the workflow extends directly to professional tooling: Hardhat / Foundry , set chainId: 2800 and url: "https://rpc.aere.network" in your network config. Every test and deploy script works unchanged. OpenZeppelin contracts , install @openzeppelin/contracts and import as normal. All standard contracts (ERC-20, ERC-721, AccessControl, etc.) compile and deploy on AERE without modification. Verification , the AERE explorer supports Sourcify-compatible source verification. Verified contracts show their source code and ABI publicly. For a deeper look at the full developer setup, visit the developer documentation . If you're building something substantial, the grants program can fund your project. ← Back to Blog --- # AERE upgrades to Fusaka, native passkey signatures now on-chain, AERE Blog URL: https://aere.network/blog-fusaka.html Fetched: 2026-09-15 AERE upgrades to Fusaka, native passkey signatures now on-chain, AERE Blog Engineering AERE upgrades to Fusaka, native passkey signatures now on-chain By AERE Network May 31, 2026 5 min read On May 31, 2026 at 09:39:11 UTC , AERE Network activated the Fusaka EVM ruleset at block 2,106,597 , the second hardfork shipped on AERE in a single day, following the Pectra activation seven hours earlier. The chain remained at one-second blocks throughout, all three validators participated cleanly through a rolling restart staged ahead of the timestamp. Note on current state, measured 2026-08-01 against chain 2800: Aere Network ran 7 Foundation-operated validators (f=2, quorum 5 of 7; 9 with quorum 6 of 9 since 2026-08-09), and, re-checked on 2026-08-10, the average block interval over the last 2,000 blocks measured 0.557 s (it read 0.517 s when this post was written; the chain slowed afterwards and the figure was re-measured) against a configured 500 ms period. The three-validator, one-second-block details in this post are historical to its May 31 2026 date and are left as written. Fusaka is the EVM ruleset adopted by Ethereum mainnet on December 3, 2025. AERE chain 2800 is now at full Pectra+Fusaka parity with the live Ethereum specification, within a single day of activation, no chain-halting event required. What's new in one line: AERE smart contracts can now verify Apple Face ID, Touch ID, Windows Hello, Android biometric, YubiKey, and EU Digital Identity Wallet signatures on-chain at ~3,500 gas, roughly 70× cheaper than verifying the same signature in Solidity. This is the cryptographic foundation for biometric-login wallets on AERE. What Fusaka brings to AERE The marquee feature for AERE is RIP-7951 , a single new precompile, but with outsized consumer-UX implications. EIP / RIP What it does on AERE RIP-7951 secp256r1 / P-256 signature verification precompile at address 0x0000000000000000000000000000000000000100 . Fixed cost: 3,450 gas. Returns 1 if the signature is valid, 0 otherwise. This is the curve used by every modern hardware-secure-element on consumer devices. Why P-256 matters Every modern smartphone, laptop, and security key already signs cryptographic operations using the secp256r1 (P-256) curve. None of them can talk to a blockchain today, because blockchains historically only verify secp256k1 (the curve used by Bitcoin and MetaMask). Until now. With Fusaka active on AERE, the following hardware can produce signatures that smart contracts on AERE can verify natively, at production gas costs: Apple Secure Enclave , the dedicated security chip in every iPhone since the 5s, every iPad since 2013, every Mac with Apple Silicon. Powers Face ID, Touch ID, Apple Pay, passkeys. Windows Hello + TPM 2.0 , biometric and PIN-protected signatures on every modern Windows PC. Android Keystore + StrongBox , hardware-backed signatures on Android devices. YubiKey , Google Titan , SoloKey , Ledger Stax , Trezor Safe 5 , hardware security keys. WebAuthn / Passkeys (W3C standard), the cross-platform passwordless-login standard used by Apple iCloud Keychain, Google Password Manager, Microsoft Authenticator, 1Password, Dashlane. EMV credit and debit cards , every modern chip card. e-Passports, government eID cards, and the EU Digital Identity Wallet (eIDAS 2.0), the upcoming continent-wide identity standard. Before Fusaka, verifying any one of these signatures on-chain via Solidity cost roughly 250,000 gas, too expensive for everyday transactions. With the RIP-7951 precompile, it costs 3,450 gas, well within the budget of an ordinary user operation. The signature primitive that powers every consumer device on Earth is now economically usable on AERE. What this unlocks Wallet login with biometrics, no seed phrase. A user opens an AERE wallet app, performs Face ID, and signs a transaction. The Apple Secure Enclave produces a P-256 signature. The wallet relays it to AERE. The on-chain smart wallet contract verifies the signature via the precompile, and the transaction executes. No 12-word seed phrase. No password. No private key the user can lose or expose. Hardware-bound security. Because the P-256 private key lives in tamper-resistant hardware on the user's device, malware on the phone cannot exfiltrate it. Phishing sites cannot trick the user into revealing it. The user cannot accidentally email or screenshot it. Cross-device wallet recovery via passkey sync. iCloud Keychain and Google Password Manager already sync passkeys across the user's devices. A user who switches to a new iPhone gets their AERE wallet back automatically, with no migration step. EU Digital Identity Wallet integration. The EUDI Wallet (mandatory across the EU under eIDAS 2.0) uses P-256 signatures. AERE applications can verify an EU-issued identity attestation on-chain natively. Critical groundwork for compliant on-chain finance products in Europe. Modern hardware wallets. Ledger Stax, Trezor Safe 5, and GridPlus Lattice2 all ship P-256 alongside secp256k1. AERE can verify their P-256 signatures cheaply, opening the door to passkey-style hardware wallet UX without legacy secp256k1 flows. The upgrade procedure Same playbook as Pectra, executed seven hours earlier the same day: Confirmed Hyperledger Besu v26.4.0 on all 3 validators supports the Osaka hardfork (Besu's name for Fusaka). Generated a new genesis with osakaTime: 1780220351 (2026-05-31 09:39:11 UTC), backed up the existing Pectra-era genesis as genesis.pre-fusaka.bak . Pushed the new genesis to all 3 validators and rolling-restarted each one with 5+ minutes between restarts. Quorum maintained throughout. At the fork timestamp, the chain transitioned cleanly. The first post-fork block was 2,106,597. Verified Fusaka active by inspecting block-header fields and probing the secp256r1 precompile at 0x100 . What's next With Pectra and Fusaka now both active, AERE has the cryptographic primitives needed for the next wave of consumer wallet UX: EIP-7702 + RIP-7951 together = passkey-signed smart-account transactions, gas-sponsored by application paymasters. The cleanest "Face ID → transaction" path possible on EVM today. Coinbase Smart Wallet, Privy, Para, and other passkey-aware wallet stacks now work on AERE the same way they work on Base, Polygon, Optimism, and Arbitrum. Non-custodial neobank applications built on AERE inherit Face ID / Touch ID onboarding directly, no seed-phrase prompt, no custodial intermediary. The chain layer is now ready. The application layer is where the work continues. ← Back to all posts --- # AERE Genesis v2: Correcting the Supply to 2.8 Billion, AERE Blog URL: https://aere.network/blog-genesis-v2.html Fetched: 2026-09-15 AERE Genesis v2: Correcting the Supply to 2.8 Billion, AERE Blog Announcement AERE Genesis v2: Correcting the Supply to 2.8 Billion By AERE Network May 9, 2026 4 min read On May 7, 2026, AERE Network completed a full chain relaunch, referred to internally as Genesis v2, to correct the total token supply to the figure specified in the project whitepaper: 2,800,000,000 AERE. This article explains what happened, why we chose to act before public adoption, and what the corrected allocation structure looks like. Short version: An error in the original genesis configuration meant the on-chain total supply did not match the whitepaper. We caught it before any users held tokens or any contracts had real activity. We relaunched the chain cleanly, redistributed allocations correctly, and redeployed all contracts. The chain running today is the corrected one. What Went Wrong The original AERE genesis block, deployed during the initial infrastructure build, contained an allocation that did not precisely match the tokenomics specified in the whitepaper. The whitepaper defines a hard cap of exactly 2,800,000,000 AERE distributed across six named allocation buckets. The genesis v1 configuration diverged from those figures. This kind of discrepancy, between a whitepaper specification and a genesis-block implementation, is not unusual in early-stage blockchain development. What matters is when it is discovered and what is done about it. We discovered it during an internal audit of the genesis allocation before any token-holder activity or exchange listings had taken place. Why Relaunch Rather Than Patch A blockchain's total supply is set at genesis and cannot be corrected by a later transaction. There is no "edit" to an existing genesis block. The only technically sound options were: Accept the discrepancy and update the whitepaper to match the on-chain reality. Relaunch the chain with a corrected genesis, before real users had accumulated balances or real value had transacted. We chose option 2. The whitepaper supply cap of 2.8 billion was set deliberately, with a specific allocation structure designed for the long-term health of the ecosystem. Altering that structure retroactively, or locking in an error simply to avoid the inconvenience of a relaunch, would have been the wrong call. Because Genesis v2 happened before any real-user wallets held tokens, the practical disruption was zero. The Corrected Allocation The six allocation wallets in Genesis v2, each holding the whitepaper-specified amount: Allocation Amount (AERE) Share Staking Reserve 1,400,000,000 50% Ecosystem Fund 560,000,000 20% Team 420,000,000 15% Foundation 180,000,000 6.43% Airdrop 140,000,000 5% Strategic Investor 100,000,000 3.57% Total 2,800,000,000 100% Every wallet is verifiable on the block explorer at explorer.aere.network . The total circulating supply visible on-chain matches the whitepaper exactly. Contract Redeployment All 16 production contracts, staking, AMM, bridge, identity, governance, NFT marketplace, and the rest, were redeployed on the corrected chain with ownership assigned to the Foundation address. Contract addresses remain consistent with those published in the developer documentation . No external integrations had been built against the v1 chain, so no third-party developers were affected. What This Means Going Forward The chain running today, chain ID 2800, is Genesis v2. It is the only chain AERE has ever publicly presented to developers and users. The v1 genesis is an internal artifact that never reached public operation. There is no "old AERE" to reconcile with. We are publishing this account in the interest of transparency. Anyone building on AERE, or considering holding AERE, deserves to know the supply history of the chain they're working with. The 2.8 billion hard cap is set in genesis. It cannot be changed without a chain fork, and any such fork would require community governance. There are no plans for one. If you have questions about the genesis configuration or the allocation wallets, you can open an issue at git.aere.network . ← Back to Blog --- # AERE Developer Grants: Build and Get Funded, AERE Blog URL: https://aere.network/blog-grants.html Fetched: 2026-09-15 AERE Developer Grants: Build and Get Funded, AERE Blog Ecosystem AERE Developer Grants: Build and Get Funded By AERE Network May 7, 2026 4 min read AERE Network's grants program is funded from the Ecosystem allocation, 560 million AERE (20% of total supply) set aside specifically to grow the chain. If you're building something useful for the AERE ecosystem, you can apply for a grant. There's no equity involved, no token clawback clause, and no gatekeeping committee, applications go public as Gitea issues and anyone can review the process. This article covers who the program is for, what gets funded, how the three tiers work, and what a strong application looks like. Who It's For The grants program is open to anyone, solo developers, small teams, open-source projects, research groups, and technical content creators. There is no geographic restriction, no requirement to be incorporated, and no preference for teams with prior blockchain experience over those without. The evaluation criteria are about the work, not the résumé. The program funds work that makes AERE more useful. That means: dApps that deploy to AERE mainnet and serve real users Infrastructure: indexers, oracles, bridges, wallets, RPC tooling Developer tooling: SDKs, CLI tools, testing frameworks, deployment helpers Security research: audits, formal verification, vulnerability disclosure Technical content: written tutorials, video courses, translated documentation Integration adapters: connectors between AERE and third-party platforms The program does not fund marketing campaigns, generic NFT collections, projects with no working prototype at application time, or work that has nothing to do with the AERE ecosystem. The Three Grant Tiers Quick Build $1k, $5k USD 1-2 week scope Single-purpose tooling or integrations 50% on approval, 50% on delivery Approval decision in under 7 days Project $5k, $25k USD 1-3 month scope dApps, indexers, libraries, content series Milestone-based payments Approval decision in under 14 days Strategic $25k, $100k USD 3+ month scope Major infrastructure, novel research Quarterly check-ins, public KPIs DAO vote required Grants are paid in a combination of AERE and stablecoins depending on tier and applicant preference. Payment method is discussed during the review process. The Quick Build and Project tiers are approved by the Foundation; Strategic tier grants require a governance vote. What a Strong Application Looks Like The most successful grant applications share a few qualities that have nothing to do with the size of the ask: Concrete scope. A precise description of what will be built, how long it will take, and what the deliverable is. "An NFT marketplace for AERE" is weak. "An ERC-721 marketplace with EIP-2981 royalty enforcement, open-source, with a deployed frontend at [URL], using the AereNFTMarketplace contract as a reference" is strong. Evidence of ability to ship. Prior work, deployed projects, open-source repos, published articles, design portfolios, matters more than educational credentials. The question reviewers are asking is: can this person deliver what they're proposing? Realistic milestones. Break the scope into verifiable checkpoints. This protects both parties: you get paid at each milestone, and the Foundation can verify progress before releasing the next tranche. Clear connection to AERE. Explain why the ecosystem needs this thing and how it specifically takes advantage of AERE's properties (EVM compatibility, sub-second finality, existing deployed contracts). The Application Process Applications are submitted through the form at /grants.html . The form pre-fills a Gitea issue on the public grants repository , which you confirm and submit. Once submitted, the issue is public, anyone can comment, ask questions, or express support. This transparency is intentional: it lets the community provide input and holds the Foundation accountable to its own stated criteria. The Foundation reviews the issue, may ask clarifying questions directly on the Gitea thread, and posts an approval or rejection decision as a comment. For Quick Build tier, this takes under a week. For Strategic tier grants, the DAO vote adds additional time. Ready to apply? The full application form, with tier selection, milestone fields, and prior work, is at the grants page. Apply for a grant → Questions If you have questions about scope, eligibility, or whether your idea is a good fit before applying, open a discussion issue on the grants repository . The Foundation checks it regularly and responds publicly so the answer is useful to others with similar questions. ← Back to Blog --- # AERE goes intent-based, Across SpokePool + ERC-7683 live, AERE Blog URL: https://aere.network/blog-intents.html Fetched: 2026-09-15 AERE goes intent-based, Across SpokePool + ERC-7683 live, AERE Blog Engineering AERE goes intent-based, Across SpokePool + ERC-7683 live By AERE Network May 31, 2026 6 min read On May 31, 2026 AERE Network deployed two more contracts that finish the cross-chain stack: AereSpokePool (Across Protocol v3 compatible) and AereERC7683 (ERC-7683 IOriginSettler). Together they convert AERE's bridge model from "user picks chain + asset + waits 10 minutes" to "user signs one intent and a solver delivers in ~30 seconds." What this changes: Tier 1.4 (AereMessenger) gave AERE a Hyperlane-compatible message bus. Tier 1.5 puts an intent-based UI on top of it, the same UX every modern crypto app converged on. Users no longer see "bridge." They see "deposit from any chain." Behind the scenes a competitive solver network races to fill their order. The two contracts Update, 2026-08-01. Both addresses in the table below are the V1 contracts, and both are now marked deprecated and flawed in our canonical registry: the settlement path could release locked principal without properly verifying the delivered output leg. Do not integrate against them. Measured on 2026-08-01, both hold a zero balance. Corrected replacements are deployed, AereSpokePoolV2Corrected 0xbEF9BF0D22dd00DBEdA262C3Cd3178f08C623d8d and AereERC7683V2Corrected 0x8eC4e7F01790C04D450b45d399E71DFd381560e3 , and both are deliberately inert with no remote spoke enrolled, so no intent route is open on either version today. The mechanism described below is still an accurate description of the design; the addresses are not the ones to use. Contract Address What it does AereSpokePool 0xCAB1DBA5f6F06198000C20a974d675f1B3181AbD Across v3-compatible SpokePool. Three core flows: deposit(...) , origin side. User locks input tokens, emits a V3FundsDeposited event with the intent parameters. Solvers see the event and race to fill on the destination chain. fillRelay(...) , destination side. Solver transfers output tokens directly to the user's recipient, then triggers a settlement message via AereMessenger. handle(...) , settlement. AereMessenger delivers the cross-chain receipt; the SpokePool credits the solver's pending balance, which they withdraw via claimSettlement(...) . Plus claimRefund(...) if the fill deadline passes without delivery. AereERC7683 0x67Fb9830e3a2BC06cEb641cfF3beD87b273ccb29 ERC-7683 IOriginSettler. Implements both the on-chain ( open ) and gasless ( openFor with EIP-712 signature) flows from the standard. Any intent aggregator that speaks ERC-7683, UniswapX, Across UI, CoW Protocol, 1inch Fusion, Anoma, can submit cross-chain orders to AERE through a uniform interface. Resolves orders into the standard ResolvedCrossChainOrder shape with maxSpent/minReceived/fillInstructions arrays. How a consumer-app user experiences this (after solver onboarding) Before Tier 1.5: User on Polygon wants to deposit USDC into a consumer app on AERE. The app redirects them to a bridge page. User approves USDC, locks it on the Polygon bridge contract, ~$0.30 gas. Waits 5-15 minutes for a relayer to deliver to AERE. USDC.aere arrives in their wallet, needs another step to land in their app account. Total: 5 steps, 5-15 minutes, mental overhead at every step. After Tier 1.5: User opens the app → "Deposit from any chain." "I have 500 USDC on Polygon." Face ID confirms (Fusaka RIP-7951 → Pectra EIP-7702 → smart account). ~30 seconds later: 499.75 USDC in their app account. The 0.25 USDC went to the solver. Total: 1 step, 30 seconds. The bridge is invisible. Why this is permissionless Solvers make money on the spread between what the user pays on the source chain and what the user receives on the destination. Typical 0.05% on stablecoins, 0.1% on volatile assets. Multiplied across hundreds of millions of dollars per quarter, that's a real business, across the Across solver network, top solvers earn ~$1-5M/year per operator. For AERE, this means: solvers compete to serve AERE. We don't recruit them, and we don't operate any solver infrastructure ourselves. Once AERE is added to the Across Protocol registry, the existing 30+ solver networks running on Ethereum/Arbitrum/Polygon/Base/Optimism/Linea/Scroll/Mantle/etc. start filling AERE intents automatically. A consumer app also benefits: it doesn't have to build a bridge, doesn't have to manage liquidity on multiple chains, doesn't have to seed solvers. It just calls AereERC7683.open(...) with the user's signed intent. The full Tier 1.1 → 1.5 user flow With all five tiers shipped today, a consumer-app user's complete onboarding is: Tier 1.2 (Fusaka): User signs up with Face ID. The Apple Secure Enclave produces a P-256 signature. AERE verifies it via the RIP-7951 precompile. Tier 1.1 (Pectra): The app's smart wallet uses EIP-7702 to give the user's EOA smart-account capabilities, batched txs, social recovery, session keys. Tier 1.3 (Paymasters): The user's first 3 transactions are sponsored by AereOnboardingPaymaster. After that, they pay gas in USDC via AereTokenPaymaster, or stake AERE for a daily free-tx quota via AereStakeQuotaPaymaster. Tier 1.4 (AereMessenger): Cross-chain settlement messages travel between chains via Hyperlane-compatible ECDSA-multisig signatures. Tier 1.5 (Intents): The user signs one intent, "I want 500 USDC on AERE", and an Across solver delivers it in ~30 seconds. Five tiers, one day, end-to-end Revolut-grade UX on a non-custodial EVM L1. What's still pending for full operational rollout Across Protocol registry PR. Open a PR to across-protocol/contracts registering AERE chain 2800 with the SpokePool address. Typical merge + solver onboarding: 2-4 weeks. Hyperlane registry PR (from Tier 1.4), settlement messages from destination SpokePools come through AereMessenger; that needs us listed in Hyperlane's public chain registry. Same 1-3 day BD timeline. Foundation enrolls remote SpokePool addresses via enrollRemoteSpokePool(chainId, bytes32(spokePool)) once the canonical SpokePool addresses on Ethereum / Polygon / Arbitrum / BSC are determined. A consumer app's deposit UI wired against AereERC7683, the app team's task, on the app's schedule. The on-chain layer is done. The off-chain coordination is the remaining work. What's next The cross-chain stack is now complete. Tier 1.6+ shifts to upgrades that strengthen what already exists, Pyth Network oracle integration (real-time prices for every dApp), drand verifiable randomness, sub-second block tuning, batch-auction settlement on AereSwap, dual burn (wiring AereFeeBurnVault into the gas flow). The chain layer is invisible. The work continues at the application layer. ← Back to all posts --- # AERE wallets via Touch ID / Face ID, passkey accounts live, AERE Blog URL: https://aere.network/blog-passkey.html Fetched: 2026-09-15 AERE wallets via Touch ID / Face ID, passkey accounts live, AERE Blog Engineering · Wallets AERE wallets via Touch ID / Face ID, passkey accounts live By AERE Network June 1, 2026 5 min read Today AERE Network deployed AerePasskeyAccount + AerePasskeyAccountFactory on chain 2800. Anyone with a modern device (iPhone, iPad, Android, Mac, Windows 10/11, YubiKey, EU Digital Identity Wallet) can now create an AERE wallet by tapping their fingerprint or showing their face. No seed phrase. No app install. No browser extension. Why this matters: 100% of the friction in crypto onboarding is wallet UX. Seed phrases, MetaMask installs, signature popups that look like phishing, all gone. Your passkey is what your bank already trusts for login on iPhone. Now it's also your AERE wallet. What's deployed Component Address on chain 2800 AerePasskeyAccountFactory 0xfB0eF980667A79Fe1AB69c5f2d512118F1B30739 Account init code hash (for CREATE2) 0x027ece49…5506 secp256r1 precompile (Fusaka RIP-7951) 0x0000000000000000000000000000000000000100 Cryptographic flow, verified end-to-end User taps Touch ID / Face ID. The OS's secure enclave generates a P-256 (secp256r1) keypair. Private key never leaves the device; public key is exported. JavaScript on wallet.aere.network computes the user's AERE address via CREATE2, fully deterministic from the passkey public key. The address exists before the on-chain contract is even deployed. To transact, the page constructs a 32-byte challenge, keccak256(account, chainid, nonce, target, value, data) , and asks the OS to sign it with the passkey. The OS produces a real WebAuthn assertion: authenticatorData + clientDataJSON (containing the challenge as base64url) + ECDSA signature. The assertion is submitted to AerePasskeyAccount.execute() , which calls the on-chain WebAuthn library, computes the message hash sha256(authenticatorData || sha256(clientDataJSON)) , and verifies the signature via the RIP-7951 precompile at 0x100 . On valid signature, the account executes the inner call, sending AERE, calling another contract, anything. First end-to-end test transaction on chain 2800: 0x3045dd33…d4426 at block 2,157,502. Gas used: 141,246, covering WebAuthn signature parsing, JSON challenge extraction, precompile verification (~6,900 gas for the secp256r1 verify itself), and the inner call. Phase 1 limitations (honest) Relayer not yet live. Currently the user needs an external AERE-funded address to submit the first deployment transaction (createAccount) and any subsequent execute calls. Foundation-funded relayer coming next, when complete, the entire flow will be gasless (paid by AereOnboardingPaymaster from Tier 1.3). No social recovery yet. Your passkey is your only signer. Loss-of-device recovery currently depends on your iCloud / Google / Microsoft account backup syncing the passkey to a new device. Multi-key accounts (passkey + YubiKey, passkey + email-recovery) are Tier 1.19 work. No batch transactions yet in the demo UX. The contract supports executeBatch for atomic multi-call, but the demo page only shows single-call. What you can build Neobank onboarding , tap Face ID, you have an AERE wallet, your euro IBAN is provisioned via BaaS partner, ready to swipe within 30 seconds of opening the app NFT mint flows , no MetaMask, no seed phrase, mint by tapping One-tap signature requests , any dApp can prompt the user's passkey for explicit consent without an extension Account abstraction for everyone , gas sponsorship, session keys, batched txs work out of the box What we explicitly did NOT do We did not ship a "passkey wallet" with a stub verifier returning true for all signatures. We did not invent custom WebAuthn parsing, we adopted Coinbase Smart Wallet's audited approach. We did not assume the precompile worked, we proved it by submitting the canonical Wycheproof test vector and confirming 0x...01 return. → Try wallet.aere.network ← Back to all posts --- # AERE goes gasless, multi-paymaster stack live, AERE Blog URL: https://aere.network/blog-paymasters.html Fetched: 2026-09-15 AERE goes gasless, multi-paymaster stack live, AERE Blog Engineering AERE goes gasless, multi-paymaster stack live By AERE Network May 31, 2026 6 min read On May 31, 2026 , the same day AERE activated the Pectra and Fusaka EVM rulesets, we deployed a five-contract paymaster stack on chain 2800. Together they unlock the modern wallet UX every consumer chain in 2026 needs: users transact on AERE without ever needing to hold AERE. What this changes for users: a new wallet on AERE no longer needs to first acquire AERE to do anything. Users can pay gas in any whitelisted stablecoin, get a daily free-transaction quota by staking AERE (an EVM first), or get sponsored by the dApp they're using. The "you must own AERE to use AERE" onboarding wall is gone. The five contracts Contract Address What it does AereEntryPoint 0x19773ba45287A64B05d0BCBD59D1371BF51Bd5D2 ERC-4337-style v0.7 EntryPoint adapted for AERE. The central hub all smart-account wallets and paymasters connect through. Holds paymaster gas deposits, dispatches validate / postOp hooks, manages staking-for-anti-DoS. AereOnboardingPaymaster 0x4058E406475Dbed7056Aee0c808f293F05fEa879 Foundation-funded, hard-capped. Sponsors the first 3 transactions of each first-time sender (lifetime, never resets). Sitewide daily cap of 100 sponsored UserOps to prevent Sybil draining. Foundation pre-fund is a one-time seed; cannot refill without governance. AereTokenPaymaster 0x217f56a5b0C7f35abe4D2fff924A6c13B85d7243 Users pay AERE gas with any whitelisted ERC-20, USDT, USDC, or any token Foundation enables. Reads token price from AereOracle, computes AERE-equivalent cost, charges the user a small markup (default 5%). Self-funding , the markup keeps the contract solvent without subsidy. AereStakeQuotaPaymaster 0xE50464ca7E8E7F542D1816B3172a2330cFE384E8 Stake-for-free-transactions, on EVM. Users who stake AERE (in AereLockedStaking, or by holding sAERE) earn a daily quota of free transactions, proportional to their stake. Default: 20 free UserOps per day per 1,000 AERE staked. Quota resets per UTC day. Funded by a 5% routing of the validator coinbase fee remainder (via AereCoinbaseSplitter), self-sustaining from the chain's own economics. Users keep their AERE staked, still earning their normal staking yield on top. AereAppPaymasterFactory 0xEC22603E8712cBc5c31E53370D10f1a80CcB4DF0 Permissionless factory. Any dApp calls createPaymaster() and gets its own AereAppPaymaster contract, funded from the dApp's own treasury, sponsoring only its own users on its own whitelisted contracts. Each dApp's customer-acquisition cost stays in that dApp's books. Why this matters Until today, the AERE onboarding flow had a hard wall: a user with no AERE could do nothing on AERE. Even claiming a faucet drop required an existing wallet with gas. Even calling a registration contract on a consumer app required gas. Chicken-and-egg. The paymaster stack removes that wall four different ways, with four different funding models. Each path stays self-sufficient or is capped: OnboardingPaymaster is the only Foundation-funded path, and it's hard-capped at ~50,000 AERE total pre-fund, with no automatic refill. The cap is what it can ever hold, not what it holds: the paymaster is not funded yet and its EntryPoint deposit is zero, so no transaction is sponsored today. TokenPaymaster earns 5% on each token-to-AERE conversion. The markup keeps the contract perpetually solvent, accumulating token reserves the Foundation periodically swaps to AERE via AereSwap. StakeQuotaPaymaster is funded by routing 5% of the validator coinbase fee remainder (via AereCoinbaseSplitter) into the contract. Validators voluntarily opt in via a config flag. Self-sustaining from the chain's own economics. AppPaymaster instances are funded by each dApp from their own treasury. A consumer app's paymaster is funded from that app's own budget. The stake-for-gas model, and why it matters for consumer apps The single biggest driver of stablecoin adoption has been the model where users who stake the native asset get a daily quota of transactions that covers normal usage. They never pay gas. The crypto is just money, the chain is invisible. This is the account-abstraction stack we shipped; we have not surveyed every other chain, so we make no claim about who was first. For a consumer app, this is structural. A user staking 5,000 AERE (a reasonable position for an active user) gets ~100 free transactions per day, payments, transfers, swaps, all gasless, once a paymaster is funded. None of the five paymasters holds a balance today, so this path pays for nothing yet. Their stake still earns its normal staking yield (via AereLockedStaking or sAERE). How developers integrate Each paymaster follows the standard ERC-4337 v0.7 interface. To sponsor a UserOperation with one of them, set the paymasterAndData field of the UserOp to the paymaster's address (plus any paymaster-specific data, such as token address for TokenPaymaster). Bundlers (Pimlico, Biconomy, ZeroDev) that already support ERC-4337 will work on AERE once they add chain 2800 to their supported-chain registry. We've opened the relevant onboarding requests with each. For a dApp wanting to sponsor its own users, the integration is one transaction: // One call to spin up an app-controlled paymaster const factory = new Contract("0xEC22603E8712cBc5c31E53370D10f1a80CcB4DF0", FACTORY_ABI, signer); const tx = await factory.createPaymaster(); await tx.wait(); // You're now the owner of a fresh AereAppPaymaster. // Configure target whitelist + sender allowlist + fund it from treasury. What's still pending for full Tier 1.3 completion The chain layer is done. Three follow-ups remain before users see the gasless UX in their wallets: Foundation pre-funds the OnboardingPaymaster and StakeQuotaPaymaster seed balances (one-time AERE transfer to the EntryPoint). Foundation calls setToken() on the TokenPaymaster for the initial whitelisted ERC-20s (the canonical USDT/USDC bridged onto AERE, once those land via Hyperlane in Tier 1.4). Pimlico/Biconomy/ZeroDev finish chain-2800 onboarding, usually 1-2 weeks. Any consumer app can deploy its own AppPaymaster against the factory whenever its team is ready. That's on the app's schedule, not the chain's. What's next Tier 1.4, Hyperlane cross-chain messaging . Replaces our current 1-of-1 federated bridge with the standard permissionless cross-chain protocol used by 200+ chains. Users on Ethereum, BSC, Polygon, Arbitrum, Solana, and elsewhere will be able to bring assets to AERE in ~30 seconds, then immediately use them gaslessly via the paymaster stack we just shipped. The chain layer becomes invisible. The app layer is where the work continues. ← Back to all posts --- # AERE upgrades to Pectra, EIP-7702 + BLS precompiles now live, AERE Blog URL: https://aere.network/blog-pectra.html Fetched: 2026-09-15 AERE upgrades to Pectra, EIP-7702 + BLS precompiles now live, AERE Blog Engineering AERE upgrades to Pectra, EIP-7702 + BLS precompiles now live By AERE Network May 31, 2026 5 min read On May 31, 2026 at 00:57:31 UTC , AERE Network activated the Pectra EVM ruleset at block 2,075,341 . The chain produced its post-fork block on schedule with no downtime, no rollback, and no halt. Three of three validators participated cleanly through a rolling restart performed an hour beforehand. Updated since first publication: the validator set was 3 at the time of this upgrade. Measured on 2026-08-01 against chain 2800 it was 7, all Foundation-operated (f=2, quorum 5 of 7), and since 2026-08-09 it is 9 (f=2, quorum 6 of 9); and, re-checked on 2026-08-10, the average block interval over the last 2,000 blocks measured 0.557 s (it read 0.517 s when the post was written; the chain slowed and the figure was retaken). The account below is preserved as the historical record of the May 31, 2026 upgrade. Pectra is the EVM ruleset adopted by Ethereum mainnet on May 7, 2025. AERE has now reached functional parity with the current Ethereum mainnet EVM specification . Any Solidity or Vyper contract written for Ethereum post-Pectra runs identically on AERE chain 2800. What changed for users: nothing visible, no wallet update, no contract migration, no action required. The upgrade unlocks new capabilities for developers and dApps that choose to use them. Existing wallets and contracts continue to work unchanged. What Pectra brings to AERE EIP What it enables EIP-7702 EOA delegation to smart-contract code. A normal wallet (MetaMask, Trust, Rabby) can temporarily act like a smart wallet, batched transactions, sponsored gas, daily spending limits, session keys, without changing its address. EIP-2537 BLS12-381 curve precompiles at addresses 0x0b , 0x11 . On-chain BLS signature verification becomes ~70× cheaper. Powers trustless cross-chain proofs, light clients, validator aggregate signatures. EIP-2935 Historical block hashes (up to 8,192 blocks back) accessible via a system contract. Enables trustless cross-chain state proofs without external oracle. EIP-1153 TSTORE / TLOAD transient storage opcodes. Gas-efficient reentrancy guards, callbacks, and atomic-execution patterns. EIP-5656 MCOPY opcode for efficient memory copying. Reduces gas costs for many libraries. EIP-6780 SELFDESTRUCT only deletes contracts created in the same transaction. Major security improvement against state-bloat and upgrade-rug attacks. EIP-7516 BLOBBASEFEE opcode (returns 0 on AERE since the chain has no consensus-layer blob market). The upgrade procedure (full transparency) The upgrade was executed as a timestamp-activated hardfork. The procedure: Confirmed Hyperledger Besu version v26.4.0 running on all 3 validators (Pectra-capable). Generated a new genesis.json with cancunTime and pragueTime set to unix timestamp 1780189051 (45 minutes in the future). Backed up the existing genesis as genesis.pre-pectra.bak on every validator. Pushed the new genesis to all 3 validators. Rolling-restarted each validator one at a time, with 5+ minutes between restarts. QBFT quorum (2 of 3) maintained throughout, no halt. Waited for the fork timestamp. The chain transitioned cleanly at the first block produced after 00:57:31 UTC . Verified the new EVM ruleset is active by inspecting block-header fields: post-fork blocks now contain blobGasUsed , excessBlobGas , parentBeaconBlockRoot (Cancun) and requestsHash (Prague). Hyperledger Besu only emits these fields when the corresponding hardforks are active. QBFT-specific notes AERE is a permissioned-validator QBFT chain, it does not have a separate proof-of-stake consensus layer like Ethereum mainnet. Two Pectra EIPs are affected by this: EIP-4788 (parent beacon block root) : the field is present in every block header but is set to 0x00…00 because AERE has no beacon chain. Applications that depend on a real beacon root should not target AERE for that data; everything else is unaffected. EIP-4844 blobs : the related header fields exist ( blobGasUsed , excessBlobGas ) but AERE does not produce or accept blob-bearing transactions. BLOBBASEFEE always returns 0. All other Pectra EIPs are fully functional, including the marquee additions: EIP-7702 (account abstraction), EIP-2537 (BLS precompiles), and EIP-2935 (historical block hashes). What this unlocks for the AERE ecosystem The Pectra ruleset is the foundation for several upcoming AERE features: Wallet UX modernisation : EIP-7702 lets any existing wallet on AERE gain smart-wallet capabilities (batching, gas sponsorship, session keys) without users having to migrate to a new wallet address. Cross-chain integration : cheap BLS verification (EIP-2537) makes it economically practical to verify Hyperlane, LayerZero, or AERE-own validator-set signatures on-chain, the cryptographic backbone for trustless bridging. Verifiable cross-chain state : combined with EIP-2935 historical block hashes, contracts can prove the state of one AERE block from another without an external oracle. The basis for light clients and rollup interop. Cancun opcodes : every library written for Ethereum post-March 2024 can now be deployed without compiler downgrades. How developers should use this Solidity compilers from 0.8.24 onwards support Cancun opcodes. 0.8.25 + recommended. Hardhat, Foundry, and Remix all support targeting Pectra-equivalent chains by setting the EVM version to cancun or prague in their configuration. Examples: Hardhat : in hardhat.config.ts , set solidity.settings.evmVersion = "prague" . Foundry : in foundry.toml , set evm_version = "prague" . ethers.js : no changes required; transaction type 0x04 (EIP-7702 SetCode) is supported in [email protected] + . The AERE SDK has been bumped to v0.4.0 with the Pectra ruleset documented in addresses.ts . The documentation page now includes a full EVM-ruleset section. What's next The Fusaka ruleset, Ethereum's December 2025 hardfork, was activated on chain 2800 alongside Pectra on the same day. It adds the secp256r1 precompile (RIP-7951) , which makes native Face ID, Touch ID, and Windows Hello signature verification economically viable on-chain (~3.5k gas instead of ~250k via Solidity). It is the cryptographic foundation for passkey-based wallet flows, and it is now live. Beyond that, the AERE engineering plan includes the Pyth Network pull-oracle deployment, Hyperlane cross-chain messaging, the Across SpokePool for intent-based bridging, drand-backed verifiable randomness, a batch-auction settlement contract for MEV-resistant swaps on AereSwap, a staked-AERE gas-quota paymaster, and a developer-fee-share programme. Each of these will land as an independent upgrade, no single chain-halting moment is required for any of them. The Pectra activation makes those features possible at modern EVM gas costs. The work continues. ← Back to all posts --- # AERE goes pull-oracle, industry-standard price feeds live, AERE Blog URL: https://aere.network/blog-pyth.html Fetched: 2026-09-15 AERE goes pull-oracle, industry-standard price feeds live, AERE Blog Engineering AERE goes pull-oracle, industry-standard price feeds live By AERE Network May 31, 2026 5 min read On May 31, 2026 AERE Network deployed two contracts that finally upgrade our oracle stack from the bootstrap-grade single-reporter AereOracle to an industry-standard pull-oracle architecture, the AERE Oracle Network . AerePyth implements the standard IPyth pull-oracle interface; AereOracleAdapter gives every dApp on AERE one address and one signature for all price reads. What this changes for developers: code written against any standard IPyth -interface pull-oracle SDK runs unchanged on AERE. IPyth.getPrice(id) works. updatePriceFeeds(updateData) works. As the AERE Oracle Network expands its publisher set, the same AerePyth contract accepts additional signed updates with no migration, applications keep working without redeploy. The two contracts Contract Address What it does AerePyth 0xb7F3354C1E0C5ef89D8b1072a3CEa7FFEf2FfE3F IPyth -interface-compatible pull oracle. Implements getPrice , getPriceUnsafe , getEmaPrice , getPriceNoOlderThan , updatePriceFeeds , getUpdateFee , getValidTimePeriod , every method from the industry-standard pull-oracle interface. Updates are publisher-signed (ECDSA, same scheme as AereMessenger) with configurable threshold N-of-M. Owner-tunable update fee, currently 0. AereOracleAdapter 0xb28A23dc177794DEC2Cacd2738fCc6c5C1Fc4Fe6 Unified quote(symbol) interface that routes AerePyth → legacy AereOracle fallback. Apps register pull-oracle feed IDs per symbol via registerPythFeed(symbol, feedId) . Symbols without pull-oracle coverage continue to read from the existing multi-reporter AereOracle. Returns (price1e8, updatedAt, source) with source = "aerepyth" or "legacy". Why pull-oracle matters The original AereOracle deployed at genesis has three real weaknesses: single reporter, two feeds (BTC/USD + ETH/USD), 90-second updates. AereLending died from these (its $0.10 fallback price was a tell). AereSwap intents from Tier 1.5 need real prices for solvers to bid sensibly. Any future stablecoin partner needs trustless USD pricing. The pull-oracle model fixes all of this. Instead of a few reporters writing prices on a schedule (push), publishers continuously update prices off-chain, and consumers include a recent signed attestation as calldata when they need a fresh price (pull). The on-chain contract verifies threshold signatures and serves the price within the same transaction. Three properties: Always fresh. Mature pull-oracle networks reach sub-400ms. Our bootstrap publisher set is slower than that today, but the architecture scales. Pay only for what you need. A contract that needs second-by-second prices (perps) calls updatePriceFeeds per transaction. A contract that just wants a recent price (AMM quote, balance display) reads the cached price for free. Publisher-signed. No oracle middleware. The data source signs the data directly. How a contract uses it Two ways. Way 1 (standard pull-oracle pattern) , include a recent signed update as calldata: // Recent signed price update fetched from the AERE Oracle Network off-chain mirror. bytes[] memory updateData = new bytes[](1); updateData[0] = priceAttestationCalldata; // 1. Submit update (pay update fee) IPyth oracle = IPyth(0xb7F3354C1E0C5ef89D8b1072a3CEa7FFEf2FfE3F); uint256 fee = oracle.getUpdateFee(updateData); oracle.updatePriceFeeds{value: fee}(updateData); // 2. Read the price PythPrice memory btc = oracle.getPrice(BTC_USD_FEED_ID); // btc.price is signed int64, scaled by btc.expo (negative for fractional) Way 2 (AERE simplified pattern) , read through the adapter for a unified interface: // Most AERE dApps want this, one address, no pull-oracle-specific knowledge. IAereOracleAdapter adapter = IAereOracleAdapter(0xb28A23dc177794DEC2Cacd2738fCc6c5C1Fc4Fe6); (uint256 price1e8, uint256 updatedAt, string memory source) = adapter.quote(keccak256("BTC/USD")); // price1e8 always scaled to 1e8 (e.g. $30,000.12 = 3_000_012_000_000) // source tells you whether it came from AerePyth or legacy AereOracle Migration plan for existing dApps The original AereOracle at 0xf0A13823A4bFa86358Fe30aaf1f44A36AcbCf399 is still deployed and is still the source the adapter reads, but it has since been marked deprecated : it could serve a median controlled by a single fresh reporter. The corrected contract is AereOracleV2 0xca69AA961D836516010Ae669a223Ce249490ACb1 . Measured on 2026-08-01, neither serves a price at the moment, getPrice("BTC/USD") reverts on both, because V1 has one registered reporter and V2 requires three simultaneously fresh. The recommended migration: Point new contracts at AereOracleAdapter , not at AereOracle directly. As Foundation registers pull-oracle feed IDs per symbol, the adapter automatically routes those reads to AerePyth, no app code change. Symbols not yet covered by the AERE Oracle Network (initially AERE/USD) continue to flow through legacy AereOracle. As the AERE Oracle Network adds publishers, Foundation calls setPyth(newPullOracleAddress) and the adapter routes to the expanded network. What's still pending for full AERE Oracle Network operation Foundation expands publisher set. Bootstrap is the existing oracle-reporter address (single publisher, threshold 1). Roadmap: add 2 additional publishers and raise threshold to 2-of-3, then 3-of-5 once partnerships are confirmed. Existing oracle-reporter container is updated to push price updates to AerePyth via updatePriceFeeds() in addition to (or eventually replacing) the legacy AereOracle path. Cross-chain registry onboarding (planned, not yet live). Registering AERE chain 2800 with the broader pull-oracle ecosystem. Once merged, AerePyth verifies the expanded publisher signature set and AERE inherits the full catalog of public feeds. Foundation registers feed IDs in AereOracleAdapter for the major symbols (BTC/USD, ETH/USD, USDC/USD, USDT/USD, EUR/USD, GBP/USD, SOL/USD, BNB/USD, MATIC/USD, ARB/USD, etc.). AERE/USD listing is gated on meaningful CEX liquidity. Currently MEXC only; Bitget/KuCoin/Gate listings (separate workstream) unblock this. What this composes with Tier 1.5 (Across intents): Solvers can now verify quotes against AERE Oracle Network prices before filling, fairer pricing for users. Tier 1.3 (Paymasters): TokenPaymaster pricing now reads from AereOracleAdapter, so users paying gas in USDC see fair-market AERE/USDC rate, not a stale 90-second-old number. Tier 1.4 (AereMessenger): Cross-chain prices are now possible, a dApp on Ethereum can verify AERE-side prices via AERE Oracle Network attestations. Future consumer-app multi-currency UX: EUR/USD/GBP/JPY/AERE balances all displayed in user's chosen currency at fair-market rates. What's next The price-data layer is now real. Tier 1.7 ships drand verifiable randomness , the cryptographic primitive for fair lotteries, NFT trait reveals, randomized airdrops, on-chain games. Tier 1.8 wires AereFeeBurnVault into the validator coinbase , making the whitepaper §3.3 "37.5% of fees obliterated" claim measurably true on chain. Tier 1.9 adds batch-auction settlement to AereSwap for native MEV-resistant trading. AERE's foundational layer is now complete: modern EVM, smart wallets, gasless UX, cross-chain messaging, intent-based bridging, and real-time prices. The work moves up the stack. ← Back to all posts --- # AERE goes verifiably random, drand beacon live, AERE Blog URL: https://aere.network/blog-randomness.html Fetched: 2026-09-15 AERE goes verifiably random, drand beacon live, AERE Blog Engineering AERE goes verifiably random, drand beacon live By AERE Network May 31, 2026 5 min read On May 31, 2026 AERE Network deployed an on-chain consumer of the drand verifiable-randomness beacon, making fair lotteries, NFT trait reveals, fair-launch token sales, on-chain games and randomized airdrops finally possible on AERE without trusting any single party. Deployment: a one-time on-chain step. Ongoing: no relayer, no subscription, no validator coordination. Consumers (lottery contracts, NFT mints, fair launches) submit drand rounds when they need them, paying their own gas. Anyone can submit. Permissionless. The two contracts Contract Address What it does AereRandomnessBeacon 0x25b6317efD8C7d425210F56Ee1E204852CD8213C Permissionless on-chain consumer of the drand Quicknet chain. submitRound(round, signature) accepts a drand round + its BLS signature (fetched free from api.drand.sh) and stores randomness = keccak256(signature) on chain. Once submitted, randomness for that round is permanently readable via getRandomness(round) . Anyone can call submitRound; the submitter pays the gas. AereDrandConsumer 0xeBA8De4f61c923a2E43eA8d7233Cf8e1Db5911B5 Reference integration contract showing the 2-line pattern any dApp can use. Commit to a future drand round at action time, reveal when that round is published. Lottery-style flow; same pattern works for raffles, fair launches, airdrop selection, NFT mints with randomized traits, gaming, validator rotation. What drand actually is drand is the distributed randomness beacon operated by the League of Entropy , a coalition of 19 independent organisations including Cloudflare, EPFL (Swiss Federal Institute of Technology Lausanne), the U.S. Naval Research Laboratory, the University of Chile, Protocol Labs, Kudelski Security, PingCAP, CertiK, and others. Every 3 seconds, all 19 attempt to sign the value round_number using their share of a threshold BLS-12-381 private key. A threshold (currently 12 of 19) is required to produce a valid aggregate signature. Properties of the resulting random number: Bias-resistant: by the time the value is public, the signature is already cryptographically committed, no operator can pick or veto a future value. Verifiable: the BLS aggregate signature can be checked against drand's published public key (Quicknet's 96-byte G2 point is hard-coded in our contract). Unforgeable: forging requires breaking BLS-12-381 cryptography (the same curve Ethereum uses for its consensus layer). Free: drand is a public good. Anyone fetches current and historical rounds at api.drand.sh . Predictable timing: Quicknet has a 3-second period starting at unix 1692803367. Round N is published at 1692803367 + N×3 . The integration pattern Here's the 3-line lottery from the reference consumer: contract MyLottery { AereRandomnessBeacon public immutable beacon = AereRandomnessBeacon(0x25b6317efD8C7d425210F56Ee1E204852CD8213C); uint64 public drawRound; address[] public entrants; function openLottery(uint64 secondsUntilDraw) external { drawRound = beacon.roundAtTime(uint64(block.timestamp + secondsUntilDraw)); } function enter() external { entrants.push(msg.sender); } function draw(bytes calldata drandSignature) external returns (address winner) { // Anyone can fetch drandSignature from api.drand.sh/ /public/ // and call this. Submitter pays gas; everyone benefits from the random outcome. bytes32 random = beacon.submitRound(drawRound, drandSignature); winner = entrants[uint256(random) % entrants.length]; } } That's the entire integration. Three lines of contract code, one off-chain fetch from a free public API. No operator infrastructure, by design This is a permissionless on-chain primitive, not a Foundation-operated service. Three properties mean no operator has to run any infrastructure: No relayer to run. Anyone can call submitRound . The typical caller is the dApp that needs the random number, submitting a round and reading the resulting randomness happens in the same transaction. Submitter pays gas. The drand signature is ~48 bytes; submitting one costs ~20-30k AERE gas (~$0.00002 at chain-level fees). The dApp's user, or the dApp itself, absorbs this, same as paying gas for any other contract call. No subscription, no licensing, no BD. drand is a free public good run by the League of Entropy. AERE deployed a consumer; the LoE doesn't need to know we exist for their beacon to serve our submissions. Two phases Phase 1 (now, live): drand signatures are stored on submission and verifiable off-chain. Anyone in the world can confirm, by checking api.drand.sh/ /public/ , that the on-chain signature matches drand's canonical output for that round. If someone tries to submit a fake signature, the pairing check at drand's verification endpoint will reject it; the on-chain submission is then provably wrong. The trust model is "first credible submitter wins, public audit at all times." Phase 2 (post-audit, future deploy): enable on-chain BLS pairing verification via AERE's EIP-2537 precompiles (activated in Pectra, Tier 1.1). The contract will then refuse to accept any submission whose BLS signature doesn't verify against drand's public key on chain, fully trustless. The submission interface is forward-compatible; consumer code doesn't change. What this combines with Tier 1.1 Pectra , EIP-2537 BLS precompiles make on-chain BLS verification ~50× cheaper than Solidity-based verification. This is what enables Phase 2 above to be economically viable. Tier 1.3 Paymasters , lottery, NFT mint, fair launch contracts can sponsor users' submission gas via AppPaymaster, so end users see no gas at all. Tier 1.5 Across intents , cross-chain lotteries become possible: buy ticket on Ethereum, drawn on AERE using drand, winner gets paid on the chain of their choice. Tier 1.6 Pyth , prize denominated in USD via Pyth + draw via drand = the full UX of a fair on-chain lottery. What this does NOT do Doesn't replace VRF for sub-second randomness. drand emits one round per 3 seconds; for higher-frequency randomness (some HFT use cases) you still want commit-reveal or a specialised VRF. Doesn't provide chain-specific oracle data. drand gives you a public random number; for "price of BTC at noon" use Pyth (Tier 1.6). Doesn't pay subsidised gas. The Foundation deploys the contract and walks away. What's next Tier 1.8 wires AereFeeBurnVault into the validator coinbase , making the whitepaper §3.3 "37.5% of fees obliterated" claim measurably true on chain. Tier 1.9 deploys batch-auction settlement on AereSwap for native MEV-resistant trading. Tier 1.10 ships Fee Monetization for developer revenue share, strong builder magnet. The application layer is where the work continues. ← Back to all posts --- # AERE goes sub-second, 0.5s block time live, AERE Blog URL: https://aere.network/blog-subsecond.html Fetched: 2026-09-15 AERE goes sub-second, 0.5s block time live, AERE Blog Engineering AERE goes sub-second, 0.5s block time live By AERE Network May 31, 2026 4 min read On May 31, 2026 at block 2,137,652 , AERE Network's QBFT consensus block period transitioned from 1 second to 0.5 seconds (500 milliseconds) . Same Besu binary, same EVM ruleset, same validator set, same chain ID. Zero downtime. Every transaction on AERE now finalises in half the time it did this morning. Note (current state): the validator set has since expanded to 9 Foundation-operated nodes (f=2, quorum 6-of-9); the three-validator details in this post are historical to its May 31 2026 date. The block interval measured on 2026-08-02 over the 2,000 blocks to head 11,819,559 is 0.5175 s. What this changes for users: a consumer-app payment, an AereSwap quote, an NFT mint, a paymaster-sponsored transaction, all confirm in ~500ms instead of ~1s. The chain feels "instant" instead of "fast." For cross-chain UX (Hyperlane, Across), end-to-end latency is dominated by off-chain validators/solvers and doesn't change. Where AERE sits now Block time Chain 12 seconds Ethereum mainnet 2 seconds Polygon, Avalanche C-chain, Base 1 second Arbitrum One (pre-Nitro 250ms config) 0.75 s BSC Maxwell (Jun 2025) 0.5 s AERE Network 0.45 s BSC Fermi (Jan 2026) 0.4 s Sei v2, Monad 0.25 s Arbitrum Nitro ~10 ms MegaETH mini-blocks (centralised sequencer) AERE now sits in the top tier of EVM-compatible production chains for finality speed, and is the fastest production Besu QBFT chain we're aware of. How the transition worked Hyperledger Besu's QBFT supports block-period transitions in genesis.json, a list of {block, newParams} tuples that change consensus parameters at predetermined future block heights. The transition is deterministic and atomic at the block level: all validators agree, the new period takes effect at the target block. Procedure: Patched genesis.json on all 3 validators with a transitions array under config.transitions.qbft : {"block": 2137652, "xblockperiodmilliseconds": 500} Pinned the Besu image to hyperledger/besu:26.4.0 and added JVM tuning ( -XX:+UseG1GC -XX:MaxGCPauseMillis=100 ) so GC pauses can't trigger round changes at the new tighter cadence Force-recreated all 3 validator containers, rolling, with QBFT 2-of-3 quorum maintained throughout At block 2,137,652, all validators applied the new period in lockstep. From the next block onward, block times moved to 500ms. What stays the same Per-block gas limit. Unchanged. The sum of gas per second doubles, but the per-block cap is the same. EVM ruleset. Pectra + Fusaka stay active. Smart contracts behave identically. Security model. QBFT 3-validator BFT tolerance unchanged. Same architecture. Hardware requirements. No new spec demands. Same hardware, same containers. What's next The Tier-1 stack is complete: modern EVM (Pectra+Fusaka), smart wallets, gasless paymaster suite, Hyperlane + Across cross-chain, Pyth oracle, drand randomness, 37.5% validator-coinbase burn (live and sealed; validator coinbase revenue is currently zero, so Aere is not deflationary today), MEV-resistant batch DEX, developer fee monetization, and now sub-second finality. The work continues at the application layer: consumer-app launches, MiCA EMT partnership, ecosystem dApp adoption. ← Back to all posts --- # The 2.8 Billion AERE Supply, Explained, AERE Blog URL: https://aere.network/blog-tokenomics.html Fetched: 2026-09-15 The 2.8 Billion AERE Supply, Explained, AERE Blog Education The 2.8 Billion AERE Supply, Explained By AERE Network April 29, 2026 5 min read Every token system makes a set of supply decisions at launch, and those decisions have long-term consequences for everyone who holds, stakes, or builds with the token. This article documents AERE's supply structure honestly: the hard cap, the six allocation wallets, what each one is for, and how staking rewards fit within the cap rather than expanding it. The Hard Cap: 2,800,000,000 AERE The total supply of AERE is fixed at 2,800,000,000, two billion eight hundred million, set in the genesis block and enforced at the protocol level. The AERE token contract has no mint function accessible after genesis. There is no central authority that can create additional tokens, and no governance proposal can change this without a hard fork of the chain itself. The 2.8 billion figure is what the whitepaper specifies. When the initial genesis configuration was found to diverge from this number, the chain was relaunched (Genesis v2, May 7 2026) to correct it before any public activity. The chain running today has exactly 2,800,000,000 AERE in existence. The Six Allocation Wallets The entire 2.8 billion supply is distributed across six named wallets at genesis, each serving a distinct purpose: Wallet Amount Share Purpose Staking Reserve 1,400,000,000 50% Staking rewards, validator incentives, long-term ecosystem mining program Ecosystem Fund 560,000,000 20% Grants, liquidity incentives, partnerships, exchange listings Team 420,000,000 15% Core team compensation, subject to vesting schedule Foundation 180,000,000 6.43% Operational costs, legal, infrastructure, governance reserve Airdrop 140,000,000 5% Community distribution, early adopter rewards, testnet participants Strategic Investor 100,000,000 3.57% Early capital raise, strategic partnership allocations Why 50% in the Staking Reserve? The largest single allocation, half the total supply, sits in the Staking Reserve. This pre-allocated pool (there is no mining and no new minting) is the source for every staking reward paid out over the life of the network. Instead of minting new tokens as staking rewards (which would dilute existing holders), AERE distributes from a pre-allocated pool. This means: The hard cap of 2.8 billion is a genuine ceiling, not a floor that inflation erodes over time. Staking rewards are predictable. The rate at which the Staking Reserve depletes can be modeled precisely based on total staked supply and configured APY tiers. The long-term supply schedule is set at genesis and does not require ongoing governance decisions to manage inflation. At the base staking APY of 8%, the Staking Reserve sustains rewards for a substantial number of years depending on total staked participation. Higher participation rates draw down the reserve faster; lower participation rates extend it. The Ecosystem Fund The second-largest allocation, at 560 million AERE (20%), funds the activities that grow the network: the developer grants program , liquidity incentives for the native AMM, potential exchange listings, and formal partnerships. This wallet is controlled by the Foundation with planned transition to DAO governance. Team and Foundation Allocations The Team allocation (420 million, 15%) is subject to a vesting schedule to align long-term incentives. Core contributors cannot dump their entire allocation at once. The Foundation allocation (180 million, 6.43%) covers operating costs: server infrastructure, legal fees, audits, and the governance reserve needed to respond to unforeseen protocol events. Transparency note: All six wallets are visible on the block explorer at explorer.aere.network . The genesis block and all subsequent transactions are public. Anyone can verify that the circulating supply matches the whitepaper at any point in time. Circulating Supply vs. Total Supply At genesis, 2.8 billion AERE exists. The "circulating supply", tokens actually in use by the market, is a subset of that. Tokens sitting in the Staking Reserve are not in circulation until they are paid out as staking rewards. Team tokens subject to vesting are not in circulation until vested. Airdrop tokens are not in circulation until claimed. Total supply and circulating supply converge over time as rewards are paid out and vesting schedules complete. The hard cap ensures they never exceed 2.8 billion in sum. Staking to Earn from the Reserve Any AERE holder can earn from the Staking Reserve by staking through the staking interface . The base APY is 8%, with higher rates for longer lock commitments. For a full explanation of how delegated staking works, see How AERE Validators Work . ← Back to Blog --- # Universal Login, multi-key wallets, recovery, gasless onboarding, AERE Blog URL: https://aere.network/blog-universal-login.html Fetched: 2026-09-15 Universal Login, multi-key wallets, recovery, gasless onboarding, AERE Blog Engineering · Universal Login Universal Login on AERE, multi-key wallets, recovery, gasless onboarding By AERE Network June 1, 2026 6 min read Tier 1.15 shipped passkey wallets, tap your fingerprint, get an AERE wallet. The audit that followed flagged two SEV-1 gaps: no recovery (lose your phone + iCloud, lose your funds) and no ERC-4337 compatibility (standard bundlers can't sponsor AERE wallets). Today we closed both. What's new: AerePasskeyAccountV2 with MultiOwnable (multiple keys per account, passkey + EOA + add/remove freely), real ERC-4337 validateUserOp shim, EIP-1271 isValidSignature for DeFi integrations, and a Foundation-funded relayer at aere.network/relay that submits transactions on behalf of users who don't hold AERE yet. Updated since publication: AERE now enforces a 1 Gwei minimum base fee, activated at fork block 10,141,734. References below to a zero gas price or min-gas-price=0 reflect the configuration at the June 2026 post date; transaction fees remain essentially free. What's deployed Corrected 2026-08-02. The factory this post originally listed, 0x5FFa9a64… , has since been superseded. An internal review found an authorisation defect in the accounts it deploys, and a corrected factory was published in July 2026 at 0x8FA2B45D63EBaa4551A55d7f33a82d597e423428 (9,675 bytes of live code, read from a public node on 2026-08-02 at block 11,819,497). The superseded factory is still on chain and is left there deliberately, so that anything already deployed keeps working, but no new wallet should be created through it. Existing accounts have not been re-pointed; that swap is a supervised operation and has not been carried out. Both rows are shown below rather than the old one being quietly swapped out, because the address in this post is what an integrator would have copied. Component Address on chain 2800 AereEntryPointV2 0x8D6f40598d552fF0Cb358b6012cF4227B86aF770 AerePasskeyAccountFactoryV2 (superseded, do not use for new wallets) 0x5FFa9a6487DA4641a1A1e7900ff2bD4525D34fdA AerePasskeyAccountFactoryV2Fixed (canonical, use this one) 0x8FA2B45D63EBaa4551A55d7f33a82d597e423428 Account init code hash 0x59b39b48…1dc1 Foundation relayer (HTTP endpoint) https://aere.network/relay/ Relayer EOA 0x0c8e643510Ee21f72de501FE27F8882C517cdA38 End-to-end test transcript Every code path was verified on chain 2800. Account 0x2e0757962e72C3e25f7f287907fC9687CE9D956b : Test Tx hash Gas Deploy multi-owner account (1 passkey + 1 EOA) 0xae18…293a 1,991,894 Execute via passkey (owner idx 0) 0xae18…293a 130,816 Execute via EOA (owner idx 1) 0x2322…ea69 53,592 EIP-1271 isValidSignature → 0x1626ba7e view call free Recovery: passkey adds second passkey via self-call 0xc349…ac2a N/A Execute via newly-added passkey (owner idx 2) 0xf2d8…8b88 113,716 How recovery works Every owner-management op ( addOwnerPublicKey , addOwnerAddress , removeOwnerAtIndex ) is gated by onlyOwner which requires msg.sender == address(this) . To add an owner, you call account.executeWithPasskey(sig, address(this), 0, addOwnerCalldata) , your existing signer authorizes a self-call that adds a new key. Result: if you have a YubiKey paired with your Touch ID, lose both, but kept an old MetaMask EOA as a third owner, you sign with that EOA and add a fresh passkey from your new phone. Funds preserved. Why the relayer matters New users don't have AERE. Without a relayer, they can't deploy their own wallet or send their first transaction. With the Foundation-funded relayer at https://aere.network/relay/ : User taps Face ID → browser creates passkey, computes counterfactual address Browser POSTs (initialOwners, salt) to /relay/createAccount Relayer EOA submits factory.createAccount(...) + pays gas (~2M gas, ~0 AERE because min-gas-price=0 ) Account is live on chain, ready to receive funds User signs a transaction with their passkey, browser POSTs to /relay/execute Relayer submits, transaction lands The relayer NEVER sees the user's private key. The smart account validates every signature itself, the relayer is just a gas-payer. Compromising the relayer doesn't compromise any user funds; it just halts gasless submission until a new relayer is stood up. Phase 1 honest limits Single relayer EOA , no HA. If the relayer goes down, users with their own AERE can still sign + submit directly. New onboarding stalls until it's back. No rate-limiting , anyone can spam the relayer. Phase 2: Pimlico-style 10 RPS/IP, 100 ops/wallet/day, HMAC-nonced API requests with 60s replay window. Relayer balance: 2 AERE , that funds thousands of transactions at AERE's zero gas price, but the EOA needs periodic top-ups from Foundation. Phase 2 wires AereOnboardingPaymaster so the paymaster's deposit at the EntryPoint covers gas instead of the relayer EOA. No external bundler support yet , Pimlico/Stackup/ZeroDev can target our V2 EntryPoint if they configure chain 2800; outreach is Phase 2. What's next Tier 1.17, bring external users in. Cross-chain swap UI at bridge.aere.network : swap USDT on Ethereum to AERE on chain 2800 in one click, fund a passkey wallet you created via Touch ID, send your first AERE transaction without any prior interaction with the AERE ecosystem. The pieces are all live; the UX wrapper is the work. → Try wallet.aere.network ← Back to all posts --- # How AERE Validators Work, AERE Blog URL: https://aere.network/blog-validators.html Fetched: 2026-09-15 How AERE Validators Work, AERE Blog Education How AERE Validators Work By AERE Network April 24, 2026 5 min read AERE Network achieves sub-second block times with immediate finality using QBFT consensus, a deterministic, committee-based algorithm that doesn't depend on proof-of-work or on a lottery of stakers competing to propose the next block. This article explains how QBFT validators operate, how a validator is admitted by a governance vote (no staking, no bonding), and how block fees flow to whoever proposes each block. QBFT: The Consensus Algorithm QBFT stands for Quorum Byzantine Fault Tolerant. It is a variant of the PBFT (Practical Byzantine Fault Tolerance) family of consensus protocols, adapted for Hyperledger Besu. In QBFT, a fixed set of validators takes turns proposing blocks in a round-robin rotation. When a validator proposes a block, the other validators vote on it. Once two-thirds plus one of the validators have signed the block, it is final, no reorganizations, no probabilistic waiting. This design has two important properties for a production network: Deterministic finality. A transaction that lands in a block is immediately settled. There is no concept of "waiting for N confirmations" because no alternative fork can ever displace a block that has been voted on by a super-majority. Predictable block times. Because validators rotate in a known schedule and vote in a single round, block production is consistent at 0.5 seconds under normal conditions. A validator that goes offline causes its round to time out (a few seconds), and the rotation continues with the next proposer. The Validator Set The active validator set is maintained by Besu's QBFT protocol itself and can be read at any time with the qbft_getValidatorsByBlockNumber RPC method. Validators are admitted through governance, they are not anonymous nodes competing with compute power, and there is no stake, bond, or deposit that turns an address into a validator. There are 10 Foundation validators today (f=3, quorum 7-of-10), with a public path to 21. Admission is a vote of the existing set: each current validator calls qbft_proposeValidatorVote with the candidate's address and true , coordinated by the Foundation. Once a majority has proposed the candidate, QBFT adds it at the next epoch. The same mechanism removes a validator: a majority proposing an address with false drops it from the set. Validators earn the per-block fee remainder : after each block's coinbase split is routed by the AereCoinbaseSplitter ( 0xb4b0eCe9011613A5b84248a9B42a0f309E6F01Ec ) and AereCoinbaseSplitterV2 ( 0x8C1A48eFA57b66fEE743A00E3899c29ad3Fd27b4 ), the remaining fees go to the block's proposer. Their reward is therefore proportional to participation: a validator that misses rounds proposes fewer blocks and earns less than one that participates in every block. To run one, see aere.network/run-a-validator . Accountability: No Slashing, Just Removal Because no stake is ever posted, AERE has no slashing . Nothing is burned, there is no equivocation penalty, and there is no unbonding period. A validator that misbehaves or stays offline is instead removed by the same governance mechanism that admitted it: the remaining validators call qbft_proposeValidatorVote with the offender's address and false , and once a majority agrees the address is dropped from the active set at the next epoch. Accountability is operational and social, backed by the power to remove, not financial. This keeps the model simple and honest: there is no on-chain slashing contract to trust, no self-stake or delegated stake at risk, and no complex reward accounting. A validator's incentive to stay online is direct, an offline node proposes no blocks and earns no fee remainder, and a persistently faulty one loses its seat. Staking Is Separate From Validation Running a validator does not involve staking, and staking does not make you a validator. Staking on AERE is a distinct product for any holder who wants yield without operating infrastructure. It has nothing to do with the validator set or block production. There are two real staking paths: Product What it is Yield sAERE (ERC-4626) 0xA2125bE9C6fd4196D9F94757Df18B3a2A5e650b0 A liquid staking receipt. Deposit AERE, receive sAERE. Variable staker-yield from the AereSink 15/40/45 split ( 0x69581B86A48161b067Ff4E01544780625B231676 ) AereLockedStaking 0x21108c28A849b05aE6b7a3a5bc435C9Bc897E7Ad Fixed-term locks for a set APY. Reward reserve is unfunded, so no yield can be paid today. 30d/10%, 90d/15%, 180d/22%, 365d/30% APY (on-chain rates, not payable while the reserve is empty) Neither product grants validation rights, block-proposal duties, or any control over the validator set. They are simply ways for holders to put idle AERE to work. Validator vs. Staker: A Comparison Validator Staker Infrastructure required Yes (Besu node, 24/7 uptime) No How you join Admitted by governance vote of the existing validator set ( qbft_proposeValidatorVote true) Deposit AERE into sAERE or AereLockedStaking Stake required to join None (no bond, no deposit) Any AERE amount you wish to stake Reward source Per-block fee remainder via the coinbase splitter AereSink yield (sAERE) or fixed APY (locked staking) Slashing None; accountability is governance removal (vote false) None Getting Started To run a validator , follow the onboarding guide at aere.network/run-a-validator . You will stand up a synced Besu node and submit your validator address to the Foundation, which coordinates the admission vote of the current set. No AERE is staked or deposited. To stake for yield as a holder, the staking interface is available at /stake.html . You'll need MetaMask connected to AERE Network (chain ID 2800) and AERE in your wallet. Choose sAERE for a liquid, variable-yield receipt or AereLockedStaking for a fixed-term rate, approve the token allowance, and stake. Staking is not delegation to a validator. Your staked AERE does not back any validator and does not affect who is in the validator set. Validator seats are decided by governance vote, not by stake weight. For developers building on top of the staking contracts, the full ABI and documentation are available at /docs.html . ← Back to Blog --- # What is AERE Network?, AERE Blog URL: https://aere.network/blog-what-is-aere.html Fetched: 2026-09-15 What is AERE Network?, AERE Blog Education What is AERE Network? By AERE Network April 8, 2026 5 min read AERE Network is an EVM-compatible Layer 1 blockchain built for the real economy. It runs on chain ID 2800, uses Hyperledger Besu's QBFT consensus engine to produce a new block roughly every half-second, and is fully compatible with the Ethereum toolchain. If you can build on Ethereum, you can build on AERE, usually with nothing more than a chain-ID change. This article introduces the core concepts: what the chain is, how it works, what the native token does, and why it exists as a standalone Layer 1 rather than an Ethereum sidechain or rollup. EVM Compatibility The Ethereum Virtual Machine is the execution environment that Ethereum smart contracts run in. Thousands of tools, MetaMask, Remix, Hardhat, Foundry, ethers.js, viem, OpenZeppelin, are built around it. An EVM-compatible chain can run every Solidity or Vyper contract as written, and every one of those tools connects to it without modification. AERE is fully EVM-compatible. It exposes a standard Ethereum JSON-RPC API at https://rpc.aere.network , supports every standard EIP that Ethereum mainnet supports, and uses the same address format, transaction structure, and contract ABI encoding. Developers don't have to learn anything new. QBFT Consensus and Sub-Second Blocks AERE uses the QBFT (Quorum Byzantine Fault Tolerant) consensus algorithm, the same engine used in enterprise Hyperledger Besu deployments. QBFT is a deterministic, committee-based consensus protocol: a rotating block proposer assembles a block, broadcasts it, and other validators vote on it. A block becomes final as soon as a super-majority of validators have signed it, there is no probabilistic finality and no waiting for "enough confirmations." The practical result is 0.5-second block times with immediate transaction finality. When your transaction lands in a block, it is final. This matters for applications that need predictable settlement, payments, trading, on-chain bookkeeping, where waiting 12-15 seconds per Ethereum block, or several minutes on a rollup, is a user-experience problem. Updated since first publication: this post originally described 1-second blocks, which was correct when it was written. The block period was cut to 0.5s mid-chain at block 2,137,652 on May 31 2026. Consensus signing is classical secp256k1 ECDSA, not post-quantum. The Native AERE Token Every transaction on AERE Network pays gas denominated in AERE, the chain's native token. Because block production is efficient and the validator set is permissioned, Foundation-operated (not a proof-of-work lottery), gas costs are negligible for ordinary transactions. Developers can build consumer applications where users never notice gas exists. AERE has a hard cap of 2,800,000,000 tokens, 2.8 billion, specified in the project whitepaper. There is no protocol-level inflation beyond the staking-reward allocation already accounted for in that supply. The token is used for: Transaction gas on the AERE L1 Staking and validator delegation through the AereStaking contract Governance participation via AereGovernanceStaked Liquidity provision and trading on the native AMM ( AereSwapFactory ) Settlement in neobank integrations built on the chain Why a Standalone Layer 1? Ethereum rollups and sidechains inherit security guarantees from Ethereum mainnet, which is valuable, but they also inherit constraints: bridging latency, fee markets driven by Ethereum's own congestion, and governance subject to Ethereum's upgrade cycle. Applications that need predictable sub-second finality, full control over the fee market, and the ability to deploy custom precompiles or consensus-level features cannot get those things on a rollup. AERE operates as an independent L1 for the same reason that enterprises choose dedicated infrastructure over shared hosting: sovereignty. The Foundation controls the validator set governance, the fee schedule, and the upgrade path. That independence is what enables features like 0.5-second finality and negligible gas costs in a way that a shared rollup cannot guarantee. The Deployed Contract Ecosystem AERE ships with a set of production contracts already deployed on chain 2800: AereStaking , delegated staking with configurable APY tiers AereSwapFactory , V2 AMM with 0.3% fee, fully Uniswap-compatible AereBridge , federated lock-and-release bridge to external chains AereIdentity , on-chain DID registry for KYC attestations AereGovernanceStaked , proposal and voting system for AERE holders AereNFT + AereNFTMarketplace , ERC-721 with EIP-2981 royalties AereFaucet , configured for a 0.05 AERE drip to new addresses, but not funded: it holds a zero balance and cannot pay out today The full contract registry with deployed addresses is available at /docs.html . Getting Started You can add AERE to MetaMask and explore the chain in about two minutes. Note that there is currently no public way to obtain AERE: the faucet is deployed but unfunded, so you can read the network but not transact on it yet. One-click network add: /addnetwork.html Faucet: /faucet.html (not funded, cannot pay out today) Block explorer: explorer.aere.network If you're a developer, the developer documentation covers the full JSON-RPC API, SDK, and contract addresses. If you want to deploy a project with financial backing, the grants program is open to applications now. ← Back to Blog --- # AERE verifies zk proofs, SP1 + RISC Zero live, AERE Blog URL: https://aere.network/blog-zkverify.html Fetched: 2026-09-15 AERE verifies zk proofs, SP1 + RISC Zero live, AERE Blog Engineering · zkVerify AERE verifies zk proofs natively, SP1 + RISC Zero live on chain 2800 By AERE Network May 31, 2026 6 min read AERE Network now natively verifies zero-knowledge proofs from the two leading EVM-targeting proving systems: SP1 v6.1.0 (Succinct Labs) and RISC Zero zkVM . The first real proof, a canonical SP1 Groth16 proof of a Fibonacci computation, was verified end-to-end at block 2,151,318 on chain 2800. Why this matters: any application that wants to bring trustless off-chain compute (a complex calculation, a credential check, a state transition) into an EVM smart contract can now do it on AERE, for the same gas cost as Ethereum mainnet, but with 0.5-second blocks. Real Groth16 pairing math runs on the EVM's alt_bn128 precompiles. Same engine class as Polygon zkEVM and zkSync's prover-side, but as a primitive any AERE contract can call. The stack we deployed We followed the canonical pattern Succinct Labs and RISC Zero recommend for production deployments: concrete verifier contracts behind a gateway/router , with downstream apps integrating against the stable gateway address. When a future SP1 v7 or RISC Zero v2 ships, the gateway operator calls addRoute() to register the new verifier, every integrating app keeps working unchanged. Component Address on chain 2800 SP1VerifierGateway (stable) 0x9ca479C8c52C0EbB4599319a36a5a017BCC70628 SP1VerifierGroth16 v6.1.0 0xb5456d48bFdA70635c13b6CBE1Ad0310Dc0171aD SP1VerifierGroth16 v6.0.0 0xa9BD3020bC9a9614F9e2BC1618153c9fB1890ca6 SP1VerifierPlonk v6.1.0 0x24a7a85E6D9A2b120F2730880bE7283dFB14d29B RiscZeroVerifierRouter (stable) 0x3f7015BC3290e63F7EC68ecF769b00aB296a249C RiscZeroGroth16Verifier (DEPRECATED, do not use) 0x95cB30f3bdb3187f39203A9907bf707Aef07a1FD RiscZeroGroth16Verifier (corrected, this is the one the router uses) 0xb6fD00D88Bf8B08d6371d2D98E0e239B89Ab5B9D AereProofRegistry v2 (stable) 0x0A9b09677DbE995ACfC0A28F0033e68F068517Ee Update, 2026-08-01, measured. The first RiscZeroGroth16Verifier in the table was deployed with a non-canonical control root, so it computes the wrong selector and cannot verify a genuine RISC Zero receipt at all. It is deprecated and it is listed here only so that the address is recognisable as the wrong one. The corrected verifier is 0xb6fD00D8…89Ab5B9D , and the route is live: calling getVerifier(0xef6cb709) on the router 0x3f7015BC…296a249C returns exactly that address, and AereProofRegistry.risc0Router() returns that router. So canonical RISC Zero recording is wired, not pending. Honest scale, from the same reading: the registry has programCount() = 1 and proofCount() = 1. The plumbing works end to end and it has been used once. The contracts are the canonical sources from the upstream succinctlabs/sp1-contracts and risc0/risc0-ethereum repositories, compiled with Solidity 0.8.23 and the standard 200-run optimizer. No AERE-specific modifications to the math, the only edits were import-path tweaks to match our OpenZeppelin v4.9 layout, and a constructor adapter to bridge OZ v4's Ownable() to upstream's v5-style Ownable(initialOwner) signature. End-to-end verification, observed live We registered the canonical Fibonacci program (vkey 0x004a55ed…3090 ) on AereProofRegistry and submitted SP1's official v6.0.0 Fibonacci Groth16 fixture proof. The flow: AereProofRegistry.submitSP1Proof() verifies the program is registered + enabled Routes the call to SP1VerifierGateway.verifyProof() Gateway reads the first 4 bytes of the proof (selector 0x0e78f4db ) Routes to the v6.0.0 concrete verifier Real Groth16 pairing math executes on the BN254 precompiles (≈230k gas) Returns success → registry emits ProofVerified event with the program key indexed Transaction: 0x8b5f36c4…1cfef3 in block 2,151,318. Gas used: 562,415 (verification + storage). The verified proof is permanently on-chain; off-chain consumers can subscribe to ProofVerified events filtered by their program of interest and use the attestation as input to their own logic. Live event feed See verified proofs as they land at aere.network/zk-proofs , a live event feed reading ProofVerified directly from the registry on chain 2800. What you can build with this Privacy-preserving credentials: "I proved my credit score is above N without revealing my balance" Verifiable off-chain compute: "I proved this market-making strategy executed at fair price across N venues" Light-client bridges: "I proved Ethereum block N's state root, on AERE" Cross-chain state proofs: "I proved I own asset X on chain Y, redeem here" Compliance attestations: "I proved this transaction passed a regulatory check, without exposing the check's internals" What we explicitly did NOT do We did not deploy a placeholder verifier with stub math. We did not pin a release-candidate version and call it production. We did not build a fee-extracting middleware in front of free verification. Every contract on the list above is the canonical upstream source, deployed as-is, and the first proof verified is a real cryptographic proof from SP1's own test suite that any independent observer can re-run on the exact same data. ← Back to all posts --- # Aere Network, Blog & Newsroom URL: https://aere.network/blog.html Fetched: 2026-09-15 Aere Network, Blog & Newsroom Blog & Newsroom Updates, tutorials, and ecosystem news from Aere Network. For journalists and editors: the Press & Media Center collects our feeds, boilerplate, fact sheet, logo assets, and press contact in one place. All Education Announcement Ecosystem Editorial Press Release To our knowledge, Aere is the first public EVM Layer-1 with native NIST post-quantum signature verification live on mainnet Official press release, Seychelles, July 18, 2026: the complete research record behind the live post-quantum precompiles is published, an independently implemented second client reproduces the chain byte for byte at every height checked, and every served block header reconstructs its own hash. Built to be checked, not believed. July 18, 2026 4 min read Engineering · Universal Login Universal Login, multi-key wallets, recovery, gasless onboarding AerePasskeyAccountV2 + AereEntryPointV2 + Foundation relayer deployed. MultiOwnable (passkey + EOA + multiple keys), ERC-4337 validateUserOp, EIP-1271 isValidSignature, and gasless onboarding via aere.network/relay. All four code paths verified end-to-end including passkey-self-authorized recovery flow. June 1, 2026 6 min read Engineering · Wallets Aere wallets via Touch ID / Face ID, passkey accounts live AerePasskeyAccount + AerePasskeyAccountFactory deployed on chain 2800. Tap your fingerprint, get an Aere wallet. No seed phrase, no extension. WebAuthn signatures verified on-chain via Fusaka's RIP-7951 secp256r1 precompile, proven end-to-end, real test tx 0x3045dd33…d4426 in block 2,157,502. June 1, 2026 5 min read Engineering · zkVerify Aere verifies zk proofs natively, SP1 + RISC Zero live Canonical SP1 v6.1.0 verifier stack (with gateway routing v6.0.0, v6.1.0 Groth16, and v6.1.0 Plonk), RISC Zero Groth16 verifier (with router), and a multi-prover AereProofRegistry deployed on chain 2800. First real proof verified end-to-end: SP1 Fibonacci Groth16, block 2,151,318. May 31, 2026 6 min read Engineering Aere goes sub-second, 0.5s block time live QBFT block period transitioned from 1 second to 0.5 seconds at block 2,137,652 using Besu's config.transitions.qbft with xblockperiodmilliseconds. Zero downtime, same Besu binary, same EVM ruleset. Aere is now the fastest production Besu QBFT chain we're aware of. May 31, 2026 4 min read Engineering · Tokenomics Aere pays developers, Fee Monetization live AereFeeMonetization deployed on chain 2800. Registered contracts earn 20% of their gas fees as transferable ERC-721 NFTs. Plus 5% of every gas fee flows to Foundation treasury. On Aere, developers get paid for the work their code does. May 31, 2026 5 min read Engineering · DEX Aere goes MEV-resistant, batch-auction DEX live AereSettlement + AereVaultRelayer + AereSolverRegistry deployed on chain 2800. Batch-atomic clearing with uniform per-pair prices. Users sign EIP-712 orders off-chain; solvers clear in one tx. Sandwich attacks become structurally impossible. May 31, 2026 6 min read Engineering · Tokenomics Coinbase splitter live: 37.5% validator-coinbase burn sealed on chain 2800 AereCoinbaseSplitter deployed on chain 2800. 37.5% of every validator coinbase sweep is atomically routed to AereFeeBurnVault, permanent destruction, no withdraw, no admin. Correction: the burn is a share of validator coinbase reward, not of gas or base fee, and that reward is currently zero, so lifetime burned is 0.1374 AERE. Aere is not deflationary today. May 31, 2026 5 min read Engineering Aere goes verifiably random, drand beacon live AereRandomnessBeacon and AereDrandConsumer deployed on chain 2800. Threshold-BLS-signed randomness from 19 independent organisations (Cloudflare, EPFL, Protocol Labs, U.S. Naval Research Lab, et al.). Permissionless, consumers pay own gas. May 31, 2026 5 min read Engineering Aere goes pull-oracle, Pyth-compatible price feeds live AerePyth (canonical Pyth IPyth-interface-compatible pull oracle) and AereOracleAdapter (unified read interface) deployed on chain 2800. Apps written against the Pyth SDK work unchanged. Drop-in ready for canonical Pyth Network onboarding, same contracts, same interface, same migration path. May 31, 2026 5 min read Engineering Aere goes intent-based, Across SpokePool + ERC-7683 live AereSpokePool (Across-v3-compatible) and AereERC7683 (ERC-7683 IOriginSettler) were deployed on chain 2800; the V1 contracts are now deprecated and flawed, and the corrected V2 replacements are deployed but deliberately inert with no open route (update, 2026-08-01). The design: one signed intent, a solver network delivering in ~30 seconds, no multi-step bridge UX. May 31, 2026 6 min read Engineering Aere goes cross-chain, Hyperlane-compatible messenger live AereMessenger + AereIGP deployed on chain 2800, Hyperlane-Mailbox-compatible cross-chain message bus with ECDSA-multisig Interchain Security Module. When Aere joins the Hyperlane registry, the same contracts can accept signatures from the global validator network; today the deployed module still has a single validator and threshold 1 (measured 2026-08-19), so the 1-of-1 trust model is not gone yet. May 31, 2026 6 min read Engineering Aere goes gasless, multi-paymaster stack live Five-contract paymaster stack deployed: ERC-4337-style EntryPoint plus four paymaster classes. Users transact without owning AERE. Pay gas in USDT, stake for free transactions (an EVM-native model), or get sponsored by the dApp you're using. May 31, 2026 6 min read Engineering Aere upgrades to Fusaka, native passkey signatures now on-chain On May 31 2026 Aere activated the Fusaka EVM ruleset, the RIP-7951 secp256r1 precompile lets smart contracts verify Face ID, Touch ID, Windows Hello, and YubiKey signatures natively at ~3,500 gas. Foundation for biometric wallet UX on Aere. May 31, 2026 5 min read Engineering Aere upgrades to Pectra, EIP-7702 + BLS precompiles now live On May 31 2026, Aere activated the Pectra EVM ruleset, native account abstraction, BLS12-381 precompiles, historical block hashes, and the full Cancun opcode set. Zero downtime, and the three validators the chain ran at the time all stayed clean. The set is nine today. Full parity with Ethereum mainnet. May 31, 2026 5 min read Announcement Aere Genesis v2: Correcting the Supply to 2.8 Billion On May 7 2026, Aere Network relaunched its chain to align total token supply with the whitepaper, before any public activity. Here's what happened and why it matters. May 9, 2026 4 min read Ecosystem Aere Developer Grants: Build and Get Funded The Aere Foundation is funding projects across dApps, infrastructure, tooling, and content, from $1,000 quick builds to $100,000 strategic engagements. May 7, 2026 4 min read Editorial Why EVM Compatibility Matters MetaMask, Hardhat, Foundry, ethers.js, every Ethereum tool works on Aere. What EVM compatibility actually means and why it's the fastest path to a live ecosystem. May 3, 2026 5 min read Education The 2.8 Billion AERE Supply, Explained A transparent breakdown of AERE's hard-capped supply, the six allocation wallets, their purposes, and how staking rewards relate to the total cap. Apr 29, 2026 5 min read Education How Aere Validators Work QBFT consensus, block production, and the AereStaking contract, how validators and delegators both earn rewards on Aere Network. Apr 24, 2026 5 min read Education Deploy Your First Smart Contract on Aere Using Remix and MetaMask, you can deploy a Solidity contract to Aere Network in under ten minutes. Gas costs are negligible. Here's the step-by-step. Apr 19, 2026 5 min read Education Add Aere Network to MetaMask in 60 Seconds Three ways to connect MetaMask to Aere Network: the one-click page, manual network entry, and the programmatic API, each takes about a minute. Apr 14, 2026 3 min read Education What is Aere Network? An introduction to Aere Network: an EVM-compatible Layer 1 blockchain with QBFT consensus, 0.5-second blocks, and a native token designed for the real economy. Apr 8, 2026 5 min read No articles in this category yet. The Aere Network newsroom publishes original updates, explainers, and official press releases. Content is authored at the organization level by Aere Network and operated by the Aere Foundation. Press & Media Center · About · Editorial standards & ownership · Contact · Foundation · RSS · JSON feed --- # AERE Bridge, Cross-Chain Transfer URL: https://aere.network/bridge.html Fetched: 2026-09-15 AERE Bridge, Cross-Chain Transfer AERE Bridge Home Swap Stake NFTs Cross-chain bridge Cross-chain messaging layer live (May 31, 2026). AereMessenger ( 0xe54c2329…25477325 ) is a Hyperlane-Mailbox-compatible cross-chain message bus deployed on chain 2800. Token-bridge counterparties (AereWarpRoute for USDC, USDT, WETH, cbBTC) ship per-asset as the Hyperlane registry merge lands. The form below is preview-only until the first WarpRoute deployment. Move tokens between AERE Network and any chain registered in Hyperlane. ECDSA-multisig attested, replay-protected, drop-in compatible with the public Hyperlane validator network when AERE joins the registry. Bridge architecture (Tier 1.4 + 1.5 live) AereMessenger: 0xe54c2329…25477325 , Hyperlane-compatible message bus AereIGP: 0x61B48615…fdD86E837 , Interchain Gas Paymaster AereSpokePool V1, deprecated: 0xCAB1DBA5…B3181AbD . Do not integrate. Our own registry marks it flawed: its settlement path could release locked principal without properly verifying the delivered output leg. Measured 2026-08-01, it holds a zero balance. Replaced by AereSpokePoolV2Corrected 0xbEF9BF0D…8C623d8d (6,317 bytes live), which is deployed but deliberately inert: no remote spoke is enrolled, so no intent route is open on either version today. AereERC7683 V1, deprecated: 0x67Fb9830…273ccb29 . It routes into the deprecated SpokePool above, so it inherits the same problem. Replaced by AereERC7683V2Corrected 0x8eC4e7F0…381560e3 (7,931 bytes live), also inert. Patterns: Hyperlane Warp Route (typed token), Across-v3 intent (one-click) Status: Phase 1, bootstrap validator set. No intent route is live: the V1 intent contracts are deprecated and the corrected V2 pair is deployed but not wired. Across registry and solver onboarding are pending. The legacy 1-of-1 federated AereBridge was torn down on the Foundation's AERE-only-token mandate. AereMessenger + per-asset Warp Routes are the canonical path going forward. Connect Wallet From AERE Network (Chain 2800) Ethereum, Warp Route not yet deployed BSC, Warp Route not yet deployed Polygon, Warp Route not yet deployed Arbitrum, Warp Route not yet deployed Optimism, Warp Route not yet deployed Base, Warp Route not yet deployed Avalanche, Warp Route not yet deployed To Ethereum, Warp Route not yet deployed AERE Network (Chain 2800) BSC, Warp Route not yet deployed Polygon, Warp Route not yet deployed Arbitrum, Warp Route not yet deployed Optimism, Warp Route not yet deployed Base, Warp Route not yet deployed Avalanche, Warp Route not yet deployed Amount Recipient (destination address) Estimated finality on Hyperlane: ~30 seconds source confirmation + 1-3 minutes destination relay. ECDSA-multisig quorum threshold rises as the Foundation Council validator set expands. Bridge (Warp Routes shipping shortly) --- # AERE Payment Channels, Bidirectional State Channels URL: https://aere.network/channels.html Fetched: 2026-09-15 AERE Payment Channels, Bidirectional State Channels AERE Payment Channels Home All dApps Explorer Bidirectional State Channels Coming soon. This feature is built and on the AERE roadmap, its on-chain contracts are not yet deployed. Actions are disabled until launch. Open a payment channel with another address. Both parties can deposit AERE; off-chain co-signed states settle the final balance. 1-day challenge window protects against stale states. Whitepaper §2.4. Open new channel Contract Not yet deployed Challenge period 1 day Counterparty (address) Initial deposit (AERE) Connect Wallet Open channel Existing channels Loading… Refresh Fund or settle a channel Channel ID Fund amount (AERE) Fund Settle --- # Aere Cloud Console URL: https://aere.network/cloud-console.html Fetched: 2026-09-15 Aere Cloud Console Plans API docs Status Aere Cloud · account console Your account, held by mathematics. Sign in with your wallet: one signature proves you own the account, and that is the whole login. No password to steal, no session database to breach, no reset-email to phish: the console is read-only by design, and every change (key rotation, renewal) is a transaction only your wallet can sign. Sign in You will be asked to sign a short message (free, no gas): it names your address and the current time, and it expires in 10 minutes. Our gateway verifies the signature through the chain’s own ecrecover precompile. Connect wallet & sign in Subscription Account Plan Status Expires Rotate API key Renew / upgrade Request invoice New API key: shown once, store it now. Copy key Usage, last 31 days JSON-RPC Post-quantum verifications Data API Sponsored operations Counted by the gateway per request family; the same numbers your /v1/account API returns. Receipts, straight from the chain Every subscription event is an on-chain record no invoice PDF can compete with: click any transaction to verify it on the explorer. Event Plan Paid Block Transaction No on-chain events for this account yet. Webhooks The chain pushes to your servers: new PQ anchors, activity on a watched address, your billing events. Managed here with wallet signatures: your production API key never touches this browser. Each action asks for a fresh, free signature. Type Target Status No webhooks yet. pq-anchors address-activity subscription-events Create webhook Webhook secret: shown once, store it now. Every delivery carries x-aere-signature = HMAC-SHA256 of the raw body with this secret; verify it before trusting a payload. Quickstart with your account Aere Cloud: overview · API docs · console · status --- # Aere Cloud API Reference URL: https://aere.network/cloud-docs.html Fetched: 2026-09-15 Aere Cloud API Reference Overview & pricing Subscribe Console OpenAPI Chain RPC docs Getting started Official SDK Overview Authentication Subscribing Endpoints GET /v1/health POST /v1/rpc WSS /v1/ws POST /v1/pq/verify GET /v1/account POST /v1/console/account /v1/webhooks /v1/notarize /v1/sponsor GET /v1/data/head GET /v1/data/validators GET /v1/data/anchors GET /v1/data/transfers Reference Rate limits Errors The contract Changelog Aere Cloud · API reference One key. The whole network. Base URL https://cloud.aere.network/v1 . Authentication is an API key whose hash lives in an on-chain subscription: there is no signup form and no server-side account database to breach. Every endpoint returns JSON. Every claim in these docs can be re-checked against chain 2800. Official SDK Skip the raw HTTP: @aere/cloud wraps every route below, zero dependencies, Node 18+ and browsers. npm install @aere/cloud import { AereCloud } from '@aere/cloud'; const aere = new AereCloud({ apiKey: process.env.AERE_KEY }); const anchors = await aere.anchors(5); const { valid } = await aere.pqVerify({ scheme: 'ml-dsa-44', publicKey: '0x…', signature: '0x…', message: '0x…' }); const receipt = await aere.notarize('0x' + sha256Hex); Source and README: git.aere.network/aere-network/aere-cloud-sdk . It also ships verifyWebhook(rawBody, signatureHeader, secret) so you never hand-roll the HMAC check. Overview Aere Cloud exposes three families of endpoints behind one API key: JSON-RPC : keyed access to chain 2800 with per-plan rate limits, full eth_* / net_* / web3_* namespaces plus read-only QBFT methods. Post-quantum verification : NIST post-quantum signature verdicts computed by the chain’s native precompiles (live since block 9,189,161), not by application code. Chain data : the validator set, chain head, and the post-quantum anchor certificates, proven and independently verifiable: every 128th block (every 32nd block until block 17,225,968, on 2026-09-05)’s Falcon-512 certificate digest and seal count, parsed for you. Authentication Send your key in the x-api-key header on every request except /v1/health . x-api-key: ak2800.. The key format is load-bearing: the address tells the gateway whose subscription to check. On every request the gateway computes keccak256 of the whole key string and asks the subscription contract check(address, keyHash) on chain 2800. If the chain cannot be reached, the gateway answers 503 and refuses to guess: it fails closed, never open. We never see or store your key. It is generated in your browser (or by you), and only its keccak-256 hash is registered on-chain. There is no key table on any server, so there is nothing to leak. If you lose the key, rotate to a new one: rotation is free, only gas. Subscribing The free trial is fully self-serve in the subscribe panel : connect a wallet, take the key, done. Paid plans, while AERE is pre-listing, are invoiced in USDC or EUR: email [email protected] (the panel prefills the order) and we activate your subscription on-chain via grantSubscription when payment clears; your account never needs gas. Everything the panel does is plain contract calls you can also make yourself: # 1. generate a key and hash it (any keccak-256 tool works) KEY="ak2800.0xYourAddress.$(openssl rand -base64 24 | tr '+/' '-_' | tr -d '=')" HASH=$(cast keccak "$KEY") # 2. read the plan's on-chain price (the dollar list price at the published reference rate) cast call 0xfA2375F5c30d25e0b952F5Ac07Bc292aD3C20433 \ "plans(uint64)(string,uint256,bool)" 0 --rpc-url https://rpc.aere.network # 3. subscribe: planId, months (1-12), key hash; pay price x months exactly. # plan 5 is the free trial: a real key for the cost of gas alone cast send 0xfA2375F5c30d25e0b952F5Ac07Bc292aD3C20433 \ "subscribe(uint64,uint256,bytes32)" 5 1 "$HASH" \ --value 0 --rpc-url https://rpc.aere.network --private-key $PK # 4. use the key curl -s https://cloud.aere.network/v1/account -H "x-api-key: $KEY" Renewals extend from your current expiry, never from the payment date; pass 0x0 as the hash to keep your existing key. List prices are in US dollars; the contract stores each plan’s price as the AERE amount at the published reference rate ($0.05/AERE until market listing, then market, applied to new subscriptions only): always read the exact amount from plans(planId) before paying. Enterprise agreements skip the token and are invoiced in EUR or USDC. Health GET /v1/health no key $ curl -s https://cloud.aere.network/v1/health {"ok":true,"chainId":2800,"block":15220078} JSON-RPC POST /v1/rpc A JSON-RPC 2.0 endpoint on chain 2800; single requests and batches both work. Allowed methods: everything in eth_* (including eth_sendRawTransaction ), net_* , web3_* , and the read-only QBFT set ( qbft_getValidatorsByBlockNumber , qbft_getValidatorsByBlockHash , qbft_getSignerMetrics , qbft_getPendingVotes ). Validator-vote methods are refused on every tier, paid included. $ curl -s https://cloud.aere.network/v1/rpc \ -H "content-type: application/json" -H "x-api-key: $KEY" \ -d '{"jsonrpc":"2.0","id":1,"method":"eth_blockNumber","params":[]}' {"jsonrpc":"2.0","id":1,"result":"0xe83aa9"} A disallowed method answers inside the JSON-RPC envelope, so batch positions are preserved: {"jsonrpc":"2.0","id":1,"error":{"code":-32601,"message":"Method not allowed on this endpoint"}} Mind the 512-block state window : public endpoints keep world state for 512 blocks and eth_getTransactionCount answers 0x0 beyond it instead of erroring. Details in the chain RPC docs . WebSocket subscriptions WSS /v1/ws Live JSON-RPC over WebSocket, including eth_subscribe for newHeads and logs : a new head arrives roughly every half second. The WS route exposes the eth / net / web3 namespaces only, so validator-vote methods do not exist on this path at all. Authenticate one of two ways: Header (servers, preferred): x-api-key: ak2800.… on the upgrade request. Query (browsers, which cannot set WS headers): wss://cloud.aere.network/v1/ws?key=ak2800.… : access logging is disabled on this route so the key is not written to server logs; still prefer the header wherever you control the client. // node, with the ws package const ws = new WebSocket('wss://cloud.aere.network/v1/ws', { headers: { 'x-api-key': KEY } }); ws.on('open', () => ws.send(JSON.stringify( { jsonrpc: '2.0', id: 1, method: 'eth_subscribe', params: ['newHeads'] }))); ws.on('message', (d) => console.log(JSON.parse(d).params?.result?.number)); // → a new block number roughly every 0.5s A bad or missing key is refused at the door with 403 / 401 before any socket to the node is opened. Post-quantum verification POST /v1/pq/verify The verdict is computed by the chain’s native precompiles via eth_call : the response tells you which precompile answered and at what block height. Send hex fields with 0x prefixes. scheme precompile request fields notes ml-dsa-44 0x…0ae3 publicKey (1312 B), signature (2420 B), message NIST ML-DSA-44 (Dilithium2) slh-dsa-128s 0x…0ae4 publicKey (32 B), signature (7856 B), message NIST SLH-DSA-SHA2-128s; ~11.8 KB requests are fine here falcon-512 0x…0ae1 publicKey (897 B), signedMessage Falcon reference signed-message blob falcon-1024 0x…0ae2 publicKey (1793 B), signedMessage same shape as falcon-512 # a real exchange, produced by this endpoint from a NIST ACVP vector $ curl -s https://cloud.aere.network/v1/pq/verify \ -H "content-type: application/json" -H "x-api-key: $KEY" \ -d '{"scheme":"ml-dsa-44","publicKey":"0x…","signature":"0x…","message":"0x…"}' {"valid":true,"scheme":"ml-dsa-44", "precompile":"0x0000000000000000000000000000000000000ae3", "block":15220111,"chainId":2800} # flip one bit of the signature and the chain flips the answer {"valid":false,"scheme":"ml-dsa-44", …} Account GET /v1/account Your subscription as the gateway sees it, plus usage across the last 31 days. Usage counts requests by family ( rpc , pq , data ). $ curl -s https://cloud.aere.network/v1/account -H "x-api-key: $KEY" {"address":"0xbeb3…6465","planId":0, "plan":{"name":"rpc-build","monthlyPriceWei":"39000000000000000000","active":true}, "expiresAt":1790065218,"expiresAtIso":"2026-09-22T08:20:18.000Z", "usageLast31Days":{"rpc":1204,"pq":37,"data":12}, "contract":"0xbe65a4f3a1fc300c262adc0fbb9c6968fcc81fa0","chainId":2800} Console sign-in POST /v1/console/account Powers the account console : the same account view as /v1/account , plus the full on-chain receipt history, authenticated by a wallet signature instead of the API key : so a company admin can see the account without handling the production key. Sign this exact message with the account’s wallet ( personal_sign ): Aere Cloud console login address: timestamp: $ curl -s https://cloud.aere.network/v1/console/account -H "content-type: application/json" -d '{"address":"0x…","timestamp":1787490000,"signature":"0x…"}' {"address":"0x…","subscription":{"planId":5,"plan":{"name":"trial",…},"active":true,…}, "usageLast31Days":{"rpc":3,"pq":4,"data":8}, "history":[{"type":"Subscribed","planId":5,"paidWei":"0","block":15236801,"tx":"0x…"}], "historyComplete":true,"contract":"0x…","chainId":2800} The gateway rebuilds the message, hashes it under the EIP-191 prefix, and recovers the signer through the chain’s own ecrecover precompile: no signature code of ours to trust. A stale timestamp or a signature by any other key answers 401 . The route is read-only: rotation and renewal are transactions only your wallet can sign. The same signed body also manages webhooks without exposing your API key: add "webhookAction":"list" , or "create" (with type , url , and watch for address-activity), or "delete" (with id ). Creation returns the HMAC secret once, exactly like the keyed route; private targets are refused on this path too. Chain head GET /v1/data/head {"chainId":2800,"block":15225986,"hash":"0x6539…a3b0", "timestamp":1787477821,"baseFeeWei":"1000000000"} Validator set GET /v1/data/validators The live QBFT validator set, read from consensus, not from a config file. {"chainId":2800,"count":9,"validators":["0x1bd5…1c9d","0x4bf6…0044", …]} Post-quantum anchors GET /v1/data/anchors?limit=10 · GET /v1/data/anchors/{height} Every 32nd block of chain 2800 (heights with height % 32 == 16 , from 13,014,000) carries a Falcon-512 validator certificate: its 32-byte digest sits in the first bytes of extraData , under the block hash, and the seals themselves ride alongside. This endpoint parses that structure for you: the data no other public chain can serve. $ curl -s "https://cloud.aere.network/v1/data/anchors?limit=2" -H "x-api-key: $KEY" {"chainId":2800,"head":15225986,"anchorIntervalBlocks":32,"firstAnchorBlock":13014000, "note":"every 128th block (every 32nd block until block 17,225,968, on 2026-09-05) carries a Falcon-512 validator certificate whose digest sits in the first 32 bytes of extraData, under the block hash", "anchors":[ {"height":15225968,"hash":"0x6539…a3b0","timestamp":1787477821, "falconSeals":9,"certificateDigest":"0x0449…3039"}, {"height":15225936,"hash":"0xaea7…106b","timestamp":1787477803, "falconSeals":9,"certificateDigest":"0x9e82…511c"}]} limit is 1–50 (default 10). A height that is not an anchor answers 400 not_an_anchor_height with the rule in the hint. Since block 14,961,456 an anchor does not finalize with fewer than six valid seals (six of the nine validators of that time; ten validators since 2026-09-11, so six is now below the quorum of seven); the counts you see here are the chain’s own, typically 9. Webhooks POST /v1/webhooks · GET /v1/webhooks · DELETE /v1/webhooks/{id} The chain pushes to you. Up to 5 webhooks per account, three event types: type fires payload data pq-anchors every new post-quantum anchor (~16s) height, hash, timestamp, falconSeals, certificateDigest address-activity any transaction touching your watched address hash, from, to, valueWei, block, timestamp subscription-events your account’s billing events the on-chain receipt (type, planId, paidWei, tx) $ curl -s https://cloud.aere.network/v1/webhooks -H "x-api-key: $KEY" -H "content-type: application/json" -d '{"type":"pq-anchors","url":"https://your-server.example/hooks/aere"}' {"id":"wh_7e584f1d0ad0d403","secret":"", …} Every delivery is a POST with headers x-aere-event and x-aere-signature : hex HMAC-SHA256 of the raw body, keyed with your webhook secret. Verify it before trusting the payload: const valid = crypto.createHmac('sha256', SECRET).update(rawBody).digest('hex') === req.headers['x-aere-signature']; Delivery policy, stated plainly: 10s timeout, 3 attempts with backoff; 20 consecutive failures disable the webhook (visible in the list) until you recreate it. Targets must be public http(s): private and loopback addresses are refused at creation and re-checked at every delivery. On gateway restart, catch-up is capped at 300 blocks: webhooks are near-real-time signal; complete history lives in the data API. Notarization POST /v1/notarize · GET /v1/notarize/{hash} Prove a document existed no later than a moment in time: on a chain whose every 128th block (every 32nd block until block 17,225,968, on 2026-09-05) carries a post-quantum validator certificate, so the proof is built to outlive the cryptography era it was made in. Your file never leaves your hands: hash it locally, send only the 32-byte digest, we pay the gas and carry the transaction. $ HASH="0x$(sha256sum contract.pdf | cut -d' ' -f1)" $ curl -s https://cloud.aere.network/v1/notarize -H "x-api-key: $KEY" -H "content-type: application/json" -d "{\"hash\":\"$HASH\"}" {"hash":"0x2cdc…af96","txHash":"0x4949…0f51","block":15244146, "firstSeenAt":1787488094,"firstTime":true, "contract":"0x4aB392c4Aca7D9D4C16c0b60a9514c5025bd58c7","chainId":2800} $ curl -s https://cloud.aere.network/v1/notarize/$HASH -H "x-api-key: $KEY" {"notarized":true,"firstSeenAt":1787488094,"firstSeenIso":"2026-08-23T12:28:14.000Z",…} The property that makes it a proof: first-seen can never be overwritten , re-notarizing answers firstTime:false with the original timestamp, enforced by the contract, covered by tests with negative controls. The contract ( AereNotary ) has no owner, no funds and no admin path; it is also fully permissionless, you can skip our API entirely and call notarize(bytes32) yourself, paying your own gas. The API is the convenience, not the gatekeeper. Transfer history GET /v1/data/transfers?address=0x…&limit=50 Transfers touching an address, split honestly along what the chain itself allows: token transfers (ERC-20/721 Transfer events) are indexed from genesis ; native AERE transfers emit no events, so they are indexed from the feature’s launch block onward: the response carries both boundaries ( tokenHistoryComplete , nativeSince ) so you never mistake a partial answer for a full one. $ curl -s "https://cloud.aere.network/v1/data/transfers?address=0xYourAddr&limit=5" -H "x-api-key: $KEY" {"chainId":2800,"address":"0x…", "tokenTransfers":[{"token":"0x7e84…f5e8","from":"0x…","to":"0x…", "valueWei":"5000000000000000","tx":"0x…","block":15245202}], "nativeTransfers":[{"from":"0x…","to":"0x…","valueWei":"1000000000000000", "tx":"0x…","block":15245105,"timestamp":1787488549}], "tokenHistoryComplete":true,"nativeSince":15245018,…} Gas sponsorship POST /v1/sponsor/createAccount · POST /v1/sponsor/execute · GET /v1/sponsor/health Onboard users who hold zero AERE: your backend calls with your API key, the Foundation relayer deploys the user’s passkey smart account and submits their transactions, paying the gas. The smart account validates every signature itself: the relayer never sees a user key, so even a fully hostile relayer could only waste its own gas; user funds stay out of its reach by construction. Usage is metered per account (the sponsor counter in /v1/account ). $ curl -s https://cloud.aere.network/v1/sponsor/createAccount -H "x-api-key: $KEY" -H "content-type: application/json" -d '{"initialOwners":[…],"salt":"0x…"}' # the relayer deploys the account and pays the gas; see the wallet # infrastructure engagement for the full passkey flow Honest phase-1 limits, same as the public relayer’s: a single relayer EOA, no high availability; if it is down, users holding AERE can still transact directly. The keyed route adds authentication and metering on top of the same engine. Rate limits Limits are per key, per second, by plan; the gateway also meters usage for your /v1/account view. Above the limit you get 429 with Retry-After: 1 . plan list price requests / second trial (5) free 25 rpc-build (0) $49/mo 150 data-api (2) $199/mo 100 rpc-scale (1) $249/mo 500 pq-verify-api (3) $299/mo 50 managed-node (4) $999/mo 150 Request bodies are capped at 256 KB at the gateway (1 MB at the edge). The API plans above are the developer tier; enterprise programs (post-quantum migration, dedicated chains, compliance infrastructure, managed fleets) are scoped from six figures a year and invoiced in EUR or USDC: [email protected] . Errors status body error meaning 401 missing_api_key no x-api-key header; the body repeats the key format and contract 403 invalid_or_expired_key bad format, unregistered hash, or an expired subscription 429 rate_limit over your plan’s per-second limit; retry after 1s 400 bad_json , unknown_scheme , bad_publicKey , not_an_anchor_height , … malformed input; the hint says what to fix 413 body_too_large request body over 256 KB 503 subscription_check_unavailable the gateway could not verify your key on-chain and refuses to guess; temporary 502 upstream the node behind the gateway failed to answer The subscription contract AereCloudSubscriptionsV2 at 0xfA2375F5c30d25e0b952F5Ac07Bc292aD3C20433 on chain 2800 ( explorer ). Properties, each enforced by code and covered by tests with negative controls: No custody. Every payment is forwarded to the Foundation treasury inside the same transaction; the contract’s balance is always zero. There is no receive() : a bare transfer to the contract reverts, so funds cannot get stuck in it. Only the key hash on-chain. subscribe(planId, periods, keccak256(key)) ; pass 0x0 to keep the current key. Extension from expiry. Renewing early never costs you time: the new expiry is max(now, current expiry) + 30 days × periods . Prepay is capped at 12 periods. Never retroactive. Price changes apply to new subscriptions only; a retired plan stops selling but every paid subscription stays valid to its expiry. No upgradability, no pause, no backdoor. The owner can configure plans and move the treasury target, nothing else. Interface function subscribe(uint64 planId, uint256 periods, bytes32 apiKeyHash) payable function rotateApiKey(bytes32 newApiKeyHash) // free, needs a live subscription function grantSubscription(address account, uint64 planId, uint256 periods, bytes32 apiKeyHash) // owner only: invoice-paid customers function check(address account, bytes32 apiKeyHash) view returns (bool valid, uint64 planId, uint64 expiresAt) function plans(uint64 planId) view returns (string name, uint256 monthlyPriceWei, bool active) function subs(address account) view returns (uint64 expiresAt, uint64 planId, bytes32 apiKeyHash) event Subscribed(address indexed account, uint64 indexed planId, bytes32 apiKeyHash, uint64 expiresAt, uint256 paidWei) event Granted(address indexed account, uint64 indexed planId, bytes32 apiKeyHash, uint64 expiresAt) // invoice-paid, distinguishable on-chain event ApiKeyRotated(address indexed account, bytes32 newApiKeyHash) Changelog & status 2026-08-23 : v1 launch: keyed JSON-RPC, keyed WebSocket subscriptions, webhooks (PQ anchors, address activity, billing events), the notarization API, keyed gas sponsorship, post-quantum verification API, account & usage, chain data endpoints (head, validators, PQ anchors, transfer history), wallet-based subscribe panel, dollar list pricing settled on-chain at the published reference rate, and a free keyed trial plan. Machine-readable spec at /cloud-openapi.json . Planned next, in the open: USDC settlement for enterprise invoices, native-transfer history backfill. Live status: /cloud-status.html runs every check in your own browser; GET /v1/health answers without a key. Support: [email protected] . Aere Cloud: overview · API docs · console · status --- # Aere Status URL: https://aere.network/cloud-status.html Fetched: 2026-09-15 Aere Status Aere Cloud API docs Verify the chain Aere Network · live status Status you compute yourself. Most status pages show you a green dot their operator painted. Every check below runs in your browser, right now , against the real public endpoints: if something is down, no one can paint over it. Method: JSON-RPC endpoints are asked for the chain head and judged on answering with a well-formed block number; the Cloud API is judged on its health route; WebSocket is judged on a real subscription handshake. Latency is measured from your device, so it includes your own network path. Chain 2800 … chain head, read live … seconds per block, measured over 10 blocks … validators in the live QBFT set … Falcon seals on the latest PQ anchor Public endpoints Anything red? It is either genuinely down or blocked on your network path: try the same check from another connection, then tell us: [email protected] . This page has no server-side component to fail independently of what it measures. Aere Cloud: overview · API docs · console · status --- # Aere Cloud | Infrastructure & post-quantum services URL: https://aere.network/cloud.html Fetched: 2026-09-15 Aere Cloud | Infrastructure & post-quantum services Services Pricing Subscribe Enterprise Post-quantum API Docs Console Contact sales Aere Cloud · Infrastructure & services Infrastructure for the post-quantum internet of value. Enterprise RPC, managed nodes, blockchain data, and chain-native post-quantum verification computed by the chain’s own precompiles. Priced in USD, settled monthly in AERE on-chain, verifiable end to end: no account manager required to prove it works. See plans & pricing Subscribe with your wallet npm install @aere/cloud 0.5s deterministic finality 6 of 10 Falcon seals per anchor, minimum 2 independent client implementations 100% claims verifiable from a public endpoint every 128th block (every 32nd block until block 17,225,968, on 2026-09-05) · Falcon-512 certificate · 6 of 10 seals under the block hash What we run for you Seven services. One chain. Everything checkable. Each service carries an honest status. We sell what runs in production and label the rest, because the whole point of building on a chain like this is that you can verify the claim instead of trusting the vendor. ⚡ Live Enterprise RPC Dedicated JSON-RPC and WebSocket endpoints on chain 2800, sized to your traffic instead of shared with the world. eth_subscribe pushes you a new head roughly every half second. Dedicated endpoints & higher rate limits Archive access & full historical state Uptime SLA and geographic redundancy Per-key usage metering, on-chain billing from $49 / mo 📡 Live Managed Nodes Your own AERE node, deployed and operated by us: upgrades, monitoring, backups, high availability. You get the endpoint; we carry the pager. Dedicated full or archive node Automatic upgrades & patching 24/7 monitoring & heartbeat alerting Daily off-box backups from $999 / mo 🔑 Live Post-Quantum Verification API Computed by the chain’s own precompiles, not by our application code. Send a signature, message, and public key; the network’s own precompiles, live on-chain since block 9,189,161, return the verdict, stamped with the block height it was computed at. Falcon-512, Falcon-1024, ML-DSA-44, SLH-DSA-128s Verdicts computed by chain-native precompiles, not by our application code NIST ACVP test vectors pass on the live endpoint: re-check them yourself Answers carry block height and chain id, reproducible against public RPC from $299 / mo 👜 Beta Wallet & Account Infrastructure Passkey wallets your users open with a fingerprint: no seed phrase, multi-key recovery, gasless onboarding through our relayer. The account contracts are live on chain 2800 and every address below them is verifiable. Passkey (WebAuthn) smart accounts, ERC-4337 compatible Multi-key recovery: add a device, lose a device, keep the funds Gas sponsorship API: keyed, metered, live (phase-1 limits stated honestly) DID registry & revocable attestations included from $199 / mo 📊 Live Blockchain Data API Keyed chain data, transfer history and webhooks are all live: anchor certificates parsed per block, transfers indexed per address, address activity pushed to your servers with signed deliveries, billing events from the chain. Explorer & standard API: public, live now Keyed access with dedicated limits: live PQ anchor certificates, parsed per block: live Indexed transfers: live: token history from genesis, native from launch Webhooks: live: PQ anchors, address activity, billing events Notarization & timestamping API: live from $199 / mo 🛡 Private beta Compliance-as-a-Service Zero-knowledge compliance: sanctions screening, KYC attribute proofs, and eligibility checks answered valid / invalid with a proof, without the private data ever reaching us. Sanctions & eligibility screening ZK attribute proofs, no data disclosure On-chain compliance event registry Onboarding under NDA; contract required Design partners: talk to us 🤖 Waitlist Agent Payments (x402) Machine-to-machine settlement for AI agents: a payment quote, an EIP-712 authorization, atomic settlement. Micropayments and prepaid balances for autonomous software. HTTP 402 / x402 compatible Agent-to-agent & API micropayments Machine accounts with prepaid balances Join the early-access list Early access: join the waitlist RPC & Data plans Priced in dollars. Settled on-chain. List prices are in US dollars, at the level of the platforms you already use. While AERE is pre-listing, paid plans are invoiced in USDC or EUR and we activate your subscription on-chain the moment payment clears; the free trial is self-serve with your wallet, today. On-chain AERE self-serve opens at market listing, at the published reference rate. Every plan lives on chain 2800 inside AereCloudSubscriptions at 0xfA2375F5c30d25e0b952F5Ac07Bc292aD3C20433 : the payment goes straight to the Foundation treasury in the same transaction; the contract never custodies your funds, and only the hash of your API key ever touches the chain. Free $0 A real API key, free, today. 25 requests / second, keyed Post-quantum verification API included WebSocket subscriptions included Public shared RPC stays free for all Get a free key Most popular Build $49 /mo For teams shipping a real product. 150 requests / second API key, verified against the chain Post-quantum verification API included Email support Subscribe on-chain Scale $249 /mo Growing traffic, tighter guarantees. 500 requests / second Post-quantum verification API included Dedicated node option Priority email support Subscribe on-chain Enterprise Custom Infrastructure SLAs from $5,000/mo; solution programs from $100,000/yr. Custom throughput Private endpoints & nodes Signed uptime SLA Named solutions engineer See enterprise programs On-chain amounts are the dollar list price converted at the published reference rate ($0.05/AERE until listing, then market), updated for new subscriptions only, never retroactively: what you paid for stays valid, by contract design. Enterprise agreements are quoted and invoiced in EUR or USDC. Nothing here is financial advice or a token-price claim. Chain-native, verifiable post-quantum verification Post-quantum verification, as a live API. NIST post-quantum signature verifiers have been native precompiles on Aere since block 9,189,161, and every 128th block (every 32nd block until block 17,225,968, on 2026-09-05) does not finalize without a certificate of at least six valid Falcon-512 validator seals (of ten validators since 2026-09-11) under its hash. That machinery is now an API at cloud.aere.network : your application sends a signature, and the chain itself, not our application code, computes the verdict. The response below is a real one, produced by this endpoint from a NIST ACVP test vector. # Verify an ML-DSA-44 (Dilithium) signature via the live chain precompile POST https://cloud.aere.network/v1/pq/verify x-api-key: ak2800.. { "scheme" : "ml-dsa-44" , "publicKey" : "0x…" , "signature" : "0x…" , "message" : "0x…" } # → {"valid":true,"scheme":"ml-dsa-44", # "precompile":"0x0000000000000000000000000000000000000ae3", # "block":15220111,"chainId":2800} # No key yet? The health route is open: GET https://cloud.aere.network/v1/health # → {"ok":true,"chainId":2800,"block":…} Request API access Enterprise programs Where the serious budgets go. The monthly plans above are the developer door. The programs below are what enterprises actually buy from infrastructure vendors: scoped engagements delivered under contract, priced where this market prices them: from six figures a year upward. Invoiced in EUR or USDC. Every program is scoped in a call first; the anchors below are where scoping starts, not where it ends. 🛡 By contract Post-Quantum Migration Program The one program only we can anchor to a live chain: assessment of your signature estate, hybrid classical + post-quantum rollout, and on-chain verification against a live network whose every 128th block (every 32nd block until block 17,225,968, on 2026-09-05) carries a certificate of at least six of ten validator Falcon-512 seals under its block hash. Cryptographic inventory & quantum-exposure assessment Hybrid signature architecture & rollout plan On-chain PQ verification integration (live precompiles) Quarterly re-assessment against NIST guidance from $150,000 / year 🏭 By contract Dedicated Chain (White-Label L1) Your own QBFT network, built and operated the way we run chain 2800: sub-second finality, post-quantum anchoring available, your branding, our operations: monitoring, alerting, upgrades, backups, the discipline included. Dedicated validator set, deployed & operated Explorer, RPC and monitoring stack included Optional post-quantum anchor certificates Signed SLA, named engineers from $250,000 / year ⚖ Private beta Compliance Infrastructure (AereProof) Zero-knowledge compliance answered valid / invalid with a proof: sanctions screening, eligibility, KYC attributes, without the private data ever leaving your perimeter. Priced where compliance platforms price: as an annual license. Sanctions & eligibility screening pipelines ZK attribute proofs, no data disclosure On-chain compliance event registry Design-partner onboarding under NDA from $100,000 / year 📡 By contract Managed Validator Fleet A fleet of nodes run with the same operational discipline as our own validators: heartbeat monitoring with dual alarm channels, negative-controlled health gates, daily off-box backups, and upgrades rehearsed before they touch production. From 5 dedicated nodes, any supported role 24/7 monitoring, alerting & incident response Documented runbooks & rollback paths Monthly operational report from $120,000 / year 🔎 By contract Post-Quantum Security Assessment A scoped engagement, not a subscription: we inventory where quantum-vulnerable cryptography lives in your systems, quantify the harvest-now risk honestly (signatures are not it; long-lived encrypted data and key custody are), and hand you a migration plan your board can read. Cryptographic asset inventory Threat model with citations, no vendor fear-selling Prioritized migration roadmap Executive briefing included from $50,000 / engagement 🌎 Scoping Settlement & RWA Infrastructure Cross-border settlement rails and real-world-asset tokenization on dedicated infrastructure: stablecoin settlement flows, asset registries, compliance hooks. Scoped per project; typical programs land in the mid six figures. Settlement flows with deterministic finality Asset registry & lifecycle contracts Compliance integration (AereProof) Scoping engagement first, program second from $150,000 / deployment Program anchors are where scoping starts; multi-year, multi-program agreements run well into seven figures. Every engagement is delivered against a written statement of work with acceptance criteria: we put negative controls in our own infrastructure, and we put them in contracts too. Subscribe now Your wallet is your account. No password, no card form. Connect a wallet and take the free trial key right now; paid plans are invoiced in USDC or EUR until AERE lists, and we activate them on-chain when payment clears. Your API key is generated in this page, in your browser: only its hash goes on-chain, so nobody, including us, can recover or steal it from a server. Connect to begin Works with MetaMask and any EIP-1193 wallet. If Aere Network is not in your wallet yet, we will offer to add chain 2800 automatically. Connect wallet Reading subscription… Rotate API key Choose a plan Reading live plan prices from the contract… Months (1–12): Get your free key now Your API key: shown once, store it now. Copy key We never see this key and cannot recover it. If you lose it, rotate to a new one from this panel: rotation is free, only gas. Renewing keeps your existing key and extends from your current expiry, never from the payment date. Contract: 0xfA2375F5c30d25e0b952F5Ac07Bc292aD3C20433 · verify everything in the docs . How billing works Subscribe on-chain in three steps. No signup form, no card, no sales call required. The contract is AereCloudSubscriptions at 0xfA2375F5c30d25e0b952F5Ac07Bc292aD3C20433 on chain 2800. 1 Generate an API key Create it locally, in the format ak2800.. . Only its keccak-256 hash ever touches the chain: we never see or store the key itself. 2 Activate the plan Trial: call subscribe yourself, free. Paid plans: pay the USDC/EUR invoice and we activate you on-chain via grantSubscription , and when a payment does travel on-chain, it lands in the Foundation treasury in the same transaction; the contract holds nothing, ever. Tested properties, not promises. 3 Use your endpoint Send requests to cloud.aere.network/v1/ with the x-api-key header, and manage everything in the console : usage, on-chain receipts, key rotation. The gateway checks every key against your on-chain subscription. Renew from expiry, rotate the key any time, cancel by letting it lapse. What is live, stated plainly. The keyed RPC endpoint, the post-quantum verification API, and the on-chain subscription contract are running in production today: cloud.aere.network/v1/health answers without a key, and every billing property on this page is enforced by a contract you can read at 0xfA2375F5c30d25e0b952F5Ac07Bc292aD3C20433 . Managed nodes are provisioned per agreement. The keyed data API is in beta, Compliance-as-a-Service is in private beta with design partners, and Agent Payments is on an early-access waitlist. We would rather tell you the status than let a page imply more than the chain can prove. Aere Network is Foundation-operated while an independent-operator program is being built, and no external security audit has completed yet: both are on our public roadmap. Questions Frequently asked Do I have to build my application on Aere to use these services? No. The post-quantum verification API is plain HTTPS: your systems send a signature from wherever they already run and get a verdict back. RPC and managed nodes give you access to chain 2800. The only on-chain step is paying the subscription itself, which any wallet holding AERE can do; nothing requires you to deploy contracts first. What exactly is the post-quantum API doing that others cannot? The NIST post-quantum verifiers are native precompiles on a public EVM chain, live since July 2026, so the verdict your application receives is computed by the chain itself, not by a library we run next to it. And the chain carries its own post-quantum attestation: every 128th block (every 32nd block until block 17,225,968, on 2026-09-05) does not finalize without a certificate of at least six valid Falcon-512 validator seals under its hash (of ten validators since 2026-09-11; a full 2f+1 quorum of nine when raised, below the ten-validator quorum of seven), which to our knowledge no other public network runs in production and proves. You can re-check every claim yourself: the NIST ACVP vectors pass on this endpoint, and flipping one bit of a signature flips the answer. How is billing settled, and does the contract hold my money? Subscriptions are paid in AERE through the AereCloudSubscriptions contract. The payment is forwarded to the Foundation treasury inside the same transaction: the contract never accumulates a balance, so there is nothing to custody and nothing to drain. Only the hash of your API key is stored on-chain. How do I actually pay, since AERE is not listed anywhere yet? Exactly because AERE cannot be bought yet, paid plans are invoiced in USDC or EUR today: you email sales (the subscribe panel prefills the order), pay the invoice, and we activate your subscription on-chain with a dedicated grantSubscription call: your key then works like any other, verifiable on-chain, and your account never needs to touch the chain or hold gas. The trial plan is free and self-serve right now. On-chain AERE self-serve opens at listing, at the published reference rate ($0.05/AERE), applied to new subscriptions only. Is there a free tier? Yes, two: the public shared RPC stays free for everyone, and the trial plan gives you a real API key at no cost: 25 requests per second across the whole API, post-quantum verification and WebSocket included. Pick it in the subscribe panel; the transaction costs only gas. Talk to us Let’s size the right plan for your workload. Tell us your expected traffic, the services you need, and whether you want post-quantum anchoring, compliance proofs, or a dedicated chain. Self-serve starts free above; enterprise programs start at six figures a year. We answer with a concrete plan: not a sales funnel. Email sales Read the docs Status: cloud-status · API docs: cloud-docs · Console: cloud-console --- # Contact Aere Network URL: https://aere.network/contact.html Fetched: 2026-09-15 Contact Aere Network Contact How to reach the Aere Foundation and the Aere Network newsroom. General, press, and media enquiries [email protected] Operated by the Aere Foundation. We read press and media requests at this address and respond during European business hours. Channels Newsroom Engineering updates, explainers, and official press releases. aere.network/blog.html Feeds: RSS · JSON Block explorer Verify blocks, transactions, and contract state directly. explorer.aere.network Source and research Open repositories, improvement proposals, and the published research record. git.aere.network/aere-network Foundation and governance Grants, treasury, and on-chain governance. Foundation · Grants · Governance For journalists Press releases are published in the newsroom and syndicated through the RSS and JSON feeds above. For interviews, background, or clarification on any published claim, email [email protected] . Our sourcing, dating, and corrections practices are described in the editorial standards . Aere Network is a technology project. Nothing on this site is investment advice or a solicitation to buy or sell any asset. --- # Deploy Your First Smart Contract, AERE Academy URL: https://aere.network/course-first-contract.html Fetched: 2026-09-15 Deploy Your First Smart Contract, AERE Academy ← Back to AERE Academy Deploy Your First Smart Contract Beginner ~2 hours 6 modules Module 1, Solidity Basics Solidity is the most widely used language for writing smart contracts on EVM chains. A Solidity file is compiled to EVM bytecode and deployed on-chain, where it runs exactly as written, no one can alter it after deployment, and it executes identically on every node. Contract structure Every Solidity file starts with a pragma directive specifying the compiler version, then defines one or more contract blocks. Inside a contract you declare state variables (stored permanently on-chain), functions, events, and modifiers. // SPDX-License-Identifier: MIT pragma solidity ^0.8.20; contract HelloAERE { // State variable, stored on the blockchain string public greeting = "Hello, AERE Network!" ; // Function to update the greeting function setGreeting( string calldata _msg) external { greeting = _msg; } } Key concepts State variables are stored in contract storage, reading is free, writing costs gas. Functions marked view or pure only read state; they cost no gas when called off-chain. Events are cheap on-chain logs your front-end can listen for with ethers.js or the indexer API. Visibility : public (callable by anyone), external (only from outside the contract), internal (this contract + inheritors), private (this contract only). Module 2, Setting Up Remix IDE Remix is a browser-based Solidity IDE, no installation required. It handles compilation, deployment, and interaction with your contracts directly from the browser. Step 1. Open remix.ethereum.org in your browser. Step 2. In the file explorer on the left, create a new file: click the "+" icon and name it SimpleStorage.sol . Step 3. In the compiler panel (the "S" icon), select compiler version 0.8.20 and leave EVM version on the default. Step 4. Compile is triggered automatically whenever you save (Ctrl+S). Green checkmark = no errors. Remix keeps a virtual filesystem in your browser's local storage. You will not lose your files if you close and reopen the tab on the same browser, but do not rely on this for important projects. Use Hardhat or Foundry locally for production development. Module 3, Connecting MetaMask to AERE Remix can deploy contracts via MetaMask. You need MetaMask installed and connected to AERE Network (chain ID 2800) before you deploy. Step 1. Install MetaMask from metamask.io if you have not already. Step 2. Add AERE Network. Visit aere.network/addnetwork.html and click the one-click button, or add manually: RPC https://rpc.aere.network , Chain ID 2800 , symbol AERE , explorer https://explorer.aere.network . Step 3. Fund your address. This is currently a blocker: the faucet at aere.network/faucet.html is deployed but holds a zero balance, so it cannot pay out, and there is no other public way to obtain AERE today. You can write and compile the contract in the following steps, but deploying it to chain 2800 requires a funded address. Step 4. In Remix, open the Deploy & Run Transactions panel (the plug icon on the left sidebar). Change "Environment" from "Remix VM" to Injected Provider, MetaMask . MetaMask will ask you to confirm the connection. Step 5. Confirm you see "Custom (2800) network" in Remix. Your MetaMask account address will appear next to it. Module 4, Simple Storage Contract Let's deploy a real contract. Copy the following into SimpleStorage.sol in Remix: // SPDX-License-Identifier: MIT pragma solidity ^0.8.20; /** * @title SimpleStorage * @notice Stores and retrieves a single uint256 value on AERE Network. */ contract SimpleStorage { uint256 private _value; // Emitted whenever the stored value changes event ValueChanged ( address indexed caller, uint256 newValue); /// @notice Write a new value to storage function store( uint256 value) external { _value = value; emit ValueChanged(msg.sender, value); } /// @notice Read the stored value (free, no gas) function retrieve() external view returns ( uint256 ) { return _value; } } Compile it (Ctrl+S), then in the Deploy panel click Deploy . MetaMask will pop up, confirm the transaction. Within about half a second (AERE's block time), the contract is deployed. You will see its address in the "Deployed Contracts" list at the bottom of the Deploy panel. Click the deployed contract to expand it. Try calling store with a number, then retrieve to read it back. Each store call sends an on-chain transaction; each retrieve is a free local call. Module 5, Writing and Deploying an ERC-20 Token ERC-20 is the standard interface for fungible tokens on EVM chains. It defines a set of functions ( transfer , approve , transferFrom , balanceOf , etc.) that wallets and exchanges know how to interact with automatically. Create a new file MyToken.sol : // SPDX-License-Identifier: MIT pragma solidity ^0.8.20; /** * @title MyToken * @notice A minimal ERC-20 token deployed on AERE Network. * 1,000,000 tokens minted to the deployer on construction. */ contract MyToken { string public name; string public symbol; uint8 public constant decimals = 18; uint256 public totalSupply; mapping ( address => uint256 ) public balanceOf; mapping ( address => mapping ( address => uint256 )) public allowance; event Transfer ( address indexed from, address indexed to, uint256 value); event Approval ( address indexed owner, address indexed spender, uint256 value); constructor ( string memory _name, string memory _symbol) { name = _name; symbol = _symbol; uint256 initialSupply = 1_000_000 * 10 ** decimals; totalSupply = initialSupply; balanceOf[msg.sender] = initialSupply; emit Transfer( address (0), msg.sender, initialSupply); } function transfer( address to, uint256 value) external returns ( bool ) { require (balanceOf[msg.sender] >= value, "Insufficient balance" ); balanceOf[msg.sender] -= value; balanceOf[to] += value; emit Transfer(msg.sender, to, value); return true; } function approve( address spender, uint256 value) external returns ( bool ) { allowance[msg.sender][spender] = value; emit Approval(msg.sender, spender, value); return true; } function transferFrom( address from, address to, uint256 value) external returns ( bool ) { require (balanceOf[from] >= value, "Insufficient balance" ); require (allowance[from][msg.sender] >= value, "Allowance exceeded" ); allowance[from][msg.sender] -= value; balanceOf[from] -= value; balanceOf[to] += value; emit Transfer(from, to, value); return true; } } In Remix, compile MyToken.sol . In the Deploy panel you will see a constructor with two inputs, enter your token name (e.g. My Token ) and symbol (e.g. MTK ), then click Deploy and confirm in MetaMask. After one block, your token contract is live on AERE mainnet. Security note: This is a minimal implementation for learning. Production tokens should use a battle-tested library such as OpenZeppelin's ERC20.sol , which handles edge cases (overflow, approval race conditions) and has been extensively audited. Module 6, Verifying on the Block Explorer Verifying a contract means uploading the Solidity source code to the block explorer so that anyone can read exactly what the contract does. Verified contracts also become callable directly from the explorer's UI. Find your deployed contract After deploying, copy the contract address from Remix's "Deployed Contracts" section. Open explorer.aere.network and paste the address into the search bar. You will see the contract's transaction history and, under the "Contract" tab, the raw bytecode. Submit source for verification On the contract page, click the Contract tab, then Verify & Publish . Select: Compiler type → Solidity (Single file) , Compiler version → 0.8.20 , Open source license → MIT . Paste your full Solidity source into the editor. Make sure the pragma version matches exactly. If you deployed with constructor arguments (like the token name and symbol), the explorer will ask you to provide the ABI-encoded constructor arguments. Remix displays these in its transaction details, copy the hex string beginning after 0x . Click Verify and Publish . The explorer compiles the source server-side and checks that the resulting bytecode matches what was deployed. If it matches, a green checkmark appears on the contract page, and the ABI is published so anyone can call your functions directly from the browser. Verification is optional but strongly recommended. Unverified contracts are opaque to users and auditors, a verified contract signals that you have nothing to hide and makes your project far more trustworthy. Module recap Solidity contracts are compiled to EVM bytecode and run identically on every node. Remix is a browser IDE, no installation needed; connect via MetaMask to deploy to AERE. Always confirm MetaMask shows "Custom (2800) network" before deploying. State-changing functions cost gas; view and pure functions are free to call. ERC-20 is the standard fungible token interface, wallets and exchanges recognize it automatically. Verifying your contract on the explorer publishes the source and ABI for public inspection. ← Back to AERE Academy --- # AERE Network Fundamentals, AERE Academy URL: https://aere.network/course-fundamentals.html Fetched: 2026-09-15 AERE Network Fundamentals, AERE Academy ← Back to AERE Academy AERE Network Fundamentals Reality check, added 2026-08-19. This course teaches the design. On chain 2800 today: no staking yield is payable (the staking contracts hold no reward balance, so the 8% figure is a parameter, not an income); the governance contracts (AereGovLockV2, AereGovernorV2) are deployed but own no protocol contract yet, so a vote cannot change fees, validators or funds and is advisory; there is no on-chain vesting contract (team, investor and Foundation allocations sit in plain accounts); and an unmodified upstream Hyperledger Besu cannot follow chain 2800, the node software is the aere-node fork with its published patches (post-quantum precompiles since block 9,189,161, the base-fee floor, the header anchor). Nine Foundation-run validators, commit quorum 6 of 9, blocks every ~0.5 s. Beginner ~1 hour 5 modules Module 1, What is a Blockchain? A blockchain is a database that is maintained by many computers at the same time, none of which trust each other, yet all of which agree on the same history. That agreement is called consensus , and it is the core problem that blockchains solve. Traditional databases are controlled by a single operator (a bank, a company, a government). Changing a row requires trusting whoever runs the database. A blockchain replaces that trust with cryptographic proof and economic incentives: participants are rewarded for honest behavior and penalized for cheating. Blocks and chains Transactions are grouped into blocks . Each block contains a cryptographic hash of the block before it, forming a tamper-evident chain. Changing any historical transaction would invalidate every block that follows it, which an honest majority of the network would reject. This immutability is what lets developers build applications that self-execute (smart contracts) without needing to trust a third party to enforce the rules. Accounts and state On an EVM blockchain like AERE, every participant has an account : a 20-byte address derived from a private key. The chain stores the current state of every account (its balance, any stored contract code, internal storage). Every transaction updates that state. The result is a shared world-computer: programs deployed on the chain run deterministically on every node. Module 2, AERE as an EVM Layer 1 AERE Network is an independent Layer 1 blockchain, it has its own validators, its own transaction history, and its own native token (AERE). It is not a rollup or a sidechain of Ethereum. The "EVM" part means it is fully compatible with the Ethereum Virtual Machine: Solidity contracts, MetaMask, Ethers.js, Hardhat, and Foundry all work on AERE without modification. Why EVM compatibility matters: The entire Ethereum tooling ecosystem, compilers, wallets, explorers, audit tools, works out of the box on AERE. A developer who knows how to build on Ethereum can build on AERE in minutes, not months. Key parameters Parameter Value Chain name AERE Network Chain ID 2800 (hex: 0xAF0) Native token AERE (18 decimals) Consensus QBFT (Hyperledger Besu) Block time ~0.5 seconds (since block 2,137,652; measured mean ~0.55 s) HTTP RPC https://rpc.aere.network Block explorer https://explorer.aere.network The Chain ID is the number that prevents replay attacks between networks: a signed transaction on AERE cannot be replayed on Ethereum mainnet or any other chain because the Chain ID is baked into the signature. Always confirm chain ID 2800 is set correctly in your wallet and scripts. Module 3, QBFT Consensus and Instant Finality AERE uses QBFT (Quorum Byzantine Fault Tolerant) , a proof-of-authority consensus algorithm implemented in Hyperledger Besu. It is derived from the PBFT family of consensus algorithms, which have been studied since the 1990s and are known for strong safety guarantees. How QBFT works A set of known validator nodes takes turns proposing blocks (round-robin). When a proposer publishes a block, all other validators send a prepare vote. Once a validator sees a threshold of prepare votes (quorum = ceil(2n/3) where n is the validator count: 6 of 9 on chain 2800 today), it sends a commit vote. When a block collects enough commit votes, it is finalized. There is no forking, once a block is committed, it cannot be reverted. Instant finality vs. probabilistic finality On Proof-of-Work chains (Bitcoin, pre-merge Ethereum), transactions are considered "safe" only after several blocks build on top of them, because a longer competing chain could theoretically appear. This is probabilistic finality: you can never be 100% certain a transaction is permanent. QBFT provides instant finality . The moment a block is committed by the validator set, it is mathematically final. Your transaction is settled in ~1 second, with no waiting for confirmations. This is critical for payment applications, exchanges, and any system where finality latency matters. Byzantine fault tolerance QBFT tolerates up to ⌊(n-1)/3⌋ faulty or malicious validators. With 10 validators, for example, the network stays safe even if 3 validators are offline or actively misbehaving. The remaining honest majority will continue to produce and finalize blocks correctly. Module 4, The AERE Token AERE is the native currency of AERE Network. It plays three distinct roles: Gas fees Every transaction on the network consumes a small amount of AERE as a fee paid to validators. Gas fees on AERE are extremely low, fractions of a cent for a standard transfer, making micro-transactions and high-frequency dApp usage practical. Unlike networks with volatile gas prices, AERE's QBFT architecture keeps fees stable. Staking AERE holders can lock their tokens in the AereStaking contract to earn staking rewards. The designed base rate is 8% APY; no yield is payable on chain 2800 today (the staking contracts hold no reward balance). Staked tokens also confer voting power in the DAO governance system (covered in the Tokenomics course). Governance The AereGovernanceStaked contract lets stakers propose and vote on protocol changes, fee parameters, validator set updates, treasury spending, and smart contract upgrades. Governance power is proportional to your staked balance at the time a proposal's snapshot is taken. The total maximum supply is 2,800,000,000 AERE (2.8 billion). Tokens are not mined through energy expenditure; they are minted according to the allocation schedule defined at genesis and distributed via staking rewards from the Staking Reserve. This design keeps supply growth predictable and transparent. Module 5, Adding AERE Network to MetaMask MetaMask is the most widely used browser wallet for EVM chains. Adding AERE is a one-time setup that takes about 60 seconds. Method 1: One-click form Visit aere.network/addnetwork.html and click the button. MetaMask will display a confirmation dialog, approve it and AERE Network is ready to use. Method 2: Manual entry in MetaMask Open MetaMask and click the network selector at the top. Click Add network → Add a network manually . Fill in the fields exactly as shown below: Network name: AERE Network RPC URL: https://rpc.aere.network Chain ID: 2800 Currency symbol: AERE Block explorer: https://explorer.aere.network Click Save . AERE Network will appear in your network list. Switch to the AERE Network. Your AERE balance will appear once you have received tokens. Method 3: Programmatic (for dApp developers) If you are building a dApp, you can prompt users to add the network from within your UI: await window.ethereum.request({ method: 'wallet_addEthereumChain', params: [{ chainId: '0xAF0', // 2800 in hex chainName: 'AERE Network', rpcUrls: ['https://rpc.aere.network'], nativeCurrency: { name: 'AERE', symbol: 'AERE', decimals: 18 }, blockExplorerUrls: ['https://explorer.aere.network'], }] }); Module recap A blockchain is a shared, tamper-evident database maintained by consensus among many nodes. AERE is a fully EVM-compatible Layer 1, all Ethereum tooling works without modification. QBFT consensus delivers instant, irreversible finality in approximately half a second. AERE token is used for gas, staking rewards (an 8% APY design parameter, not payable today), and DAO governance votes. Maximum supply is 2.8 billion AERE; Chain ID is 2800. Add AERE to MetaMask via the one-click form at /addnetwork.html or by entering the parameters manually. ← Back to AERE Academy --- # AERE Tokenomics & Governance, AERE Academy URL: https://aere.network/course-tokenomics.html Fetched: 2026-09-15 AERE Tokenomics & Governance, AERE Academy ← Back to AERE Academy AERE Tokenomics & Governance Reality check, added 2026-08-19. This course teaches the design. On chain 2800 today: no staking yield is payable (the staking contracts hold no reward balance, so the 8% figure is a parameter, not an income); the governance contracts (AereGovLockV2, AereGovernorV2) are deployed but own no protocol contract yet, so a vote cannot change fees, validators or funds and is advisory; there is no on-chain vesting contract (team, investor and Foundation allocations sit in plain accounts); and an unmodified upstream Hyperledger Besu cannot follow chain 2800, the node software is the aere-node fork with its published patches (post-quantum precompiles since block 9,189,161, the base-fee floor, the header anchor). Nine Foundation-run validators, commit quorum 6 of 9, blocks every ~0.5 s. Intermediate ~1.5 hours 4 modules Module 1, The 2.8 Billion Supply The AERE token has a hard-capped maximum supply of 2,800,000,000 AERE (2.8 billion). This cap was set at genesis and is enforced by the protocol, no more AERE can ever be created beyond this amount. Why a hard cap? A fixed supply ceiling creates predictable monetary policy. Participants know that holding AERE will not be diluted beyond what the genesis schedule specifies. Compare this to networks with unlimited issuance, where stakers may earn yield that is immediately offset by perpetual inflation. AERE's model is closer to Bitcoin's fixed-supply approach applied to a PoA consensus chain. How tokens enter circulation Not all 2.8 billion tokens are liquid at genesis. Most are held in allocation wallets and released according to the schedule defined in the whitepaper and encoded in smart contract vesting logic. The six allocation categories are described in detail in the next module. The burn mechanism, and what it burns today Be precise about what is burned, because it is a common source of confusion. Aere does not burn gas fees or the EIP-1559 base fee as a protocol rule. The burn is applied to the validator coinbase reward : a splitter contract routes 37.5% of that reward, a Foundation-set rate capped at 50%, into a sealed vault with no withdrawal path. Because the burn is a share of validator reward, its size depends entirely on what validators earn. Today that is zero. Genesis declares no block reward, and the base fee is destroyed by EIP-1559 rather than paid to the proposer, so lifetime burned stands at 0.1374 AERE against 2.8 billion supply. Aere is not deflationary today. Supply can never increase, and the burn contracts are live and immutable, so the mechanism will destroy AERE in proportion to real fee flow once real fee flow exists. That is a demand question, not a contract question, and you should treat any claim of present-day deflation with suspicion, including one from us. You can verify the current total supply and circulating supply at any time by querying the block explorer or calling eth_getBalance on the known allocation wallet addresses. Everything on AERE is publicly auditable on-chain. Module 2, The Six Allocation Wallets The 2.8 billion AERE supply is split across six purpose-specific wallets. Each wallet has a defined mandate that constrains how those tokens can be used. Allocation Amount (AERE) % of Supply Purpose Staking Reserve 1,400,000,000 50% Staking rewards distributed to validators and delegators over the long term. Ecosystem Fund 560,000,000 20% Developer grants, dApp incentives, hackathons, integration bounties, ecosystem growth programs. Team 420,000,000 15% Core development team, subject to multi-year vesting with a cliff to align long-term incentives. Foundation 180,000,000 ~6.4% Operational expenses, legal, infrastructure, regulatory compliance, held in the timelocked AereTreasury contract. Airdrop 140,000,000 5% Community growth, early adopter rewards, promotional distributions, scheduled in tranches. Strategic Investor 100,000,000 ~3.6% Early institutional and strategic investors who provided capital and partnerships at network launch. Staking Reserve (50%) 1.4B Ecosystem (20%) 560M Team (15%) 420M Foundation (~6.4%) 180M Airdrop (5%) 140M Strategic Investor (~3.6%) 100M Vesting and transparency The Team and Strategic Investor allocations are subject to vesting schedules enforced by the AereTreasury contract ( 0x687933AE7ea4927867AC227F1b60d476003e6119 ). Tokens cannot be transferred until vesting conditions are met. The Foundation's operational funds pass through a timelock, spending requires an on-chain transaction that is visible to the public before it executes. This prevents unilateral decisions and gives the community time to react. The Ecosystem Fund is managed by DAO governance. Any spending above a threshold requires a proposal and vote (see Module 4). Grants and bounty payouts below the threshold can be approved by the Foundation-controlled account, but all transactions are publicly visible on the explorer. Module 3, Staking Rewards No staking yield is payable today. The live fixed-term staking contract is AereLockedStaking ( 0x21108c28A849b05aE6b7a3a5bc435C9Bc897E7Ad ). Its tier rates are real on-chain constants, but the reward reserve that pays them holds a zero balance, so a lock made now returns principal only. Check the reserve yourself on the explorer before you lock anything. This module explains how the design is meant to work, not a return you can collect at present. The single largest allocation, the Staking Reserve, exists to pay staking rewards over a very long horizon without requiring fee burning to cover rewards immediately. Reserve tokens have not been moved into the staking reward reserve yet, which is why nothing is payable. How APY is meant to work A tier rate applies to your staked balance, not your total balance. If you hold 10,000 AERE and lock 5,000 AERE, the rate applies to the 5,000 only. The reward is computed from the tier constant over the lock term and paid in AERE on maturity, out of the reward reserve. While that reserve is empty, withdraw() at maturity reverts and your principal stays recoverable through earlyExit() , which forfeits the reward. Lock-up tiers AereLockedStaking has four fixed lock terms. The rates below are the on-chain constants, and none of them is payable while the reward reserve is empty: 30-day lock , 10% APY on-chain rate, not payable today. 90-day lock , 15% APY on-chain rate, not payable today. 180-day lock , 22% APY on-chain rate, not payable today. 365-day lock , 30% APY on-chain rate, the highest tier, not payable today. There is no flexible or no-lock tier on this contract, and there is no separate base rate. The minimum stake is 1 AERE, there is no unbonding delay, and there is no slashing. Lock-up tiers are designed to reduce circulating supply volatility. Tokens committed to a long lock cannot be sold during market downturns, which stabilizes price and incentivizes genuine long-term holders over short-term speculators. Compounding The pattern below is a generic staking-loop illustration and it does not match the live contract. AereLockedStaking exposes stake(tier) , withdraw(lockId) , earlyExit(lockId) and rewardOf(user, lockId) , and it has no pendingRewards() or claimRewards() . Compounding also has nothing to compound while the reward reserve is empty. Read it as teaching material, not as a script to run against Chain 2800. The general shape of compounding is: claim what has accrued, then stake it again. This can be automated with a small script or keeper bot watching the staking contract events. // Compound rewards with ethers.js on AERE (chain ID 2800) const provider = new ethers.JsonRpcProvider('https://rpc.aere.network'); const wallet = new ethers.Wallet(privateKey, provider); const staking = new ethers.Contract(STAKING_ADDRESS, STAKING_ABI, wallet); async function compound() { const rewards = await staking.pendingRewards(wallet.address); if (rewards > ethers.parseEther('1')) { await staking.claimRewards(); await staking.stake(rewards); console.log(`Compounded ${ethers.formatEther(rewards)} AERE`); } } Module 4, Stake-Weighted DAO Governance AERE Network is governed by its stakers. The AereGovernanceStaked contract ( 0x8D77C888e439C4fADb2e23F1567a0A1965F80bCb ) implements a proposal-and-vote system where voting power is determined by how much AERE you have staked at the time a proposal's snapshot is taken. Why stake-weighted governance? Governance systems need Sybil resistance, protection against one entity creating many cheap identities to accumulate disproportionate voting power. Token-weighted voting provides this: casting more votes requires holding and staking more AERE, which is an economic commitment. Participants who have more "skin in the game" have more influence over decisions that affect the network they depend on. The proposal lifecycle Proposal creation: Any staker with a balance above the proposal threshold can call propose(targets, values, calldatas, description) . The targets, values, and calldatas encode the exact on-chain actions the proposal will execute if it passes, there is no off-chain interpretation step. Voting delay: After creation, there is a delay period before voting opens. This gives token holders time to read the proposal and move tokens into staking positions if they wish to vote. Voting period: During the voting window, stakers call castVote(proposalId, support) where support is 0 (against), 1 (for), or 2 (abstain). Each account's vote weight equals its staked AERE balance at the snapshot block. Quorum check: A proposal passes only if a minimum quorum of total staked AERE participated in voting AND the for-votes exceed the against-votes. Quorum prevents low-participation governance attacks. Timelock queue: Passing proposals enter a timelock queue. The community can see the queued action and, in extreme cases, coordinate to veto it before execution. Execution: After the timelock expires, any account can call execute() to carry out the on-chain actions atomically. No manual admin step is required. What governance can change Protocol fee parameters (gas base fee adjustments, burn ratios). Staking APY rates and lock-up tier structure. Validator set management (adding or removing validators). Ecosystem Fund spending above the Foundation-approval threshold. Smart contract upgrades for governance-controlled contracts. Treasury investments and strategic allocations. Participating as a small holder You do not need a large stake to participate meaningfully. Even small stakers can vote to signal preferences, and delegating your vote to a trusted community representative means your AERE contributes to quorum even when you are not actively watching proposals. // Delegate your governance votes to another address (or yourself) const gov = new ethers.Contract(GOV_ADDRESS, GOV_ABI, wallet); await gov.delegate(delegateeAddress); // Cast a vote on an active proposal // support: 0 = Against, 1 = For, 2 = Abstain await gov.castVote(proposalId, 1); Governance participation is voluntary but important. A DAO where only a small fraction of holders vote is vulnerable to coordinated minority attacks. Staking AERE and regularly reviewing proposals is how you protect your investment and the ecosystem you build on. Module recap Maximum supply is 2,800,000,000 AERE, hard-capped at genesis, enforced by protocol. Six allocation wallets: Staking Reserve (1.4B), Ecosystem (560M), Team (420M), Foundation (180M), Airdrop (140M), Strategic Investor (100M). Staking Reserve is intended to fund staking rewards over the long term. It has not been moved into the staking reward reserve yet. AereLockedStaking carries four on-chain tier rates, 30d/10%, 90d/15%, 180d/22% and 365d/30%. The reward reserve is unfunded, so none of them is payable today and a lock returns principal only. Governance is stake-weighted: voting power = staked AERE balance at proposal snapshot. Proposals execute on-chain after passing quorum, majority vote, and a timelock delay. The burn takes 37.5% of the validator coinbase reward, not gas fees and not the base fee. It is live and immutable, and it has burned 0.1374 AERE to date because validator reward is currently zero. ← Back to AERE Academy --- # Run an AERE Validator, AERE Academy URL: https://aere.network/course-validator.html Fetched: 2026-09-15 Run an AERE Validator, AERE Academy ← Back to AERE Academy Run an AERE Validator Reality check, added 2026-08-19. This course teaches the design. On chain 2800 today: no staking yield is payable (the staking contracts hold no reward balance, so the 8% figure is a parameter, not an income); the governance contracts (AereGovLockV2, AereGovernorV2) are deployed but own no protocol contract yet, so a vote cannot change fees, validators or funds and is advisory; there is no on-chain vesting contract (team, investor and Foundation allocations sit in plain accounts); and an unmodified upstream Hyperledger Besu cannot follow chain 2800, the node software is the aere-node fork with its published patches (post-quantum precompiles since block 9,189,161, the base-fee floor, the header anchor). Nine Foundation-run validators, commit quorum 6 of 9, blocks every ~0.5 s. Intermediate ~2 hours 5 modules Module 1, What Validators Do in QBFT AERE Network uses QBFT (Quorum Byzantine Fault Tolerant) consensus. Unlike Proof-of-Work where anyone who solves a hash puzzle proposes a block, QBFT relies on a known, permissioned set of validators . Understanding what validators actually do helps you run one responsibly. Proposing blocks Validators take turns proposing new blocks in a round-robin rotation. When it is your turn, your node collects pending transactions from the mempool, orders them, and broadcasts a proposed block to all other validators. The proposer is deterministic, every node in the network can independently calculate whose turn it is. Voting on blocks When a validator receives a proposed block, it verifies that the block is structurally valid (correct parent hash, valid signatures on transactions, gas limits respected). If valid, it broadcasts a prepare message. Once a validator sees enough prepare messages from its peers (a quorum), it broadcasts a commit message. Once a block accumulates enough commit messages, it is finalized and cannot be changed. Liveness and safety QBFT guarantees safety as long as no more than one-third of validators are Byzantine (dishonest or faulty). It guarantees liveness (the chain keeps making progress) as long as more than two-thirds of validators are online and responsive. If your validator goes offline, you reduce the safety margin and slow the network, validator operators have a responsibility to maintain high uptime. Validator identity Each validator is identified by its node key, a secp256k1 key pair where the public key (and its derived address) is the validator's identity on-chain. The active validator set is maintained by Besu's QBFT protocol itself and can be read at any time with the qbft_getValidatorsByBlockNumber RPC method. There is no stake, no bond, and no deposit that makes an address a validator: the set changes only when the existing validators vote a candidate in or out. There are 10 Foundation validators today (f=3, quorum 7-of-10), with a public path to 21. Module 2, Hardware Requirements AERE produces a block every 0.5 seconds with deterministic finality. This is less compute-intensive than Proof-of-Work, but more demanding in terms of network latency and storage I/O than a light client. Component Minimum Recommended CPU 4 cores / 2.5 GHz 8 cores / 3.0 GHz+ RAM 16 GB 32 GB Storage 500 GB SSD 1 TB NVMe SSD Network 25 Mbps symmetric 100 Mbps symmetric, low latency OS Ubuntu 22.04 LTS Ubuntu 22.04 LTS (server, no GUI) Java OpenJDK 21 OpenJDK 21 Storage grows over time as the chain accumulates history. The NVMe recommendation is important: Hyperledger Besu performs many random small reads and writes per block. SATA SSDs work but will bottleneck at sustained load. Spinning disks will not keep up. Validators are expected to maintain >99% uptime. Renting a dedicated server from a reliable provider and running a monitoring stack is standard practice. Do not run a validator on a laptop or home internet connection unless you have redundant failover. Module 3, Running a Hyperledger Besu Node AERE Network runs on Hyperledger Besu, an enterprise-grade Java Ethereum client maintained by the Hyperledger Foundation. The following steps assume Ubuntu 22.04. Install Java 21 sudo apt update && sudo apt install -y openjdk-21-jre-headless java -version # should print openjdk 21... Download Besu # Check the latest release at https://github.com/hyperledger/besu/releases VERSION=24.12.0 wget https://github.com/hyperledger/besu/releases/download/${VERSION}/besu-${VERSION}.tar.gz tar -xzf besu-${VERSION}.tar.gz sudo mv besu-${VERSION} /opt/besu sudo ln -s /opt/besu/bin/besu /usr/local/bin/besu besu --version Generate a node key # Create a dedicated data directory mkdir -p /opt/aere-node/data # Besu generates a node key automatically on first start, # but you can generate one explicitly and back it up: besu --data-path=/opt/aere-node/data operator generate-blockchain-config \ --config-file=genesis.json \ --to=output/ \ --private-key-file-name=key # Your node key will be at /opt/aere-node/data/key # BACK THIS UP. Losing it means losing your validator identity. Get the AERE genesis file and bootnode list The chain-2800 genesis file and the current bootnode list are issued to approved validator operators, they are not offered as a public download. Note that the benchmark genesis in the public research repository is a different chain (chainId 28777) and will not sync you to 2800, so do not substitute it. Request the mainnet set through contact , then place the files as below. cd /opt/aere-node # genesis.json -> /opt/aere-node/genesis.json # static-nodes.json -> /opt/aere-node/data/static-nodes.json cp static-nodes.json data/ Start the node besu \ --data-path=/opt/aere-node/data \ --genesis-file=/opt/aere-node/genesis.json \ --network-id=2800 \ --p2p-port=30303 \ --rpc-http-enabled \ --rpc-http-host=127.0.0.1 \ --rpc-http-port=8545 \ --rpc-ws-enabled \ --rpc-ws-host=127.0.0.1 \ --rpc-ws-port=8546 \ --host-allowlist="localhost,127.0.0.1" \ --metrics-enabled \ --metrics-host=127.0.0.1 \ --metrics-port=9545 \ --logging=INFO Create a systemd service Running Besu as a systemd service ensures it restarts automatically on failure or reboot: # /etc/systemd/system/aere-node.service [Unit] Description=AERE Network Validator Node After=network-online.target Wants=network-online.target [Service] User=aere ExecStart=/usr/local/bin/besu \ --data-path=/opt/aere-node/data \ --genesis-file=/opt/aere-node/genesis.json \ --network-id=2800 \ --p2p-port=30303 \ --rpc-http-enabled --rpc-http-host=127.0.0.1 \ --rpc-ws-enabled --rpc-ws-host=127.0.0.1 \ --metrics-enabled --metrics-host=127.0.0.1 \ --logging=INFO Restart=on-failure RestartSec=5 [Install] WantedBy=multi-user.target sudo systemctl daemon-reload sudo systemctl enable aere-node sudo systemctl start aere-node sudo journalctl -fu aere-node # follow logs Once your node is synced, check peering: curl -s -X POST http://127.0.0.1:8545 \ -H 'Content-Type: application/json' \ -d '{"jsonrpc":"2.0","method":"net_peerCount","id":1}' # {"jsonrpc":"2.0","id":1,"result":"0x5"} ← 5 peers, good Module 4, Becoming a Validator, and Accountability AERE does not use proof-of-stake. There is no stake-to-validate , no minimum bond, no 32-AERE deposit, and no delegation. Validators are admitted by governance : the existing validator set votes a candidate in, and later can vote a misbehaving one out. This is standard Hyperledger Besu QBFT behavior. How a candidate is admitted You stand up a fully synced Besu node (Modules 1 to 3) and share your validator address with the Foundation through the onboarding process. Each existing validator calls qbft_proposeValidatorVote with your address and true . This is coordinated by the Foundation, not a token vote. Once a majority of the current validators have proposed your address, QBFT adds you to the active set at the next epoch block. Your node begins proposing and voting on blocks immediately. No AERE changes hands. Admission is a permissioning decision, not a purchase. The full, up-to-date onboarding guide (candidate requirements, how to submit your address, the live set of 9 validators today (7 until 2026-08-09) and the public path to 21) lives at aere.network/run-a-validator . What validators earn Validators are not paid a staking APY. They earn the per-block fee remainder : after each block's coinbase split is routed by the AereCoinbaseSplitter ( 0xb4b0eCe9011613A5b84248a9B42a0f309E6F01Ec ) and AereCoinbaseSplitterV2 ( 0x8C1A48eFA57b66fEE743A00E3899c29ad3Fd27b4 ), the remaining fees accrue to the block's proposer. Reward is therefore tied to actually proposing blocks and staying online, not to any locked balance. Accountability, no on-chain slashing AERE has no slashing contract . Nothing is burned, and there is no equivocation penalty or unbonding period, because no stake is ever posted. A validator that misbehaves or stays offline is instead removed by governance : the remaining validators call qbft_proposeValidatorVote with the offender's address and false , and once a majority agrees the address is dropped from the active set. Accountability is social and operational, backed by the ability to remove, not financial. Do not run two nodes with the same key simultaneously. QBFT expects exactly one signer per validator address. Two nodes signing for the same address in the same round will produce conflicting messages and can get your node peered off and, if it disrupts consensus, voted out of the set. If you are switching machines, shut the old node down completely before starting the new one. Staking on AERE is a separate product for holders and does not make you a validator. The sAERE ERC-4626 receipt ( 0xA2125bE9C6fd4196D9F94757Df18B3a2A5e650b0 ) earns a variable staker-yield from the AereSink split, and AereLockedStaking ( 0x21108c28A849b05aE6b7a3a5bc435C9Bc897E7Ad ) offers fixed-term locks (30d/10%, 90d/15%, 180d/22%, 365d/30% APY). Those lock rates are real on-chain constants, but the AereLockedStaking reward reserve is currently unfunded, so no yield can be paid today and a lock returns principal only. Both are open to any holder. Neither grants validation rights or block-proposal duties. Module 5, Monitoring Your Validator A validator running without monitoring is a liability. At a minimum, you need to know immediately if your node stops producing blocks, falls behind in sync, or loses peers. Besu metrics (Prometheus) Besu exposes a Prometheus metrics endpoint at port 9545 when --metrics-enabled is set. Key metrics to watch: besu_blockchain_height , should increase ~1 per second. besu_peers_connected_total , if this drops to 0, your node is isolated. besu_synchronizer_in_sync , 1 means fully synced, 0 means catching up. besu_transaction_pool_transactions , size of pending transaction pool. Grafana + Prometheus setup (quick start) # prometheus.yml, add a scrape job for Besu scrape_configs: - job_name: aere_validator static_configs: - targets: ['127.0.0.1:9545'] scrape_interval: 10s Run Prometheus and Grafana via Docker Compose alongside your Besu node. The Besu community maintains a pre-built Grafana dashboard (import dashboard ID 10273 from grafana.com) that works with QBFT nodes and shows block production, peer count, and JVM health in one view. On-chain check You can verify your validator is actively signing blocks by querying the explorer. Search your validator address at explorer.aere.network , the block production history shows whether your node is participating in consensus. Alerting Set up an alert rule in Grafana (or Prometheus Alertmanager) that fires if besu_blockchain_height does not increase for more than 30 seconds. Route alerts to a Telegram bot, PagerDuty, or your team's preferred channel. Slow response to a node outage reduces your fee earnings, weakens network liveness, and, if sustained, is grounds for the validator set to vote your node out. Module recap QBFT validators propose and vote on blocks in round-robin order; the chain finalizes each block in ~1 second. Minimum hardware: 4 cores, 16 GB RAM, 500 GB NVMe SSD, Ubuntu 22.04. The node software is the aere-node fork of Hyperledger Besu (upstream Besu alone cannot follow chain 2800; see git.aere.network/aere-network/aere-node, RUN-A-NODE.md); run it as a systemd service for automatic restarts. Back up your node key ( /opt/aere-node/data/key ), it is your validator's permanent identity. Validators are admitted by a governance vote of the existing set ( qbft_proposeValidatorVote true), not by staking. There is no stake-to-validate and no slashing; accountability is removal by the same vote (false). Validators earn the per-block fee remainder via the coinbase splitter, not a staking APY. Monitor with Prometheus + Grafana and alert on block height stalls and peer loss. Do not run two nodes with the same key simultaneously, one signer per validator address. ← Back to AERE Academy --- # AERE DAO, Governance URL: https://aere.network/dao.html Fetched: 2026-09-15 AERE DAO, Governance AERE DAO, Governance Propose, debate, vote against the legacy AereGovernanceStaked contract. Read the note below before you read the parameters: this contract is superseded and its vote is advisory. This console does not control the protocol. It talks to AereGovernanceStaked, an early stake-weighted voting contract that has been superseded. Measured on chain 2800 on 2026-08-01: it derives voting weight from a deprecated staking contract whose totalStaked() is 0, so its quorumRequired() is also 0, and its only execution path calls back into itself, so a passed proposal cannot act on any other contract. No protocol parameter, treasury balance or contract upgrade is decided here today. The canonical stack (AereGovLockV2, AereGovernorV2, and a 48-hour Timelock) is deployed and measured live, but protocol ownership has not been handed to it yet, so governance on Aere Network is still operational rather than on-chain. The governance page shows the measured numbers for both. DAO parameters, as measured on the contract 2026-08-01 AereGovernanceStaked (superseded) 0x8D77C888…65F80bCb Voting power Staked AERE, read from a deprecated staking contract (total staked measured 0) Proposal threshold 100,000 AERE Voting window 7 days (604,800 s) Quorum 20% of total staked, which is 0 AERE today Pass rule Simple majority, yes > no. There is no supermajority parameter on this contract Execution timelock 48 hours (172,800 s) after pass Total proposals , Your voting power , Connect Wallet Refresh Create a proposal Title (one line) Description (rationale, technical detail, expected impact) Execution data (optional, hex, for on-chain action) Submit proposal Requires ≥ 100,000 staked AERE. Stake AERE → All proposals Loading… --- # AERE Network, dApps Directory URL: https://aere.network/dapps.html Fetched: 2026-09-15 AERE Network, dApps Directory AERE dApps Home Explorer All AERE dApps Every user-facing application running on AERE Network. All connected to Chain ID 2800. Wallet & Onboarding Add Network One-click MetaMask add for AERE L1 (Chain ID 2800). Live Faucet Not funded: the contract holds a zero balance and cannot pay out. There is currently no public way to obtain AERE. Unfunded Staking & Governance Staking Fixed-term locks on AereLockedStaking. The tier APYs are real on-chain constants, but the reward reserve is unfunded, so no yield can be paid today. Staking earns yield, it does not make you a validator. Unfunded Locked Staking Lock AERE 30/90/180/365 days. APYs are real on-chain constants, but the reward reserve is unfunded, so no yield can be paid today. Unfunded DAO Deployed and read-callable. It controls no protocol parameter today. Superseded contract, vote is advisory. Preview Not seeded Governance Dashboard Live DAO proposals and on-chain voting state. New DeFi Swap Deployed, no seeded pools yet. V2-style AMM · 0.3% LP fee · WAERE-paired pools. Preview Not seeded Bridge Bridge routes: the legacy 1-of-1 federated bridge was torn down; no intent route is live yet. Not live Staking & Rewards Staking Rewards sAERE liquid staking, fixed-term locks, and QBFT validator yield. No mining, no hashpower. Live Reward Calculator Project AERE reserve-distribution and staking rewards over time. Live NFT & Identity NFT Marketplace ERC-721 mint + on-chain marketplace · 2.5% protocol fee · royalty-aware. Live Identity (DID) Self-sovereign identity with revocable attestor claims. New Tools & Info My Dashboard Multi-asset portfolio · staking positions · KYC status · recent transactions in one place. New Tokens & NFTs Browse all ERC-20 + ERC-721 contracts deployed on AERE · address lookup. New Economy Live token economy · genesis wallets · staking · supply bar. New Validators Live QBFT validator set, addresses and count. Live Network Status Live health of all AERE services. Live Grants AERE ecosystem grants programme. Live Explorer & Tools Block Explorer Live blocks, transactions, addresses · every deployed contract inspectable. Live API REST + WebSocket access to indexed data (api.aere.network). Live --- # AERE Dashboard, Multi-asset portfolio + recent activity URL: https://aere.network/dashboard.html Fetched: 2026-09-15 AERE Dashboard, Multi-asset portfolio + recent activity My Dashboard Multi-asset balance, staking positions, name registration, and recent activity for any AERE wallet. Load Connect Wallet Resolved address … Last activity … Balances AERE (native) … Spendable for gas + transfers WAERE … Wrapped, ERC-20 for DeFi Total locked … In AereStaking Staking positions … KYC & on-chain claims kyc-tier-1 (KYC partner attestor) … Claims are verifiable on-chain via AereIdentity. A KYC partner backend writes these once a user clears KYC at the BaaS provider. Coming Q3 2026. Recent transactions Block Direction Counterparty Value Tx Load an address to view transactions. --- # Blockchain Data API | Aere Network URL: https://aere.network/data-api.html Fetched: 2026-09-15 Blockchain Data API | Aere Network Aere Network Aere Cloud Docs Status Aere Cloud · indexed chain data Chain data, parsed for you. Live Transfers PQ anchors Webhooks Endpoint cloud.aere.network/v1/data Auth your API key Chain 2800 Skip running your own indexer. Read the validator set, the chain head, transfer history for any address, and the post-quantum anchor certificates that only this chain carries: all keyed, all reproducible against the public RPC. Endpoints /data/head : chain head with timestamp and base fee. /data/validators : the live QBFT validator set, read from consensus. /data/anchors : post-quantum anchor certificates, seal count and digest parsed per block, straight from the chain’s own extraData and verifiable against public RPC. /data/transfers?address= : token transfers from genesis, native transfers from launch, with both boundaries declared in the response so a partial answer never looks complete. Post-quantum anchors, ready to read curl -s "https://cloud.aere.network/v1/data/anchors?limit=1" \\ -H "x-api-key: ak2800.." → { "anchors": [ { "height": …, "falconSeals": 9, "certificateDigest": "0x…" } ], … } Push, not just pull Register a webhook and the chain pushes to your servers: every new post-quantum anchor, activity on a watched address, your own billing events: each delivery signed with HMAC so you can prove it came from us. The SDK ships a verifyWebhook helper so you never hand-roll that check. Get an API key Read the docs Part of Aere Cloud . Live status you compute in your own browser: /cloud-status.html . © 2026 Aere Network · chain 2800 · Aere Cloud --- # AERE Vote Delegation, Governance V2 URL: https://aere.network/delegate.html Fetched: 2026-09-15 AERE Vote Delegation, Governance V2 AERE Vote Delegation Home DAO Explorer Delegate Voting Power Not wired yet. The V2 governance contracts (AereGovLockV2, AereGovernorV2, see the governance page) are deployed on chain 2800 but own nothing yet; this page still targets the superseded AereGovernanceStaked, so its buttons stay disabled until it is rewired to V2. Per whitepaper §4: AereGovernanceStaked uses staked-token voting power. This page will be activated once the delegation contract is deployed. Governance V2 Deployed, owns nothing yet (see governance page) Quorum 10% of supply Supermajority 66% of decisive votes Voting period 7 days Execution delay 2 days timelock Your AERE balance , Currently delegated to , Voting power held , Delegate to (address) Self-delegate Connect Wallet Delegate Why delegation? Like Compound and most modern DAOs, voting power doesn't accrue from holding tokens alone, it accrues from delegation . This forces every voter to make an explicit choice and keeps governance attacker-resistant. Self-delegate , vote with your own AERE balance. Delegate to a representative , pass voting power to a trusted active participant. Switch any time , re-delegate updates atomically. No lockup. --- # Developer Hub, AERE Network URL: https://aere.network/developers.html Fetched: 2026-09-15 Developer Hub, AERE Network Developer Hub AERE is a live EVM Layer 1. If you can deploy Solidity to Ethereum, you can deploy to AERE, same tools, same workflow, faster blocks, lower fees. Everything you need to go from idea to mainnet is below. Chain ID 2800 RPC https://rpc.aere.network WebSocket wss://wss.aere.network Native token AERE EVM ruleset Pectra + Fusaka Consensus QBFT · 0.5s blocks EVM ruleset: AERE runs Pectra + Fusaka (both activated 2026-05-31), full functional parity with Ethereum mainnet's current EVM specification. Deploy any Solidity / Vyper code that runs on Ethereum, plus use native EIP-7702 (EOA → smart-account delegation), EIP-2537 (BLS12-381 precompiles), EIP-2935 (historical block hashes), EIP-1153 (transient storage), EIP-5656 (MCOPY), EIP-6780 (SELFDESTRUCT change), and RIP-7951 secp256r1 precompile at 0x100 for native Face ID / Touch ID / Windows Hello / YubiKey signature verification, natively. Gasless UX out of the box: AERE ships a 5-contract paymaster stack (deployed 2026-05-31). Users can transact without holding AERE, pay gas in any whitelisted ERC-20 ( AereTokenPaymaster ), get a daily free-tx quota by staking AERE ( AereStakeQuotaPaymaster , stake-for-free-tx UX on EVM), or get sponsored as a first-time user ( AereOnboardingPaymaster ). dApps deploy their own paymaster via the permissionless AereAppPaymasterFactory , one call, sponsor your own users. Cross-chain messaging: AereMessenger is a Hyperlane Mailbox-compatible cross-chain message bus (ECDSA-multisig Interchain Security Module). Apps call dispatch(destDomain, recipient, body) to send arbitrary payloads to any registered chain. AereIGP handles outbound gas fees. Built to be drop-in compatible with the public Hyperlane validator network once AERE is added to the Hyperlane registry, same contracts, same signature scheme, same Warp Route token-bridge pattern. For typed token bridging, deploy an AereWarpRoute per asset (collateral on the source chain, synthetic on AERE). Intent-based cross-chain UX, not yet usable, and the V1 addresses are deprecated. The design is an Across-v3-compatible SpokePool where a user signs an intent ("I want X on Aere Network, charge me Y from any chain") and a solver delivers, plus an ERC-7683 IOriginSettler so UniswapX, Across, CoW Protocol, 1inch Fusion and any other intent aggregator can route orders through one uniform interface, with permissionless solver participation. What is actually on chain, measured 2026-08-01: the V1 pair AereSpokePool 0xCAB1DBA5… and AereERC7683 0x67Fb9830… is marked deprecated and flawed in our own registry, because the settlement path could release locked principal without properly verifying the delivered output leg. Do not integrate against them. Both hold a zero balance. The corrected pair, AereSpokePoolV2Corrected 0xbEF9BF0D… and AereERC7683V2Corrected 0x8eC4e7F0… , is deployed and deliberately inert: no remote spoke is enrolled, so no intent route is open on either version. Build against V2 when the route opens, and never against V1. Pyth-compatible pull oracle: AerePyth implements Pyth Network's IPyth interface, apps written against the canonical Pyth SDK work unchanged on AERE. Publisher-signed pull updates: callers include a recent attestation as calldata; the contract verifies threshold signatures and serves the price within the same transaction. AereOracleAdapter exposes a unified quote(symbol) interface that routes Pyth → legacy AereOracle fallback, so existing dApps keep one address and one signature while the underlying source migrates. When AERE is added to the public Pyth network, the same contracts accept Guardian-set signatures without redeploy. Verifiable randomness (drand): AereRandomnessBeacon is a permissionless drand beacon consuming the Quicknet chain (3-second period, threshold-BLS-signed by the League of Entropy: Cloudflare, EPFL, Protocol Labs, U.S. Naval Research Lab, and ~15 other independent organisations). Any dApp that needs randomness, lotteries, NFT trait reveals, fair-launch token sales, on-chain games, randomized airdrops, fetches the canonical drand signature for any round (free at api.drand.sh) and submits it via submitRound(round, signature) . Consumers pay their own gas. AereDrandConsumer is a reference contract showing the integration pattern. Zero Foundation infrastructure, fully permissionless. Validator-reward burn (live, currently burning ~0 because validator reward is 0): AereCoinbaseSplitter atomically routes validator coinbase rewards: 37.5% to AereFeeBurnVault (permanent destruction, no withdraw, no admin), 62.5% back to the validator. This burned share is a Foundation-set cut of validator block rewards, currently 37.5% and hard-capped at 50%, routed to a sealed vault whose destination can never change; it is now measurable in real time via splitter.totalBurned() and the vault's on-chain balance. Each validator runs a small forwarder daemon that sweeps coinbase into the splitter periodically. As gas volume grows (consumer apps, dApps, paymasters, intent bridging), the burn would steadily remove AERE from a fixed, no-emission supply. Until validator coinbase revenue is non-zero, that reduction stays at today’s measured 0.1374 AERE, and Aere is not deflationary today. Developers get paid: AereFeeMonetizationV2 pays you AERE for every transaction that touches your registered contract. Call register(contractAddr, payoutAddr) , receive an ERC-721 NFT representing your fee stream, and earn 20% of all gas fees users pay to your contract. The NFT is transferable, sell your fee stream on AereNFTMarketplace, fractionalise it, collateralise it. On AERE, developers get paid for the work their code does, directly from the gas their contracts generate. Plus 5% of every gas fee goes to the AERE Foundation treasury automatically. No grants application, no token launch, no user surcharge. Touch ID / Face ID wallets: AERE chain 2800 has native passkey wallet support via the Fusaka RIP-7951 secp256r1 precompile. AerePasskeyAccountFactory deploys CREATE2 smart accounts whose only signer is a WebAuthn passkey (Touch ID, Face ID, Windows Hello, YubiKey, EU Digital Identity Wallet). On-chain WebAuthn verification costs ~6,900 gas per signature (vs ~250k gas for pure-Solidity P-256 verifiers). End-to-end test verified at block 2,157,502. Try at wallet.aere.network → Native zk-proof verification: AERE chain 2800 deploys the canonical SP1VerifierGateway (Succinct Labs v6.x Groth16 + Plonk) and RiscZeroVerifierRouter (RISC Zero zkVM). Verify any SP1 or RISC Zero proof in ~250-300k gas on real BN254 precompiles. Wrap with AereProofRegistry for permissionless program registration + permanent on-chain attestation. Future SP1 v7+ / RISC Zero v2+ versions plug in via addRoute with zero dApp migration. Live proof feed → MEV-resistant batch DEX: AereSettlement is a batch-auction settlement contract, users sign EIP-712 orders off-chain (no gas), an authorised solver collects open orders, finds a uniform clearing price per token pair, and submits the batch atomically. The entire batch executes in one transaction , so no one can sandwich it: a single uniform price applies to every order in the batch. Coincidence-of-wants matching between orders pays zero AMM fee. AereVaultRelayer proxies token allowances; AereSolverRegistry manages the solver set. Phase 2 adds permissionless bonded solver entry. AERE mainnet is live. The genesis was re-executed on 2026-05-07 establishing a 2.8 billion AERE supply. System contracts, including the staking module, governance DAO, NFT registry, oracle, and identity attestation system, are deployed and operational. You are building on a running chain, not a testnet. Learn → Build → Launch 1 Step one Learn the chain Read the documentation to understand the network architecture, system contracts, and development environment setup. Add AERE to MetaMask using Chain ID 2800 and RPC https://rpc.aere.network . A new address gets its first AERE from the faucet : 0.05 AERE per address per 24 hours, gas paid by the faucet service after a short proof of work in the browser (funded 2026-09-02 with a small operational amount; the live balance is on the faucet page). There is no public sale and no exchange listing. 2 Step two Build your project Deploy contracts using Hardhat or Foundry pointed at the AERE RPC. Use the AERE SDK for front-end integration or chain-specific helpers. Consult the RPC & API reference for the JSON-RPC method list, indexer API endpoints, and WebSocket event subscriptions. Read the state window section before you write anything that reads state at a historical block: the public endpoints keep world state for 512 blocks, and eth_getTransactionCount answers 0x0 beyond that instead of raising an error. Verify deployed contracts on the block explorer . 3 Step three Launch and grow Deploy to mainnet. Apply for a developer grant if your project contributes to the ecosystem, no equity, no token claw-backs. The AERE source is open on git.aere.network/aere-network (aere-contracts, sdk-js, aere-docs, aere-research, aere-node), publish your own source to build credibility with the community. The Foundation is available via the repository issue tracker for integration support. Resources 📖 Documentation Network architecture, system contract reference, deployment guides, and tutorials. ☁ Aere Cloud Keyed RPC endpoints, managed nodes and the live post-quantum verification API, billed monthly in AERE by an on-chain subscription contract that never custodies funds. ⚡ RPC & API Reference Full JSON-RPC method list, indexer REST API, WebSocket subscriptions, the 512-block state window and the one call that returns zero instead of an error. 🛠 AERE SDK JavaScript / TypeScript SDK for connecting to AERE, reading chain state, and signing transactions. 🚰 Faucet 0.05 AERE per address per 24 hours, gas paid by the faucet service after a short browser proof of work. Funded 2026-09-02; the page shows the live balance and says so if it runs dry. 🧪 Testnet Chain 28001: the same node software as mainnet with hybrid post-quantum consensus (a Falcon-512 checkpoint under every 128th block (every 32nd block until block 17,225,968, on 2026-09-05) hash) and its enforcement switched on, 10 tAERE per address per 24 hours from the testnet faucet, no real value. Live since 2026-09-02. 💸 x402 on the testnet An x402 v2 facilitator for chain 28001 ( GET /supported , POST /verify , POST /settle ) settling the "exact" scheme through EIP-3009 on a test dollar ( tUSD , free faucet, no value). A real payment is run through it every 6 hours and the result is public. Mainnet needs a real EIP-3009 asset first; none is live yet. 🐳 Local devnet docker run --rm -p 8545:8545 git.aere.network/aere-network/devnet:latest — the mainnet validators' own binary as a one-validator local chain (id 28002), 500 ms blocks, ten funded Hardhat accounts, DEBUG and TRACE open. Published 2026-09-02; the public read node rpc2 also answers read-only trace calls. 💰 Developer Grants $1k, $100k in funding for dApps, infrastructure, tooling, and content. Public and milestone-based. 🔍 Block Explorer ↗ Search transactions, blocks, addresses, and token transfers on AERE mainnet. 📦 Source on Git ↗ Public repositories at git.aere.network/aere-network: aere-contracts (Solidity), aere-research (vectors, formal models, benchmarks), aere-docs (specifications), sdk-js (TypeScript client). 📡 Oracle Network Live AereOracle dashboard, integrate on-chain price feeds into your contracts. Key facts for your configuration Hardhat / Foundry network config // hardhat.config.js networks: { aere: { url: "https://rpc.aere.network", chainId: 2800, accounts: [process.env.PRIVATE_KEY] } } ethers.js / viem connection // ethers v6 import { JsonRpcProvider } from "ethers"; const provider = new JsonRpcProvider( "https://rpc.aere.network" ); // viem import { createPublicClient, http } from "viem"; const aere = { id: 2800, name: "AERE Network", nativeCurrency: { name:"AERE",symbol:"AERE",decimals:18}, rpcUrls: { default: { http: ["https://rpc.aere.network"] } } }; MetaMask, add network manually Network name AERE Network RPC URL https://rpc.aere.network Chain ID 2800 Currency symbol AERE Explorer URL https://explorer.aere.network Need help? Open an issue on aere-contracts for technical questions, bug reports, or integration requests. The source code for all system contracts is public, reading the contract is often faster than waiting for a forum response. For grant applications and larger partnership discussions, use the grants repository . --- # AERE Network, Developer Docs URL: https://aere.network/docs.html Fetched: 2026-09-15 AERE Network, Developer Docs AERE Network, Developer Documentation Everything you need to build on AERE Layer 1: quickstart, JSON-RPC reference, deployed contract registry, faucet API, indexer API. Public repositories: aere-contracts · aere-research · aere-docs · sdk-js Get Started Quickstart SDK (@aere/sdk) Network parameters Add to MetaMask Faucet Neobank Integration Reference backend KYC attestation Wallet provisioning Reference JSON-RPC endpoints Advanced cryptography & AI Contract registry Indexer API Deep dives Cross-chain bridge Run a validator Quickstart Connect to AERE and read the chain in five minutes. Sending a transaction needs a funded address, and there is no public way to get one today. Read the notice below before you start. ⚠ Getting your first AERE. The faucet pays 0.05 AERE per address per 24 hours; the faucet service covers the gas after a short proof of work in your browser, so a brand-new address can send its first transaction (funded 2026-09-02 with a small operational amount; the live balance is on the faucet page, which says so if it runs dry). There is no public sale and no exchange listing. For building and testing without real AERE, use the public testnet (chain 28001, same node software, free tAERE). # 1. Add the network to MetaMask Network name: AERE Network RPC URL: https://rpc.aere.network Chain ID: 2800 Currency symbol: AERE Block explorer: https://explorer.aere.network # 2. Read the chain, works with an unfunded address (ethers v6) const provider = new ethers.JsonRpcProvider('https://rpc.aere.network'); console.log(await provider.getBlockNumber()); console.log(await provider.getBalance('0xYour…')); # 3. Send a tx, REQUIRES a funded address # No faucet, no public source of AERE today. This step will # fail with "insufficient funds" on a new address. const wallet = new ethers.Wallet(privateKey, provider); await wallet.sendTransaction({ to: recipient, value: ethers.parseEther('0.01') }); SDK · @aere/sdk Official TypeScript SDK wrapping ethers v6 with typed contract clients for every deployed AERE L1 contract. Designed for consumer neobank backends. # @aere/sdk is not yet on public npm, install from the public source: npm i git+https://git.aere.network/aere-network/sdk-js.git ethers import { AereClient } from '@aere/sdk'; import { ethers } from 'ethers'; const aere = new AereClient({ privateKey: process.env.OPS_PRIVATE_KEY }); // Multi-asset balance for any user const p = await aere.getPortfolio('0xUser…'); console.log(ethers.formatEther(p.aere), 'AERE'); console.log(ethers.formatEther(p.waere), 'WAERE'); // Lock 100 AERE for 90 days. The tier-1 rate is 15% APY on-chain, // but the AereLockedStaking reward pool is UNFUNDED (balance 0), // so no yield can be paid on maturity today. See #contracts. await aere.staking.lockTier90(ethers.parseEther('100')); // Write KYC attestation on-chain const oneYear = Math.floor(Date.now() / 1000) + 365 * 86400; await aere.identity.addClaim(userAddr, 'kyc-tier-1', reportHash, oneYear); // Watch for incoming AERE deposits, for a neobank webhook const stop = await aere.watchTransfersTo(userAddr, tx => { console.log(\`+\${ethers.formatEther(tx.value)} AERE in \${tx.hash}\`); }); Source + types on GitHub at git.aere.network/aere-network/sdk-js (gitea mirror: git.aere.network/aere-network/sdk-js). Wraps: staking, locked staking, governance, identity, bridge, swap, faucet, NFT marketplace, mining subscription. Full address book bundled, no manual constants. Neobank reference backend Working Express server demonstrating the full neobank-on-AERE integration pattern: signup, KYC attestation, multi-asset portfolio, on-chain savings, deposit-watching webhook. Source is available on the AERE gitea at git.aere.network/aere-network . OPS_PRIVATE_KEY=0x… npm run dev # Server on :4400 with routes: # POST /signup # POST /webhooks/baas/kyc-cleared → writes AereIdentity claim on-chain # GET /users/:id/portfolio → AERE + WAERE balances # POST /users/:id/earn → returns tx instructions for client to sign # POST /webhooks/onramp/deposit → MoonPay/Transak callback # Live block watcher → fires on user deposits KYC attestation pattern Two layers of KYC, independent: Fiat KYC , performed by your BaaS provider (Striga / Dipocket / Modulr / etc) on signup. Returns a verified status + report hash via webhook. On-chain attestation , the neobank backend writes the cleared status to AereIdentity against the user's AERE wallet. Smart contracts gate features (lending, higher limits, fiat off-ramp) by checking hasValidClaim(user, 'kyc-tier-1', kycOpsAddress) . // In the kyc-cleared webhook handler await aere.identity.addClaim( userAereAddress, 'kyc-tier-1', reportHash, // keccak256 of BaaS report Math.floor(Date.now()/1000) + 365 * 86400, // expires in 1 year ); Wallet provisioning AERE is non-custodial. Don't ask consumers to manage seed phrases, use one of: Privy , email/social login, MPC + email recovery, ~1 day to integrate. Recommended. Magic.link , similar pattern, slightly different recovery model. Web3Auth , open-source, more configuration knobs. Each provisions an EVM wallet keyed to the user's identity. Pass that signer into AereClient on the client side; the wallet works on chain 2800 immediately. Network parameters Parameter Value Chain name AERE Network Chain ID 2800 (0xAF0) Consensus Hyperledger Besu QBFT, 0.5-second blocks (transitioned from 1s at block 2,137,652) Native token AERE (18 decimals) Genesis foundation alloc 180,000,000 AERE → 0x0243A4f47D44b40b65D33f20329dE20D00c6f3C3 HTTP RPC https://rpc.aere.network WebSocket RPC wss://wss.aere.network Block explorer https://explorer.aere.network Indexer REST/WS https://api.aere.network Add to MetaMask One-click form: /addnetwork.html . Or programmatically: await window.ethereum.request({ method: 'wallet_addEthereumChain', params: [{ chainId: '0xAF0', chainName: 'AERE Network', rpcUrls: ['https://rpc.aere.network'], nativeCurrency: { name: 'AERE', symbol: 'AERE', decimals: 18 }, blockExplorerUrls: ['https://explorer.aere.network'], }] }); Faucet ⚠ Two faucets, one for each situation. The faucet service (used by the faucet page ) pays the gas for you: 0.05 AERE per address and per IP every 24 hours, after a proof of work in the browser. The on-chain AereFaucet contract at the address below also pays 0.05 AERE per claim() per 24 hours from its own balance, but the caller pays the gas, so it only helps addresses that already hold some AERE. Both were funded on 2026-09-02 with small operational amounts; read the balances live rather than trusting this sentence. UI: /faucet.html , shows the current faucet state. Claiming is disabled while the balance is zero. Configured drip: 0.05 AERE per address per 24 hours. This is the contract setting, not an amount you can receive today. JSON-RPC endpoints Standard Ethereum JSON-RPC, plus the QBFT namespace. curl -s -X POST https://rpc.aere.network \ -H 'content-type: application/json' \ -d '{"jsonrpc":"2.0","method":"eth_blockNumber","id":1}' # Namespaces served on the public endpoints: ETH, NET, WEB3, QBFT # both endpoints TXPOOL # rpc.aere.network only # Not exposed publicly: DEBUG, TRACE, ADMIN. # A -32601 "Method not found" for these means the namespace is closed, # not that the underlying data is missing. Rate-limit: ~100 req/s per IP. Open a ticket at git.aere.network for higher quota. State window. Both public endpoints are pruning full nodes. Blocks, transactions, receipts and logs go back to block 0, but account and contract state is retained for only about the most recent 512 blocks , roughly 4 minutes 25 seconds. Read state at latest . In particular, eth_getTransactionCount returns 0x0 outside that window rather than an error, so never test a nonce for zero at a historical block. Full explanation, a reproducible example and the SDK guard: the state window section of the developer docs . Also note eth_getLogs accepts at most 5,000 blocks between fromBlock and toBlock . No tracing on the public endpoints. The debug_ and trace_ namespaces are switched off, because one traced block can allocate hundreds of megabytes on an endpoint that also carries wallets, the explorer and every integration on the network. They answer -32601 Method not found , which reads like a method that never existed, so be clear that this is policy and not a statement about the chain. eth_simulateV1 , eth_createAccessList , eth_getBlockReceipts and decoded revert reasons from eth_call are all available and cover most of the ground. An archive node with full history and tracing exists and is fully synced; it is not yet publicly reachable. What that costs you, and what replaces it . EVM ruleset AERE Network runs the Pectra + Fusaka EVM ruleset, both hardforks activated on 2026-05-31. Full functional parity with Ethereum mainnet post-Fusaka. Includes: Pectra (activated at block 2,075,341): EIP-7702 , EOA delegation to smart-contract code (native account abstraction; works alongside ERC-4337) EIP-2537 , BLS12-381 curve precompiles at addresses 0x0b , 0x11 (G1ADD, G1MSM, G2ADD, G2MSM, PAIRING_CHECK, MAP_FP_TO_G1, MAP_FP2_TO_G2), cheap on-chain BLS signature verification, used for trustless cross-chain proofs EIP-2935 , Historical block hashes (up to 8,192 blocks back) available via system contract Cancun pack , EIP-1153 (TSTORE/TLOAD transient storage), EIP-5656 (MCOPY), EIP-6780 (SELFDESTRUCT change), EIP-7516 (BLOBBASEFEE) Cancun opcode set proven live on-chain: a canary contract AereCancunCanary ( 0x8DbFC002bB23124cBeCd7B4916c179D2AFd65498 ) demonstrates TSTORE/TLOAD (including the cross-transaction auto-reset), MCOPY, PUSH0, and BLOBHASH / BLOBBASEFEE returning correct values on chain 2800, inspectable via eth_call and eth_getCode . Fusaka (activated at block 2,106,597): RIP-7951 , secp256r1 / P-256 signature precompile at address 0x0000000000000000000000000000000000000100 . Fixed cost ~3,450 gas. Verifies signatures from Apple Face ID / Touch ID, Windows Hello, Android biometric APIs, YubiKey, TPM 2.0, EMV cards, and the EU Digital Identity Wallet. ~70× cheaper than Solidity-based verification. Note: AERE has no consensus-layer beacon chain, so EIP-4788 (parent beacon block root) is set to zero each block, and EIP-4844 blob fields exist in headers but no actual blobs are produced. Fusaka EIPs that are consensus-layer-only or rollup-only (PeerDAS, FOCIL, EOF) are no-ops on QBFT. Advanced cryptography & AI infrastructure All of the following are deployed on chain 2800 and callable. Each carries an explicit honest-scope note. Read recording vs view-only carefully. Post-quantum verifier suite A broad set of NIST post-quantum signature verifiers (not key generation or signing) run on-chain. We are not aware of any other public chain that verifies all of these signature schemes on-chain (stated as a hedge, not an unqualified "world first"). Recording means a state-changing verifyAndRecord transaction fits the L1 per-transaction gas cap (EIP-7825, 2 24 ); view-only means verification is correct and demonstrable via eth_call (validated bit-for-bit against official NIST vectors) but a recording transaction would exceed that per-tx cap. Contract Address Scope AereFalcon512Verifier 0x4E8e9682329e646784fB3bd01430aA4bA54D8fFC NIST Falcon-512, KAT-validated, recording (~10.5M gas) AereFalcon1024Verifier 0xF0aFA59BaB2058e4B6e6B424b7f76750F1F66e36 NIST Falcon-1024, KAT-validated, view-only (recording ~21.7M gas exceeds per-tx cap) AerePQCVerifier 0x1cE2949e8cE3f1A77b178aF767a4455c08ec6F82 WOTS+ (Winternitz one-time) hash-based, recording AereXmssVerifier 0x77b14E264D0bb08d304d4e0E527F0fCdFc88B112 RFC 8391 XMSS many-time hash-based, recording (~1.56M gas); does not enforce one-time-per-leaf state AereMLDSA44Verifier 0xf1F7A6Acd82D5DAf9AF3166a2F736EE52C5F85AE NIST ML-DSA-44 / Dilithium2 (FIPS 204), ACVP-validated 15/15, view-only (~52.9M gas) AereHybridAuth 0xc20390C9656ECe1AE37603c84E395bC898b3FAA1 Authorizes iff BOTH ECDSA AND Falcon-512 verify over the same hash, recording (~10.3M gas) AereConsensusPQCAttestor 0xf3681Aa6444F79562683C26f9d5c369A479c87dD Falcon-512 finality attestation ALONGSIDE QBFT; does NOT replace ECDSA block signing (not consensus PQC) Confidential compute (threshold MPC) AereConfidentialCompute 0x2120350c124e4Cae2C9FfBB6E4942DB1d380c287 . A 5-node committee (MPC reconstruction threshold 3, on-chain signature quorum 4) computes an agreed arithmetic circuit over parties' private inputs using real Shamir secret sharing (BN254 scalar field) and a real BGW multiplication gate. The MPC runs off-chain ; the contract verifies a quorum of committee ECDSA signatures over the EIP-712 result and records it. Honest threat model: semi-honest (secure against a colluding minority below the threshold, not malicious-secure, no cheater detection). No owner backdoor can forge a result. TEE is not built : the host has no usable SEV-SNP/TDX/SGX attestation, so the pure-software secret-sharing path is used. Parallel L2 execution & rollup validity A real from-scratch Rust Block-STM parallel executor (~8.6-9.3x on 16 cores, parallel proven equal to sequential) is wired into the rollup sequencer. Honest scope: this Rust executor parallelizes L2 rollup batches. The L1 base layer runs a separate Block-STM-style block processor of our own inside the Besu fork, switched on on all nine validators since 2026-09-05 and proven on real blocks with a recorded negative control; with blocks carrying at most one transaction today it delivers no measurable speed-up, and none is claimed. AereBlockSTMRegistry 0x98E2C3e615841919d173D8FF642514c5902E8A28 is a deployed opt-in read/write slot-hint registry (advisory). AereRollupValidity 0x38772063572DF94E90351e44ccbBEefD5F497fbd anchors a real SP1 Groth16 validity proof of the executor (epoch 0); it is a proof of concept over a bounded-VM executor (Transfer/Sweep/Increment/AmmSwap), not a full-EVM validity rollup. Agentic + AI infrastructure Contract Address Purpose AereAgentBond 0x32E0015F622a8719d1C380A87CE1a09bcd0cB86A Slashable agent bond (WAERE); slashed value burns via AereSink AereAIReputation 0x781ef746c08760aa854cDa4621d54db6734bfeBF Composable 0-10000 agent reputation over the bond AereAgentMemoryVault 0x309b56BDf0E3F6C10783eB76c0C02127F933D641 Portable user-owned agent memory; no admin AereInferNet 0xba76891DB84B9755613dE3A1c7F3902BB6bbf856 EU AI Act Art.12 inference-log Merkle commitments; no PII, permissionless ERC6551Registry 0x7fFdA0AcDeB919938dB91dbEa779D841c833EF68 Canonical ERC-6551 token-bound-account registry AereTokenBoundAccount 0xBc5e24180f3F75DC6b1965E4aaD3D4F184b6F9E2 ERC-6551 account implementation (owned by the bound NFT) Contract source is published and verified Sourcify-style (34 contracts), browsable at /verified-contracts.html . Multi-prover ZK verifiers Beyond SP1 (Groth16 + Plonk) and RISC Zero, the substrate now includes a KZG opening verifier and a real Halo2 verifier, and recursion has been demonstrated at scale. Contract Address Purpose AereKZGVerifier 0x6596307BD8f54d9A91FE364EBC3e594F200AC862 KZG point-evaluation opening verifier; calls the live EIP-4844 precompile at 0x0A AereHalo2Verifier 0x414Cfe640B2770856d3D7262a7a3729f5c07dC55 Real on-chain Halo2 (PLONKish, KZG-backed) verifier AereProofAggregator (V1, DEPRECATED) 0x6a260238890E740dB12b371E0C5d17a2470F84C5 Recursive SP1 aggregation. Do not integrate. V1 counted the folded inner-program keys but never required them to be registered, so an aggregation over an unvetted inner program recorded as if it were legitimate. Its two historical records are genuine and it holds no funds. Superseded by AereProofAggregatorV2 0x944dE720D6C9696Bdf10b6E2F00dd21ABB1A2b4C , which rejects an unregistered inner program outright. Measured live 2026-08-01, 4,663 bytes. Modular ERC-7579 accounts (session keys + social recovery) An ERC-7579-style modular account factory with pluggable validator modules. Proven live: a userOp signed only by a scoped session key executed through the live AereEntryPointV2 . Contract Address Purpose AereModularAccountFactory 0xE3f45Ed4a81f982fF25ad172A72456a1833a440E ERC-7579 modular smart-account factory (pluggable validators) AereSessionKeyValidatorV2 0xC06EAe63Ed12307F56A1506917C48C027D8852ff Scoped, time-bounded session keys with a target allowlist and a per-key spend cap. Internally reviewed (no external audit yet) replacement for the deprecated, drainable V1 0x6e03A3D7A4c90d6f8dD6F0BA1F6e8aB1F8990D26 (per-batch value-cap bypass); do not use V1. AereSocialRecoveryModule 0x077514DB2a85F239145537e8334CC99d42c9D812 Guardian social recovery behind a 48-hour timelock Interoperability (Hyperlane v3) A live Hyperlane v3 deployment on the AERE side with a working quoteDispatch . The USDC.e Warp Route rides this v3 mailbox: the AERE side is live and proven, while the Ethereum L1 leg still needs an L1 deployment and real ETH gas (pending). Contract Address Purpose Hyperlane v3 Mailbox 0x7BF113Ab1BCd2b6da01804764065776e3057605a Live Hyperlane v3 mailbox, working quoteDispatch (owner = Foundation-controlled account) Hyperlane v3 IGP 0x5e4B8e9b196B1c7b3Be86148769aB0047c79744c Hyperlane v3 Interchain Gas Paymaster (owner = Foundation-controlled account) AereWarpRouteV3 0x1f44573684aB6bC617e7200A19b940b05e4EE098 USDC.e Warp Route on Hyperlane v3; AERE side live+proven, Ethereum L1 leg pending Application-level building blocks (honest scope) AereShutterMempoolV2 0x135100D523edA8D0AdC70e08af905dE5042A9310 is an application-level, opt-in threshold-encrypted anti-MEV mempool proof of concept. A Besu QBFT L1 has no protocol-level encrypted mempool, so this is not a base-layer feature and is not wired into consensus. AereStateRootAnchor 0x78b40a983E89c91Aefd8A62Be709bDF25ABB57cb anchors state/storage roots whose canonicity comes from the BLOCKHASH opcode; that reaches back only 256 blocks (~128s at 0.5s blocks); with the AerePQC fork (activationTime 1783820272, first block at or after it is 9,189,161) EIP-2935 is now live on chain 2800, extending the trustless block-hash lookback to an 8,191-block window. Contract registry All currently-deployed contracts on AERE L1 (chain ID 2800). Owner: Foundation 0x0243A4f47D44b40b65D33f20329dE20D00c6f3C3 . Contract Address Purpose WAERE 0x7e84d7d66d5da4cfE46Da67CDEeB05B323e1f5e8 Wrapped AERE (WETH9-style ERC-20) AereTreasury 0x687933AE7ea4927867AC227F1b60d476003e6119 Timelocked foundation treasury AereOracleV2 0xca69AA961D836516010Ae669a223Ce249490ACb1 Multi-reporter median price feed (canonical, quorum-safe). Legacy AereOracle 0xf0A1…F399 remains the live read source until the Foundation repoints AereOracleAdapter. AereIdentity 0x658dD2CD1F798AAb19fEc8FF69A270B2d192CaD1 DID registry + revocable claims AereFaucet 0xDdBe942aD9eB0F3E7C541BdCF7CC2cfA29d35aE4 Not funded, balance 0. Configured for a 0.05 AERE drip per 24 h; every claim() reverts until it is refunded AereCardEscrow 0xD1f7f12830AdCFd1B7676C8460B9e30602b1f059 Consumer card settlement escrow AereSecurity 0xaD305e4D91e0a9160Bd338Fd1ecb2Ee1645daC44 Security module sAERE 0xA2125bE9C6fd4196D9F94757Df18B3a2A5e650b0 ERC-4626 staking receipt · variable staker-yield from the AereSink fee split (earns yield, not a validator seat) AereLockedStaking 0x21108c28A849b05aE6b7a3a5bc435C9Bc897E7Ad Fixed-term locked staking · on-chain rates 30d/10%, 90d/15%, 180d/22%, 365d/30% APY (yield product, not delegation-to-a-validator). Reward pool is unfunded, balance 0: no yield can be paid today. Locking returns principal only AereSink 0x69581B86A48161b067Ff4E01544780625B231676 Immutable fee router · 15/40/45 split feeding sAERE staker-yield, buyback, and burn AereSwapFactory 0xf0a8df7BDc25721892475B21271e52D77B0e84DC V2 AMM factory · 0.3% fee AereSwapRouter 0x7526B2E5526EfA84018378b60F2844Dad77523D8 V2 periphery: add/remove liquidity, swap, native-AERE auto-wrap AereBridge 0x7eDa66cd93baAE19530839Bbb28ee36aC8aFAd68 Federated lock-and-release bridge AereMiningSubscription 0xDad25d2163187DF8AAEcf9EA31b6355315Bb69f1 On-chain name only · scheduled reserve distribution, not PoW mining AereNFT 0x3f9A9D9CAB005327869396C69bE226ef98039f1c ERC-721 + EIP-2981 royalties AereNFTMarketplace 0x852e07F2619F7F4aD10d9f2aC681310301d99528 2.5% fee, royalty-aware marketplace AereGovernanceStaked 0x8D77C888e439C4fADb2e23F1567a0A1965F80bCb Staked governance · proposals + voting AereLockedStaking 0x21108c28A849b05aE6b7a3a5bc435C9Bc897E7Ad Fixed-term locks · on-chain rates 30d/10%, 90d/15%, 180d/22%, 365d/30% APY. Reward pool unfunded, balance 0: no yield payable today AereFeeBurnVault 0x696afDF4f814e6Fd6aa45CE14C498ed9375fB2c6 Stateless protocol-fee burn endpoint (no admin, no withdraw) AereYieldFarm 0xF86Fb0Eb3262C4e93Dbb349d63023218a5Db713F LP staking → native AERE rewards (MasterChef-style) AereMiningDistributor 0x0607ad23534ee251f359D960f7a6823C6b876b26 Merkle-claim reserve-distribution payout (per-epoch, deadline-sweepable) AereEntryPoint 0x19773ba45287A64B05d0BCBD59D1371BF51Bd5D2 ERC-4337 EntryPoint for AERE paymaster stack AereOnboardingPaymaster 0x4058E406475Dbed7056Aee0c808f293F05fEa879 Foundation-funded · 3 free txs/sender (lifetime) · 100/day sitewide cap AereTokenPaymaster 0x217f56a5b0C7f35abe4D2fff924A6c13B85d7243 Pay AERE gas with any whitelisted ERC-20 (USDT/USDC/etc.) AereStakeQuotaPaymaster 0xE50464ca7E8E7F542D1816B3172a2330cFE384E8 Stake AERE → daily free-tx quota AereAppPaymasterFactory 0xEC22603E8712cBc5c31E53370D10f1a80CcB4DF0 Permissionless factory, each dApp deploys its own paymaster AereMessenger 0xe54c2329f0786CFE3420c566B646148D25477325 Hyperlane Mailbox-compatible cross-chain message bus (multisig ISM) AereIGP 0x61B48615F490A23945988c92835eF35fdD86E837 Interchain Gas Paymaster, collects AERE for outbound cross-chain relays AereSpokePool (V1, DEPRECATED) 0xCAB1DBA5f6F06198000C20a974d675f1B3181AbD Do not integrate. Our own registry marks this flawed: its settlement path could release locked principal without properly verifying the delivered output leg. Zero balance, measured 2026-08-01. Superseded by AereSpokePoolV2Corrected 0xbEF9BF0D22dd00DBEdA262C3Cd3178f08C623d8d, which is live (6,317 bytes) but inert, no remote spoke enrolled. AereERC7683 (V1, DEPRECATED) 0x67Fb9830e3a2BC06cEb641cfF3beD87b273ccb29 Do not integrate. It routes into the deprecated SpokePool above and inherits its defect. Superseded by AereERC7683V2Corrected 0x8eC4e7F01790C04D450b45d399E71DFd381560e3, live (7,931 bytes) and likewise inert. No intent route is open on Aere Network today. AerePyth 0xb7F3354C1E0C5ef89D8b1072a3CEa7FFEf2FfE3F Pyth-IPyth-compatible pull oracle, publisher-signed price updates AereOracleAdapter 0xb28A23dc177794DEC2Cacd2738fCc6c5C1Fc4Fe6 Unified price-quote interface, routes Pyth → legacy AereOracle fallback AereRandomnessBeacon 0x25b6317efD8C7d425210F56Ee1E204852CD8213C Permissionless drand verifiable-randomness beacon (Quicknet chain) AereDrandConsumer 0xeBA8De4f61c923a2E43eA8d7233Cf8e1Db5911B5 Reference drand consumer (integration example/library) AereCoinbaseSplitter 0xb4b0eCe9011613A5b84248a9B42a0f309E6F01Ec Atomic 37.5% → AereFeeBurnVault burn + 62.5% → validator (whitepaper §3.3 made real) AereVaultRelayer 0x9FCA122e87E36D7cba20DbEA7b9b7354A4Cece91 Token allowance proxy for AereSettlement batch DEX AereSolverRegistry 0xDBD29332a9993d2816EF0bD240288E03a8103f3B Permissioned solver allowlist for the batch DEX AereSettlement 0x9C2957b1622567B4802E4AFd4c42FB2ec70dE875 Batch-atomic settlement contract, MEV-resistant DEX AereFeeMonetizationV2 0xb560bdFB8b8B918012e6481e3bcF473c79c2a850 Developer fee-share NFTs (20%) + Foundation treasury slice (5%) per gas fee. Canonical; register() here. Deprecated V1 0x6b62…dd98 (fee-stream squat) must not be used. SP1VerifierGateway 0x9ca479C8c52C0EbB4599319a36a5a017BCC70628 SP1 (Succinct Labs) proof verifier, stable address, routes by selector to v6.x Groth16/Plonk concrete verifiers RiscZeroVerifierRouter 0x3f7015BC3290e63F7EC68ecF769b00aB296a249C RISC Zero zkVM proof router, stable address, routes by selector to concrete Groth16 verifier AereProofRegistry 0x0A9b09677DbE995ACfC0A28F0033e68F068517Ee Multi-prover attestation log, verifies via SP1 gateway + R0 router, permissionless program registration AerePasskeyAccountFactory 0xfB0eF980667A79Fe1AB69c5f2d512118F1B30739 CREATE2 factory for passkey-controlled smart accounts (Touch ID, Face ID, Windows Hello, YubiKey, EU Digital Identity) AereEntryPointV2 0x8D6f40598d552fF0Cb358b6012cF4227B86aF770 ERC-4337 v0.7-shaped EntryPoint, handleOps, validateUserOp, deposits/withdrawals, paymaster dispatch AerePasskeyAccountFactoryV2 0x5FFa9a6487DA4641a1A1e7900ff2bD4525D34fdA V2 factory, multi-owner (passkey + EOA), recovery, EIP-1271, ERC-4337 compat Each contract is inspectable on the explorer at explorer.aere.network . Indexer API (api.aere.network) # Latest blocks GET https://api.aere.network/api/blocks?limit=20 # Block by number GET https://api.aere.network/api/block/12345 # Transaction by hash GET https://api.aere.network/api/tx/0xabc... # Address (balance, txs, contract code) GET https://api.aere.network/api/address/0xdeadbeef... # Network stats GET https://api.aere.network/api/stats # WebSocket: live block stream wss://api.aere.network/ws Cross-chain bridge Federated 2-of-2 lock-and-release. Lock AERE on L1 → relayers gather signatures → mint wAERE on the foreign chain. Burn wAERE → release native AERE on L1. # Lock await bridge.lockAndBridge(toChainId, recipient, { value: amount }); # Foreign side await counterparty.releaseFromL1(srcChainId, nonce, recipient, amount, signatures); Run a validator Hyperledger Besu QBFT image, 32-byte private key file, peer with the existing bootnode. Step by step in the validator course . The chain-2800 genesis and bootnode list are issued to approved operators via contact . Public repositories at git.aere.network/aere-network (aere-contracts, aere-research, aere-docs, sdk-js). Docs pull requests and issues welcome there. --- # AERE Documentation URL: https://aere.network/docs/ Fetched: 2026-09-15 AERE Documentation AERE Documentation Everything needed to build on, verify, and run AERE Network: a public EVM Layer 1, chain ID 2800, with NIST post-quantum signature verification live on mainnet. Getting started Connect to the chain, get funds, send your first transaction, deploy your first contract. 7 pages Build EVM compatibility, JSON-RPC, fees, events, and the differences that actually matter. 8 pages Post-quantum The five NIST precompiles, the certificate anchor under the block hash, and how to verify both yourself. 8 pages Network Chain parameters, consensus, the anchor schedule, enforcement heights and endpoints. 7 pages Run a node Follow the chain from your own machine, with the package we publish and the options we run. 6 pages Reference Lookups: methods, ABIs, addresses, registries and the glossary. 7 pages --- # Events and logs · AERE Documentation URL: https://aere.network/docs/build/events-and-logs Fetched: 2026-09-15 Events and logs · AERE Documentation Events and logs Reading logs, and the state window that makes some answers wrong if you ignore it. Getting started What AERE is Connect to the network Tooling that works unchanged Your first transaction Your first contract Faucet Next steps Build EVM compatibility JSON-RPC Fees and the base fee floor Events and logs Hardhat Foundry Verifying a contract TypeScript SDK Post-quantum Overview, stated precisely The five precompiles Falcon input framing The certificate anchor Verify an anchor yourself Hybrid certificates Threat model Requiring a post-quantum signature not written Network Chain parameters Consensus Anchor schedule Enforcement heights Fork history Public endpoints Network operations Run a node Requirements Install Configure Sync Monitor Troubleshoot Reference Protocol specification Precompile ABI Indexer API JSON-RPC methods Contract registry Genesis Glossary Docs / Build / Events and logs Logs work exactly as on Ethereum. The thing to know is not about logs, it is about the state window behind the endpoint you are reading them from. Reading logs const logs = await provider.getLogs({ address: '0x…', topics: [id('Bumped(address,uint256)')], fromBlock: head - 5000, toBlock: head, }); eth_getLogs , bloom filters, indexed topics and receipt logs are standard. Contract events are emitted, indexed and filtered the way any Ethereum tool expects. The 512-block state window The public RPC keeps state for 512 blocks . Beyond that window: eth_call at an old block answers from a pruned state. eth_getTransactionCount returns a false 0x0 . Not an error. A zero. At half-second blocks, 512 blocks is about four minutes. Anything older is outside the window. A false zero is worse than an error, because it looks like a measurement. A tool that reads a nonce at an old block and concludes "this account has never sent a transaction" is wrong and nothing tells it so. Prove facts about accounts with eth_getProof , which either answers with a proof or fails. Never with a nonce read at an old height. Historical logs For history beyond the window, use the indexer rather than the RPC. It holds indexed transactions per address and per block. See Indexer API . If you need full history under your own control, run an archive node. The package and the exact options are published; see Run a node . Log volume and empty blocks The chain produces a block every half second whether or not there are transactions, so most blocks are empty and carry no logs. A subscriber that treats a run of empty blocks as a stall will raise false alarms; chain liveness is the block number advancing, not the transaction count. A note on log-filter caches If you run a node, the log-filter cache can grow to several gigabytes while being almost entirely zeros. It is a computed index, not history: it can be rebuilt, so clearing it loses no chain data. Headers are not in that category and must never be treated the same way. Previous Fees and the base fee floor Next Hardhat On this page Reading logs The 512-block state window Historical logs Log volume and empty blocks A note on log-filter caches --- # EVM compatibility · AERE Documentation URL: https://aere.network/docs/build/evm-compatibility Fetched: 2026-09-15 EVM compatibility · AERE Documentation EVM compatibility Which forks are active, what behaves exactly like Ethereum, and what does not. Getting started What AERE is Connect to the network Tooling that works unchanged Your first transaction Your first contract Faucet Next steps Build EVM compatibility JSON-RPC Fees and the base fee floor Events and logs Hardhat Foundry Verifying a contract TypeScript SDK Post-quantum Overview, stated precisely The five precompiles Falcon input framing The certificate anchor Verify an anchor yourself Hybrid certificates Threat model Requiring a post-quantum signature not written Network Chain parameters Consensus Anchor schedule Enforcement heights Fork history Public endpoints Network operations Run a node Requirements Install Configure Sync Monitor Troubleshoot Reference Protocol specification Precompile ABI Indexer API JSON-RPC methods Contract registry Genesis Glossary Docs / Build / EVM compatibility Chain 2800 runs the Ethereum Virtual Machine. Contracts, tooling and the JSON-RPC surface behave as they do on Ethereum, with a small number of differences that are listed here in full. Active forks Homestead through Shanghai at block 0, Cancun and Prague at timestamp 1780189051, Osaka at timestamp 1780220351, and one AERE milestone at timestamp 1783820272, whose first block is 9,189,161. Compile for osaka or any earlier EVM target. Nothing in the AERE milestone removes or changes an opcode. What the AERE milestone adds The five post-quantum precompiles at 0x0AE1 through 0x0AE5 . EIP-2935 historical block hashes, which performs one system state write per block into the ring buffer at 0x0000F90827F1C53a10cb7A02335B175320002935 . It is isolated on the Osaka definition, not on upstream Besu's Amsterdam-based futureEips . That matters only if you are writing a node; see Chain parameters . The differences that affect application code A base fee floor. From block 10,141,734 the base fee cannot go below 1 Gwei. Everything else about EIP-1559 is unchanged. See Fees . A 512-block state window on the public RPC. Beyond it, eth_getTransactionCount returns a false 0x0 instead of an error. Use eth_getProof for anything you intend to rely on. See Events and logs . Large headers at anchor heights. Every 128th header carries a post-quantum certificate and is tens of kilobytes rather than hundreds of bytes. Read the field length; never assume a header size. Empty blocks are normal. The chain produces a block every half second whether or not there are transactions, so most blocks carry none. A tool that treats an empty block as an error, or that infers chain liveness from transaction counts, will be wrong here. What is the same Address derivation, CREATE and CREATE2 addresses, gas costs for every standard opcode, ecrecover at 0x01 , the pairing and KZG precompiles, transaction types including EIP-1559 and EIP-4844 shapes, receipts, logs and bloom filters, and the standard JSON-RPC method set. System contracts EIP-4788 beacon roots is active in genesis. The beacon roots contract has no code on this chain, so the system call fails on every block. The chain is unaffected: this is a logging condition, not a consensus one, and it is filtered rather than silenced so that other errors from the same class still appear. Previous Next steps Next JSON-RPC On this page Active forks What the AERE milestone adds The differences that affect application code What is the same System contracts --- # Fees and the base fee floor · AERE Documentation URL: https://aere.network/docs/build/fees Fetched: 2026-09-15 Fees and the base fee floor · AERE Documentation Fees and the base fee floor EIP-1559 with an AERE floor: what it changes and from which block. Getting started What AERE is Connect to the network Tooling that works unchanged Your first transaction Your first contract Faucet Next steps Build EVM compatibility JSON-RPC Fees and the base fee floor Events and logs Hardhat Foundry Verifying a contract TypeScript SDK Post-quantum Overview, stated precisely The five precompiles Falcon input framing The certificate anchor Verify an anchor yourself Hybrid certificates Threat model Requiring a post-quantum signature not written Network Chain parameters Consensus Anchor schedule Enforcement heights Fork history Public endpoints Network operations Run a node Requirements Install Configure Sync Monitor Troubleshoot Reference Protocol specification Precompile ABI Indexer API JSON-RPC methods Contract registry Genesis Glossary Docs / Build / Fees and the base fee floor EIP-1559 with one AERE change: the base fee has a floor. The rule From block 10,141,734 , the base fee on chain 2800 cannot fall below 1 Gwei (1,000,000,000 wei). Below the floor it is clamped to the floor. Above it, EIP-1559 behaves exactly as on Ethereum: the base fee rises when blocks are fuller than target and falls when they are emptier. What it means for you A plain transfer costs 21,000 gas, so its minimum cost is 21,000 x 1 Gwei = 0.000021 AERE . Fee estimation from any standard library works unchanged. eth_feeHistory , eth_gasPrice and eth_maxPriorityFeePerGas all report the real values, floor included, so a wallet does not need to know about the floor to produce a valid transaction. The thing that surprises tools is the shape of the curve: on a chain with little traffic the base fee does not decay toward zero, it decays to 1 Gwei and stays there. Why the floor exists Without it, a chain that produces a block every half second and is mostly empty settles at a base fee near zero, which prices transaction inclusion at approximately nothing and makes spam free. The floor is the cheapest defence that does not require a change to the fee market. Fee burn, and a claim we do not make AERE does not burn the base fee. The burn on this chain is a cut of the validator reward , routed by the AereSink contract at a Foundation-set rate that is hard-capped at 50%. So base fee multiplied by gas used is not a burn figure on this chain, and any tool that presents it as one is wrong here. On an explorer page for a block you will see this stated rather than a number, because there is no honest per-block figure to print. A caveat for node implementers If you are following the chain rather than using it, the floor is a consensus rule: a client that does not enforce it computes a different base fee for the affected blocks, therefore a different state root, and rejects every block from block 10,141,734 onward. The failure is quiet rather than loud. A client missing the floor does not crash; it reports a base fee below 1 Gwei and diverges. Check the value rather than waiting for an error. Previous JSON-RPC Next Events and logs On this page The rule What it means for you Why the floor exists Fee burn, and a claim we do not make A caveat for node implementers --- # Foundry · AERE Documentation URL: https://aere.network/docs/build/foundry Fetched: 2026-09-15 Foundry · AERE Documentation Foundry A working Foundry configuration for chain 2800. Getting started What AERE is Connect to the network Tooling that works unchanged Your first transaction Your first contract Faucet Next steps Build EVM compatibility JSON-RPC Fees and the base fee floor Events and logs Hardhat Foundry Verifying a contract TypeScript SDK Post-quantum Overview, stated precisely The five precompiles Falcon input framing The certificate anchor Verify an anchor yourself Hybrid certificates Threat model Requiring a post-quantum signature not written Network Chain parameters Consensus Anchor schedule Enforcement heights Fork history Public endpoints Network operations Run a node Requirements Install Configure Sync Monitor Troubleshoot Reference Protocol specification Precompile ABI Indexer API JSON-RPC methods Contract registry Genesis Glossary Docs / Build / Foundry A working Foundry setup for chain 2800. Configuration # foundry.toml [profile.default] src = "src" out = "out" libs = ["lib"] evm_version = "cancun" optimizer = true optimizer_runs = 200 [rpc_endpoints] aere = "https://rpc.aere.network" evm_version can be cancun , prague , osaka or earlier. Deploy export PRIVATE_KEY=0x… forge create src/Counter.sol:Counter \ --rpc-url aere \ --chain 2800 \ --private-key $PRIVATE_KEY Call and send cast block-number --rpc-url aere cast call 0xCONTRACT "value()(uint256)" --rpc-url aere cast send 0xCONTRACT "bump()" \ --rpc-url aere --chain 2800 --private-key $PRIVATE_KEY Calling a post-quantum precompile from a test The verifiers are plain addresses, so cast call reaches them directly. This asks 0x0AE5 for 32 bytes of SHAKE256 over the bytes abc : cast call 0x0000000000000000000000000000000000000ae5 \ 0x0000000000000000000000000000000000000000000000000000000000000020616263 \ --rpc-url aere For the signature verifiers, read Falcon input framing first. They return a zero word for a wrong layout and for an invalid signature alike, so put a known-good vector in the same test as a positive control. Notes Forking. --fork-url against the public endpoint works for recent blocks only: state is kept for 512 blocks. Forking deeper needs your own archive node. Finality. One confirmation is final; cast send returning a receipt is the end of the story. Fee floor. The base fee cannot go below 1 Gwei. Let cast read fee data rather than pinning a gas price by hand. Previous Hardhat Next Verifying a contract On this page Configuration Deploy Call and send Calling a post-quantum precompile from a test Notes --- # Hardhat · AERE Documentation URL: https://aere.network/docs/build/hardhat Fetched: 2026-09-15 Hardhat · AERE Documentation Hardhat A working Hardhat configuration for chain 2800. Getting started What AERE is Connect to the network Tooling that works unchanged Your first transaction Your first contract Faucet Next steps Build EVM compatibility JSON-RPC Fees and the base fee floor Events and logs Hardhat Foundry Verifying a contract TypeScript SDK Post-quantum Overview, stated precisely The five precompiles Falcon input framing The certificate anchor Verify an anchor yourself Hybrid certificates Threat model Requiring a post-quantum signature not written Network Chain parameters Consensus Anchor schedule Enforcement heights Fork history Public endpoints Network operations Run a node Requirements Install Configure Sync Monitor Troubleshoot Reference Protocol specification Precompile ABI Indexer API JSON-RPC methods Contract registry Genesis Glossary Docs / Build / Hardhat A working Hardhat setup for chain 2800. Configuration // hardhat.config.js require('@nomicfoundation/hardhat-toolbox'); module.exports = { solidity: { version: '0.8.24', settings: { optimizer: { enabled: true, runs: 200 }, evmVersion: 'cancun' }, }, networks: { aere: { url: 'https://rpc.aere.network', chainId: 2800, accounts: process.env.PRIVATE_KEY ? [process.env.PRIVATE_KEY] : [], }, }, }; evmVersion can be cancun , prague , osaka or anything earlier. Chain 2800 activates through Osaka. Deploy export PRIVATE_KEY=0x… npx hardhat compile npx hardhat run scripts/deploy.js --network aere // scripts/deploy.js const hre = require('hardhat'); async function main() { const Counter = await hre.ethers.getContractFactory('Counter'); const counter = await Counter.deploy(); await counter.waitForDeployment(); console.log('deployed at', await counter.getAddress()); } main().catch((e) => { console.error(e); process.exit(1); }); Notes that save time One confirmation is final. waitForDeployment() returning means the block is committed and will not be reorganised. There is no reason to wait for more confirmations. Blocks are half a second. Tests that poll with long intervals spend most of their time waiting. Gas estimation works, but the base fee has a floor of 1 Gwei. If you pin gasPrice manually to something below the floor the transaction is rejected as underpriced. Let the toolchain read fee data from the chain. See Fees . Forking. hardhat_reset against https://rpc.aere.network works for recent blocks only, because the public endpoint keeps state for 512 blocks. Forking at an older height needs an archive node of your own. Previous Events and logs Next Foundry On this page Configuration Deploy Notes that save time --- # JSON-RPC · AERE Documentation URL: https://aere.network/docs/build/json-rpc Fetched: 2026-09-15 JSON-RPC · AERE Documentation JSON-RPC Endpoints, the method set, and the limits a client must know about. Getting started What AERE is Connect to the network Tooling that works unchanged Your first transaction Your first contract Faucet Next steps Build EVM compatibility JSON-RPC Fees and the base fee floor Events and logs Hardhat Foundry Verifying a contract TypeScript SDK Post-quantum Overview, stated precisely The five precompiles Falcon input framing The certificate anchor Verify an anchor yourself Hybrid certificates Threat model Requiring a post-quantum signature not written Network Chain parameters Consensus Anchor schedule Enforcement heights Fork history Public endpoints Network operations Run a node Requirements Install Configure Sync Monitor Troubleshoot Reference Protocol specification Precompile ABI Indexer API JSON-RPC methods Contract registry Genesis Glossary Docs / Build / JSON-RPC Chain 2800 exposes the standard Ethereum JSON-RPC API over HTTPS, plus the QBFT namespace. Endpoints https://rpc.aere.network https://rpc2.aere.network Both are public, unauthenticated, and operated by the AERE Foundation. Subscriptions are on separate WebSocket endpoints, not on those hosts: wss://wss.aere.network wss://api.aere.network/ws eth_subscribe works there and not over HTTPS. A call curl -s -X POST -H 'content-type: application/json' \ -d '{"jsonrpc":"2.0","id":1,"method":"eth_blockNumber","params":[]}' \ https://rpc.aere.network Namespaces Namespace Notes eth_ The standard set: blocks, transactions, receipts, calls, logs, fee history, proofs net_ net_version returns 2800 web3_ Client version and sha3 qbft_ Validator set and signer metrics, specific to the consensus engine Two qbft_ methods are worth knowing: qbft_getValidatorsByBlockNumber returns the validator set at a height. This is the correct way to count validators; do not infer the set from who produced recent blocks. qbft_getSignerMetrics reports how many blocks each validator actually produced over a range. A validator that proposes is not necessarily a validator that produces. What is not exposed admin_ is not exposed on the public endpoints. If you need a node's enode or peer list, you are looking at an operational question and the answer is to run your own node. Limits worth knowing before you build State window of 512 blocks. Beyond it, state-reading calls answer from a pruned state and eth_getTransactionCount returns a false 0x0 . Use eth_getProof . See Events and logs . A revert with empty data means the name is missing, not the function. An eth_call that returns empty tells you that selector is not present. It does not tell you the capability is absent. Prove capability positively, from bytecode. Do not scan for history. Use the indexer for per-address history. Errors Standard JSON-RPC error objects. A transaction rejected for a fee below the base fee floor comes back as an ordinary underpriced error; see Fees . Previous EVM compatibility Next Fees and the base fee floor On this page Endpoints A call Namespaces What is not exposed Limits worth knowing before you build Errors --- # TypeScript SDK · AERE Documentation URL: https://aere.network/docs/build/sdk Fetched: 2026-09-15 TypeScript SDK · AERE Documentation TypeScript SDK The typed client for chain 2800. Getting started What AERE is Connect to the network Tooling that works unchanged Your first transaction Your first contract Faucet Next steps Build EVM compatibility JSON-RPC Fees and the base fee floor Events and logs Hardhat Foundry Verifying a contract TypeScript SDK Post-quantum Overview, stated precisely The five precompiles Falcon input framing The certificate anchor Verify an anchor yourself Hybrid certificates Threat model Requiring a post-quantum signature not written Network Chain parameters Consensus Anchor schedule Enforcement heights Fork history Public endpoints Network operations Run a node Requirements Install Configure Sync Monitor Troubleshoot Reference Protocol specification Precompile ABI Indexer API JSON-RPC methods Contract registry Genesis Glossary Docs / Build / TypeScript SDK @aere/sdk is the official TypeScript client for chain 2800. It wraps the deployed contracts, is built on ethers v6, and is MIT licensed. Install It is published from source rather than from the npm registry: npm install git+https://git.aere.network/aere-network/sdk-js.git pnpm add git+https://git.aere.network/aere-network/sdk-js.git Source and issues: git.aere.network/aere-network/sdk-js . What it gives you A typed client for chain 2800 with the endpoints already configured. Typed wrappers around the deployed contracts, so you do not hand-copy ABIs and addresses. The canonical address registry, in src/addresses.ts , which is the single place addresses live. What it does not give you It is a convenience layer over ethers, not a requirement. Everything on this chain is reachable with plain ethers or viem and the JSON-RPC endpoints , and the getting started pages deliberately use plain ethers so that nothing depends on our package. It is the only published AERE client today. Rust, Python and Go clients are described in places on this site as planned; they are not published, and a plan is not a package. Addresses The address registry inside the SDK is the canonical list. If a contract address appears in a blog post, a diagram or an older page and disagrees with src/addresses.ts , the registry is right. Note that the registry holding an address does not by itself mean the contract's source has been verified against its on-chain bytecode. Verification coverage is a separate, smaller list; see Verifying a contract . Previous Verifying a contract Next Overview, stated precisely On this page Install What it gives you What it does not give you Addresses --- # Verifying a contract · AERE Documentation URL: https://aere.network/docs/build/verify-a-contract Fetched: 2026-09-15 Verifying a contract · AERE Documentation Verifying a contract How source verification works here and what a match actually proves. Getting started What AERE is Connect to the network Tooling that works unchanged Your first transaction Your first contract Faucet Next steps Build EVM compatibility JSON-RPC Fees and the base fee floor Events and logs Hardhat Foundry Verifying a contract TypeScript SDK Post-quantum Overview, stated precisely The five precompiles Falcon input framing The certificate anchor Verify an anchor yourself Hybrid certificates Threat model Requiring a post-quantum signature not written Network Chain parameters Consensus Anchor schedule Enforcement heights Fork history Public endpoints Network operations Run a node Requirements Install Configure Sync Monitor Troubleshoot Reference Protocol specification Precompile ABI Indexer API JSON-RPC methods Contract registry Genesis Glossary Docs / Build / Verifying a contract Source verification on AERE is a Sourcify-style bytecode and metadata comparison. This page says what a result actually proves, because "verified" is a word that carries more weight than it earns. How the comparison works The runtime bytecode at the address is fetched with eth_getCode . The published Solidity source is compiled with the recorded compiler version and settings. The two are compared byte for byte, with constructor immutables and library links masked. The metadata hash embedded at the end of the bytecode is compared separately. The three results Result What it means Full match The executable bytecode and the embedded metadata hash are byte-identical to the compiled artifact. This proves the exact source and compiler settings in the repository were deployed. Partial match The executable bytecode is byte-identical, but the trailing metadata hash differs. The deployed logic is this source, recompiled with slightly different metadata, for example a different set of surrounding source files, file paths, or comments in the compilation unit. No match The executable bytecode itself differs. The deployed code is not this source. A partial match is not a weaker claim about the logic. The logic is proven identical. What differs is the compilation context recorded alongside it. What a verified list does not prove Absence from the list is not a failure, and it is not a pass either. A contract that has not been checked has not been checked. A "no match" count of zero is a statement about the rows that were examined, and nothing at all about the ones that were not. The published results page states its own coverage for this reason: how many contracts hold live runtime code, how many of those appear in the table, and how many are known not to reproduce from the public repository. Read that paragraph before reading the table. Where the results are Verified contracts carries the current table, the coverage statement and the compiler settings used for each row. Verifying one yourself Everything needed is public: the addresses are in the SDK's address registry, the sources are in the public repositories, and eth_getCode is available on any endpoint or on your own node. The comparison needs no permission from us, which is the only property that makes it worth anything. Previous Foundry Next TypeScript SDK On this page How the comparison works The three results What a verified list does not prove Where the results are Verifying one yourself --- # Connect to the network · AERE Documentation URL: https://aere.network/docs/getting-started/connect Fetched: 2026-09-15 Connect to the network · AERE Documentation Connect to the network Chain ID, RPC endpoints, explorer and currency, for a wallet or a script. Getting started What AERE is Connect to the network Tooling that works unchanged Your first transaction Your first contract Faucet Next steps Build EVM compatibility JSON-RPC Fees and the base fee floor Events and logs Hardhat Foundry Verifying a contract TypeScript SDK Post-quantum Overview, stated precisely The five precompiles Falcon input framing The certificate anchor Verify an anchor yourself Hybrid certificates Threat model Requiring a post-quantum signature not written Network Chain parameters Consensus Anchor schedule Enforcement heights Fork history Public endpoints Network operations Run a node Requirements Install Configure Sync Monitor Troubleshoot Reference Protocol specification Precompile ABI Indexer API JSON-RPC methods Contract registry Genesis Glossary Docs / Getting started / Connect to the network Everything a wallet, a script or a node needs to reach chain 2800. Network details Field Value Network name AERE Network Chain ID 2800 RPC URL https://rpc.aere.network Second RPC URL https://rpc2.aere.network Currency symbol AERE Currency decimals 18 WebSocket wss://wss.aere.network Block explorer https://explorer.aere.network There is a one-click page at /addnetwork.html that hands these to an injected wallet through wallet_addEthereumChain . Check that you reached the right chain Do not take the endpoint's word for it. Two calls settle it: the chain ID, and the genesis hash. curl -s -X POST -H 'content-type: application/json' \ -d '{"jsonrpc":"2.0","id":1,"method":"eth_chainId","params":[]}' \ https://rpc.aere.network The result is "0xaf0" , which is 2800. curl -s -X POST -H 'content-type: application/json' \ -d '{"jsonrpc":"2.0","id":1,"method":"eth_getBlockByNumber","params":["0x0",false]}' \ https://rpc.aere.network The hash field must be 0xd86d57a899cbfa580669f0e1c7cd4ae5f525247c3c823f8f75df176a0c5d7f1a . That value covers every consensus-relevant genesis field, so a match is a complete identity check and a mismatch means you are talking to something else. From code import { JsonRpcProvider } from 'ethers'; const provider = new JsonRpcProvider('https://rpc.aere.network', { name: 'aere', chainId: 2800, }); const head = await provider.getBlockNumber(); const genesis = await provider.getBlock(0); console.log(head, genesis.hash); Which endpoint to use rpc.aere.network and rpc2.aere.network are both public read endpoints operated by the Foundation. Use either. For subscriptions, use wss://wss.aere.network . Both of them are ours. If you are verifying a claim we made about this chain, running the check against our server proves less than you might want. Running your own node removes that, and Run a node is written for exactly that reason. For indexed history such as transaction lists per address, use the indexer at https://api.aere.network rather than scanning blocks over RPC. See Indexer API . Previous What AERE is Next Tooling that works unchanged On this page Network details Check that you reached the right chain From code Which endpoint to use --- # Faucet · AERE Documentation URL: https://aere.network/docs/getting-started/faucet Fetched: 2026-09-15 Faucet · AERE Documentation Faucet First AERE on mainnet for a new address, so it can pay gas for its first transaction. Getting started What AERE is Connect to the network Tooling that works unchanged Your first transaction Your first contract Faucet Next steps Build EVM compatibility JSON-RPC Fees and the base fee floor Events and logs Hardhat Foundry Verifying a contract TypeScript SDK Post-quantum Overview, stated precisely The five precompiles Falcon input framing The certificate anchor Verify an anchor yourself Hybrid certificates Threat model Requiring a post-quantum signature not written Network Chain parameters Consensus Anchor schedule Enforcement heights Fork history Public endpoints Network operations Run a node Requirements Install Configure Sync Monitor Troubleshoot Reference Protocol specification Precompile ABI Indexer API JSON-RPC methods Contract registry Genesis Glossary Docs / Getting started / Faucet The faucet gives a new address its first AERE on mainnet, so it can pay gas for its first transaction. It is at faucet.aere.network . What it gives Network AERE Network, chain 2800 (mainnet) Amount 0.05 AERE Limit One claim per address and per IP address every 24 hours Cost to you None. The faucet service pays the gas. This is mainnet, not a testnet. The amount is deliberately small: enough to send a first transaction and deploy a small contract, not enough to be worth farming. How it works Enter an address. Your browser performs a few seconds of proof of work, which is what makes automated draining expensive rather than free, and the service sends the drip. The live figures on the faucet page, including its remaining balance and the number of claims paid, are read from the service and from the chain. Believe those over any number written into a page, including this one. What it is not It is not a sale, an airdrop or a distribution. AERE is not listed on any exchange. The faucet exists so that a developer with an empty address can make a first transaction without asking anyone for funds. If you need more than a drip For sustained testing, run against the public test network rather than mainnet, or run a local node with your own genesis. Both keep your experiments off a live chain and remove the rate limit entirely. Then Your first transaction . Previous Your first contract Next Next steps On this page What it gives How it works What it is not If you need more than a drip Then --- # Your first contract · AERE Documentation URL: https://aere.network/docs/getting-started/first-contract Fetched: 2026-09-15 Your first contract · AERE Documentation Your first contract Compile and deploy a Solidity contract with Hardhat or Foundry. Getting started What AERE is Connect to the network Tooling that works unchanged Your first transaction Your first contract Faucet Next steps Build EVM compatibility JSON-RPC Fees and the base fee floor Events and logs Hardhat Foundry Verifying a contract TypeScript SDK Post-quantum Overview, stated precisely The five precompiles Falcon input framing The certificate anchor Verify an anchor yourself Hybrid certificates Threat model Requiring a post-quantum signature not written Network Chain parameters Consensus Anchor schedule Enforcement heights Fork history Public endpoints Network operations Run a node Requirements Install Configure Sync Monitor Troubleshoot Reference Protocol specification Precompile ABI Indexer API JSON-RPC methods Contract registry Genesis Glossary Docs / Getting started / Your first contract Compile and deploy a Solidity contract to chain 2800. The contract itself is ordinary; only the network entry is AERE-specific. The contract // SPDX-License-Identifier: MIT pragma solidity ^0.8.24; contract Counter { uint256 public value; event Bumped(address indexed by, uint256 to); function bump() external { value += 1; emit Bumped(msg.sender, value); } } With Hardhat // hardhat.config.js module.exports = { solidity: '0.8.24', networks: { aere: { url: 'https://rpc.aere.network', chainId: 2800, accounts: [process.env.PRIVATE_KEY], }, }, }; npx hardhat compile npx hardhat run scripts/deploy.js --network aere With Foundry forge create src/Counter.sol:Counter \ --rpc-url https://rpc.aere.network \ --chain 2800 \ --private-key $PRIVATE_KEY What to expect Deployment lands in the next block, so roughly half a second. receipt.status is 1 and the block is final. There is no reorganisation risk to wait out. The address is deterministic from your sender and nonce, exactly as on Ethereum. Solidity version and EVM target Compile for osaka or any earlier target. Chain 2800 activates Homestead through Osaka plus one AERE milestone which adds the five post-quantum precompiles and EIP-2935 historical block hashes. Nothing in that milestone removes or changes an opcode, so a contract compiled for Osaka, Prague, Cancun or Shanghai behaves the same here as on Ethereum. If you want your contract to call a post-quantum verifier, it is a plain staticcall to a fixed address. See The five precompiles . Previous Your first transaction Next Faucet On this page The contract With Hardhat With Foundry What to expect Solidity version and EVM target --- # Your first transaction · AERE Documentation URL: https://aere.network/docs/getting-started/first-transaction Fetched: 2026-09-15 Your first transaction · AERE Documentation Your first transaction Send AERE from a script with ethers or viem, and read the receipt. Getting started What AERE is Connect to the network Tooling that works unchanged Your first transaction Your first contract Faucet Next steps Build EVM compatibility JSON-RPC Fees and the base fee floor Events and logs Hardhat Foundry Verifying a contract TypeScript SDK Post-quantum Overview, stated precisely The five precompiles Falcon input framing The certificate anchor Verify an anchor yourself Hybrid certificates Threat model Requiring a post-quantum signature not written Network Chain parameters Consensus Anchor schedule Enforcement heights Fork history Public endpoints Network operations Run a node Requirements Install Configure Sync Monitor Troubleshoot Reference Protocol specification Precompile ABI Indexer API JSON-RPC methods Contract registry Genesis Glossary Docs / Getting started / Your first transaction Send AERE from a script, and read the receipt. Nothing here is AERE-specific except the chain ID and the endpoint. With ethers v6 import { JsonRpcProvider, Wallet, parseEther } from 'ethers'; const provider = new JsonRpcProvider('https://rpc.aere.network', { name: 'aere', chainId: 2800 }); const wallet = new Wallet(process.env.PRIVATE_KEY, provider); const tx = await wallet.sendTransaction({ to: '0x0000000000000000000000000000000000000001', value: parseEther('0.001'), }); console.log('sent', tx.hash); const receipt = await tx.wait(); console.log('block', receipt.blockNumber, 'status', receipt.status, 'gas', receipt.gasUsed.toString()); tx.wait() returns after one confirmation, and on AERE one confirmation is final: QBFT commits a block or it does not, and a committed block is not reorganised. You do not need to wait for additional confirmations to treat a transfer as settled. With viem import { createWalletClient, createPublicClient, http, parseEther, defineChain } from 'viem'; import { privateKeyToAccount } from 'viem/accounts'; const aere = defineChain({ id: 2800, name: 'AERE Network', nativeCurrency: { name: 'AERE', symbol: 'AERE', decimals: 18 }, rpcUrls: { default: { http: ['https://rpc.aere.network'] } }, blockExplorers: { default: { name: 'AERE Explorer', url: 'https://explorer.aere.network' } }, }); const account = privateKeyToAccount(process.env.PRIVATE_KEY); const wallet = createWalletClient({ account, chain: aere, transport: http() }); const publicClient = createPublicClient({ chain: aere, transport: http() }); const hash = await wallet.sendTransaction({ to: '0x0000000000000000000000000000000000000001', value: parseEther('0.001'), }); const receipt = await publicClient.waitForTransactionReceipt({ hash }); console.log(receipt.blockNumber, receipt.status); Fees A plain transfer costs 21,000 gas. The base fee has a floor of 1 Gwei, so the minimum cost of a transfer is 21,000 x 1 Gwei = 0.000021 AERE. Both libraries read the fee data from the chain and will do the right thing without help. Keys Never paste a private key into a shell, into a config file that gets committed, or into a page. Read it from the environment, as above. Note also that a key with a stray whitespace character can be printed whole inside a library's error message, so trim what you read and never log a raw error object that may contain key material. Then look at it Every transaction is on the explorer . Paste the hash into the search field, or go straight to https://explorer.aere.network/tx/ . Previous Tooling that works unchanged Next Your first contract On this page With ethers v6 With viem Fees Keys Then look at it --- # Next steps · AERE Documentation URL: https://aere.network/docs/getting-started/next-steps Fetched: 2026-09-15 Next steps · AERE Documentation Next steps Where to go after the first deploy. Getting started What AERE is Connect to the network Tooling that works unchanged Your first transaction Your first contract Faucet Next steps Build EVM compatibility JSON-RPC Fees and the base fee floor Events and logs Hardhat Foundry Verifying a contract TypeScript SDK Post-quantum Overview, stated precisely The five precompiles Falcon input framing The certificate anchor Verify an anchor yourself Hybrid certificates Threat model Requiring a post-quantum signature not written Network Chain parameters Consensus Anchor schedule Enforcement heights Fork history Public endpoints Network operations Run a node Requirements Install Configure Sync Monitor Troubleshoot Reference Protocol specification Precompile ABI Indexer API JSON-RPC methods Contract registry Genesis Glossary Docs / Getting started / Next steps You have a wallet on chain 2800, a transaction and a deployed contract. Where to go depends on what you came for. You are building an application EVM compatibility : which forks are active and what differs. Fees and the base fee floor : the one economic rule that is not Ethereum's. Events and logs : including the state window that makes some answers silently wrong. Indexer API : indexed history without scanning blocks yourself. You came for the cryptography Overview, stated precisely : what is post-quantum here and what is not. Read this before the rest, because it is the part most projects get wrong in their own favour. The five precompiles : addresses, gas, input framing. Verify an anchor yourself : three commands, from an empty directory, using nothing of ours except the chain itself. You want to check us rather than believe us Run a node . Every verification we offer through our own endpoint is, in the end, a verification done on our server. Your own node removes that. Protocol specification : the normative document, including a section on what it cannot state from the published sources. Network operations : who operates the validator set today, client diversity and audit status. You want to talk to someone The code is public at git.aere.network . Issues there are read. The Foundation page says how the project is funded and stewarded. Previous Faucet Next EVM compatibility On this page You are building an application You came for the cryptography You want to check us rather than believe us You want to talk to someone --- # Tooling that works unchanged · AERE Documentation URL: https://aere.network/docs/getting-started/tooling Fetched: 2026-09-15 Tooling that works unchanged · AERE Documentation Tooling that works unchanged Which Ethereum tools work against AERE with nothing but a chain ID change. Getting started What AERE is Connect to the network Tooling that works unchanged Your first transaction Your first contract Faucet Next steps Build EVM compatibility JSON-RPC Fees and the base fee floor Events and logs Hardhat Foundry Verifying a contract TypeScript SDK Post-quantum Overview, stated precisely The five precompiles Falcon input framing The certificate anchor Verify an anchor yourself Hybrid certificates Threat model Requiring a post-quantum signature not written Network Chain parameters Consensus Anchor schedule Enforcement heights Fork history Public endpoints Network operations Run a node Requirements Install Configure Sync Monitor Troubleshoot Reference Protocol specification Precompile ABI Indexer API JSON-RPC methods Contract registry Genesis Glossary Docs / Getting started / Tooling that works unchanged AERE runs the Ethereum Virtual Machine and exposes the standard Ethereum JSON-RPC API. The design target is that a tool which works against Ethereum works against AERE with nothing changed but the chain ID and the RPC URL. Works unchanged Tool What you change MetaMask and other injected wallets Add the network once ethers.js v6 The provider URL and chainId: 2800 viem The chain object Hardhat One entry in networks Foundry --rpc-url and --chain 2800 Solidity, any version targeting Osaka or earlier Nothing Vyper Nothing OpenZeppelin contracts Nothing eth_call -based indexers and subgraph-style pipelines The endpoint The things that are genuinely different Three, and none of them break a standard tool. They change what an answer means. A base fee floor. From block 10,141,734 the base fee cannot fall below 1 Gwei. EIP-1559 is otherwise unchanged. A tool that assumes the base fee decays toward zero on an empty chain will see it stop at the floor. See Fees and the base fee floor . A 512-block state window on the public RPC. Beyond that window, state-reading calls answer from a pruned state and eth_getTransactionCount returns a false 0x0 . Prove facts about accounts with eth_getProof , never with a nonce read against an old block. See Events and logs . Anchor blocks carry a large extraData . Every 128th header carries a post-quantum certificate, which makes those headers tens of kilobytes rather than hundreds of bytes. A client that assumes a small fixed header size will be surprised; a client that reads the field length will not. If you are writing a client If you are implementing a node or a light client rather than an application, the normative document is the protocol specification , not this page. It states what a third-party client must implement to follow chain 2800, including the parts where our own tooling had to be corrected. Previous Connect to the network Next Your first transaction On this page Works unchanged The things that are genuinely different If you are writing a client --- # What AERE is · AERE Documentation URL: https://aere.network/docs/getting-started/what-is-aere Fetched: 2026-09-15 What AERE is · AERE Documentation What AERE is A public EVM Layer 1 with post-quantum signature verification on mainnet, stated precisely and without overclaiming. Getting started What AERE is Connect to the network Tooling that works unchanged Your first transaction Your first contract Faucet Next steps Build EVM compatibility JSON-RPC Fees and the base fee floor Events and logs Hardhat Foundry Verifying a contract TypeScript SDK Post-quantum Overview, stated precisely The five precompiles Falcon input framing The certificate anchor Verify an anchor yourself Hybrid certificates Threat model Requiring a post-quantum signature not written Network Chain parameters Consensus Anchor schedule Enforcement heights Fork history Public endpoints Network operations Run a node Requirements Install Configure Sync Monitor Troubleshoot Reference Protocol specification Precompile ABI Indexer API JSON-RPC methods Contract registry Genesis Glossary Docs / Getting started / What AERE is AERE Network is a public Layer 1 blockchain that runs the Ethereum Virtual Machine. Chain ID 2800. It produces a block roughly every half second with deterministic finality, and it verifies NIST-standardised post-quantum signatures natively, on mainnet, from inside the EVM. What you can rely on Property Value Chain ID 2800 ( 0xaf0 ) Consensus QBFT, ten validators, quorum seven of ten, f=3 Finality Deterministic. A committed block does not reorganise. Block period 0.5 s configured; measured 0.57 s under normal load Native token AERE, 18 decimals, 2,800,000,000 fixed at genesis, no minting EVM Homestead through Osaka, plus one AERE milestone Genesis block 0 hash 0xd86d57a899cbfa580669f0e1c7cd4ae5f525247c3c823f8f75df176a0c5d7f1a Every one of those is checkable from a public endpoint. The genesis hash is the complete chain identity check: it covers every consensus-relevant field including the state root of the genesis allocations, so if your node reports that hash you are on this chain and no other. What makes it different, stated exactly Two things, and both are narrower than the marketing version of them. Five post-quantum verifiers live in the EVM. Falcon-512, Falcon-1024, ML-DSA-44 (FIPS 204), SLH-DSA-SHA2-128s (FIPS 205) and SHAKE256 (FIPS 202) are precompiled contracts at fixed addresses, active on mainnet since block 9,189,161. Any contract can call them. All five pass the official NIST Known-Answer Tests on chain. See The five precompiles . A post-quantum certificate under the block hash. Every 128th block on chain 2800 is an anchor block, and an anchor block does not finalise without a certificate of at least six valid Falcon-512 validator seals bound under its block hash (six of the nine validators of that time; ten validators since 2026-09-11, so six is now above f+1 and below the quorum of seven). See The certificate anchor . What is not true We would rather write this than have you discover it. **A post-quantum verifier called from an ECDSA-authenticated transaction gives no post-quantum security.** The adversary does not attack the verifier, they forge the outer transaction. Having the precompiles is not the same as having protected accounts. Ordinary blocks are secured by classical ECDSA. The post-quantum certificate binds anchor blocks. It is not the case that no block finalises without post-quantum signatures. The AERE Foundation operates the validator set today. What that means for a check you run, and where the path from here is published, is on Network operations . There is no third-party security audit of the post-quantum anchor layer yet. Everything we publish about it is our own work, offered so that you can re-run it rather than believe it. Where to go next Connect to the network , which takes about a minute. Your first transaction . If you came for the cryptography, go straight to Verify an anchor yourself . It is three commands and it does not trust us. Next Connect to the network On this page What you can rely on What makes it different, stated exactly What is not true Where to go next --- # Anchor schedule · AERE Documentation URL: https://aere.network/docs/network/anchor-schedule Fetched: 2026-09-15 Anchor schedule · AERE Documentation Anchor schedule Which heights carry a certificate, and how the grid moved from 32 to 128. Getting started What AERE is Connect to the network Tooling that works unchanged Your first transaction Your first contract Faucet Next steps Build EVM compatibility JSON-RPC Fees and the base fee floor Events and logs Hardhat Foundry Verifying a contract TypeScript SDK Post-quantum Overview, stated precisely The five precompiles Falcon input framing The certificate anchor Verify an anchor yourself Hybrid certificates Threat model Requiring a post-quantum signature not written Network Chain parameters Consensus Anchor schedule Enforcement heights Fork history Public endpoints Network operations Run a node Requirements Install Configure Sync Monitor Troubleshoot Reference Protocol specification Precompile ABI Indexer API JSON-RPC methods Contract registry Genesis Glossary Docs / Network / Anchor schedule Which heights carry a post-quantum certificate, and how to compute the next one. The rule today An anchor height is any height on the grid H + k * 128 , where H = 17,225,968 . Not every multiple of 128: the grid is offset from that height. A client that tests height % 128 == 0 will pick the wrong blocks and reject valid ones. Before block 17,225,968 the interval was 32, on its own grid. History of the interval From block Interval Note 13,014,000 32 Anchor rules armed, minimum seals 0 13,034,000 32 Minimum 3 of 9 14,961,456 32 Minimum 6 of 9, a full quorum 17,047,600 32 Certificate format v2, hybrid 17,225,968 128 Current Deriving it rather than assuming it The reliable way to find anchor heights is to read them off the chain: walk back from the head until you find two headers that carry a certificate, and the distance between them is the interval and their positions fix the grid. The interval has changed twice, so a hard-coded value has been wrong twice; deriving it from the chain is the form that keeps working. A node's own copy of the schedule comes from the published package, not from a page. See Configure . Why the interval exists at all Cost. An anchor header carries the certificate, which is tens of kilobytes. A certificate in every block would multiply that across every height, and the result is not a storage inconvenience: it is a chain whose headers grow faster than any ordinary node can keep. With an interval, the same security property survives with a bounded rewrite window: an adversary without the post-quantum keys can rewrite at most the tail since the last anchor, which at interval 128 is roughly 70 seconds of chain. Seals attached versus seals required The minimum is a floor , not a cap. Nodes attach as many valid seals as arrive in time, so a certificate at a six-of-nine minimum commonly carries eight or nine. Sizing anything from the minimum will under-count; measure the header. Previous Consensus Next Enforcement heights On this page The rule today History of the interval Deriving it rather than assuming it Why the interval exists at all Seals attached versus seals required --- # Consensus · AERE Documentation URL: https://aere.network/docs/network/consensus Fetched: 2026-09-15 Consensus · AERE Documentation Consensus QBFT with ten validators, deterministic finality, and what header validation checks. Getting started What AERE is Connect to the network Tooling that works unchanged Your first transaction Your first contract Faucet Next steps Build EVM compatibility JSON-RPC Fees and the base fee floor Events and logs Hardhat Foundry Verifying a contract TypeScript SDK Post-quantum Overview, stated precisely The five precompiles Falcon input framing The certificate anchor Verify an anchor yourself Hybrid certificates Threat model Requiring a post-quantum signature not written Network Chain parameters Consensus Anchor schedule Enforcement heights Fork history Public endpoints Network operations Run a node Requirements Install Configure Sync Monitor Troubleshoot Reference Protocol specification Precompile ABI Indexer API JSON-RPC methods Contract registry Genesis Glossary Docs / Network / Consensus Chain 2800 runs QBFT, the Byzantine fault tolerant engine from Hyperledger Besu, with ten validators. Parameters Parameter Value Engine QBFT Validators 9 Quorum 7 of 10 Fault tolerance f = 3 Block period 0.5 s configured Finality Deterministic. A committed block is not reorganised. Proposer selection Round-robin, deterministic Seven of ten must agree for a block to commit, so the chain tolerates three faulty or offline validators and stops at three. There is no probabilistic settlement: one confirmation is final. What header validation checks A node validating a header on chain 2800 checks the ordinary Ethereum rules, the QBFT seal rules, the AERE base fee floor from block 10,141,734, and, at anchor heights, the post-quantum certificate. Two behaviours are worth knowing because they surprise client authors: The block hash is not keccak over the raw header. Seals are stripped and the round is set to zero before hashing. An exporter that compares a re-encoded header hash with the one the node reports will disagree from block 1 if it hashes the header as it stands. Each node assembles the final header locally, and the hash does not cover the seals. Two honest neighbours can therefore store different extraData for the same block, legally. If you are measuring the effect of a configuration change, read it from the node you changed, not from a public endpoint. Consensus messages under post-quantum seal Beyond the anchor, the QBFT message layers themselves are moving under post-quantum seals, one layer at a time, each armed at a block height. See Enforcement heights for which layers are in force. The reason it is one layer at a time, rather than all at once, is cost: a hash-based signature costing seconds cannot go on every message of a half-second chain. Measured, putting SLH-DSA-SHA2-128s on every commit took a test network from 0.5 to 4 seconds per block. The seal therefore rides only on the messages that the next anchor's certificate actually needs. Two properties an operator should know A node's store of post-quantum seals is in memory, so a node that has just started has nothing to contribute to the next certificate until it has taken part in a commit. The anchor rules are delivered as node options, and a node judging headers with a different build can interpret the same option differently. A rule change therefore ships as the same build to every node that validates headers, and the check compares the build stamp rather than the options. Previous Chain parameters Next Anchor schedule On this page Parameters What header validation checks Consensus messages under post-quantum seal Two properties an operator should know --- # Network operations · AERE Documentation URL: https://aere.network/docs/network/decentralization Fetched: 2026-09-15 Network operations · AERE Documentation Network operations Who operates the validator set today, client diversity, audit status, and where the path is published. Getting started What AERE is Connect to the network Tooling that works unchanged Your first transaction Your first contract Faucet Next steps Build EVM compatibility JSON-RPC Fees and the base fee floor Events and logs Hardhat Foundry Verifying a contract TypeScript SDK Post-quantum Overview, stated precisely The five precompiles Falcon input framing The certificate anchor Verify an anchor yourself Hybrid certificates Threat model Requiring a post-quantum signature not written Network Chain parameters Consensus Anchor schedule Enforcement heights Fork history Public endpoints Network operations Run a node Requirements Install Configure Sync Monitor Troubleshoot Reference Protocol specification Precompile ABI Indexer API JSON-RPC methods Contract registry Genesis Glossary Docs / Network / Network operations Who operates chain 2800 today, and where the path from here is written down. Who operates the validator set The AERE Foundation operates the validator set today. Ten validators, quorum seven of ten (ten validators since 2026-09-11). The Foundation stewards the protocol, maintains the open-source codebase and funds contributors through a public grants program. What it does, how it is funded and how to engage with it is on the Foundation page . What that means for a verification you run Every check offered through rpc.aere.network is, in the end, performed against a machine the Foundation operates. That is true of every chain's public endpoint, and it is the reason the node package, the genesis file and the exact follower options are published: so that a check can be run somewhere else. If a result matters to you, run it against your own node. See Run a node . Audit status The network has not completed a third-party security audit. The proofs, conformance tests and verification tools published by the project are its own work, offered so that anyone can re-run them rather than take them on trust. Client diversity Mainnet blocks are produced by the AERE client, which is Hyperledger Besu with the published patches. A second, independently derived client exists and produces blocks on a public test network, including post-quantum seals. Moving a second client into mainnet production is a validator-set decision rather than a code question. Where the path is published The decentralization path is set out in the project roadmap and in the whitepaper, both of which are linked from the About page . This documentation covers how the chain works; the roadmap covers where it is going. Previous Public endpoints Next Requirements On this page Who operates the validator set What that means for a verification you run Audit status Client diversity Where the path is published --- # Public endpoints · AERE Documentation URL: https://aere.network/docs/network/endpoints Fetched: 2026-09-15 Public endpoints · AERE Documentation Public endpoints RPC, explorer, indexer, and what each one is and is not good for. Getting started What AERE is Connect to the network Tooling that works unchanged Your first transaction Your first contract Faucet Next steps Build EVM compatibility JSON-RPC Fees and the base fee floor Events and logs Hardhat Foundry Verifying a contract TypeScript SDK Post-quantum Overview, stated precisely The five precompiles Falcon input framing The certificate anchor Verify an anchor yourself Hybrid certificates Threat model Requiring a post-quantum signature not written Network Chain parameters Consensus Anchor schedule Enforcement heights Fork history Public endpoints Network operations Run a node Requirements Install Configure Sync Monitor Troubleshoot Reference Protocol specification Precompile ABI Indexer API JSON-RPC methods Contract registry Genesis Glossary Docs / Network / Public endpoints What each public endpoint is, and what it is not good for. The endpoints Endpoint What it is https://rpc.aere.network Public JSON-RPC read endpoint https://rpc2.aere.network Second public JSON-RPC endpoint wss://wss.aere.network WebSocket, for eth_subscribe wss://api.aere.network/ws Second WebSocket endpoint https://explorer.aere.network Block explorer, human-facing https://api.aere.network Indexer REST API, for indexed history All of them are operated by the AERE Foundation. Which one for which job Reading the chain right now : either HTTPS endpoint. eth_blockNumber , eth_getBlockByNumber , eth_call , eth_sendRawTransaction and the rest of the standard set. Watching for new blocks : a WebSocket endpoint with eth_subscribe . Subscriptions are not available over HTTPS. History for an address : the indexer, not the RPC. Scanning blocks over RPC to find an address's transactions is slow and will time out. See Indexer API . Proving something about an account : eth_getProof , and only that. See the state window below. The state window, and the false zero The public RPC keeps state for 512 blocks . Beyond that window, state-reading calls answer from a pruned state, and eth_getTransactionCount returns a false 0x0 rather than an error. That is the dangerous shape: an answer that looks like a measurement. A tool that reads a nonce at an old block and concludes "this account has never transacted" is wrong, and nothing tells it so. Prove facts about accounts with eth_getProof , which either answers or fails. At 512 blocks and half-second blocks, the window is roughly four minutes of chain. A node that is down is not a node that says zero If you build monitoring against these endpoints, treat "no answer" as its own state and never as zero. A node that is catching up may not answer RPC at all, and a peer count or a height read as zero in that moment is not a measurement of anything. Rate limits and etiquette The endpoints are public and unauthenticated. They are also a small number of real machines. If you need sustained throughput, run your own node: the package, the genesis and the exact options are published for that. See Run a node . Previous Fork history Next Network operations On this page The endpoints Which one for which job The state window, and the false zero A node that is down is not a node that says zero Rate limits and etiquette --- # Enforcement heights · AERE Documentation URL: https://aere.network/docs/network/enforcement-heights Fetched: 2026-09-15 Enforcement heights · AERE Documentation Enforcement heights The heights at which each consensus message layer starts requiring a post-quantum seal. Getting started What AERE is Connect to the network Tooling that works unchanged Your first transaction Your first contract Faucet Next steps Build EVM compatibility JSON-RPC Fees and the base fee floor Events and logs Hardhat Foundry Verifying a contract TypeScript SDK Post-quantum Overview, stated precisely The five precompiles Falcon input framing The certificate anchor Verify an anchor yourself Hybrid certificates Threat model Requiring a post-quantum signature not written Network Chain parameters Consensus Anchor schedule Enforcement heights Fork history Public endpoints Network operations Run a node Requirements Install Configure Sync Monitor Troubleshoot Reference Protocol specification Precompile ABI Indexer API JSON-RPC methods Contract registry Genesis Glossary Docs / Network / Enforcement heights The QBFT message layers move under post-quantum seals one layer at a time, each armed at a block height. This page says which layers are in force. The schedule Layer Height Status Commit 17,250,000 In force Proposal 17,400,000 Armed, not yet reached at height 17,395,409 on 2026-09-06 Round change 17,550,000 Armed Prepare 17,700,000 Armed "Armed" means every node carries the rule and the height, and the rule begins to apply when the chain reaches it. Read the current height from any endpoint and compare; do not trust this table to be fresh. Why one layer at a time A hash-based post-quantum signature costs seconds, and this chain produces a block every half second. Measured: putting SLH-DSA-SHA2-128s on every commit message took a test network from 0.5 to 4 seconds per block. Enforcing all four layers at once would not have been a stricter chain, it would have been a stopped one. Layering also means each step can be observed on the live chain before the next is armed: after the commit layer came into force, the measurement was nine of nine validators, zero rejections, zero round changes, and block rate inside its normal band. Why heights and not timestamps Every AERE rule activates on a block number, delivered through per-node system properties rather than through genesis. That is a deliberate choice for a chain whose validator set is small enough to coordinate, and it has a real cost: two nodes with different heights do not agree on what a valid header is, and nothing in the protocol makes them agree. The mitigation is procedural rather than cryptographic: uniformity across the fleet is measured, and a split configuration is treated as an open defect. If you run a node, this is the reason the configuration page tells you to take the options from a live node rather than write them by hand. See Configure . Coordinated postponement is the safe move If a milestone has to be moved, it is moved on every node before the height, not disarmed on one. A node that validates differently from its neighbours does not fail loudly; it goes quiet, or it forks. Ethereum postponed Constantinople by 200,000 blocks a day before activation, and that remains the right shape for a chain that is already running. Previous Anchor schedule Next Fork history On this page The schedule Why one layer at a time Why heights and not timestamps Coordinated postponement is the safe move --- # Fork history · AERE Documentation URL: https://aere.network/docs/network/forks Fetched: 2026-09-15 Fork history · AERE Documentation Fork history Every AERE rule change, by block number, and what it changed. Getting started What AERE is Connect to the network Tooling that works unchanged Your first transaction Your first contract Faucet Next steps Build EVM compatibility JSON-RPC Fees and the base fee floor Events and logs Hardhat Foundry Verifying a contract TypeScript SDK Post-quantum Overview, stated precisely The five precompiles Falcon input framing The certificate anchor Verify an anchor yourself Hybrid certificates Threat model Requiring a post-quantum signature not written Network Chain parameters Consensus Anchor schedule Enforcement heights Fork history Public endpoints Network operations Run a node Requirements Install Configure Sync Monitor Troubleshoot Reference Protocol specification Precompile ABI Indexer API JSON-RPC methods Contract registry Genesis Glossary Docs / Network / Fork history Every AERE rule change, by block number. Standard Ethereum forks are on Chain parameters ; this page is the AERE-specific ones. The list Block Change 2,137,652 Block period drops from 1.050 to 0.544 seconds, measured on timestamps. See the note on this height in Chain parameters . 9,189,161 The AERE EVM milestone: five post-quantum precompiles and EIP-2935 historical block hashes become active. 10,141,734 Base fee floor: the EIP-1559 base fee cannot fall below 1 Gwei. 13,014,000 Post-quantum anchor rules armed, minimum seals 0 (warm-up). 13,034,000 Anchor minimum 3 of 9 valid Falcon-512 seals, f+1 . 14,050,000 Nothing changed. See the correction below. 14,961,456 Anchor minimum 6 of 9, a full 2f+1 quorum. 17,047,600 Anchor certificate format v2: hybrid Falcon-512 and SLH-DSA-SHA2-128s. 17,225,968 Anchor interval moves from 32 to 128, on a grid offset from that height. 17,250,000 QBFT commit messages require a post-quantum seal. 17,400,000 QBFT proposal messages require a post-quantum seal. 17,550,000 QBFT round-change messages require a post-quantum seal. 17,700,000 QBFT prepare messages require a post-quantum seal. The last three are armed and take effect when the chain reaches them. Compare against the current height rather than trusting this table to be fresh. The correction at 14,050,000 Until 2026-08-19, this project's website, whitepaper and press releases in seven languages stated that from block 14,050,000 no block finalises without a six-of-nine post-quantum quorum. That was false. The property armed at that height is a per-block rule which the shipped code retires when the anchor rules activate. Reading the source and the deployed bytecode, and then the chain itself, settles it: between anchors, blocks carry zero Falcon seals, and a per-block rule would have rejected all of them. Nothing changed at 14,050,000. The correction was published the same day, dated, in every language the original claim appeared in. The row is kept in this table rather than deleted, because a fork history that quietly loses a retracted entry is not a history. How AERE rules activate By block number, through per-node system properties, not through genesis. The consequences of that choice, including the one that bites, are on Enforcement heights . Previous Enforcement heights Next Public endpoints On this page The list The correction at 14,050,000 How AERE rules activate --- # Chain parameters · AERE Documentation URL: https://aere.network/docs/network/parameters Fetched: 2026-09-15 Chain parameters · AERE Documentation Chain parameters Identity, supply, block period, and the genesis values a client must not correct. Getting started What AERE is Connect to the network Tooling that works unchanged Your first transaction Your first contract Faucet Next steps Build EVM compatibility JSON-RPC Fees and the base fee floor Events and logs Hardhat Foundry Verifying a contract TypeScript SDK Post-quantum Overview, stated precisely The five precompiles Falcon input framing The certificate anchor Verify an anchor yourself Hybrid certificates Threat model Requiring a post-quantum signature not written Network Chain parameters Consensus Anchor schedule Enforcement heights Fork history Public endpoints Network operations Run a node Requirements Install Configure Sync Monitor Troubleshoot Reference Protocol specification Precompile ABI Indexer API JSON-RPC methods Contract registry Genesis Glossary Docs / Network / Chain parameters Every value on this page is readable from a public endpoint. Where a value is surprising, the surprise is explained rather than smoothed over. Identity Parameter Value Chain ID 2800 ( 0xaf0 ) Network ID 2800 Consensus QBFT, Hyperledger Besu implementation Native token AERE, 18 decimals Genesis supply 2,800,000,000 AERE, fixed, no minting Genesis file sha256 e5038e6a1437bd85fa51294609edf2126a997f14f4fa7a65a0d39bd0aa24d2e5 Block 0 hash 0xd86d57a899cbfa580669f0e1c7cd4ae5f525247c3c823f8f75df176a0c5d7f1a The block 0 hash covers every consensus-relevant genesis field including the state root of the allocations, so matching it is the complete identity check. A node that reports that hash is on this chain. The file digest changed on 2026-09-10, when a third pqRegistryHash entry (block 18,082,816) was added to config ; the block 0 hash did not change. Before that date the file digest was 361709dcce… . EVM fork schedule Fork Activation Homestead through Shanghai block 0 / time 0 Cancun timestamp 1780189051 Prague timestamp 1780189051, the same instant as Cancun Osaka timestamp 1780220351 The AERE milestone timestamp 1783820272, first block 9,189,161 The AERE milestone is not upstream Besu's futureEips . Upstream bases that on the unreleased Amsterdam definition, which commits state differently. Chain 2800 isolates it on the Osaka definition and adds, in that same fork, the five post-quantum precompiles and EIP-2935 historical block hashes, which performs one system state write per block into the ring buffer at 0x0000F90827F1C53a10cb7A02335B175320002935 . A client carrying Osaka rules plus those two additions computes the same state roots as the fleet. A client carrying upstream's Amsterdam-based futureEips does not: it stops at block 9,189,161 with a state root mismatch. That is not a hypothetical, it is how the height was measured. Block period Configured at 0.5 seconds. Measured 0.57 seconds under normal load. The transition to sub-second blocks happened at block 2,137,652 , where the rate moves from 1.050 to 0.544 seconds per block, a factor of 1.93. The genesis file every node runs carries 2,138,451 for that transition, not 2,137,652. The two differ by 799 blocks. The value in the running configuration is the one clients must use; the measured value is the answer to "when did the chain speed up". Do not "fix" the genesis: a node with a corrected file computes a different chain. An archive node has resynchronised through that window to 13.4 million without stopping, so the value does not impede sync. Supply 2,800,000,000 AERE allocated at genesis across six accounts, summing to exactly 2.8e27 wei. There is no minting. The comment strings inside those allocations are not consensus data, are read by no client, and two of them are textually wrong; the file is published byte for byte as the fleet holds it rather than tidied. Previous Requiring a post-quantum signature Next Consensus On this page Identity EVM fork schedule Block period Supply --- # The certificate anchor · AERE Documentation URL: https://aere.network/docs/post-quantum/anchor-certificate Fetched: 2026-09-15 The certificate anchor · AERE Documentation The certificate anchor What the anchor is, what it proves, and the formulation that survives a hostile reading. Getting started What AERE is Connect to the network Tooling that works unchanged Your first transaction Your first contract Faucet Next steps Build EVM compatibility JSON-RPC Fees and the base fee floor Events and logs Hardhat Foundry Verifying a contract TypeScript SDK Post-quantum Overview, stated precisely The five precompiles Falcon input framing The certificate anchor Verify an anchor yourself Hybrid certificates Threat model Requiring a post-quantum signature not written Network Chain parameters Consensus Anchor schedule Enforcement heights Fork history Public endpoints Network operations Run a node Requirements Install Configure Sync Monitor Troubleshoot Reference Protocol specification Precompile ABI Indexer API JSON-RPC methods Contract registry Genesis Glossary Docs / Post-quantum / The certificate anchor The anchor is the part of AERE that is proven and independently verifiable. This page states it exactly, including the parts that make it smaller than it sounds. The claim, in one sentence Every 128th block of chain 2800 does not finalise without a certificate of at least six valid Falcon-512 validator seals bound under its block hash (six of the nine validators of that time; ten validators since 2026-09-11, so six is now above f+1 and below the quorum of seven). Three of nine before block 14,961,456; six from that height, which was then a full 2f+1 quorum of nine. Since ten validators since 2026-09-11 the threshold is still six, now above f+1 and below the ten-validator quorum of seven. Every 32nd block before block 17,225,968; every 128th from that height. How the binding works The block hash in QBFT is not keccak over the raw header: seals are stripped and the round is zeroed before hashing. So anything a decoder discards is discarded before the hash. The certificate itself therefore does not go under keccak directly. What goes under keccak is a 32-byte digest of the certificate, carried in vanityData , element 0 of extraData , which is already inside the hashed pre-image. Changing one byte of the certificate changes the digest, which changes the block hash, which breaks every child block. What it protects, and what it does not An adversary who holds every classical validator key and no Falcon key can rewrite at most the tail since the last anchor. That is a fork depth of at most 128 blocks, roughly 70 seconds. Rewriting anything below an anchor changes that anchor's parent hash, forces the anchor to be reproduced, and reproducing it requires Falcon signatures the adversary does not have. What it does not do: It does not make ordinary blocks post-quantum. Blocks between anchors carry no Falcon seals and are finalised by ECDSA alone. It does not make consensus post-quantum. Proposal, identity, transport and per-block finality are secp256k1. The anchor is a binding, not a replacement. It does not give slashable safety. A validator that signs two conflicting anchors is not punished by the protocol. It is not audited. No third party has reviewed this code. Activation is by node configuration, not by genesis This is a real caveat and we would rather state it than have it found. The anchor rules are armed through per-node system properties, not through a genesis milestone. Two nodes configured with different heights or different minimum seal counts do not agree on what a valid header is. The fleet is checked for uniformity, and a split configuration is treated as an open defect rather than a warning. History Block Change 13,014,000 Anchor rules armed. Minimum seals 0, a deliberate warm-up window. 13,034,000 Minimum 3 of 9, that is f+1 , enforced on the fleet from 2026-08-14. 14,961,456 Minimum 6 of 9, a full 2f+1 quorum, the same count QBFT itself requires. 17,047,600 Certificate format v2, hybrid. See Hybrid certificates . 17,225,968 Interval moves from every 32nd block to every 128th. A correction we published against ourselves Until 2026-08-19 our own site, whitepaper and press releases said that from block 14,050,000 no block finalises without a six-of-nine post-quantum quorum. That was false. The property armed at that height is a per-block rule that the shipped code retires at the anchor activation, so nothing changed at 14,050,000. The correction was published the same day in seven languages. The formulation on this page is the one that survives being checked. Check it rather than believe it Verify an anchor yourself . Three commands, from an empty directory. Previous Falcon input framing Next Verify an anchor yourself On this page The claim, in one sentence How the binding works What it protects, and what it does not Activation is by node configuration, not by genesis History A correction we published against ourselves Check it rather than believe it --- # Falcon input framing · AERE Documentation URL: https://aere.network/docs/post-quantum/falcon-input-format Fetched: 2026-09-15 Falcon input framing · AERE Documentation Falcon input framing The exact byte layout the Falcon precompiles expect. The message sits in the middle. Getting started What AERE is Connect to the network Tooling that works unchanged Your first transaction Your first contract Faucet Next steps Build EVM compatibility JSON-RPC Fees and the base fee floor Events and logs Hardhat Foundry Verifying a contract TypeScript SDK Post-quantum Overview, stated precisely The five precompiles Falcon input framing The certificate anchor Verify an anchor yourself Hybrid certificates Threat model Requiring a post-quantum signature not written Network Chain parameters Consensus Anchor schedule Enforcement heights Fork history Public endpoints Network operations Run a node Requirements Install Configure Sync Monitor Troubleshoot Reference Protocol specification Precompile ABI Indexer API JSON-RPC methods Contract registry Genesis Glossary Docs / Post-quantum / Falcon input framing This page is normative and it is the single most common integration mistake against chain 2800. The message goes in the middle of the input, not at the end. The layout input = pk || sm pk = (0x00 + logn) || packed_h 897 bytes for Falcon-512 (logn = 9, header byte 0x09) 1793 bytes for Falcon-1024 (logn = 10, header byte 0x0A) sm = sigLen(2 bytes, big-endian) || nonce(40) || message || esig esig = (0x20 + logn) || compressedSignature header 0x29 for Falcon-512, 0x2A for Falcon-1024 sigLen == len(esig) This is the NIST reference signed-message convention. If you pass a detached signature with the message appended at the end, the way most non-Falcon APIs work, the precompile returns a clean zero for a perfectly valid signature and looks dead. Two things that will bite you Falcon signatures are variable length. They are compressed. Two signatures produced by the same key measured 614 and 616 bytes. sigLen must be read per call and written into the two-byte prefix each time. A hard-coded length works today and fails tomorrow, on a signature that is perfectly valid. Zero is ambiguous. The precompile does not revert on malformed input; it returns the zero word. So a wrong layout and a bad signature are indistinguishable from the outside. Put a positive control in the same run: a signature you know is good, framed the way you believe is right. If that comes back zero, nothing else in that run tells you anything. ML-DSA and SLH-DSA For 0x0AE3 and 0x0AE4 the convention is the ordinary NIST sm = signature || message , with the fixed signature lengths from the precompile table . Everything after pk || sig is the message. SHAKE256 0x0AE5 reads a 32-byte big-endian output length first, then hashes the remaining bytes. Values above 65,536 are capped to 65,536, a non-zero high 28 bytes also caps, and an input shorter than 32 bytes returns empty output. Where this is written down normatively Section 4.2 of the protocol specification , and the source it cites, precompiles/AereFalconSupport.java in the published node package. The specification is the authority; this page is the readable form of it. Previous The five precompiles Next The certificate anchor On this page The layout Two things that will bite you ML-DSA and SLH-DSA SHAKE256 Where this is written down normatively --- # Hybrid certificates · AERE Documentation URL: https://aere.network/docs/post-quantum/hybrid-certificates Fetched: 2026-09-15 Hybrid certificates · AERE Documentation Hybrid certificates Falcon-512 and SLH-DSA-SHA2-128s in the same certificate, live since block 17,047,600. Getting started What AERE is Connect to the network Tooling that works unchanged Your first transaction Your first contract Faucet Next steps Build EVM compatibility JSON-RPC Fees and the base fee floor Events and logs Hardhat Foundry Verifying a contract TypeScript SDK Post-quantum Overview, stated precisely The five precompiles Falcon input framing The certificate anchor Verify an anchor yourself Hybrid certificates Threat model Requiring a post-quantum signature not written Network Chain parameters Consensus Anchor schedule Enforcement heights Fork history Public endpoints Network operations Run a node Requirements Install Configure Sync Monitor Troubleshoot Reference Protocol specification Precompile ABI Indexer API JSON-RPC methods Contract registry Genesis Glossary Docs / Post-quantum / Hybrid certificates From block 17,047,600 an anchor certificate carries two different post-quantum signature families at once: Falcon-512, which is lattice-based, and SLH-DSA-SHA2-128s, which is hash-based. Why two The two families rest on different mathematics. If lattice assumptions fall, the hash-based half still holds. If something is found in the hash-based construction, the lattice half still holds. A single family is a single point of cryptanalytic failure, and the whole point of the anchor is to be the part of the chain that survives. This was only affordable because the certificate is periodic. Hash-based signatures are large, and carrying one in every block would have grown the headers faster than a node can keep. Once the anchor became every 32nd and then every 128th block, both families fit. The format v1 v2 From block 13,014,000 17,047,600 Domain AERE-PQ-ANCHOR-1 AERE-PQ-ANCHOR-2 Encoding list of [index, falconSignature] RLP[2, [[scheme, index, signature], …]] Schemes Falcon-512 only 1 = Falcon-512, 2 = SLH-DSA-SHA2-128s The v2 digest is keccak256(RLP[domain, chainId, parentNumber, parentHash, BYTES(rlp(certificate))]) . The rules that make it a hybrid rather than a mixture Three, and they are enforced, not conventions. The scheme schedule names which schemes are required at a given height, so a node cannot quietly drop one. The minimum seal count applies to each scheme separately . Six Falcon seals and one SLH-DSA seal is not a valid quorum. Every SLH-DSA seal must sit at an index that also carries a valid Falcon seal from the same validator. Measured over 400 consecutive anchors. What it cost, measured A hash-based signature is large and slow, and both showed up on the live chain. Header size: an anchor header carries roughly 53 KB more under the hybrid format. Block rate: after the first hybrid anchor the chain slowed from 0.56 to 0.76 seconds per block, and the parent-plus-anchor cycle cost 8.4 seconds instead of 1. The cause of the slowdown was not the signature but the hash . SLH-DSA performs millions of short hashes, and the SHA-256 implementation in use was pure Java while the platform's own SHA-256 uses hardware instructions. Moving to the platform digest took signing from 2.7 seconds to 0.6 per validator, with byte-identical signatures, proven by cross-verification in both directions. The general lesson, which we now apply before adding any primitive to a consensus path: measure its cost on that machine with that implementation, and when a primitive looks inexplicably expensive, look at what it hashes rather than what it signs. Previous Verify an anchor yourself Next Threat model On this page Why two The format The rules that make it a hybrid rather than a mixture What it cost, measured --- # Overview, stated precisely · AERE Documentation URL: https://aere.network/docs/post-quantum/overview Fetched: 2026-09-15 Overview, stated precisely · AERE Documentation Overview, stated precisely What is post-quantum on AERE today, what is not, and why the distinction is the whole point. Getting started What AERE is Connect to the network Tooling that works unchanged Your first transaction Your first contract Faucet Next steps Build EVM compatibility JSON-RPC Fees and the base fee floor Events and logs Hardhat Foundry Verifying a contract TypeScript SDK Post-quantum Overview, stated precisely The five precompiles Falcon input framing The certificate anchor Verify an anchor yourself Hybrid certificates Threat model Requiring a post-quantum signature not written Network Chain parameters Consensus Anchor schedule Enforcement heights Fork history Public endpoints Network operations Run a node Requirements Install Configure Sync Monitor Troubleshoot Reference Protocol specification Precompile ABI Indexer API JSON-RPC methods Contract registry Genesis Glossary Docs / Post-quantum / Overview, stated precisely Read this page before the rest of the section. It is the part that most projects state in their own favour, and stating it accurately is the only reason the rest of our claims are worth anything. Two separate things There are two post-quantum mechanisms on chain 2800, at different layers, with different guarantees. Layer one: verification inside the EVM. Five precompiled contracts verify NIST post-quantum signatures and hashes. Live on mainnet since block 9,189,161. Any contract can call them. They are a capability offered to applications. Layer two: a certificate under the block hash. Every 128th block does not finalise without a certificate of at least six valid Falcon-512 validator seals bound under its block hash (six of the nine validators of that time; ten validators since 2026-09-11, so six is now above f+1 and below the quorum of seven). Live since block 13,014,000, at a quorum of six since block 14,961,456. What the first one does not buy you A post-quantum verifier called from a transaction that was authenticated with ECDSA provides no post-quantum security. The adversary does not attack the verifier. They forge the outer transaction. This is not a subtlety we are being modest about; it is the whole argument. "Post-quantum precompiles are live" is true and it does not mean "accounts are protected". An account is protected only when moving its funds requires a post-quantum signature, which is an application-level construction on top of the precompiles, not a property of having them. A second, equally hard point: "a primitive is an address you call" is not an architecture. It is the EVM since 2015, with 0x01 for ecrecover and 0x08 for pairings. Anyone can deploy a Dilithium verifier in Solidity on Ethereum today. The difference between that and a native precompile is gas, which is a number, not a thesis. What the second one does buy you The block hash is the thing every other node, light client and bridge already relies on. On chain 2800 that hash covers a 32-byte commitment to a certificate of post-quantum validator signatures. So an adversary who holds every classical validator key, and no Falcon key, can rewrite at most the tail since the last anchor. Rewriting anything below an anchor changes that anchor's parent hash, which forces the anchor to be reproduced, and reproducing it needs Falcon signatures the adversary does not have. The honest boundary, in one sentence: history below the last anchor is bound by post-quantum signatures; individual blocks are still finalised by classical ECDSA. What we do not claim Not "no block finalises without post-quantum signatures". Only anchor blocks carry a certificate. Not "post-quantum consensus". Proposal, identity, transport and per-block finality are secp256k1 ECDSA. The anchor is a binding on top, not a replacement. Not "the only chain that can do this". Other codebases can bind post-quantum signatures under a block hash. What we claim is narrower and is about verifiability: ours is proven and independently verifiable , and you can check it in three commands without asking us. See Verify an anchor yourself . Not audited. No third party has reviewed the anchor code. Where to read the rest The five precompiles , with addresses and gas. Falcon input framing , which is where integrations fail. The certificate anchor , stated exactly. Threat model , including which quantum threat does not apply. Previous TypeScript SDK Next The five precompiles On this page Two separate things What the first one does not buy you What the second one does buy you What we do not claim Where to read the rest --- # Requiring a post-quantum signature · AERE Documentation URL: https://aere.network/docs/post-quantum/pq-accounts Fetched: 2026-09-15 Requiring a post-quantum signature · AERE Documentation Requiring a post-quantum signature How a contract can require a NIST post-quantum signature before it acts, and the limit of what that protects. Getting started What AERE is Connect to the network Tooling that works unchanged Your first transaction Your first contract Faucet Next steps Build EVM compatibility JSON-RPC Fees and the base fee floor Events and logs Hardhat Foundry Verifying a contract TypeScript SDK Post-quantum Overview, stated precisely The five precompiles Falcon input framing The certificate anchor Verify an anchor yourself Hybrid certificates Threat model Requiring a post-quantum signature not written Network Chain parameters Consensus Anchor schedule Enforcement heights Fork history Public endpoints Network operations Run a node Requirements Install Configure Sync Monitor Troubleshoot Reference Protocol specification Precompile ABI Indexer API JSON-RPC methods Contract registry Genesis Glossary Docs / Post-quantum / Requiring a post-quantum signature Not written yet. This page is listed in the documentation tree so the gap is visible rather than hidden. It has no content because no one has written it, and we would rather show that than fill it with text we cannot stand behind. Previous Threat model Next Chain parameters --- # The five precompiles · AERE Documentation URL: https://aere.network/docs/post-quantum/precompiles Fetched: 2026-09-15 The five precompiles · AERE Documentation The five precompiles Addresses, standards, gas, input framing and return values, live on mainnet. Getting started What AERE is Connect to the network Tooling that works unchanged Your first transaction Your first contract Faucet Next steps Build EVM compatibility JSON-RPC Fees and the base fee floor Events and logs Hardhat Foundry Verifying a contract TypeScript SDK Post-quantum Overview, stated precisely The five precompiles Falcon input framing The certificate anchor Verify an anchor yourself Hybrid certificates Threat model Requiring a post-quantum signature not written Network Chain parameters Consensus Anchor schedule Enforcement heights Fork history Public endpoints Network operations Run a node Requirements Install Configure Sync Monitor Troubleshoot Reference Protocol specification Precompile ABI Indexer API JSON-RPC methods Contract registry Genesis Glossary Docs / Post-quantum / The five precompiles Five precompiled contracts verify NIST post-quantum signatures and hashes inside the EVM. They are active on mainnet from block 9,189,161 and callable by any contract with a plain staticcall . The five Address Function Standard Gas Input Output 0x0AE1 Falcon-512 verify NIST Falcon round 3 40,000 flat `pk(897) \ \ sm` 32-byte word: …01 valid, …00 invalid 0x0AE2 Falcon-1024 verify NIST Falcon round 3 75,000 flat `pk(1793) \ \ sm` same 0x0AE3 ML-DSA-44 verify FIPS 204 55,000 flat `pk(1312) \ \ sig(2420) \ \ message` same 0x0AE4 SLH-DSA-SHA2-128s verify FIPS 205 350,000 flat `pk(32) \ \ sig(7856) \ \ message` same 0x0AE5 SHAKE256 XOF FIPS 202 60 + 12 per 32-byte word of input plus output 32-byte big-endian output length, then data outLen bytes Gas is flat, not size-dependent, for the four verifiers. They never revert A verification precompile does not revert on malformed input. It returns the 32-byte zero word. That means a caller cannot distinguish "the signature is invalid" from "I framed the input wrongly" by catching a revert. Both come back as zero. This is the single most common integration failure, and it is why Falcon input framing is a page of its own. Write a positive control into your test: verify a signature you know is good, with framing you know is right, in the same run. If that returns zero, no other zero in that run means anything. Calling one from Solidity // SPDX-License-Identifier: MIT pragma solidity ^0.8.24; library Falcon512 { address internal constant PRECOMPILE = address(0x0AE1); /// @param input pk(897) || sigLen(2 BE) || nonce(40) || message || esig function verify(bytes memory input) internal view returns (bool) { (bool ok, bytes memory out) = PRECOMPILE.staticcall(input); return ok && out.length == 32 && uint256(bytes32(out)) == 1; } } Checking them against the live chain The five pass the official NIST Known-Answer Tests on chain. You can run one yourself against the public endpoint with eth_call , which costs nothing: curl -s -X POST -H 'content-type: application/json' \ -d '{"jsonrpc":"2.0","id":1,"method":"eth_call","params":[{"to":"0x0000000000000000000000000000000000000ae5","data":"0x0000000000000000000000000000000000000000000000000000000000000020616263"},"latest"]}' \ https://rpc.aere.network That asks 0x0AE5 for 32 bytes of SHAKE256 over the three bytes abc , and the answer is the FIPS 202 value for that input. Not on mainnet 0x0AE6 (ML-KEM-768 deterministic encapsulation, FIPS 203) and 0x0AE7 exist on the public testnet only. Do not build mainnet code against them. The caveat that matters Having these does not make an account post-quantum secure. See Overview, stated precisely for why, in one paragraph, before you build on top of them. Previous Overview, stated precisely Next Falcon input framing On this page The five They never revert Calling one from Solidity Checking them against the live chain Not on mainnet The caveat that matters --- # Threat model · AERE Documentation URL: https://aere.network/docs/post-quantum/threat-model Fetched: 2026-09-15 Threat model · AERE Documentation Threat model Which quantum threat applies to a signature, which does not, and what the anchor defends against. Getting started What AERE is Connect to the network Tooling that works unchanged Your first transaction Your first contract Faucet Next steps Build EVM compatibility JSON-RPC Fees and the base fee floor Events and logs Hardhat Foundry Verifying a contract TypeScript SDK Post-quantum Overview, stated precisely The five precompiles Falcon input framing The certificate anchor Verify an anchor yourself Hybrid certificates Threat model Requiring a post-quantum signature not written Network Chain parameters Consensus Anchor schedule Enforcement heights Fork history Public endpoints Network operations Run a node Requirements Install Configure Sync Monitor Troubleshoot Reference Protocol specification Precompile ABI Indexer API JSON-RPC methods Contract registry Genesis Glossary Docs / Post-quantum / Threat model Which quantum threat applies to a blockchain signature, which does not, and what the anchor actually defends against. The threat that does not apply "Harvest now, decrypt later" does not apply to signatures. It is a threat to encrypted data: an adversary records ciphertext today and decrypts it when a capable machine exists. A signature is public the moment it is made. There is nothing to harvest. A claim that HNDL threatens a chain's signatures mixes up two different things, and it is visible to any reader who knows the difference. The threat that does apply, and it is worse A quantum adversary who can recover a private key from a public key can recover validator keys that signed blocks years ago. With those keys they can produce an alternative history that is internally valid, signed by the same validator set, and rewrite the past. This is the long-range or posterior-corruption attack. It is worse than the HNDL framing because it does not need the adversary to be present at the time. The keys are already published, in every block header those validators ever sealed. What the anchor does about it An adversary holding every classical validator key and no Falcon key can rewrite at most the tail since the last anchor: at most 128 blocks, roughly 70 seconds. Rewriting anything below an anchor changes that anchor's parent hash, which forces the anchor to be reproduced, and reproducing it needs Falcon signatures the adversary does not have. History below the anchor activation height remains protected by ECDSA alone, permanently. The anchor cannot reach backwards. Where this sits in the literature The threat has peer-reviewed treatment: Azouvi, Danezis and Nikolaenko, "Winkle: Foiling Long-Range Attacks in Proof-of-Stake Systems", IACR 2019/1440, published at AFT 2020, pages 189 to 201. Two things must be said precisely about that citation: Winkle does not say "quantum" anywhere. It supports the *threat*, that is long-range attacks through old compromised keys. The quantum framing is ours. Winkle's defence is a different one. It proposes a secondary validation layer in which clients sign a hash of the previous block. Ours is a validator certificate under the block hash. So the correct sentence is: the threat has peer-reviewed grounding, the defence is our own. There is a second published defence for the same threat, "Pikachu" (arXiv 2208.05408), which anchors into Bitcoin through Taproot. If you are wondering why we did not simply checkpoint into another chain, that paper is the honest comparison, and the answer is that checkpointing moves your trust to that other chain's liveness and its own signature scheme. What is not defended An adversary who holds the Falcon keys as well. The anchor is a binding on validator behaviour, not a defence against a compromised validator set. Equivocation. Signing two conflicting anchors is not slashable. Anything at the account layer. Ordinary accounts on chain 2800 are secp256k1, exactly as on Ethereum. See Overview . Previous Hybrid certificates Next Requiring a post-quantum signature On this page The threat that does not apply The threat that does apply, and it is worse What the anchor does about it Where this sits in the literature What is not defended --- # Verify an anchor yourself · AERE Documentation URL: https://aere.network/docs/post-quantum/verify-an-anchor Fetched: 2026-09-15 Verify an anchor yourself · AERE Documentation Verify an anchor yourself Three commands, no trust in us, run from an empty directory. Getting started What AERE is Connect to the network Tooling that works unchanged Your first transaction Your first contract Faucet Next steps Build EVM compatibility JSON-RPC Fees and the base fee floor Events and logs Hardhat Foundry Verifying a contract TypeScript SDK Post-quantum Overview, stated precisely The five precompiles Falcon input framing The certificate anchor Verify an anchor yourself Hybrid certificates Threat model Requiring a post-quantum signature not written Network Chain parameters Consensus Anchor schedule Enforcement heights Fork history Public endpoints Network operations Run a node Requirements Install Configure Sync Monitor Troubleshoot Reference Protocol specification Precompile ABI Indexer API JSON-RPC methods Contract registry Genesis Glossary Docs / Post-quantum / Verify an anchor yourself Three commands. They use nothing of ours except the chain itself, and they can be run from an empty directory on a machine that has never touched AERE. Run it curl -O https://aere.network/tools/verify-anchor.mjs \ -O https://aere.network/tools/falcon512.mjs \ -O https://aere.network/tools/package.json && npm install node verify-anchor.mjs The tool reads recent anchor heights from a public endpoint, pulls each header, rebuilds the block hash the way QBFT builds it, recomputes the certificate digest, and verifies every Falcon-512 seal against the validator registry. A clean run prints VERIFIED for each anchor it measured. What the exit code means Code Meaning 0 Verified. Every anchor it measured carried a valid certificate bound under its hash. 1 The chain failed the check. This is the one that matters. 2 Unmeasured here. The tool could not complete the check on this machine, for example a missing verifier for one scheme. Not a pass and not a failure. Exit code 2 exists deliberately. A tool that cannot tell "I checked and it is fine" apart from "I could not check" will report the second as the first, and that is worse than a red result. What it proves and what it does not It proves that the certificates published in those headers verify against the registry, and that the block hash covers them. It does not prove that the registry contains the right keys: that is a question about who the validators are, and it is answered on Network operations . It also, by default, reads the chain through our public endpoint. If you want a check that does not route through a machine we operate, point the tool at your own node. See Run a node . The same tool checks a document The whitepaper is anchored to the chain and re-anchored several times a day, and the same verifier checks that anchor. This is not a second mechanism, it is the same one applied to a different pre-image, which is why we publish one tool rather than two. If it fails If verify-anchor.mjs exits 1 against the live chain, that is a finding about us, not about your setup, and we would like to hear about it at git.aere.network . We build our own gates so that they can go red; a public verifier that has never been able to fail would not be worth publishing. Previous The certificate anchor Next Hybrid certificates On this page Run it What the exit code means What it proves and what it does not The same tool checks a document If it fails --- # Contract registry · AERE Documentation URL: https://aere.network/docs/reference/contract-registry Fetched: 2026-09-15 Contract registry · AERE Documentation Contract registry Canonical addresses and what is verified. Getting started What AERE is Connect to the network Tooling that works unchanged Your first transaction Your first contract Faucet Next steps Build EVM compatibility JSON-RPC Fees and the base fee floor Events and logs Hardhat Foundry Verifying a contract TypeScript SDK Post-quantum Overview, stated precisely The five precompiles Falcon input framing The certificate anchor Verify an anchor yourself Hybrid certificates Threat model Requiring a post-quantum signature not written Network Chain parameters Consensus Anchor schedule Enforcement heights Fork history Public endpoints Network operations Run a node Requirements Install Configure Sync Monitor Troubleshoot Reference Protocol specification Precompile ABI Indexer API JSON-RPC methods Contract registry Genesis Glossary Docs / Reference / Contract registry Where the canonical contract addresses live, and what being in the registry does and does not mean. The single source The canonical address registry is src/addresses.ts in the SDK repository: git.aere.network/aere-network/sdk-js It is deliberately one file in one repository. If an address in a blog post, a diagram or an older page disagrees with it, the registry is right and the other place is stale. This page does not restate the addresses. A list retyped into a web page is a list that goes out of date silently, and there is no reason to have two. What the registry is A mapping from a contract name to the address it is deployed at on chain 2800, used by the SDK so that applications do not hand-copy addresses. What being in it does not mean It does not mean the source has been verified against the deployed bytecode. That is a separate, smaller list. The registry answers "where is this contract". Verification answers "is the code at that address the code we published". Only the second is a claim about trustworthiness, and the published verification table states its own coverage: how many contracts hold live runtime code, how many of those were checked, and how many are known not to reproduce from the public repository. Read Verifying a contract for what a match proves, and Verified contracts for the current table with its coverage statement. Checking an address yourself Everything needed is public and needs no permission from us: curl -s -X POST -H 'content-type: application/json' \ -d '{"jsonrpc":"2.0","id":1,"method":"eth_getCode","params":["0xADDRESS","latest"]}' \ https://rpc.aere.network An empty result ( 0x ) means there is no contract at that address. Anything else is the deployed runtime bytecode, which is what a verification compares against. The precompiles are not in this registry The five post-quantum precompiles live at fixed protocol addresses, not deployed contracts. They are listed on Precompile ABI . Previous JSON-RPC methods Next Genesis On this page The single source What the registry is What being in it does not mean Checking an address yourself The precompiles are not in this registry --- # Genesis · AERE Documentation URL: https://aere.network/docs/reference/genesis Fetched: 2026-09-15 Genesis · AERE Documentation Genesis The genesis file, its hash, and the fields that matter. Getting started What AERE is Connect to the network Tooling that works unchanged Your first transaction Your first contract Faucet Next steps Build EVM compatibility JSON-RPC Fees and the base fee floor Events and logs Hardhat Foundry Verifying a contract TypeScript SDK Post-quantum Overview, stated precisely The five precompiles Falcon input framing The certificate anchor Verify an anchor yourself Hybrid certificates Threat model Requiring a post-quantum signature not written Network Chain parameters Consensus Anchor schedule Enforcement heights Fork history Public endpoints Network operations Run a node Requirements Install Configure Sync Monitor Troubleshoot Reference Protocol specification Precompile ABI Indexer API JSON-RPC methods Contract registry Genesis Glossary Docs / Reference / Genesis The genesis file, its hash, and the fields a client must not correct. Identity File sha256 e5038e6a1437bd85fa51294609edf2126a997f14f4fa7a65a0d39bd0aa24d2e5 Block 0 hash 0xd86d57a899cbfa580669f0e1c7cd4ae5f525247c3c823f8f75df176a0c5d7f1a Chain ID 2800 Consensus QBFT Genesis supply 2,800,000,000 AERE across six accounts, exactly 2.8e27 wei The file hash is of the published file with LF line endings. The block 0 hash covers every consensus-relevant field including the state root of the six allocations, so matching it is the complete identity check. The file digest changed on 2026-09-10, when a third pqRegistryHash entry (block 18,082,816) was added to config ; the block 0 hash did not change. Before that date the file digest was 361709dcce… . Where to get it Inside the node package, as genesis.json . It is published byte for byte as the fleet holds it, not tidied. git clone https://git.aere.network/aere-network/aere-node.git sha256sum aere-node/genesis.json Two fields you must not "fix" The sub-second transition height. The genesis carries 2138451 . The height at which the block period actually changed, measured on timestamps, is 2137652 . The two differ by 799 blocks. The value in the running configuration is the one every node uses, so a node with a "corrected" genesis computes a different chain. Do not change it. An archive node has resynchronised through that window without stopping, so the value does not impede sync. The comment strings inside alloc . They are not consensus data, no client reads them, and two of them are textually wrong. They are published unaltered because the file is published as it is, not as it should have been written. pqRegistryHash The genesis config carries the hashes of the canonical Falcon validator registries, one entry per registry epoch with the height from which it applies: 13,014,000, 13,600,000 and, since 2026-09-10, 18,082,816. Two genesis files can produce the same block 0 hash and still differ in config , and a node whose genesis lacks this field rejects every anchor the moment it receives the anchor rules, while peering happily with nodes that have it. So the genesis check for a node that judges anchors is the file hash , not only the block 0 hash. Compare with sha256sum before giving a node the anchor rules. EVM fork schedule Homestead through Shanghai at block 0, Cancun and Prague at timestamp 1780189051, Osaka at timestamp 1780220351, and the AERE milestone at timestamp 1783820272, whose first block is 9,189,161. Details and the caveat about upstream's futureEips are on Chain parameters . Previous Contract registry Next Glossary On this page Identity Where to get it Two fields you must not "fix" `pqRegistryHash` EVM fork schedule --- # Glossary · AERE Documentation URL: https://aere.network/docs/reference/glossary Fetched: 2026-09-15 Glossary · AERE Documentation Glossary Terms used across this documentation, defined once. Getting started What AERE is Connect to the network Tooling that works unchanged Your first transaction Your first contract Faucet Next steps Build EVM compatibility JSON-RPC Fees and the base fee floor Events and logs Hardhat Foundry Verifying a contract TypeScript SDK Post-quantum Overview, stated precisely The five precompiles Falcon input framing The certificate anchor Verify an anchor yourself Hybrid certificates Threat model Requiring a post-quantum signature not written Network Chain parameters Consensus Anchor schedule Enforcement heights Fork history Public endpoints Network operations Run a node Requirements Install Configure Sync Monitor Troubleshoot Reference Protocol specification Precompile ABI Indexer API JSON-RPC methods Contract registry Genesis Glossary Docs / Reference / Glossary Terms used across this documentation, defined once. Chain and consensus Anchor block. A block whose header carries a post-quantum certificate over its parent, and whose block hash covers a commitment to that certificate. Every 128th block on a grid offset from block 17,225,968. Certificate. The set of validator seals attached to an anchor header, encoded and committed to by a 32-byte digest in vanityData . Deterministic finality. A committed block does not reorganise. One confirmation is final. This is a property of QBFT, not a probabilistic assumption. f . The number of faulty validators the consensus tolerates. On chain 2800, f = 3 with ten validators. Quorum. The number of validators that must agree for a block to commit: seven of ten. QBFT. The Byzantine fault tolerant consensus engine from Hyperledger Besu that chain 2800 runs. Seal. One validator's signature. A classical seal is secp256k1; a post-quantum seal is Falcon-512 or SLH-DSA-SHA2-128s. extraData . The header field carrying QBFT's consensus data. On chain 2800 it has an AERE sixth element, and element 0, vanityData , carries the anchor digest. Cryptography Falcon-512, Falcon-1024. Lattice-based post-quantum signature schemes from the NIST process. Signatures are compressed and therefore variable length. ML-DSA-44. FIPS 204, the standardised lattice-based signature scheme, formerly Dilithium. SLH-DSA-SHA2-128s. FIPS 205, the standardised hash-based signature scheme, formerly SPHINCS+. Large and slow, and dependent on nothing but the hash function. SHAKE256. FIPS 202 extendable-output hash function. Hybrid certificate. A certificate carrying seals from two different signature families at once, so that a break in one family does not break the certificate. Live from block 17,047,600. HNDL, harvest now decrypt later. A threat to encrypted data, not to signatures. It does not apply to a blockchain signature, which is public the moment it is made. See Threat model . Long-range attack. Rewriting old history using validator keys recovered later. This is the threat the anchor addresses. Positive control. A check, run in the same execution as a measurement, that a thing known to be present is found. Without it, a zero from a broken tool is indistinguishable from a zero that was earned. This term appears throughout our documentation because it is the difference between a measurement and a guess. Operations Anchor interval. How often an anchor block occurs. 32 until block 17,225,968, then 128. Enforcement height. The block number at which a consensus rule begins to be required. Follower. A node that follows the chain without producing blocks. Registry. The list of validator post-quantum public keys, indexed, against which certificate seals are verified. Its hash is committed in the genesis config. State window. The number of recent blocks for which an endpoint keeps state. 512 on the public RPC, beyond which some reads return a false zero rather than an error. Previous Genesis On this page Chain and consensus Cryptography Operations --- # Indexer API · AERE Documentation URL: https://aere.network/docs/reference/indexer-api Fetched: 2026-09-15 Indexer API · AERE Documentation Indexer API Every route the public indexer exposes, with its real response shape. Getting started What AERE is Connect to the network Tooling that works unchanged Your first transaction Your first contract Faucet Next steps Build EVM compatibility JSON-RPC Fees and the base fee floor Events and logs Hardhat Foundry Verifying a contract TypeScript SDK Post-quantum Overview, stated precisely The five precompiles Falcon input framing The certificate anchor Verify an anchor yourself Hybrid certificates Threat model Requiring a post-quantum signature not written Network Chain parameters Consensus Anchor schedule Enforcement heights Fork history Public endpoints Network operations Run a node Requirements Install Configure Sync Monitor Troubleshoot Reference Protocol specification Precompile ABI Indexer API JSON-RPC methods Contract registry Genesis Glossary Docs / Reference / Indexer API The public indexer at https://api.aere.network serves indexed history so you do not have to scan blocks over RPC. Routes Route Returns /api/stats chainId , block , timestamp , gasPriceWei , baseFeeWei /api/blocks?limit=N { chainId, blocks: [...] } , newest first /api/block/{number} One block, fields at the top level, plus transactions /api/transactions?limit=N { chainId, scanned_back, transactions: [...] } /api/tx/{hash} One transaction /api/address/{address} address , balanceWei , nonce , isContract , codeSize A request to an unknown route returns 404 with a JSON body that lists the routes above, so the API describes itself. The field naming is not uniform, and you must not assume This is the part that costs an afternoon if you assume. The shapes differ by route: Route Field style /api/blocks items camelCase: gasUsed , gasLimit , baseFeePerGas , txCount , parentHash /api/block/{n} camelCase, at the top level , with no wrapper object /api/block/{n} → transactions items from , to , valueWei , block , gas , gasPriceWei /api/transactions items snake_case: block_number , from_addr , to_addr , gas_limit , gas_price /api/address/{a} camelCase: balanceWei , isContract , codeSize In JavaScript a missing field is not an error, it is undefined , and a formatter turns that into a convincing 0 . Reading tx_count where this API returns txCount yields zero for every block; expecting a block wrapper on /api/block/{n} , where the fields are at the top level, yields "not found" for blocks that exist. Neither throws, and the request returns 200. Check the shape against a real response before you trust a number. Examples curl -s https://api.aere.network/api/stats curl -s https://api.aere.network/api/blocks?limit=2 curl -s https://api.aere.network/api/block/17389117 What it does not have There is no token-transfers route and no total-transaction count. If a route is not in the list the API returns on a 404, it does not exist, and a client should not call it hopefully: an endpoint that answers 404 on every call is not a feature that is coming, it is noise in someone's console. Which to use when Live chain state, calls, sending transactions: the JSON-RPC endpoints . History for an address or a range: this indexer. Anything you intend to rely on cryptographically: your own node, and eth_getProof . Previous Precompile ABI Next JSON-RPC methods On this page Routes The field naming is not uniform, and you must not assume Examples What it does not have Which to use when --- # JSON-RPC methods · AERE Documentation URL: https://aere.network/docs/reference/json-rpc-methods Fetched: 2026-09-15 JSON-RPC methods · AERE Documentation JSON-RPC methods The supported method set, including the QBFT methods. Getting started What AERE is Connect to the network Tooling that works unchanged Your first transaction Your first contract Faucet Next steps Build EVM compatibility JSON-RPC Fees and the base fee floor Events and logs Hardhat Foundry Verifying a contract TypeScript SDK Post-quantum Overview, stated precisely The five precompiles Falcon input framing The certificate anchor Verify an anchor yourself Hybrid certificates Threat model Requiring a post-quantum signature not written Network Chain parameters Consensus Anchor schedule Enforcement heights Fork history Public endpoints Network operations Run a node Requirements Install Configure Sync Monitor Troubleshoot Reference Protocol specification Precompile ABI Indexer API JSON-RPC methods Contract registry Genesis Glossary Docs / Reference / JSON-RPC methods The method set available on the public endpoints, measured against them rather than copied from a client's feature list. Endpoints Transport URL HTTPS https://rpc.aere.network , https://rpc2.aere.network WebSocket wss://wss.aere.network , wss://api.aere.network/ws Subscriptions live on the WebSocket endpoints. eth_subscribe is not available over HTTPS, which is the normal split for a JSON-RPC endpoint. Available Method Notes eth_blockNumber eth_chainId Returns 0xaf0 eth_getBlockByNumber , eth_getBlockByHash eth_getBlockReceipts eth_getTransactionByHash , eth_getTransactionReceipt eth_getTransactionCount Only meaningful inside the 512-block state window eth_getBalance , eth_getCode , eth_getStorageAt eth_getProof The correct way to prove an account fact eth_call , eth_estimateGas , eth_createAccessList eth_sendRawTransaction eth_getLogs eth_gasPrice , eth_maxPriorityFeePerGas , eth_feeHistory Report the floor correctly eth_subscribe , eth_unsubscribe WebSocket only net_version , net_peerCount web3_clientVersion , web3_sha3 txpool_status qbft_getValidatorsByBlockNumber The correct way to read the validator set qbft_getSignerMetrics Which validators actually produced blocks over a range Not available on the public endpoints Namespace Why it matters debug_ No debug_traceTransaction . Tracing needs your own node. trace_ No trace_block or trace_transaction . admin_ No peer list, no enode. Operational surface is not exposed. If your workflow needs tracing, run your own node: the package and options are published. See Run a node . Two behaviours to design around eth_getTransactionCount outside the state window returns 0x0 , not an error. The public endpoints keep state for 512 blocks. Use eth_getProof for anything you rely on. An eth_call that returns empty data means that selector is not present. It does not mean the capability is absent. Prove a capability positively, from bytecode. Checking this page This table was produced by calling each method against the public endpoint and recording whether it answered, returned a parameter error, or reported that the method does not exist. You can repeat that check in a loop; a method that reports a parameter error is present, a method that reports it does not exist is not. Previous Indexer API Next Contract registry On this page Endpoints Available Not available on the public endpoints Two behaviours to design around Checking this page --- # Precompile ABI · AERE Documentation URL: https://aere.network/docs/reference/precompile-abi Fetched: 2026-09-15 Precompile ABI · AERE Documentation Precompile ABI Addresses, input layout, gas and return value, in one table. Getting started What AERE is Connect to the network Tooling that works unchanged Your first transaction Your first contract Faucet Next steps Build EVM compatibility JSON-RPC Fees and the base fee floor Events and logs Hardhat Foundry Verifying a contract TypeScript SDK Post-quantum Overview, stated precisely The five precompiles Falcon input framing The certificate anchor Verify an anchor yourself Hybrid certificates Threat model Requiring a post-quantum signature not written Network Chain parameters Consensus Anchor schedule Enforcement heights Fork history Public endpoints Network operations Run a node Requirements Install Configure Sync Monitor Troubleshoot Reference Protocol specification Precompile ABI Indexer API JSON-RPC methods Contract registry Genesis Glossary Docs / Reference / Precompile ABI One table, for looking up. The explanations are on The five precompiles and Falcon input framing . Mainnet Address Function Standard Gas Input Output 0x0AE1 Falcon-512 verify NIST Falcon round 3 40,000 `pk(897) \ \ sm` 32-byte word, …01 valid 0x0AE2 Falcon-1024 verify NIST Falcon round 3 75,000 `pk(1793) \ \ sm` 32-byte word, …01 valid 0x0AE3 ML-DSA-44 verify FIPS 204 55,000 `pk(1312) \ \ sig(2420) \ \ message` 32-byte word, …01 valid 0x0AE4 SLH-DSA-SHA2-128s verify FIPS 205 350,000 `pk(32) \ \ sig(7856) \ \ message` 32-byte word, …01 valid 0x0AE5 SHAKE256 XOF FIPS 202 60 + 12 per 32-byte word of input plus output 32-byte big-endian outLen , then data outLen bytes Active from block 9,189,161. Gas is flat for the four verifiers. Falcon sm layout sm = sigLen(2, big-endian) || nonce(40) || message || esig esig = (0x20 + logn) || compressedSignature 0x29 for Falcon-512, 0x2A for Falcon-1024 sigLen == len(esig) pk = (0x00 + logn) || packed_h 0x09 for Falcon-512, 0x0A for Falcon-1024 The message is in the middle . Signature length is variable and must be read per call. ML-DSA and SLH-DSA layout sm = signature || message , with the fixed signature lengths above. Everything after pk || sig is the message. SHAKE256 behaviour Output length above 65,536 is capped to 65,536. A non-zero high 28 bytes of the length word also caps. Input shorter than 32 bytes returns empty output. Failure behaviour The verifiers never revert. Malformed input returns the 32-byte zero word, exactly as an invalid signature does. Put a known-good vector in the same run as a positive control, or a zero tells you nothing. Testnet only 0x0AE6 (ML-KEM-768 deterministic encapsulation, FIPS 203) and 0x0AE7 exist on the public testnet and are not on mainnet. Test vectors The NIST Known-Answer Test vectors used against these implementations ship in the node package under vectors/ . Previous Protocol specification Next Indexer API On this page Mainnet Falcon `sm` layout ML-DSA and SLH-DSA layout SHAKE256 behaviour Failure behaviour Testnet only Test vectors --- # Protocol specification · AERE Documentation URL: https://aere.network/docs/reference/specification Fetched: 2026-09-15 Protocol specification · AERE Documentation Protocol specification The full normative specification of chain 2800, and where to read it. Getting started What AERE is Connect to the network Tooling that works unchanged Your first transaction Your first contract Faucet Next steps Build EVM compatibility JSON-RPC Fees and the base fee floor Events and logs Hardhat Foundry Verifying a contract TypeScript SDK Post-quantum Overview, stated precisely The five precompiles Falcon input framing The certificate anchor Verify an anchor yourself Hybrid certificates Threat model Requiring a post-quantum signature not written Network Chain parameters Consensus Anchor schedule Enforcement heights Fork history Public endpoints Network operations Run a node Requirements Install Configure Sync Monitor Troubleshoot Reference Protocol specification Precompile ABI Indexer API JSON-RPC methods Contract registry Genesis Glossary Docs / Reference / Protocol specification Chain 2800 has a normative protocol specification. It is the authority; every other page in this documentation is the readable form of part of it. Where it is It ships inside the public node package as SPEC.md : git clone https://git.aere.network/aere-network/aere-node.git less aere-node/SPEC.md What is in it Section Subject 0 Conventions, and how every statement in the document is grounded 1 Chain parameters: identity, genesis header fields, EVM fork schedule, block period 2 Consensus: QBFT engine, quorum, the extraData structure with the AERE sixth element, decoder strictness, what header validation checks and one thing it does not 3 The post-quantum certificate anchor: the claim stated exactly, activation, the two pre-images and the certificate encoding, the validation rules, the Falcon registries 4 Precompiles: the five on mainnet, Falcon input framing, testnet-only ones, verification against the live chain 5 Fee rules: EIP-1559 with the AERE floor, what a follower must and must not enforce 6 Sync requirements: what a third-party client must implement to follow the chain 7 Formal models: what is proven, where, and the limits 8 Known divergences, historical windows and corrections. Normative. 9 What this specification cannot state from the published sources Two sections worth reading even if you read nothing else Section 8, known divergences. It is normative and it records the windows where the chain did not behave the way the rest of the document describes, including the ones caused by our own mistakes. A specification without that section is a specification you cannot use to write a second client. Section 9, what it cannot state. It lists the questions the published sources do not answer. We would rather publish the boundary of what we can ground than let a reader assume the document is complete. How claims are grounded Every factual statement in the specification carries its ground: either a source reference to a file in the package, or a MEASURED tag with a date and the method. A statement with neither is a statement the document does not make. That convention is the reason the specification is useful to someone implementing a second client: you can tell, per sentence, whether you are reading code, a measurement, or an intention. If you are writing a client Read section 6 first. It is written for exactly that, and it includes the facts a syncing client will observe so that they are expectations rather than surprises. Previous Troubleshoot Next Precompile ABI On this page Where it is What is in it Two sections worth reading even if you read nothing else How claims are grounded If you are writing a client --- # Configure · AERE Documentation URL: https://aere.network/docs/run-a-node/configure Fetched: 2026-09-15 Configure · AERE Documentation Configure The options a follower needs, derived from a live node rather than written by hand. Getting started What AERE is Connect to the network Tooling that works unchanged Your first transaction Your first contract Faucet Next steps Build EVM compatibility JSON-RPC Fees and the base fee floor Events and logs Hardhat Foundry Verifying a contract TypeScript SDK Post-quantum Overview, stated precisely The five precompiles Falcon input framing The certificate anchor Verify an anchor yourself Hybrid certificates Threat model Requiring a post-quantum signature not written Network Chain parameters Consensus Anchor schedule Enforcement heights Fork history Public endpoints Network operations Run a node Requirements Install Configure Sync Monitor Troubleshoot Reference Protocol specification Precompile ABI Indexer API JSON-RPC methods Contract registry Genesis Glossary Docs / Run a node / Configure AERE rules are delivered as node options, not through genesis. A follower that is missing one of them does not crash: it rejects blocks, or accepts blocks the fleet rejects. Take the options from a live node, not from a page The option block a follower needs is derived from a running archive node and shipped inside the package, in run-node.sh and in RUN-A-NODE.md . Use those. This page explains what the options mean; it deliberately does not restate the values, because a list retyped into a web page is a list that goes stale in silence. What the options cover Group Why a follower needs it Base fee floor and its fork block Without it the client computes a different base fee from block 10,141,734, therefore a different state root, and rejects every block after it Anchor activation and chain id Which heights carry a certificate, and the domain the digest is computed under Interval schedule Which heights are anchors. The grid is offset, not height % 128 Minimum seal schedule How many valid seals a certificate must carry at a given height Scheme schedule Which signature families are required from the hybrid activation onward Registry paths Where the validator public keys live, and which registry epoch applies The rule that is not obvious Two nodes with different values do not agree on what a valid header is. There is no consensus binding on these options: they are per-node system properties. A node configured with an older interval sees a valid anchor as an invalid one and stalls, while its neighbours continue. A rule change therefore ships as the same build to every node that judges headers, and the check compares the build stamp rather than the option strings. Two nodes can hold identical options and still disagree if their builds interpret them differently. Check you are on the right chain before trusting anything curl -s -X POST -H 'content-type: application/json' \ -d '{"jsonrpc":"2.0","id":1,"method":"eth_getBlockByNumber","params":["0x0",false]}' \ http://127.0.0.1:8545 The hash must be 0xd86d57a899cbfa580669f0e1c7cd4ae5f525247c3c823f8f75df176a0c5d7f1a . Then check peers: curl -s -X POST -H 'content-type: application/json' \ -d '{"jsonrpc":"2.0","id":1,"method":"net_peerCount","params":[]}' \ http://127.0.0.1:8545 A non-zero answer means discovery worked. Zero after a few minutes means your UDP port is closed or you have no bootnode. A node that does not answer is not a node reporting zero. While a node is catching up it may not answer RPC at all, and reading that silence as a zero produces confident, wrong conclusions. When the node may be down, read the log. Previous Install Next Sync On this page Take the options from a live node, not from a page What the options cover The rule that is not obvious Check you are on the right chain before trusting anything --- # Install · AERE Documentation URL: https://aere.network/docs/run-a-node/install Fetched: 2026-09-15 Install · AERE Documentation Install Get the node package and build the client. Getting started What AERE is Connect to the network Tooling that works unchanged Your first transaction Your first contract Faucet Next steps Build EVM compatibility JSON-RPC Fees and the base fee floor Events and logs Hardhat Foundry Verifying a contract TypeScript SDK Post-quantum Overview, stated precisely The five precompiles Falcon input framing The certificate anchor Verify an anchor yourself Hybrid certificates Threat model Requiring a post-quantum signature not written Network Chain parameters Consensus Anchor schedule Enforcement heights Fork history Public endpoints Network operations Run a node Requirements Install Configure Sync Monitor Troubleshoot Reference Protocol specification Precompile ABI Indexer API JSON-RPC methods Contract registry Genesis Glossary Docs / Run a node / Install The node package contains everything needed to build a client that follows chain 2800: the genesis file, the patches against upstream Besu, the post-quantum precompiles, the anchor code, the validator registries and the NIST test vectors. Get the package git clone https://git.aere.network/aere-network/aere-node.git cd aere-node What is in it Path What it is genesis.json The genesis file the fleet runs, byte for byte patches/0001…0005 The changes against upstream Besu precompiles/ The five post-quantum precompile implementations anchor/ The certificate anchor: rules, producer, registry binding registries/ The Falcon validator registries and their hashes vectors/ NIST Known-Answer Test vectors for the precompiles SPEC.md The normative protocol specification RUN-A-NODE.md The operational procedure this page summarises run-node.sh A start script that carries the options a follower needs Check the genesis before anything else sha256sum genesis.json Expect e5038e6a1437bd85fa51294609edf2126a997f14f4fa7a65a0d39bd0aa24d2e5 , on the file with LF line endings (since 2026-09-10; 361709dcce… before, when config carried two registry entries instead of three). A genesis that differs in config , even with the same block 0 hash, is a different chain for anything that judges anchors: two nodes can peer happily and still disagree about which headers are valid. Build The package builds against a named upstream Besu commit with the patches applied. The exact commit and the build recipe are in RUN-A-NODE.md , which is the authority; it is kept there rather than duplicated here so that the two cannot drift apart. Do not skip patch 0005. It carries the AERE milestone, and a build without it stops at block 9,189,161 with a state root mismatch. That height was measured by attempting exactly that import, not derived from the configuration. Which parts are which If you want to follow the chain, you need the client, the genesis and the follower options. If you want to run a validator , you additionally need a Falcon key in the registry, which is a decision by the validator set and not something the package can give you. Then Configure , then check you are on the right chain before trusting any reading from your node. Previous Requirements Next Configure On this page Get the package What is in it Check the genesis before anything else Build Which parts are which Then --- # Monitor · AERE Documentation URL: https://aere.network/docs/run-a-node/monitor Fetched: 2026-09-15 Monitor · AERE Documentation Monitor What to watch, and which readings lie. Getting started What AERE is Connect to the network Tooling that works unchanged Your first transaction Your first contract Faucet Next steps Build EVM compatibility JSON-RPC Fees and the base fee floor Events and logs Hardhat Foundry Verifying a contract TypeScript SDK Post-quantum Overview, stated precisely The five precompiles Falcon input framing The certificate anchor Verify an anchor yourself Hybrid certificates Threat model Requiring a post-quantum signature not written Network Chain parameters Consensus Anchor schedule Enforcement heights Fork history Public endpoints Network operations Run a node Requirements Install Configure Sync Monitor Troubleshoot Reference Protocol specification Precompile ABI Indexer API JSON-RPC methods Contract registry Genesis Glossary Docs / Run a node / Monitor What to watch on a node you run, and which readings are not what they look like. The four readings that matter Reading How Healthy Height eth_blockNumber Advancing, and within a few blocks of a public endpoint Peers net_peerCount Non-zero and stable Genesis eth_getBlockByNumber("0x0") 0xd86d57a899cbfa580669f0e1c7cd4ae5f525247c3c823f8f75df176a0c5d7f1a Memory jstat -gcutil Old generation not pinned near 100%, full collections rare Readings that lie, and what to do instead A node that does not answer is not a node reporting zero. While a node is catching up it may not answer RPC at all. A height or peer count read as zero in that moment measures nothing. Treat "no answer" as its own state, and when the node may be down, read the log rather than the RPC. "It advanced once" is not "it is keeping up". A node can import one block from its own database and then sit frozen with no peers. A liveness check needs three things at once: peers non-zero, a minimum amount of growth, and both measured across the whole window rather than at its ends. An empty block is not a stall. The chain produces a block every half second whether or not there are transactions, so most blocks carry none. Liveness is the height advancing, not the transaction count. Comparing against a public endpoint fails when the endpoint is the one that is behind. If your reference is itself stuck, a comparison declares your healthy node unhealthy. When the reference is behind, judge by local progress instead. Disk Headers are roughly 95% of the database on this chain, and anchor headers are large. Measure growth as size divided by height over the life of the database, with du on the directory, not with df on the filesystem. A compacting database reports wildly different rates over short windows. Logs EIP-4788 beacon roots is active in genesis and the beacon roots contract has no code on this chain, so the system call fails on every block. It is a logging condition, not a consensus one. Filter that one message rather than silencing the class, so that real errors from the same component still reach you. A log that is permanently full of errors trains its reader to ignore it. Previous Sync Next Troubleshoot On this page The four readings that matter Readings that lie, and what to do instead Disk Logs --- # Requirements · AERE Documentation URL: https://aere.network/docs/run-a-node/requirements Fetched: 2026-09-15 Requirements · AERE Documentation Requirements Measured disk, memory and CPU, not a guess. Getting started What AERE is Connect to the network Tooling that works unchanged Your first transaction Your first contract Faucet Next steps Build EVM compatibility JSON-RPC Fees and the base fee floor Events and logs Hardhat Foundry Verifying a contract TypeScript SDK Post-quantum Overview, stated precisely The five precompiles Falcon input framing The certificate anchor Verify an anchor yourself Hybrid certificates Threat model Requiring a post-quantum signature not written Network Chain parameters Consensus Anchor schedule Enforcement heights Fork history Public endpoints Network operations Run a node Requirements Install Configure Sync Monitor Troubleshoot Reference Protocol specification Precompile ABI Indexer API JSON-RPC methods Contract registry Genesis Glossary Docs / Run a node / Requirements These figures are measured on a real import of chain 2800, not estimated. Where a number moves with the height of the chain, that is said rather than averaged away. Memory 8 GB is the floor at which a full from-genesis import stops being practical, not a comfortable size. 16 GB gives the database the room the measurement shows it wants. The requirement is not flat. It grows with the height, because the storage engine's working set grows with the chain. Measured on an 8 GB machine: past 12.2 million blocks the process sat at 5.96 GB resident with a 3.4 GB heap, the old generation 99.8% full, and four full garbage collections in five minutes. Heap: bigger is not faster The same -Xmx flag was measured at four values on the same machine: -Xmx What the JVM did Blocks per minute 4500m 89 OutOfMemoryError , 7.1 GB resident, import stopped dead 0 3200m Ran, then degraded with repeated out-of-memory errors ~1,500 2400m Healthy early, 1,409 full collections past 9.19 M ~82,000 early, ~640 late 3400m Zero full collections past nine million ~28,800 The reason a larger heap is slower is that the storage engine's block cache lives outside the heap. A heap that takes the memory the database also needs starves it, and the process spends its time collecting instead of importing. So do not pick a fraction of RAM and hope. Watch it: jstat -gcutil 5000 3 If the old generation sits near 100% and full collections are frequent, the heap is too small. If you see OutOfMemoryError in the log, it is too large for what the database also needs: lower it. On 8 GB the band that worked was roughly 2.4 GB early and 3.4 GB past nine million blocks, and the optimum moves as the chain grows. Disk Headers are roughly 95% of a node's disk on chain 2800. Blocks are mostly empty, so there are few transactions, receipts or state to store. Anchor headers are the exception and they are large: every 128th header carries a post-quantum certificate of tens of kilobytes. Size from the measured header, never from the minimum seal count, because nodes attach as many valid seals as arrive rather than the minimum required. Growth is best measured as size divided by height over the life of the database, not over a short window. A compacting database can report zero growth for eighteen minutes and tens of kilobytes per block over the next eighteen. Measure a database's growth with du on its directory, never with df on the filesystem. df measures the whole filesystem, so it counts every other thing that changes on that disk, including whatever you copied there yourself, and will attribute it to the chain. Network Outbound and inbound TCP and UDP on your peer-to-peer port. Discovery is UDP; a TCP-only opening gives you a node that never finds peers and looks broken for no visible reason. Then Install and Configure . Previous Network operations Next Install On this page Memory Heap: bigger is not faster Disk Network Then --- # Sync · AERE Documentation URL: https://aere.network/docs/run-a-node/sync Fetched: 2026-09-15 Sync · AERE Documentation Sync What a sync from genesis actually costs, measured. Getting started What AERE is Connect to the network Tooling that works unchanged Your first transaction Your first contract Faucet Next steps Build EVM compatibility JSON-RPC Fees and the base fee floor Events and logs Hardhat Foundry Verifying a contract TypeScript SDK Post-quantum Overview, stated precisely The five precompiles Falcon input framing The certificate anchor Verify an anchor yourself Hybrid certificates Threat model Requiring a post-quantum signature not written Network Chain parameters Consensus Anchor schedule Enforcement heights Fork history Public endpoints Network operations Run a node Requirements Install Configure Sync Monitor Troubleshoot Reference Protocol specification Precompile ABI Indexer API JSON-RPC methods Contract registry Genesis Glossary Docs / Run a node / Sync What a sync from genesis involves, and the one setting that a from-genesis follower needs and a validator does not. Full sync, not snap sync Full sync from block 0 is the mode that verifies the published history, and it is what the anchor requires: a node with the anchor rules armed refuses a lighter mode at startup. Snap sync against a QBFT chain trusts a peer for the state and verifies far less. It is not a faster route to the same guarantee; it is a different guarantee. Storage format is a local choice and not part of consensus. Peering Discovery needs a bootnode enode, and both discovery UDP and peer-to-peer TCP must be open in both directions. The node package explains how to obtain a current enode; a dedicated public bootnode does not exist yet, and that is stated in the package rather than implied. The only proof that your peering works is your own net_peerCount . A non-zero count after a few minutes means discovery succeeded. The genesis validator set, and the setting it forces This is the part that surprises everyone who syncs from block 0, so it is worth reading before you start. A node syncing from genesis starts into the genesis validator set , which is three validators with a quorum of two, not the nine of today. The anchor threshold guard refuses to arm a minimum of three or six seals against a set of three, so a from-genesis follower with the published schedule will not start at all without one more setting. The published answer is a ceiling that lowers the effective seal-count floor to quorum(3) - 1 = 1 , without editing the schedule. The exact property name is in the package. State the consequence honestly, because it is a real weakening of one check. With that ceiling, the follower's seal-*count* requirement is 1 at every height rather than 3 or 6. What is not weakened, and this is most of the check: every anchor must still carry a digest binding its certificate under the block hash seal indices must still be strictly increasing every carried seal is still Falcon-verified against the registry correct for that height eligibility in the parent's validator set is still enforced Real anchor blocks carry between three and nine seals, so all of history imports cleanly. The seal-count floor is a proposer-liveness property relative to the current set, not a history-verification property. A validator, which starts into the full set, does not set the ceiling. When the sync is done Compare your head to a public endpoint, and compare your block 0 hash to 0xd86d57a899cbfa580669f0e1c7cd4ae5f525247c3c823f8f75df176a0c5d7f1a before you trust either. Sizing Memory is the constraint, not CPU, and the requirement grows with the height. Read Requirements before starting a from-genesis sync; the heap table there is the difference between an import that finishes and one that stops. Previous Configure Next Monitor On this page Full sync, not snap sync Peering The genesis validator set, and the setting it forces When the sync is done Sizing --- # Troubleshoot · AERE Documentation URL: https://aere.network/docs/run-a-node/troubleshoot Fetched: 2026-09-15 Troubleshoot · AERE Documentation Troubleshoot Common failure modes when following the chain, and what they mean. Getting started What AERE is Connect to the network Tooling that works unchanged Your first transaction Your first contract Faucet Next steps Build EVM compatibility JSON-RPC Fees and the base fee floor Events and logs Hardhat Foundry Verifying a contract TypeScript SDK Post-quantum Overview, stated precisely The five precompiles Falcon input framing The certificate anchor Verify an anchor yourself Hybrid certificates Threat model Requiring a post-quantum signature not written Network Chain parameters Consensus Anchor schedule Enforcement heights Fork history Public endpoints Network operations Run a node Requirements Install Configure Sync Monitor Troubleshoot Reference Protocol specification Precompile ABI Indexer API JSON-RPC methods Contract registry Genesis Glossary Docs / Run a node / Troubleshoot Failure modes when following chain 2800, and what each one actually means. The node stops at a specific height and never passes it failed persisting block due to stateroot mismatch means your client computes a different state than the chain. The height tells you which rule you are missing. Stops at Missing 9,189,161 The AERE EVM milestone: the five post-quantum precompiles and the EIP-2935 write 10,141,734 or shortly after The base fee floor An anchor height An anchor rule: activation, interval, minimum seals, scheme schedule or registry path All three are node options, not genesis settings. See Configure . The node will not start at all A threshold guard refusing to arm. A node syncing from genesis starts into the genesis validator set of three, and the anchor guard refuses a minimum of three or six seals against a set of three. The published answer is the seal-count ceiling described in Sync . A file it cannot read. Configuration that is loaded lazily fails at the moment of use rather than at startup, which turns a permissions mistake into a consensus event. If you run in a container, prove that every mounted file is readable as the user the process runs as , before you start it. Zero peers Discovery is UDP. A firewall that opens only TCP produces a node that starts, looks healthy, and never finds anyone. Open both, inbound and outbound, and confirm with net_peerCount . A node that calls its static peer in its first second, while the other side is not yet listening, can fail a handful of times in a fraction of a second and not try again. When bringing up two nodes that must find each other, start the one being called first, with its RPC up, before the one that calls. The node is up but far behind Check memory before anything else. On this chain the constraint is the heap against the storage engine's off-heap cache, and the symptom of a heap that is too large is not an error, it is a process that spends its time collecting garbage. The table in Requirements is the fastest way to see whether your setting is in the band. It disagrees with a public endpoint about a recent block First check block 0. If the genesis hash differs, nothing else matters: you are on another chain. If block 0 matches and a recent header differs, compare the headers field by field rather than reading the difference as a fork. Each QBFT node assembles its own final header, and the block hash does not cover the seals, so two honest nodes can legally store different extraData for the same block. An anchor header is rejected Read the height against the anchor grid. Anchor heights sit on H + k * 128 from block 17,225,968, which is not the same as height % 128 == 0 . A client testing the wrong condition rejects valid blocks and accepts nothing at the right ones. See Anchor schedule . Previous Monitor Next Protocol specification On this page The node stops at a specific height and never passes it The node will not start at all Zero peers The node is up but far behind It disagrees with a public endpoint about a recent block An anchor header is rejected --- # AERE Economy, Token supply, treasury, locks, burns URL: https://aere.network/economy.html Fetched: 2026-09-15 AERE Economy, Token supply, treasury, locks, burns AERE economy, full transparency Every AERE token, accounted for. Balances, the live sAERE vault total and burn metrics are read live from rpc.aere.network . Staking runs through the immutable sAERE vault, open /stake for the current exchange rate. Refreshes every 30s. Supply Max cap 2,800,000,000 AERE Circulating , Locked , Routed to the burn vault , A note on the burn figure, because the wording used to be looser than the measurement. The number above is the splitter's cumulative counter, and it counts AERE routed into AereFeeBurnVault 0x696a…B2c6 . Measured on 2026-08-01: the counter and the vault's balance are the same number to the last wei, and the zero address holds nothing, so none of it has been forwarded to the zero address yet. The vault has no withdraw function and no admin, so what arrives there is out of circulation and cannot come back; the optional final sweep to the zero address simply has not been called. The amount is small because the chain is lightly used, and we would rather publish the small honest number than round it into a claim. loading… Foundation Strategic Investor Staking Reserve Ecosystem Team Airdrop Staked Allocated at genesis, held outside these six wallets Read the grey segment carefully. It used to be labelled unallocated, and that was wrong. Measured on 2026-08-01 with eth_getBalance at the chain head, the six genesis wallets below hold 2,239,999,990.70 AERE between them, not 2,800,000,000. The grey segment is the difference, 560,000,009.30 AERE . It was allocated at genesis and it still exists; it is simply not sitting in these six wallets any more. The Ecosystem Reserve allocation of 560,000,000 AERE was moved on chain in July 2026 to a separate account, which is why the Ecosystem row below reads under 1 AERE. No AERE was created and none was destroyed: the cap is 2,800,000,000 and there is no emission. Custody of that moved balance is being brought under the same governance handover as the rest of the protocol, and until that is finished we would rather say so here than let a grey bar imply the tokens were never handed out. Key holders, the six genesis wallets These six rows are the genesis wallets and nothing else. Measured 2026-08-01 they sum to 2,239,999,990.70 AERE against a 2,800,000,000 cap, and the table does not silently round that up. The Circulating tile above is computed as cap minus Foundation minus Staking Reserve minus staked minus the burn-vault counter, so it treats everything not in those buckets as circulating, including the moved Ecosystem allocation described above. The formula is stated rather than tuned, so you can disagree with it while looking at the same numbers. Account Address Balance % of max Status Loading… Programmatic locks Contract Address Mechanism State Loading… Staking Staking lives at /stake AERE staking now runs through the immutable sAERE vault (ERC-4626, no admin keys, no lockups). There is no fixed-tier APY: protocol revenue routed by AereSink vests to stakers over a seven-day drip and the exchange rate never falls. Live totals and the current exchange rate are shown on the staking page. Open staking → Reads via https://rpc.aere.network . Refreshes every 30s. Source contracts published at git.aere.network/aere-network/aere-contracts . --- # Editorial Standards & Ownership, Aere Network URL: https://aere.network/editorial-standards.html Fetched: 2026-09-15 Editorial Standards & Ownership, Aere Network Editorial Standards & Ownership How the Aere Network newsroom is authored, owned, sourced, dated, and corrected. The Aere Network newsroom publishes original engineering updates, explainers, and official press releases about Aere Network. Its guiding standard is the same one the network applies to itself: publish claims that anyone can check, and correct the record in public when something is wrong. Authorship Newsroom content is authored at the organization level and credited to Aere Network , not to individual bylines. Posts are written and reviewed by the network's engineering and communications contributors and published under the collective name of the organization. We do this deliberately: the work is a team output, and organization-level authorship is an honest description of how it is produced. We do not attach invented individual author names to any post. Ownership and funding Aere Network and this newsroom are operated by the Aere Foundation , the non-profit-style steward of the protocol. The Foundation maintains the codebase, funds builders through a public grants program, and supports on-chain governance. It holds a defined allocation of the fixed 2.8 billion AERE supply, established at genesis and published in the whitepaper; there is no off-chain funding mechanism, equity sale, or private sale that bypasses on-chain accountability. Treasury activity occurs on Aere mainnet (Chain ID 2800) and is publicly auditable. Leadership and contributors are listed on the team page . Original content Every newsroom post is original and written for Aere Network. We do not republish or syndicate third-party articles as our own. Where a post relies on external standards, specifications, or datasets, it names and links them. Sourcing and verification Aere's position is that a settlement network should be verifiable rather than trusted, and the newsroom holds itself to the same standard. In practice that means: On-chain claims link to the block explorer, a transaction hash, a block number, or a contract address so readers can confirm them independently. Performance and capability claims are stated as what they are. A design ceiling implied by parameters is labelled as a ceiling, not a measured live rate; benchmarks are labelled as benchmarks. Limits and caveats are stated in the same place as the capability, including that mainnet consensus signing is classical ECDSA today, that the validator set is Foundation-operated, and that the live system has not yet completed a third-party audit. We do not fabricate authors, dates, credentials, metrics, or endorsements. Dates Each post carries a visible publication date, and the same date is recorded in the machine-readable structured data on the page. When a post is materially updated after publication, we mark the update in the text and record a modification date rather than silently rewriting history. A post with no authoritative publication date is not asserted as dated news. Corrections If we publish an error, we fix it and say so. Substantive corrections are noted directly in the affected post with what changed and when, so the public record stays honest rather than being quietly overwritten. To report an error or request a clarification, email [email protected] with the page URL and the specific claim. We review corrections requests and respond during European business hours. Feedback and contact General, press, and corrections contact: [email protected] . More ways to reach us and verify the network are on the contact page and the about page . --- # AERE Yield Farm, LP staking · native AERE rewards URL: https://aere.network/farm.html Fetched: 2026-09-15 AERE Yield Farm, LP staking · native AERE rewards AERE Yield Farm MasterChef-style yield farming. Stake any ERC-20 (typically AereSwap LP tokens), earn native AERE rewards accruing every second. No lockup, withdraw and harvest anytime. Whitepaper §5.1. Farm overview AereYieldFarm 0xF86Fb0Eb…5Db713F Active pools , Reward reserve (this contract) , Your address , Connect Wallet Refresh Pools Loading… For pool operators (Foundation only) Pools are added by Foundation via addPool(stakeToken, rewardPerSecond) . Rewards are funded by sending native AERE to this contract (plain transfer or fundRewards() ). Per-second emission can be adjusted via setRewardRate(pid, rate) . --- # AERE Faucet URL: https://aere.network/faucet.html Fetched: 2026-09-15 AERE Faucet AERE Faucet Home Add Network Explorer AERE Faucet Your first AERE on chain 2800, so a new address can send its first transaction. 0.05 AERE per address per 24 hours. ⓘ How it works, and its limits. The faucet service pays the gas for you: enter an address, your browser does a few seconds of proof of work, and the service sends 0.05 AERE. One claim per address and per IP every 24 hours. It was funded on 2026-09-02 with a small operational amount; the figures below are read live from the service and from the chain, so believe them over this sentence. Nothing here is a sale, and AERE is not listed on any exchange. Drip … Cooldown … Faucet balance (service) … Claims paid so far … Network AERE Network (2800) Status enter an address Your wallet address Use Connected Wallet Get 0.05 AERE Already have gas? The on-chain AereFaucet contract at 0xDdBe942aD9eB0F3E7C541BdCF7CC2cfA29d35aE4 also pays 0.05 AERE per claim() per 24 hours, from its own balance; it needs you to pay the call's gas, which is why new addresses use the service above instead. --- # For Regulated Finance | Aere Network URL: https://aere.network/for-regulated-finance.html Fetched: 2026-09-15 For Regulated Finance | Aere Network Solutions For Regulated Finance Institutions Compliance Settlement Updated 2026-08-15 Verified at block 13,938,808 2 min read The public settlement ledger where your quantum-safe migration story is already true, already checkable, and ready for a regulator. Every signature that secures a public blockchain today rests on elliptic-curve cryptography, and its retirement is already on a regulator's calendar. NIST deprecates the classical 112-bit schemes after 2030 and disallows them after 2035 (IR 8547); the US federal migration mandate (OMB M-23-02) and the EU's coordinated roadmap run on the same clock. For a bank, a central securities depository, or a payment institution, the question is no longer whether to migrate a settlement system to post-quantum cryptography, but how to show a supervisor, an auditor, and a board that the work is real. What you can show them Chain 2800 is the public settlement ledger where that story is already true and already checkable. Since block 13,014,000, every anchor block binds a certificate of Falcon-512 validator signatures under the block hash itself, at an enforced minimum of six per anchor block, a full 2f+1 quorum since block 14,961,456 (August 21, 2026; three from 2026-08-14). Five NIST post-quantum verifiers run as native precompiles. Since 2026-08-14, consensus does not finalize an anchor block (every 32nd) without at least three of the then nine valid post-quantum validator seals (raised at block 14,961,456, August 21, 2026, to six seals, then a full 2f+1 quorum of nine; since the set grew to ten on 2026-09-11 the enforced minimum is still six, above f+1 but below the ten-validator quorum of seven) (corrected 2026-08-19: not every block). None of this is a slide: it is a set of blocks your own team verifies against a public endpoint. The engagement starts with verification, not slides Your crypto-agility team downloads a single-file verifier, runs one command, and watches it recompute the binding digest independently from raw bytes. Then it fails on purpose, on pre-enforcement history and on a tampered domain, so you know the check can say no. Only after your team has seen the proof with its own eyes do we map your settlement flows onto post-quantum authorization together. The chain is EVM at Ethereum parity, so your existing tooling, wallets, and audits carry over. Three ways to work with us Post-quantum migration testbed. Timed access for your team to exercise Falcon, ML-DSA, and SLH-DSA on a live public chain, with a reproducible conformance report for your regulator; see a sample report , generated by the same toolkit you can run yourself. A private post-quantum ledger. The same QBFT-plus-post-quantum stack, deployed for you, with two independently built clients. A quantum-safe tokenization pilot. Your asset, tokenized, with post-quantum evidence in the block record, not only at the application layer. Honest boundaries, stated up front Since 2026-08-14 every 128th block (every 32nd block until block 17,225,968, on 2026-09-05) on chain 2800 (an anchor block) does not finalize without a certificate of at least three valid Falcon-512 validator seals (f+1 of the nine validators of that time) (raised at block 14,961,456, August 21, 2026, to six seals, then a full 2f+1 quorum of nine; since the set grew to ten on 2026-09-11 the enforced minimum is still six, above f+1 but below the ten-validator quorum of seven) bound under its block hash; classical secp256k1 ECDSA QBFT finalizes every block. (Correction 2026-08-19: the earlier statement that from block 14,050,000 every block required a six-of-nine post-quantum quorum to finalize is withdrawn; the per-block rule armed at that height is retired in the shipped code in favour of the anchor rules and changed no enforcement.) All ten validators are Foundation-operated while the independent-operator program is built, so the chain is not yet decentralized and we do not describe it that way. No external security audit has been completed; one is on the roadmap with a date. Each of these is a real limitation, published, and each is a step we are taking in the open. We would rather you learn them from us than from a hostile reader. Have your team check us first curl -O https://aere.network/tools/verify-anchor.mjs -O https://aere.network/tools/falcon512.mjs -O https://aere.network/tools/package.json && npm install node verify-anchor.mjs # VERIFIED: 20/20 anchor blocks carry a post-quantum certificate # bound under the block hash, each with at least 3 Falcon-512 seals. # The full toolkit: precompiles vs NIST vectors, block interval, # validator set, contract fingerprints. Zero dependencies. Run the # self-test first: it plants 21 defects and must catch every one. curl -O https://aere.network/tools/verifica-lantul.tar.gz tar -xzf verifica-lantul.tar.gz && cd verifica-lantul node autotest.mjs # prove the toolkit can say NO node verifica.mjs # then a green run means something Write to us: [email protected] Subject line "Post-quantum migration testbed" reaches the right person directly. Or start with the Foundation . The stack Six layers, live vs armed What is delivered, what is armed, and the number behind each. The pitch Quantum-safe settlement Why a settlement ledger needs post-quantum evidence, and what ours carries. The proof Run the verifier Recompute the binding digest yourself, from raw bytes, in a minute. Next up Quantum-safe settlement, in depth The Aere glossary Post Quantum Anchor Seal Certificate Signer Registry Finality Client Diversity Falcon 512 About About Aere Foundation Roadmap Press & Newsroom Brand Kit Editorial Standards Build Developer Hub Documentation RPC Reference SDK Add Network Faucet Academy Grants Network Architecture Post-Quantum Stack Validators Run a Validator Network Status Audits Security Decentralization Solutions Payments DeFi Real-World Assets Infrastructure Gaming NFTs & Culture Explore Explorer Blocks Transactions Tokens Research & Papers Glossary Blog Legal Terms & Privacy Sanctions Compliance Aere Network. Chain ID 2800. Every claim on this site is checkable: rpc.aere.network --- # AERE Foundation URL: https://aere.network/foundation.html Fetched: 2026-09-15 AERE Foundation AERE Foundation The non-profit-style steward of the AERE Network protocol, responsible for ecosystem development, grant funding, and the long-term health of the network. The AERE Foundation operates all ten validators today (ten validators since 2026-09-11) and holds the admin keys to most protocol contracts; the path to independent operators and on-chain governance is published in the roadmap. It does not custody end-user wallet funds. Its mandate is to steward the commons: maintain the open-source codebase, fund builders through the grants program, support governance, and represent the network's interests in the wider blockchain ecosystem. What the Foundation does ⚙ Protocol stewardship The Foundation maintains the canonical AERE Network repositories, coordinates protocol upgrades, and publishes technical documentation. All changes go through public review on git.aere.network . 💰 Ecosystem grants The Foundation administers the AERE Developer Grants program, funding dApps, infrastructure, tooling, research, and content with no equity claw-backs. Applications are public and community-visible. 📊 Governance support The Foundation supports the AERE DAO by maintaining governance infrastructure, publishing proposals in plain language, and ensuring stake-weighted votes are correctly tallied and executed on-chain. Treasury Foundation treasury wallet 0x0243A4f47D44b40b65D33f20329dE20D00c6f3C3 Funded from the Foundation allocation of the 2.8 billion AERE total supply (per the AERE whitepaper §6). Treasury movements are on-chain and publicly verifiable. View on AERE Explorer → The Foundation treasury is the source of grant disbursements, protocol development funding, and operational costs. Disbursements above the Quick Build threshold require a DAO vote, creating a public record. The Foundation does not retain profits, surplus treasury holdings remain on-chain and are governed collectively. How the Foundation is funded The Foundation holds a defined allocation of the 2.8 billion AERE supply, established at genesis; the vesting schedule is published but not yet enforced by an on-chain contract (see the vesting page). There is no off-chain funding mechanism, no equity sale, and no private sale that bypasses on-chain accountability. The allocation and its vesting schedule are published in the AERE whitepaper and visible on-chain. The Foundation does not accept fiat donations or off-chain investment. All financial activity occurs on AERE Network mainnet (Chain ID 2800) and is publicly auditable. How to engage Apply for a grant Builders, researchers, and content creators can apply for funding through the open grants program. Tiers from $1k to $100k. Public applications, milestone-based payments, no equity. View grants program → Participate in governance AERE token holders will vote on protocol upgrades, treasury disbursements, and ecosystem decisions through the AERE DAO. The governance contracts are deployed and stake-weighted, but they own nothing yet, so their votes are advisory until the ownership transfer described on the governance page. Go to governance → Contribute to the protocol All AERE Network source code is open. Submit issues, review proposals, or open pull requests on Gitea. The Foundation reviews and merges contributions that pass technical review. Open Gitea → Talk to the Foundation For the post-quantum migration testbed, private deployments, tokenization pilots, press, or anything else: write to us directly. A person answers, not a funnel. [email protected] → Follow Foundation decisions Foundation governance proposals and grant approvals are published as public issues on Gitea before execution. No decision affecting the treasury above the Quick Build threshold is made without community visibility. View grant issues → --- # Gas Sponsorship | Aere Network URL: https://aere.network/gasless.html Fetched: 2026-09-15 Gas Sponsorship | Aere Network Aere Network Aere Cloud Docs Status Aere Cloud · developer service Your users never need to hold gas. Live Keyed & metered ERC-4337 Passkey smart accounts Endpoint cloud.aere.network/v1/sponsor Auth your Aere Cloud API key Chain 2800 The first transaction is where most crypto products lose the user: they arrive with no token, and nothing works until they buy one. Gas sponsorship removes that wall. Your backend makes one keyed call; the Foundation relayer deploys the user’s smart account and pays the gas. The user signs with a passkey and is on-chain, with zero AERE in hand. How it works Your user creates a passkey in their browser (Face ID, Touch ID, a security key): no seed phrase. Your backend calls /v1/sponsor/createAccount with your API key; the relayer deploys their ERC-4337 smart account and pays the gas. The user signs their transactions with the passkey; your backend relays them through /v1/sponsor/execute . Usage is metered per API key and shows up in your console under sponsored operations. Why it is safe by construction The smart account validates every signature itself. The relayer only pays gas: it never sees a user’s key and cannot move a user’s funds. So even a fully compromised relayer could waste its own gas budget and nothing more; user assets stay out of its reach by the design of the account, not by our promise. Onboard a gasless user POST https://cloud.aere.network/v1/sponsor/createAccount x-api-key: ak2800.. { "initialOwners": ["0x…passkey-derived…"], "salt": "0x…" } # the relayer deploys the account and pays the gas; # your user never held a single wei of AERE Honest phase-1 limits Stated up front, the same as the public relayer: today it runs a single relayer account with no high-availability failover. If it is down, users who already hold AERE can still transact directly; new gasless onboarding pauses until it is back. The keyed route adds authentication and per-key metering on top of that engine, and a redundant relayer is on the roadmap. Get an API key Part of Aere Cloud . Full API reference and the wallet-infrastructure engagement that builds the complete passkey flow are in the docs . © 2026 Aere Network · chain 2800 · Aere Cloud --- # Base Fee Floor | Aere Network URL: https://aere.network/glossary/base-fee-floor.html Fetched: 2026-09-15 Base Fee Floor | Aere Network Glossary Base Fee Floor Chain 2800 Verified on-chain Updated 2026-08-15 Verified at block 13,921,041 1 min read A consensus-enforced minimum base fee: chain 2800 rejects any block header whose base fee falls below the floor, keeping spam costly and fees predictable. Every block on an EVM chain publishes a base fee in its block header : the minimum price a transaction must pay, per unit of work, to be included in that block. Under the standard EIP-1559 rules the base fee is elastic. It rises when blocks are congested and decays when they are not. On chain 2800, which produces a block roughly every 500 ms, quiet stretches would let that decay compound block after block, driving the base fee toward zero. A near-zero base fee makes spam close to free, and it makes fee estimation unstable the moment real demand returns. The base fee floor closes that gap. It is a consensus rule enforced at header validation, active from a fixed block height: a header whose base fee sits below the floor is invalid, and the network refuses it. The floor is a lower bound only. It does not cap fees, and above it the normal elastic adjustment applies unchanged. On chain 2800 the rule is checked by each of the ten validators that run QBFT consensus, where a block needs a quorum of seven to advance, and independently by a second client built from a separate codebase (see client diversity ). A header that violates the floor cannot gather a quorum on a fleet that carries the rule (for about two days in August 2026 the fleet ran without the rule by a configuration mistake, and roughly 112,000 final blocks from that window sit below the floor; since the repair on 2026-08-09 none do), so it cannot reach finality . Because the floor lives in the standard EIP-1559 header field, wallets and tooling read it with no changes (see EVM compatibility ). Verify it yourself Verify it yourself: POST {"jsonrpc":"2.0","id":1,"method":"eth_getBlockByNumber","params":["latest",false]} to https://rpc.aere.network and read the baseFeePerGas field of the returned header; sample consecutive blocks during a quiet period and the value holds at a fixed minimum instead of decaying toward zero. Explore the post-quantum stack Next up Block Header The Aere glossary Post-Quantum Anchor Validator Finality Precompile QBFT Consensus Falcon-512 Seal Certificate Base Fee Floor Block Header Signer Registry Client Diversity EVM Compatibility About About Aere Foundation Roadmap Press & Newsroom Brand Kit Editorial Standards Build Developer Hub Documentation RPC Reference SDK Add Network Faucet Academy Grants Network Architecture Post-Quantum Stack Validators Run a Validator Network Status Audits Security Decentralization Solutions Payments DeFi Real-World Assets Infrastructure Gaming NFTs & Culture Explore Explorer Blocks Transactions Tokens Research & Papers Glossary Blog Legal Terms & Privacy Sanctions Compliance Aere Network. Chain ID 2800. Every claim on this site is checkable: rpc.aere.network --- # Block Header | Aere Network URL: https://aere.network/glossary/block-header.html Fetched: 2026-09-15 Block Header | Aere Network Glossary Block Header Chain 2800 Verified on-chain Updated 2026-08-15 Verified at block 13,921,041 1 min read A block header is what the block hash commits to; on chain 2800 every 32nd header since block 13,014,000 also binds a post-quantum certificate digest. A block header is the compact record at the top of every block: the hash of the parent block, the roots that commit to state and transactions, a timestamp, and a field called extraData that consensus protocols use for their own bookkeeping. The block hash is computed from the header, so whatever sits inside the hashed portion is fixed for good: change one byte and every later block stops matching. On AERE Network (chain id 2800), a new header is produced roughly every 500 ms under QBFT consensus by ten validators with a quorum of seven. The consensus signatures that finalize each block are classical ECDSA secp256k1 today. On chain 2800, the header is also where the post-quantum anchor lives. Since block 13,014,000, every 32nd header carries a certificate of Falcon-512 signatures from the validators over the parent block, and a 32-byte digest of that certificate sits inside the data covered by the block hash. At least 3 signatures are required per anchor block; in practice certificates carry 8 or 9 (the configured cap is 9 since 2026-08-16). The keys that may sign are the 9 entries of the on-chain signer registry , which anyone can read. Every header is checked twice: the producing client and a second, independently implemented client validate the chain side by side, which is what client diversity means in practice. Verify it yourself Verify it yourself: POST to https://rpc.aere.network the body {"jsonrpc":"2.0","id":1,"method":"eth_getBlockByNumber","params":["latest",false]} and inspect the returned header fields, including parentHash, stateRoot, timestamp, and extraData. Explore the post-quantum stack Next up Signer Registry The Aere glossary Post-Quantum Anchor Validator Finality Precompile QBFT Consensus Falcon-512 Seal Certificate Base Fee Floor Block Header Signer Registry Client Diversity EVM Compatibility About About Aere Foundation Roadmap Press & Newsroom Brand Kit Editorial Standards Build Developer Hub Documentation RPC Reference SDK Add Network Faucet Academy Grants Network Architecture Post-Quantum Stack Validators Run a Validator Network Status Audits Security Decentralization Solutions Payments DeFi Real-World Assets Infrastructure Gaming NFTs & Culture Explore Explorer Blocks Transactions Tokens Research & Papers Glossary Blog Legal Terms & Privacy Sanctions Compliance Aere Network. Chain ID 2800. Every claim on this site is checkable: rpc.aere.network --- # Client Diversity | Aere Network URL: https://aere.network/glossary/client-diversity.html Fetched: 2026-09-15 Client Diversity | Aere Network Glossary Client Diversity Chain 2800 Verified on-chain Updated 2026-08-15 Verified at block 13,921,041 1 min read Two independently written clients validate chain 2800, so a bug in one implementation becomes a visible disagreement instead of a silent network-wide fault. A blockchain protocol is a set of rules; a client is a program that implements them. When every node runs the same program, a bug in that program is indistinguishable from the rules themselves: all nodes fail together, in the same way, and agree on the wrong answer. Client diversity is the practice of running at least two independently written implementations of the same protocol. Different codebases have different bugs, so a defect in one shows up as a disagreement between clients instead of a fault the whole network shares. The disagreement itself is the alarm. Chain 2800 runs two implementations. Blocks are produced by ten validators , nine running a fork of Hyperledger Besu and one running Nethermind since ten validators since 2026-09-11, under QBFT consensus, with a quorum of seven and one block roughly every 500 ms. Alongside the producing client, a second client, an independently implemented Nethermind fork, follows the same chain and checks every block header and state transition against its own, separately written reading of the rules, including the network's EVM semantics and AERE-specific rules such as the base fee floor . An independent implementation cannot be talked into a block it computes differently. It stops, and a stop is a measurement: if the producing client ever accepted an invalid block, the second client would refuse it, turning a hidden consensus bug into a visible divergence that can be located and fixed. Verify it yourself Verify it yourself: POST {"jsonrpc":"2.0","method":"web3_clientVersion","params":[],"id":1} to https://rpc.aere.network and the response names the client software and version answering the public endpoint. Explore the post-quantum stack Next up EVM Compatibility The Aere glossary Post-Quantum Anchor Validator Finality Precompile QBFT Consensus Falcon-512 Seal Certificate Base Fee Floor Block Header Signer Registry Client Diversity EVM Compatibility About About Aere Foundation Roadmap Press & Newsroom Brand Kit Editorial Standards Build Developer Hub Documentation RPC Reference SDK Add Network Faucet Academy Grants Network Architecture Post-Quantum Stack Validators Run a Validator Network Status Audits Security Decentralization Solutions Payments DeFi Real-World Assets Infrastructure Gaming NFTs & Culture Explore Explorer Blocks Transactions Tokens Research & Papers Glossary Blog Legal Terms & Privacy Sanctions Compliance Aere Network. Chain ID 2800. Every claim on this site is checkable: rpc.aere.network --- # EVM Compatibility | Aere Network URL: https://aere.network/glossary/evm-compatibility.html Fetched: 2026-09-15 EVM Compatibility | Aere Network Glossary EVM Compatibility Chain 2800 Verified on-chain Updated 2026-08-15 Verified at block 13,921,041 1 min read Chain 2800 runs the standard EVM: Ethereum contracts and tooling work unchanged; post-quantum additions live in precompiles and the header, not the EVM. EVM compatibility means a chain runs the same execution environment as Ethereum: the same bytecode, the same account and transaction model, and the same JSON-RPC interface. A contract compiled for Ethereum deploys unchanged. Wallets, libraries, and developer tools connect without modification, because the surface they depend on is identical: opcodes, state layout, and RPC methods such as eth_call and eth_getStorageAt. AERE Network is a public EVM L1 with chain id 2800. Blocks are produced roughly every 500 ms under QBFT consensus among ten validators , with a quorum of seven. Any standard Ethereum client library can point at the public RPC, https://rpc.aere.network, and a second public read endpoint exists. A second, independently implemented client validates the chain alongside the producing client, which is what client diversity means in practice. Where chain 2800 extends the EVM, it uses the EVM's own extension mechanism: the precompile . Five post-quantum precompiles have been live since block 9,189,161 at addresses 0x0AE1 through 0x0AE5, covering the Falcon-512 , ML-DSA, and SLH-DSA families, validated against NIST test vectors on-chain. The post-quantum anchor lives in the block header , outside the execution layer, so contracts and tooling see an ordinary EVM chain. Consensus signatures for finality remain classical ECDSA secp256k1 today; the post-quantum work adds to the EVM rather than forking away from it. Verify it yourself Verify it yourself: POST {"jsonrpc":"2.0","method":"eth_chainId","params":[],"id":1} to https://rpc.aere.network; the result is 0xaf0, which is 2800 in hex. Explore the post-quantum stack Next up Post-Quantum Anchor The Aere glossary Post-Quantum Anchor Validator Finality Precompile QBFT Consensus Falcon-512 Seal Certificate Base Fee Floor Block Header Signer Registry Client Diversity EVM Compatibility About About Aere Foundation Roadmap Press & Newsroom Brand Kit Editorial Standards Build Developer Hub Documentation RPC Reference SDK Add Network Faucet Academy Grants Network Architecture Post-Quantum Stack Validators Run a Validator Network Status Audits Security Decentralization Solutions Payments DeFi Real-World Assets Infrastructure Gaming NFTs & Culture Explore Explorer Blocks Transactions Tokens Research & Papers Glossary Blog Legal Terms & Privacy Sanctions Compliance Aere Network. Chain ID 2800. Every claim on this site is checkable: rpc.aere.network --- # Falcon-512 | Aere Network URL: https://aere.network/glossary/falcon-512.html Fetched: 2026-09-15 Falcon-512 | Aere Network Glossary Falcon-512 Chain 2800 Verified on-chain Updated 2026-08-15 Verified at block 13,921,041 1 min read The lattice-based signature scheme, selected by NIST for post-quantum standardization, that chain 2800 uses to anchor its block history. Falcon-512 is a digital signature scheme built on NTRU lattices, one of the schemes selected by NIST for post-quantum standardization and the basis of the FN-DSA draft standard. Its security does not rest on the elliptic-curve discrete logarithm problem, so Shor's algorithm, the quantum attack that breaks that problem, does not apply to it. Among post-quantum schemes it is notable for compact signatures and fast verification. Signatures are compressed, so their exact length varies slightly from one signature to the next. On chain 2800, Falcon-512 plays two distinct roles, and the distinction matters. First, as a precompile : Falcon-512 verification has been callable from any contract since block 9,189,161, as one of five post-quantum precompiles at addresses 0x0AE1 through 0x0AE5, validated against NIST test vectors on-chain. Second, in the post-quantum anchor : since block 13,014,000, every 32nd block header carries a certificate of Falcon-512 signatures from the validators over the parent block, and a 32-byte digest of that certificate sits inside the data covered by the block hash. The enforced threshold today is at least 3 signatures per anchor block; in practice certificates carry 8 or 9 (the configured cap is 9 since 2026-08-16). The validators' Falcon-512 public keys are bound on-chain in a 9-entry signer registry held by an immutable contract whose storage holds the registry's keccak hash. Equally important is what Falcon-512 does not do today: the consensus signatures that give blocks finality remain classical ECDSA secp256k1 under QBFT . The anchor gives block history a signature layer designed to withstand quantum attack; it does not make the consensus itself post-quantum, and the chain does not claim that it does. Verify it yourself Verify it yourself: the Falcon-512 verifier is the precompile at 0x0000000000000000000000000000000000000AE1. Send this to https://rpc.aere.network: {"jsonrpc":"2.0","id":1,"method":"eth_call","params":[{"to":"0x0000000000000000000000000000000000000AE1","data":"0x00"},"latest"]}. The verifier answers 0x0000000000000000000000000000000000000000000000000000000000000000, a full word of zeros, for anything that is not a valid signature, while an address with no code answers 0x. A valid Falcon-512 signature, supplied as public key, signature length, nonce, message and signature in that order, makes the same call return 1. Explore the post-quantum stack Next up Seal Certificate The Aere glossary Post-Quantum Anchor Validator Finality Precompile QBFT Consensus Falcon-512 Seal Certificate Base Fee Floor Block Header Signer Registry Client Diversity EVM Compatibility About About Aere Foundation Roadmap Press & Newsroom Brand Kit Editorial Standards Build Developer Hub Documentation RPC Reference SDK Add Network Faucet Academy Grants Network Architecture Post-Quantum Stack Validators Run a Validator Network Status Audits Security Decentralization Solutions Payments DeFi Real-World Assets Infrastructure Gaming NFTs & Culture Explore Explorer Blocks Transactions Tokens Research & Papers Glossary Blog Legal Terms & Privacy Sanctions Compliance Aere Network. Chain ID 2800. Every claim on this site is checkable: rpc.aere.network --- # Finality | Aere Network URL: https://aere.network/glossary/finality.html Fetched: 2026-09-15 Finality | Aere Network Glossary Finality Chain 2800 Verified on-chain Updated 2026-08-15 Verified at block 13,921,041 1 min read On chain 2800 a block is final the instant seven of ten validators commit it under QBFT, so finality arrives with the block itself, in about half a second. Finality is the moment a block becomes permanent. Before it, a transaction is a claim; after it, the transaction is history that no honest node will roll back. Chains differ in how they reach that point. Probabilistic designs such as proof-of-work only make a block less and less likely to be replaced as more work accumulates on top of it, which is why exchanges and bridges wait for many confirmations. BFT consensus takes the other route: a block signed by a supermajority of known validators is final the instant it is committed, and honest nodes never reorganize it. Chain 2800 takes the second route. It runs QBFT with ten validators and a quorum of seven: once seven commit signatures exist for a block, that block is final. Blocks are produced roughly every 500 ms, so inclusion and finality arrive together, in about half a second. The commit signatures are classical ECDSA over secp256k1; chain 2800 does not claim post-quantum consensus. Two further mechanisms guard finalized history. A second client, an independently implemented Nethermind fork, validates every block alongside the producing client, which is the point of client diversity . And since block 13,014,000, every 32nd block header carries a post-quantum anchor : a certificate of Falcon-512 signatures from the validators over the parent block, at least 3 per anchor block and 5 in practice, whose 32-byte digest sits inside the data covered by the block hash. Verify it yourself Verify it yourself: POST {"jsonrpc":"2.0","method":"eth_getBlockByNumber","params":["latest",false],"id":1} to https://rpc.aere.network, record the returned number and hash, then call eth_getBlockByNumber again any time later with ["", false]; the same hash comes back every time, because a committed QBFT block is never replaced. Explore the post-quantum stack Next up Precompile The Aere glossary Post-Quantum Anchor Validator Finality Precompile QBFT Consensus Falcon-512 Seal Certificate Base Fee Floor Block Header Signer Registry Client Diversity EVM Compatibility About About Aere Foundation Roadmap Press & Newsroom Brand Kit Editorial Standards Build Developer Hub Documentation RPC Reference SDK Add Network Faucet Academy Grants Network Architecture Post-Quantum Stack Validators Run a Validator Network Status Audits Security Decentralization Solutions Payments DeFi Real-World Assets Infrastructure Gaming NFTs & Culture Explore Explorer Blocks Transactions Tokens Research & Papers Glossary Blog Legal Terms & Privacy Sanctions Compliance Aere Network. Chain ID 2800. Every claim on this site is checkable: rpc.aere.network --- # Post-Quantum Anchor | Aere Network URL: https://aere.network/glossary/post-quantum-anchor.html Fetched: 2026-09-15 Post-Quantum Anchor | Aere Network Glossary Post-Quantum Anchor Chain 2800 Verified on-chain Updated 2026-08-15 Verified at block 13,921,041 1 min read Every 32nd block header on chain 2800 binds a Falcon-512 validator certificate under the block hash via a 32-byte digest, live since block 13,014,000. A post-quantum anchor ties a certificate of post-quantum signatures into the data that a block hash covers. The problem it addresses is retroactive. Classical signatures stay verifiable in the record forever, so an attacker who later recovered old validator keys could, in principle, re-sign an alternative history that looks as valid as the real one. An anchor leaves periodic evidence in the chain that was signed with a scheme designed to resist that recovery, and it binds that evidence under the block hash so it cannot be detached or replaced afterwards. On chain 2800 the anchor has been live since block 13,014,000. Every 32nd block header carries a seal certificate of Falcon-512 signatures from the validators over the parent block, and a 32-byte digest of that certificate sits inside the data covered by the block hash. The rule enforced today requires at least 3 signatures per anchor block; in practice certificates carry 8 or 9 (the configured cap is 9 since 2026-08-16). The signers are the 9 entries of the signer registry , bound on-chain in an immutable contract whose storage holds the registry keccak. Two boundaries matter. Block production and finality on chain 2800 still run on classical ECDSA secp256k1 signatures under QBFT ; the anchor adds post-quantum evidence to the record, it does not make consensus post-quantum. The Falcon-512 verification the anchor relies on is itself available on-chain: five post-quantum precompiles have been live since block 9,189,161 at addresses 0x0AE1 to 0x0AE5, validated against NIST test vectors. Verify it yourself Verify it yourself: POST {"jsonrpc":"2.0","method":"eth_getBlockByNumber","params":["0xC693F0",false],"id":1} to https://rpc.aere.network (0xC693F0 is block 13,014,000, an anchor height). RLP-decode the extraData field: its first element is the 32-byte certificate digest. Repeat with the next block, 0xC693F1, and the same element is ordinary client vanity bytes instead; anchor heights recur every 32 blocks. Explore the post-quantum stack Next up Validator The Aere glossary Post-Quantum Anchor Validator Finality Precompile QBFT Consensus Falcon-512 Seal Certificate Base Fee Floor Block Header Signer Registry Client Diversity EVM Compatibility About About Aere Foundation Roadmap Press & Newsroom Brand Kit Editorial Standards Build Developer Hub Documentation RPC Reference SDK Add Network Faucet Academy Grants Network Architecture Post-Quantum Stack Validators Run a Validator Network Status Audits Security Decentralization Solutions Payments DeFi Real-World Assets Infrastructure Gaming NFTs & Culture Explore Explorer Blocks Transactions Tokens Research & Papers Glossary Blog Legal Terms & Privacy Sanctions Compliance Aere Network. Chain ID 2800. Every claim on this site is checkable: rpc.aere.network --- # Precompile | Aere Network URL: https://aere.network/glossary/precompile.html Fetched: 2026-09-15 Precompile | Aere Network Glossary Precompile Chain 2800 Verified on-chain Updated 2026-08-15 Verified at block 13,921,041 1 min read A precompile is a native function at a fixed address; on chain 2800, five post-quantum signature verifiers have run this way since block 9,189,161. A precompile is a function built directly into the node software and exposed at a fixed address. To a smart contract it looks like any other contract: you call the address, pass input, read output. The difference is that the code behind it is native, not EVM bytecode, so operations that would be impractical to express as bytecode, such as verifying signatures over large keys, run at practical cost. Every EVM chain ships with a base set of precompiles (ecrecover is the original example), and that shared set is part of what EVM compatibility means. Chain 2800 extends that set. Five post-quantum precompiles have been live since block 9,189,161, at addresses 0x0AE1 through 0x0AE5, covering the Falcon-512 , ML-DSA, and SLH-DSA signature families. Each was validated on-chain against NIST test vectors, so any contract on chain 2800 can verify a post-quantum signature today. One boundary matters here. A precompile is a capability, not a guarantee: it verifies whatever it is given. Consensus signatures on chain 2800 are classical ECDSA secp256k1, and calling a post-quantum verifier from an ordinary transaction does not, by itself, make the calling account post-quantum safe. What binds post-quantum cryptography to the chain itself is the post-quantum anchor : since block 13,014,000, every 32nd block header carries a seal certificate of at least 3 Falcon-512 signatures from the validators over the parent block, with a 32-byte digest of that certificate inside the data covered by the block hash. Verify it yourself Verify it yourself: POST to https://rpc.aere.network the body {"jsonrpc":"2.0","id":1,"method":"eth_call","params":[{"to":"0x0000000000000000000000000000000000000ae1","data":"0x"},"latest"]}. The Falcon-512 verifier executes natively and returns a 32-byte zero word for an input that fails verification; a passing check requires a correctly formatted signature payload in the precompile's documented input format. Explore the post-quantum stack Next up QBFT Consensus The Aere glossary Post-Quantum Anchor Validator Finality Precompile QBFT Consensus Falcon-512 Seal Certificate Base Fee Floor Block Header Signer Registry Client Diversity EVM Compatibility About About Aere Foundation Roadmap Press & Newsroom Brand Kit Editorial Standards Build Developer Hub Documentation RPC Reference SDK Add Network Faucet Academy Grants Network Architecture Post-Quantum Stack Validators Run a Validator Network Status Audits Security Decentralization Solutions Payments DeFi Real-World Assets Infrastructure Gaming NFTs & Culture Explore Explorer Blocks Transactions Tokens Research & Papers Glossary Blog Legal Terms & Privacy Sanctions Compliance Aere Network. Chain ID 2800. Every claim on this site is checkable: rpc.aere.network --- # QBFT Consensus | Aere Network URL: https://aere.network/glossary/qbft.html Fetched: 2026-09-15 QBFT Consensus | Aere Network Glossary QBFT Consensus Chain 2800 Verified on-chain Updated 2026-08-15 Verified at block 13,921,041 1 min read The vote-based consensus behind chain 2800: ten validators, a quorum of seven, one block roughly every 500 ms, and finality the moment a block appears. QBFT, Quorum Byzantine Fault Tolerance, is a consensus protocol for networks with a known set of validators rather than open mining. Validators take turns proposing blocks. Each proposal passes through a prepare phase and a commit phase, and a block joins the chain only once a quorum of validators has signed it. Quorums are sized to overlap in honest validators, so conflicting blocks can never both collect enough signatures. The result is immediate finality : no forks, no reorganizations, no waiting for confirmations. The protocol keeps working as long as the honest validators can still form a quorum, even if the rest are faulty, offline, or malicious. Chain 2800 runs QBFT with ten validators and a quorum of seven, producing one block roughly every 500 ms. The commit signatures that finalize each block are classical ECDSA on secp256k1, recorded in the block header . Consensus itself is therefore not post-quantum, and Aere does not claim that it is. What the chain adds is a distinct layer on top: since block 13,014,000, every 32nd header carries a seal certificate of Falcon-512 signatures from the validators over the parent block, and a 32-byte digest of that certificate sits inside the data covered by the block hash. That mechanism is the post-quantum anchor . A second, independently implemented client validates every block alongside the producing client, so a consensus defect in either implementation surfaces as a disagreement between them instead of a silent failure. See client diversity . Verify it yourself Verify it yourself: POST {"jsonrpc":"2.0","method":"qbft_getValidatorsByBlockNumber","params":["latest"],"id":1} to https://rpc.aere.network and count the ten validator addresses in the result. Explore the post-quantum stack Next up Falcon-512 The Aere glossary Post-Quantum Anchor Validator Finality Precompile QBFT Consensus Falcon-512 Seal Certificate Base Fee Floor Block Header Signer Registry Client Diversity EVM Compatibility About About Aere Foundation Roadmap Press & Newsroom Brand Kit Editorial Standards Build Developer Hub Documentation RPC Reference SDK Add Network Faucet Academy Grants Network Architecture Post-Quantum Stack Validators Run a Validator Network Status Audits Security Decentralization Solutions Payments DeFi Real-World Assets Infrastructure Gaming NFTs & Culture Explore Explorer Blocks Transactions Tokens Research & Papers Glossary Blog Legal Terms & Privacy Sanctions Compliance Aere Network. Chain ID 2800. Every claim on this site is checkable: rpc.aere.network --- # Seal Certificate | Aere Network URL: https://aere.network/glossary/seal-certificate.html Fetched: 2026-09-15 Seal Certificate | Aere Network Glossary Seal Certificate Chain 2800 Verified on-chain Updated 2026-08-15 Verified at block 13,921,041 1 min read A bundle of Falcon-512 validator signatures over a block, with a 32-byte digest sealed under the block hash on every 32nd header of chain 2800. A seal certificate is a package of signatures in which several validators independently attest to the same block. One signature proves that one machine endorsed the block; a certificate proves that a defined minimum of the validator set did. What makes a certificate useful is not the signatures alone but how it is bound to the chain: if it could be detached or swapped without changing the block hash, it would prove nothing to a later reader. On chain 2800, the seal certificate is the carrier of the post-quantum anchor . Since block 13,014,000, every 32nd block header carries a certificate of Falcon-512 signatures from the validators over the parent block. The certificate travels in the header, and a 32-byte digest of it sits inside the data covered by the block hash. Change or remove one signature and the certificate no longer matches the digest sealed under the hash, so the header fails validation. The rule enforced today requires at least 3 signatures per anchor block, drawn from the 9 entries of the on-chain signer registry ; in practice certificates carry 8 or 9 (the configured cap is 9 since 2026-08-16). The certificate is an attestation layer, not the consensus itself: finality on chain 2800 is decided today under QBFT with classical ECDSA secp256k1 signatures, and AERE does not claim post-quantum consensus. The certificate records, in a signature family designed to resist quantum attack, which validators stood behind each anchored block. Verify it yourself Verify it yourself: POST {"jsonrpc":"2.0","method":"eth_getBlockByNumber","params":["0xC693F0", false],"id":1} to https://rpc.aere.network. Height 0xC693F0 is block 13,014,000, an anchor height: the returned extraData decodes to the Falcon-512 certificate, and its first 32-byte field is the digest covered by the block hash. A non-anchor header nearby decodes to a plain vanity string instead. Explore the post-quantum stack Next up Base Fee Floor The Aere glossary Post-Quantum Anchor Validator Finality Precompile QBFT Consensus Falcon-512 Seal Certificate Base Fee Floor Block Header Signer Registry Client Diversity EVM Compatibility About About Aere Foundation Roadmap Press & Newsroom Brand Kit Editorial Standards Build Developer Hub Documentation RPC Reference SDK Add Network Faucet Academy Grants Network Architecture Post-Quantum Stack Validators Run a Validator Network Status Audits Security Decentralization Solutions Payments DeFi Real-World Assets Infrastructure Gaming NFTs & Culture Explore Explorer Blocks Transactions Tokens Research & Papers Glossary Blog Legal Terms & Privacy Sanctions Compliance Aere Network. Chain ID 2800. Every claim on this site is checkable: rpc.aere.network --- # Signer Registry | Aere Network URL: https://aere.network/glossary/signer-registry.html Fetched: 2026-09-15 Signer Registry | Aere Network Glossary Signer Registry Chain 2800 Verified on-chain Updated 2026-08-15 Verified at block 13,921,041 1 min read The on-chain list binding each of chain 2800's ten validators to a Falcon-512 public key, committed as a keccak digest in an immutable contract. A signer registry answers a question that signature verification alone cannot: not "did some key sign this?" but "did the right key sign this?". A signature proves possession of a private key; only a registry, a published binding between each validator and its public key, turns that into proof that a specific validator signed. Without one, a certificate of post-quantum signatures floats free, because anyone can generate keys and sign anything. On chain 2800 the registry has nine entries, one per validator , each binding a validator address to its Falcon-512 public key. The registry is committed on chain: an immutable contract holds, in its storage, the keccak hash of the full registry contents. Immutable means what it says: the contract has no update path, so the commitment cannot be quietly replaced. Changing the bound set means publishing a new commitment, in the open, where anyone can see the change. The registry is what the post-quantum anchor checks against. Since block 13,014,000, every 32nd block header carries a seal certificate of Falcon-512 signatures from the validators over the parent block, and a 32-byte digest of that certificate sits inside the data covered by the block hash. A signature counts toward the certificate only if its key appears in the registry. The threshold enforced today is at least 3 signatures per anchor block; in practice certificates carry 5. One boundary, stated plainly: the consensus signatures behind finality are classical ECDSA secp256k1 today. The registry serves the anchor, not consensus voting. Verify it yourself Verify it yourself: POST {"jsonrpc":"2.0","method":"eth_getStorageAt","params":["0x6a690b22dacf773b4bef121c9b5dbecffe530873","0x0","latest"],"id":1} to https://rpc.aere.network. The 32 bytes returned are the keccak commitment of the current nine-entry registry: each validator address followed by its Falcon-512 public key, hashed in index order. Explore the post-quantum stack Next up Client Diversity The Aere glossary Post-Quantum Anchor Validator Finality Precompile QBFT Consensus Falcon-512 Seal Certificate Base Fee Floor Block Header Signer Registry Client Diversity EVM Compatibility About About Aere Foundation Roadmap Press & Newsroom Brand Kit Editorial Standards Build Developer Hub Documentation RPC Reference SDK Add Network Faucet Academy Grants Network Architecture Post-Quantum Stack Validators Run a Validator Network Status Audits Security Decentralization Solutions Payments DeFi Real-World Assets Infrastructure Gaming NFTs & Culture Explore Explorer Blocks Transactions Tokens Research & Papers Glossary Blog Legal Terms & Privacy Sanctions Compliance Aere Network. Chain ID 2800. Every claim on this site is checkable: rpc.aere.network --- # Validator | Aere Network URL: https://aere.network/glossary/validator.html Fetched: 2026-09-15 Validator | Aere Network Glossary Validator Chain 2800 Verified on-chain Updated 2026-08-15 Verified at block 13,921,041 1 min read A validator is one of nine nodes that propose and sign blocks on chain 2800, where a block becomes final once six of them have signed it. A validator is a node with the right and the duty to take part in consensus. It proposes new blocks, checks blocks proposed by others against the protocol rules, and signs the ones it accepts. On a proof-of-authority chain like this one, the validator set is a known list of identified signers rather than an open mining or staking market, so agreement comes from counted signatures, not from computational work. Chain 2800 runs QBFT consensus with ten validators and a block roughly every 500 ms. A block is committed only when seven of the ten validators sign it; that commit is what gives the chain its finality , since a committed block is not replaced by a competing branch. These consensus signatures are classical ECDSA secp256k1. The chain does not claim post-quantum consensus. Each validator also holds a Falcon-512 key, one of the 9 entries in the on-chain signer registry . Since block 13,014,000, every 32nd block header carries a seal certificate of validator Falcon-512 signatures over the parent block, at least 3 per certificate and in practice 5, the configured cap, and a 32-byte digest of that certificate sits inside the data covered by the block hash. That mechanism is the post-quantum anchor . The chain is also validated by a second, independently implemented client running alongside the producing one, so no single codebase decides on its own what the chain is. See client diversity . Verify it yourself Verify it yourself: POST {"jsonrpc":"2.0","id":1,"method":"eth_getBlockByNumber","params":["latest",false]} to https://rpc.aere.network, then repeat with the preceding heights as hex block numbers until you have 32 consecutive blocks, and count the distinct "miner" addresses across the results: you will find nine. Explore the post-quantum stack Next up Finality The Aere glossary Post-Quantum Anchor Validator Finality Precompile QBFT Consensus Falcon-512 Seal Certificate Base Fee Floor Block Header Signer Registry Client Diversity EVM Compatibility About About Aere Foundation Roadmap Press & Newsroom Brand Kit Editorial Standards Build Developer Hub Documentation RPC Reference SDK Add Network Faucet Academy Grants Network Architecture Post-Quantum Stack Validators Run a Validator Network Status Audits Security Decentralization Solutions Payments DeFi Real-World Assets Infrastructure Gaming NFTs & Culture Explore Explorer Blocks Transactions Tokens Research & Papers Glossary Blog Legal Terms & Privacy Sanctions Compliance Aere Network. Chain ID 2800. Every claim on this site is checkable: rpc.aere.network --- # AERE Governance, On-chain DAO state URL: https://aere.network/governance.html Fetched: 2026-09-15 AERE Governance, On-chain DAO state Governance, live DAO state Read this before you read the numbers. This page shows the live state of AereGovernanceStaked , an early stake-weighted voting contract. It is superseded . It is kept live and shown here because it exists on chain and people can find it, not because it is the governance path. Two measured facts about it, both taken from chain 2800 on 2026-08-01: it reads its voting weight from a deprecated staking contract whose totalStaked() returns 0 , so its quorumRequired() also returns 0 ; and its only execution path is a call back into itself, so a passed proposal here cannot act on any other contract. Treat every vote on this contract as advisory. Nothing on chain 2800 is governed by it today. Where governance is actually being built. The canonical stack is deployed and measured live on chain 2800 on 2026-08-01: AereGovLockV2 0x547F…7731 (10,240 bytes, non-transferable checkpointed vote lock), AereGovernorV2 0x0325…3047 (16,616 bytes, voting delay 2 days, voting period 14 days, proposal threshold 100,000 votes) and AereGovernorV2Timelock 0x9d61…5f85 (7,427 bytes, getMinDelay() = 172,800 s, that is 48 hours). What has not happened is the handover: protocol contracts are not yet owned by that Timelock, so the stack is deployed and idle rather than in charge. Contracts move to it as ownership is transferred, and that transfer is the open step, not the deployment. AereGovernanceStaked at 0x8D77…F80bCb . Every value below is read from that contract on each render. To look at the same contract in an interactive form, see the DAO console . Parameters, read from the contract Proposal threshold , Voting period , Execution delay , Quorum , Quorum in AERE right now , Pass rule , Total proposals , Loading on-chain params… Proposals # Title Proposer Status Yes No Abstain Ends / Executes Loading… Direct on-chain reads via rpc.aere.network , refreshed every 15 seconds. Values shown here were last checked by hand against chain 2800 on 2026-08-01: proposal threshold 100,000 AERE, voting period 604,800 s (7 days), execution delay 172,800 s (48 hours), quorum 20 percent of total staked, quorumRequired() 0, proposalCount() 0. --- # AERE Developer Grants URL: https://aere.network/grants.html Fetched: 2026-09-15 AERE Developer Grants Developer grants AERE Network funds builders. Open to everyone, no equity, no token claw-backs, no committee gate-keeping. Per whitepaper §6.2. What we fund: dApps that go live on AERE, ecosystem infrastructure (indexers, wallets, bridges, oracles), developer tooling, technical content (tutorials, video courses), security research, integration adapters. What we don't fund: projects with no working prototype, marketing campaigns, generic NFT collections, things outside the AERE ecosystem. Tiers Quick build $1k, $5k USD 1-2 week scope Single-purpose tooling, integrations 50% on approval, 50% on delivery Approval in < 7 days Project $5k, $25k USD 1-3 month scope dApps, indexers, libraries, content series Milestone-based payments Approval in < 14 days Strategic $25k, $100k USD 3+ month scope Major infrastructure, novel research Quarterly check-ins, public KPIs DAO vote required Apply All applications open as a public issue on git.aere.network/aere-network/grants for transparency. The form below pre-fills the issue body, you'll be redirected to Gitea to confirm and submit. Project title Requested tier Quick build ($1k, $5k) Project ($5k, $25k) Strategic ($25k, $100k) Requested amount (USD) Your GitHub / Gitea handle (or portfolio URL) AERE payout address Contact (Discord / Telegram / email, optional) One-paragraph summary of what you'll build Milestones (markdown bullet list) Prior work (links, screenshots, repos, markdown OK) Submit application → All submissions are public. Sensitive info should not be included. Approval criteria: clear scope, demonstrable past work, AERE-aligned outcomes, fair pricing. The DAO can call out conflicts of interest at any time. --- # AERE HTLC, Hashed Timelock Contracts URL: https://aere.network/htlc.html Fetched: 2026-09-15 AERE HTLC, Hashed Timelock Contracts Status note, 2026-08-23. This page presents the AereHTLC contract at an address that currently holds no code on chain 2800 ( 0x71851094e5bAaC3e70Ca76A399510B2Ed9100988 , verifiable with eth_getCode ). This capability is not deployed at the address shown. We publish this note rather than let the page imply otherwise; anything interactive on it will not resolve until a verified address is in place. AERE HTLC Home All dApps Explorer Hashed Timelock Contracts Coming soon. This feature is built and on the AERE roadmap, its on-chain contracts are not yet deployed. Actions are disabled until launch. The cryptographic primitive behind Lightning Network, atomic swaps with other chains, submarine swaps, and trustless time-locked escrow. Lock AERE with a hashlock + timeout. The recipient claims by revealing the preimage; if they don't, you get refunded after expiry. Contract overview AereHTLC 0x71851094…100988 (planned address; no contract code there on chain 2800 today) Total locked , HTLCs created , Connect Wallet Refresh Open a new HTLC Step 1 · Generate a preimage Save the preimage privately and share only with the recipient (or share the hashlock publicly and reveal the preimage at claim time). Generate fresh 32-byte preimage , Step 2 · Lock funds with hashlock + timeout Recipient address Amount (AERE) Timeout (hours from now) Open HTLC , Claim or Refund existing HTLCs Claim · I'm the recipient and I have the preimage HTLC id Preimage (0x... 32 bytes) Claim , Refund · I'm the sender and the timeout has passed HTLC id Refund , Recent HTLCs Loading… What this enables Atomic swaps , trade AERE for BTC/ETH/XMR with no trusted intermediary, by mirroring HTLCs on both chains under the same hashlock Lightning Network primitive , multi-hop payment routing where each hop is its own HTLC; the final preimage propagates back through the path Submarine swaps , convert on-chain AERE to off-chain Lightning AERE without exposing your routing channel Time-locked escrow , service payments that auto-refund if the service isn't delivered by a deadline --- # AERE Identity, DID Registry URL: https://aere.network/identity.html Fetched: 2026-09-15 AERE Identity, DID Registry AERE Identity Home DAO Explorer Self-Sovereign Identity AereIdentity is an on-chain DID registry. Anyone can publish a profile URI (IPFS, Arweave, or HTTP) attached to their wallet. Whitelisted attestors can issue revocable claims (KYC, email-verified, age-18+, DAO membership) that other contracts can check at runtime. Whitepaper §5.4. Your profile Contract 0x658d…CaD1 Address connect a wallet to view Profile URI connect a wallet to view Last updated connect a wallet to view Attestor status connect a wallet to view Connect Wallet New profile URI Update profile Check a claim Verify whether a specific attestor has issued a still-valid claim of a given type for a subject. Claim type is bytes32 (e.g. keccak256("KYC_LEVEL_1")). Subject Claim type (bytes32) Attestor Check claim Issue a claim (attestors only) Subject Claim type (bytes32) Expires at (unix timestamp, 0 = never) Evidence hash (bytes32) Issue claim AI-native identity Identity built for machine actors as well as people. An autonomous agent gets a post-quantum root that survives a cryptographic break, plus fast, revocable secp256k1 session keys for day-to-day signing. AerePQCKeyRegistry binds a PQC public key with on-chain proof of possession; AereAgentDID roots an agent DID in a Falcon key and rotates disposable session keys beneath it, settling through AERE's machine-account rail (AERE402 / AereAgent). Deployed and self-tested on chain 2800, independent audit pending. Application-layer contracts only; consensus still signs classical secp256k1 QBFT. PQC key registry 0x1eCa…3691 Agent DID 0xce64…22C5 Session keys secp256k1, revocable --- # AereInsurance, smart-contract exploit cover URL: https://aere.network/insurance.html Fetched: 2026-09-15 AereInsurance, smart-contract exploit cover Status note, 2026-08-23. This page presents the insurance pool and governance contracts at an address that currently holds no code on chain 2800 ( 0xe9Baa9174621845Eb8196238628fdF82c6b7383b , verifiable with eth_getCode ). This capability is not deployed at the address shown. We publish this note rather than let the page imply otherwise; anything interactive on it will not resolve until a verified address is in place. AereInsurance Pool Coming soon. This feature is built and on the AERE roadmap, its on-chain contracts are not yet deployed. Actions are disabled until launch. Provide AERE to the insurance reserve, earn premium rewards funded by DAO-paid premiums + voluntary protocol contributions. If a covered loss event is approved by governance, depositors take a haircut proportional to the payout. 7-day withdrawal notice window prevents opportunistic exits. Pool AereInsurancePool 0xe9Baa917…2c6b7383b Governance AereGovernance Total reserve awaiting launch Total shares awaiting launch Price per share awaiting launch Your reserve awaiting launch Your shares awaiting launch Withdrawal notice pending awaiting launch Connect Wallet Refresh Deposit AERE Amount (AERE) Deposit Withdraw (start notice period) After giving withdrawal notice, you must wait 7 days before withdrawing. During the notice period your shares are reserved, you stop earning premiums but are no longer at risk for new claims. Shares to withdraw Give notice Withdraw (after 7d notice) --- # AERE L2, Optimistic Rollup Deposit URL: https://aere.network/l2.html Fetched: 2026-09-15 AERE L2, Optimistic Rollup Deposit AERE L2 Bridge Home Add Network Explorer Deposit to AERE L2 There is no deposit inbox to deposit into, and the addresses this page used to show were wrong. Measured on chain 2800 on 2026-08-01 by walking each address's live runtime bytecode: not one of the eight addresses previously listed as a rollup inbox contains a deposit() or a MIN_DEPOSIT() function. Three of them have no code at all. The other five are unrelated live contracts that have nothing to do with an L2 inbox, and one of them is a bridge contract our own registry marks as deprecated and flawed. The deposit button was already disabled, but the addresses were still printed where a reader could copy one and send AERE to it by hand. They have been removed. No rollup is live on Aere Network today, no sequencer is producing blocks, and nothing on this page can move your funds. What this page describes is the intended deposit path: send native AERE on Layer 1 to a rollup inbox, and the sequencer credits the same address on the rollup. None of it is deployed. Layer 1 itself is live and public, and that is the only thing on Aere Network you can transact on today. Source AERE L1 · Chain ID 2800 · live Destination AERE L2 · Chain ID 28001 · reserved, not running Inbox contract none deployed (measured 2026-08-01) Bridge time not applicable, there is nothing to bridge to yet Choose rollup Rollup #1, chainId 28001 (reserved) Rollup #2, chainId 28002 Rollup #3, chainId 28003 Rollup #4, chainId 28004 Rollup #5, chainId 28005 Rollup #6, chainId 28006 Rollup #7, chainId 28007 Rollup #8, chainId 28008 (reserved) Amount (AERE) Connect MetaMask Deposit to L2 Your L1 balance , Last deposit , Planned rollup endpoints These are the chain IDs and RPC hostnames reserved for the eight rollups. They are not serving yet, so there is nothing to add to a wallet today: Rollup #1: RPC https://l2-rpc.aere.network · Chain ID 28001 Rollup #2: RPC https://l2b-rpc.aere.network · Chain ID 28002 Rollup #3: RPC https://l2c-rpc.aere.network · Chain ID 28003 Rollup #4: RPC https://l2d-rpc.aere.network · Chain ID 28004 Rollup #5: RPC https://l2e-rpc.aere.network · Chain ID 28005 Rollup #6: RPC https://l2f-rpc.aere.network · Chain ID 28006 Rollup #7: RPC https://l2g-rpc.aere.network · Chain ID 28007 Rollup #8: RPC https://l2h-rpc.aere.network · Chain ID 28008 Checked 2026-08-01: the hostnames resolve and terminate TLS, but no RPC answers on them yet. There is no L2 block explorer to link to until a sequencer is producing blocks. Layer 1 activity is live and public at explorer.aere.network . --- # AereLaunchpad, Token launches on AERE URL: https://aere.network/launchpad.html Fetched: 2026-09-15 AereLaunchpad, Token launches on AERE AereLaunchpad Coming soon. This feature is built and on the AERE roadmap, its on-chain contracts are not yet deployed. Actions are disabled until launch. Fixed-price IDO platform. Project creators configure (token, price, soft/hard cap, per-wallet limits, start/end, whitelist), users contribute AERE, claim tokens after success or refund on failure. Platform AereLaunchpad 0x33E3B06A…84dbca32 Total sales , Your address , Connect Wallet Refresh All sales Loading… Create a sale Creating a sale requires the token contract address (must be ERC-20), the price in wei AERE per smallest token unit, soft/hard cap in wei AERE, and tokens to deposit. Approve the launchpad contract to spend the deposit amount before calling createSale. Token address Payment receiver Price (wei AERE per 1e18 token) Tokens to deposit (wei) Soft cap (AERE) Hard cap (AERE) Per-wallet cap (AERE, 0 = no limit) Whitelist only? No Yes Start time (unix sec) End time (unix sec) Create sale --- # AERE Network, Lending URL: https://aere.network/lending.html Fetched: 2026-09-15 AERE Network, Lending Lending Not part of the AERE Network roadmap at this time. AERE Network does not issue or operate a CDP-style lending product, and AERE is the only native token on this network. If a future on-chain lending product is built, it will be announced through the official AERE channels. For staking AERE to earn yield, see the live sAERE staking vault , protocol revenue vests to stakers over a seven-day drip and the exchange rate never falls. Yield depends entirely on network fee flow; when revenue is quiet, the rate simply holds. Back to home --- # AERE Lightning Channels, Off-chain payment channels with HTLCs URL: https://aere.network/lightning-channels.html Fetched: 2026-09-15 AERE Lightning Channels, Off-chain payment channels with HTLCs AERE Lightning Channels Home All dApps HTLC Routed Lightning Off-chain Lightning Channels Coming soon. This feature is built and on the AERE roadmap, its on-chain contracts are not yet deployed. Actions are disabled until launch. Real Lightning-style payment channels with HTLC support inside channel state. Open with one on-chain transaction, then send unlimited off-chain co-signed payments, including conditional payments, with your counterparty. Only the open and the close (or a dispute) touch the chain. Channel state can carry up to 16 pending HTLCs at any time. Contract overview AereLightningChannels 0xc58Fc171…04c15B62 (placeholder; the channel contract is not deployed on chain 2800 today, and this address holds a different contract) Challenge window 1 day Max HTLCs per state 16 Your address , Connect Wallet 1 · Open or load a channel Open new channel, counterparty address Initial deposit (AERE) Open Channel Or load existing channel by ID Load , Channel # , OPEN Party A , Party B , On-chain deposit total , You are , Bar shows current off-chain state: A balance, B balance, locked in HTLCs. Add funds (deposit more) 2 · Off-chain payments (no gas) Build a new state, sign it, paste your counterparty's signature. Once both signatures are present, the state is final off-chain. No on-chain transaction. State editor Balance A (AERE) Balance B (AERE) Pending HTLCs (JSON array, leave [] for plain payment) [] HTLC entry: {"payer":"0x..","payee":"0x..","amount":"0.1","hashlock":"0x..","timeout":1820000000} , amount in AERE, timeout in unix seconds. Add HTLC builder +1 nonce Nonce 1 Sign this state (your half) Sign with MetaMask , Copy this JSON and send it to your counterparty (any channel, chat, email, QR). They paste it below, sign their half, and send it back. Import counterparty's signed state Load + verify , 3 · Close the channel Submit the latest fully-signed state on-chain. This starts a 1-day challenge window during which either party can override with a higher-nonce signed state. After the window expires, balances are paid out and any remaining HTLCs are claimed (with preimage) or refunded (after their timeout). Submit current state to close , 4 · Resolve HTLCs after closing No on-chain HTLCs yet (channel not in closing state). Settle (after challenge window) , How off-chain channels work Open channel (on-chain) Send 100 micro-payments (off-chain) Close channel (on-chain) ───────────────────── ────────────────────────────────── ───────────────────────── A deposits 1 AERE ───► state #1: A=0.99 B=0.01 (signed) A submits state #100 state #2: A=0.98 B=0.02 (signed) ↓ [1 tx] ... challenge window 1 day state #100: A=0.5 B=0.5 (signed) ↓ settle → balances paid [0 tx, no fees, instant] [1 tx] Lightning routing fits into the same state machine, payments hop across channels by inserting HTLCs into each hop's state, then resolving them once the preimage propagates back. --- # AERE Lightning Network, Channel discovery + multi-hop routing URL: https://aere.network/lightning-network.html Fetched: 2026-09-15 AERE Lightning Network, Channel discovery + multi-hop routing AERE Lightning Network Coming soon. This feature is built and on the AERE roadmap, its on-chain contracts are not yet deployed. Actions are disabled until launch. Every open Lightning channel can announce itself as routable on the on-chain AereChannelRegistry . The off-chain router service indexes the registry, builds the channel graph, and computes BFS multi-hop routes, Lightning's gossip protocol + pathfinding, working on AERE Layer 1. Network status Registry contract Not yet deployed Channels contract Not yet deployed Router API channels-api.aere.network Indexed edges , Last index , Connect Wallet Refresh 1 · Announce your channel Announcing your channel publishes routing fee policy + endpoint hint to the on-chain registry, so other peers can route through you. Either party of an open channel can announce. Withdraw anytime. Channel ID Routing fee (basis points, 0-100) Endpoint (optional, your hub URL or contact) Announce Withdraw announcement , 2 · Find a multi-hop route Sender (your address) Recipient Amount (in wei, paste raw bigint) Compute route , All announced channels , How the network works On-chain (AERE L1) Off-chain (router service) ─────────────────── ────────────────────────── AereLightningChannels ┌─ Polls AereChannelRegistry every 15s └ open(counterparty) → channelId │ Reads each Announcement.party + feeBps │ Cross-references AereLightningChannels.channels(id) AereChannelRegistry │ Filters out withdrawn / non-OPEN └ announce(id, feeBps, endpoint) ├─ Builds directed graph: party → counterparty └ withdraw(id) ├─ Capacity = current balance on each side └─ BFS for shortest path with sufficient capacity Sender: computes route via /route?from=X&to=Y&amount=Z then plays the multi-hop HTLC dance with each hop (lock at each hop with shared hashlock, cascading timeouts) Each hop: co-signs in-channel HTLC state with their counterparty Recipient: reveals preimage; preimage propagates back unlocking each hop --- # AERE Lightning, Multi-Hop Routed Payments (Coming Soon) URL: https://aere.network/lightning.html Fetched: 2026-09-15 AERE Lightning, Multi-Hop Routed Payments (Coming Soon) AERE Lightning Home HTLC All dApps Lightning Network Routing Coming soon. This feature is built and on the AERE roadmap, its on-chain contracts are not yet deployed. Actions are disabled until launch. Send AERE through a router using a shared hashlock. The router opens a paired HTLC to the recipient with a shorter timeout. Recipient reveals the preimage to claim; the router uses the same preimage to pull from your HTLC. Atomic, if the recipient never claims, both HTLCs refund. Active router Address awaiting launch API https://lightning-api.aere.network Fee awaiting launch Max forward (per route) awaiting launch Liquidity awaiting launch Active routes awaiting launch Connect Wallet Refresh I want to SEND I want to RECEIVE Send routed payment Step 1 · Get the recipient's hashlock Ask the recipient to switch to "I want to RECEIVE" above and send you their hashlock. They keep the preimage private. Recipient's hashlock (0x... 32 bytes) Recipient address Amount (AERE) Timeout (hours, must be ≥ 2) Step 2 · Open in-HTLC to router Open HTLC to router Step 3 · Ask router to forward Submit route request Step 4 · Tell the recipient the out-HTLC id Send them the out-HTLC id from step 3. They'll claim it with their preimage. The router automatically pulls your in-HTLC after they claim. Receive routed payment Step 1 · Generate a fresh preimage Keep the preimage private. Send only the hashlock to the sender. Generate Step 2 · Send the hashlock to the sender Copy the hashlock above and send it to whoever's paying you (any messenger). They give it to the router along with your address. Step 3 · Wait for the sender to share the out-HTLC id, then claim Out-HTLC id (from sender) Claim with preimage How the routing works Sender Router Recipient │ open in-HTLC, lock X │ │ │ hashlock=H, timeout=T+δ │ │ ├──────────────────────────▶ │ │ │ │ open out-HTLC, lock X-fee│ │ │ hashlock=H, timeout=T │ │ ├──────────────────────────▶ │ │ │ reveal preimage, │ │ │ claim X-fee │ │ │ ◀──────────────────────────┤ │ router uses preimage │ │ │ to claim X from in-HTLC │ │ │ ◀──────────────────────────┤ │ If the recipient never claims, both HTLCs eventually refund. The router's outgoing timeout is shorter than the incoming, guaranteeing the router can always pull the in-HTLC after the recipient claims out, even if the recipient stalls until the very last second. --- # AERE Mempool, Live pending transactions URL: https://aere.network/mempool.html Fetched: 2026-09-15 AERE Mempool, Live pending transactions Live mempool connecting… · pending transactions broadcast to AERE validators but not yet mined Pending , Seen total 0 Last update , Hash From To Value (AERE) Nonce Seen Waiting for transactions… Source: GET https://api.aere.network/api/mempool (not served today: this endpoint answers 404, so the page shows no data until the feed is published) (snapshot) and GET /api/mempool/stream (Server-Sent Events). Pending pool is sampled every 2s from the public RPC; transactions older than 5 min are evicted from the snapshot. --- # AERE MultiSig, Live signer activity URL: https://aere.network/multisig-live.html Fetched: 2026-09-15 AERE MultiSig, Live signer activity Status note, 2026-08-23. This page presents an operations multisig at an address that currently holds no code on chain 2800 ( 0x30f62deb4fE4e926c414813D4184732d5be181D7 , verifiable with eth_getCode ). This capability is not deployed at the address shown. We publish this note rather than let the page imply otherwise; anything interactive on it will not resolve until a verified address is in place. MultiSig, live signer activity Coming soon, contract not yet deployed. The AereMultiSig contract is not live on chain 2800. Data below will not load. Operations multisig at 0x30f6…81D7 · M-of-N consensus over privileged actions (treasury, upgrades, params). Owners , Threshold , Total tx , Awaiting signatures , Owners # Address Role Loading… Transactions # Status To Value Confirmations Data Loading… Direct on-chain reads via rpc.aere.network . Refreshes every 8s. Confirmation per owner determined via isConfirmed(txId, owner) . --- # AereMultiSig, M-of-N foundation wallet URL: https://aere.network/multisig.html Fetched: 2026-09-15 AereMultiSig, M-of-N foundation wallet Status note, 2026-08-23. This page presents an AereMultiSig contract at an address that currently holds no code on chain 2800 ( 0x30f62deb4fE4e926c414813D4184732d5be181D7 , verifiable with eth_getCode ). This capability is not deployed at the address shown. We publish this note rather than let the page imply otherwise; anything interactive on it will not resolve until a verified address is in place. AereMultiSig Coming soon, contract not yet deployed. The AereMultiSig contract is not live on chain 2800. Buttons below are disabled. Gnosis-Safe-style M-of-N multi-signature wallet. Owners propose transactions; M owners must confirm before execution. Self-administering: changing the owner set or threshold itself requires M confirmations. Wallet AereMultiSig 0x30f62deb…5be181D7 Threshold , Owners , Native AERE balance , Pending transactions , You are , Connect Wallet Refresh Submit transaction To address Value (AERE) Calldata (hex, optional, leave 0x for plain transfers) Submit Requires being an owner. Submission auto-confirms from your address. All transactions Loading… --- # AERE Name Service, Human-readable addresses on AERE URL: https://aere.network/names.html Fetched: 2026-09-15 AERE Name Service, Human-readable addresses on AERE Aere Network Aere Cloud Docs Status AERE Name Service Coming soon. This feature is built and on the AERE roadmap, its on-chain contracts are not yet deployed. Actions are disabled until launch. Register short human-readable names that resolve to your wallet address. alice.aere is much easier to remember and share than a full 40-character hexadecimal address. ENS-style registry running natively on AERE Layer 1. Status: LIVE on mainnet since 2026-08-23 Deployed, tested (8 suites with negative controls), and already holding its first registration. Earlier on the same day this page carried an honesty note: the address it used to show had zero bytes of code. That is fixed the only way we fix things, by shipping: the address below has verifiable code on chain 2800. Registry overview AereNameService 0xb073E226…a6Db30 Treasury (receives fees) 0x0243A4f4…c6f3C3 Min registration 1 year Grace period after expiry 30 days Your address connect a wallet to view Your primary name connect a wallet to view Connect Wallet 1 · Look up a name .aere Resolve 2 · Register a name .aere Years (1-10) Total price Register Names must be 2-32 chars, lowercase a-z, 0-9, hyphen (not at start/end). 3 · Set as primary (reverse lookup) Once you own a name, set it as your "primary" so apps can show alice instead of your hex address. .aere Set as primary Clear primary Pricing Length Price / year Example 5+ chars $5 (100 AERE) alice, satoshi 4 chars $160 (3,200 AERE) aere, neo 3 chars $640 (12,800 AERE) btc, dao 2 chars $2,000 (40,000 AERE) l1, vc 1 char reserved governance only Dollar list prices at the ENS levels; the on-chain amount is the AERE equivalent at the published reference rate ($0.05/AERE until listing), owner-updatable, never retroactive on years already paid. All fees go to the Foundation treasury in the same transaction; the registry contract never holds a balance. --- # AERE Network, System status URL: https://aere.network/network-status.html Fetched: 2026-09-15 AERE Network, System status AERE Network, system status Live health of the services this page can actually measure. Every number on this page is read from the chain or from the service itself when the page loads. Nothing here is written down in advance. Post-quantum finality checkpoints … Last anchor block … Certificate in its header … Certificate form … Anchor interval (blocks) … Message layers enforced … Next enforcement height Reading the last anchor header… Every 32nd block (every 128th from block 17,225,968) carries, under its block hash, a certificate of validator post-quantum seals; since block 17,047,600 the certificate is hybrid, Falcon-512 and SLH-DSA-SHA2-128s, at least six validators per scheme (six of the nine of that time; ten validators since 2026-09-11). The four QBFT message types are refused without a post-quantum seal from blocks 17,250,000 (commit), 17,400,000 (proposal), 17,550,000 (round change) and 17,700,000 (prepare); which of those are in force is computed here from the latest block, not written down in advance. The certificate itself is verified from raw header bytes by verify-anchor.mjs ; this card only reads whether the header carries one. Chain liveness … Latest block … Age (s) … Validator set … Proposed a block recently … Faults tolerated / quorum … Gas price (gwei) "Proposed a block recently" counts how many validators actually produced a block inside the node's recent signing window, read from qbft_getSignerMetrics . It is a separate measurement from the set size, so it can disagree with it, and it will say so when it does. Network parameters 2800 Chain ID QBFT Consensus Pectra + Fusaka EVM ruleset 0.5 s Block time SP1 + R0 zk-verifiers 2,106,597 Fusaka fork block AERE Native token Hyperlane-compat Cross-chain messaging ERC-4337 Account abstraction ERC-7683 Intent-based bridging Across-v3 Solver-based deposits Pyth IPyth Pull oracle drand Quicknet Verifiable randomness 37.5% Validator-reward burn share CoW-batch MEV-resistant DEX 20% / 5% Dev share / Treasury Burn tracker … Held in the burn vault … Splitter counter (independent read) … Forwarded to address(0) Cross-check not run yet. The burn share is a cut of the validator reward , not of the base fee, and on an idle chain it is close to nothing. AereFeeBurnVault has no withdraw function and no admin, so native AERE that arrives there is out of circulation whether or not the optional sweepToZero() step has been called. The first two cards read two different contracts and should agree; the line above says whether they do. FeeBurnVault contract · CoinbaseSplitter contract Public services Checking… A browser cannot always tell a service being down from a service refusing to answer this page. When it cannot tell, the light reads NOT MEASURED. It never reads UP on a guess. dApp pages A 200 on an HTML file proves the file is served, not that the application behind it works, so this page no longer carries a reachability grid for the dApp pages. Open any dApp from the dApps directory to see its own live state. Smart contracts … Contracts in the site's known map … Of those, carrying code on chain On-chain check not run yet. The first number is the length of the list this page carries, so it cannot drift away from it. The second is measured with eth_getCode against the live chain, which is the check that catches a contract address that points at nothing. Browse the full set in the block explorer . --- # AERE NFT, Mint & Marketplace URL: https://aere.network/nft.html Fetched: 2026-09-15 AERE NFT, Mint & Marketplace AERE NFT Home Whitepaper Add Network Explorer NFT Minter & Marketplace Permissionless ERC-721 minting on AERE Network. EIP-2981 royalties. 2.5% protocol fee. Built into the chain. Connect Wallet Mint Marketplace My NFTs Metadata URI (IPFS recommended) Royalty (basis points, max 1000 = 10%) Mint fee: 0.01 AERE. Royalties paid to you on every secondary sale via EIP-2981. Mint NFT Browse listings on the AERE NFT marketplace. Loading listings… NFTs you own. List them for sale at a fixed price. Connect your wallet to see NFTs you own. --- # Post-Quantum Notarization | Aere Network URL: https://aere.network/notarization.html Fetched: 2026-09-15 Post-Quantum Notarization | Aere Network Solutions Post-Quantum Notarization Timestamping Long-term proof Chain 2800 Updated 2026-08-15 Verified at block 13,943,730 2 min read Anchor a document hash on chain 2800 and get a timestamp whose proof outlives the cryptography that made it. No file leaves your hands. A timestamp is only as durable as the cryptography under it. Anchor a document's hash on a public chain today and you get proof it existed at a moment in time, verifiable by anyone. But the classical signatures that secure most chains are on a retirement schedule: once elliptic-curve cryptography falls, an adversary who recovers old validator keys could, in principle, re-sign an alternative history and cast doubt on a record you meant to keep for decades. For a legal exhibit, an archive, or a compliance record that must survive twenty or thirty years, that is not an abstract risk. A timestamp that outlives the cryptography that made it Chain 2800 leaves post-quantum evidence in its own block record. Since block 13,014,000, every anchor block binds a certificate of Falcon-512 validator signatures under the block hash — introduced at a minimum of three seals, and raised at block 14,961,456 (August 21, 2026) to six of nine, a full quorum. A document hash committed on this chain inherits that durability: the proof it existed is carried in a record whose integrity does not rest on classical signatures alone. When you need to show, years from now, that a file is exactly the one you timestamped, the verification does not depend on cryptography that has since been retired. How it works You compute the SHA-256 (or SHAKE-256, via the precompile at 0x0AE5) hash of your document locally, so the file itself never leaves your hands. That 32-byte hash is committed on chain 2800 with half-second deterministic finality . You receive a receipt: the block number, the transaction, and the anchor certificate covering it. Anyone can later verify the hash against the chain, independently of us, with a single read-only call. No file is uploaded, no personal data is stored. Who this is for Law firms and courts that need tamper-evident exhibits. Archives and registries with retention obligations measured in decades. Intellectual-property and research teams establishing priority. Regulated firms under records-retention rules (SEC 17a-4, MiFID II, MiCA) who must keep records provably unaltered. Anywhere the value of a proof is that it will still hold up long after today's cryptography is gone. What exists today, honestly The productised path is live as of August 23, 2026: the AereNotary contract at 0x4aB392c4…bd58c7 records each digest’s first appearance immutably (re-notarizing can never move the original timestamp, by contract), and the Aere Cloud API notarizes and verifies per document, with authentication and billing — we pay the gas and carry the transaction; your file never leaves your hands. The contract is permissionless on purpose: you can bypass our API entirely and call notarize(bytes32) yourself. What remains an engagement deliverable: a counterparty-facing verification page under your brand and a signed conformance report. Verify an anchor yourself curl -O https://aere.network/tools/verify-anchor.mjs -O https://aere.network/tools/falcon512.mjs -O https://aere.network/tools/package.json && npm install node verify-anchor.mjs # the same tool that checks a document anchor checks the # chain's own post-quantum certificate: 20/20 blocks bound. Verify a notarization Talk to the Foundation Next up For regulated finance The Aere glossary Post Quantum Anchor Finality Seal Certificate Falcon 512 Block Header Precompile About About Aere Foundation Roadmap Press & Newsroom Brand Kit Editorial Standards Build Developer Hub Documentation RPC Reference SDK Add Network Faucet Academy Grants Network Architecture Post-Quantum Stack Validators Run a Validator Network Status Audits Security Decentralization Solutions Payments DeFi Real-World Assets Infrastructure Gaming NFTs & Culture Explore Explorer Blocks Transactions Tokens Research & Papers Glossary Blog Legal Terms & Privacy Sanctions Compliance Aere Network. Chain ID 2800. Every claim on this site is checkable: rpc.aere.network --- # Verify a Notarization | Aere Network URL: https://aere.network/notary-check.html Fetched: 2026-09-15 Verify a Notarization | Aere Network Aere Network Aere Cloud Docs Status Aere Network · notarization Verify a notarization. Drop a file to hash it in your browser and check whether, and when, it was notarized on chain 2800. The file never leaves your device; only its hash is looked up, straight from the chain. Drop a file here or click to choose Hashed locally with SHA-256. Nothing is uploaded. …or paste a 32-byte hash directly Check this hash A notarization is a claim that a document existed no later than a moment in time. Aere records the first appearance of each hash immutably in the AereNotary contract: re-notarizing can never move the original timestamp. And because every 128th block (every 32nd block until block 17,225,968, on 2026-09-05) of this chain carries a post-quantum validator certificate, the proof is built to outlive the cryptography that made it. To create a notarization, see the Aere Cloud API (we pay the gas) or call notarize(bytes32) on the contract yourself: it is permissionless. Learn more on the notarization page . © 2026 Aere Network · chain 2800 · Aere Cloud --- # AERE Oracle Network URL: https://aere.network/oracles.html Fetched: 2026-09-15 AERE Oracle Network Oracle Network, live state AereOracle V1 at 0xf0A1…F399 , multi-reporter median price feed, 8-decimal precision. Every value below is a direct on-chain read of that contract. This page reads the V1 oracle, and V1 is deprecated. Read this before you copy an address out of it. Our own registry marks 0xf0A1…F399 deprecated because of an audited defect: it could serve a median that a single fresh reporter controlled, with no freshness quorum underneath it. The corrected contract is AereOracleV2 0xca69AA96…490ACb1 , measured live on 2026-08-01 with 3,631 bytes of runtime code, which reverts unless a quorum of authorised reporters are all fresh. New integrations should be written against V2. V1 is still shown here, and still read by the oracle adapter, because it is currently the live-read source and pretending otherwise would be the same mistake in the other direction. The repoint of the adapter onto V2 is pending on running enough independent reporters to satisfy V2's quorum. Registered reporters , Active symbols , Max staleness , Decimals , Loading on-chain state… Why isn't AERE/USD published? AERE has no exchange listing and no on-chain liquidity pool yet, so there is no market price to publish. We will only publish AERE/USD once there is real market liquidity (CEX order books, or a deep DEX pool whose price is set by arbitrage flow). The oracle is honest data only. Symbols Reporters Submit (reporters) Integrate How it works Loading symbols… # Address Last submission Submissions Status Loading reporters… Connect a wallet to check if it's authorized as a reporter. Authorized reporters can submit price updates for any symbol. Prices are scaled to 8 decimal places (e.g. 1.00 USD = 100000000 ). Symbols are bytes32 , short ASCII works directly (e.g. AERE/USD ). Wallet not connected. Connect wallet Symbol (≤ 31 ASCII chars) Price (8-decimal integer wei) Submit price Address change, 2026-08-01. These three snippets used to hardcode the V1 oracle 0xf0A1…F399 , which our registry marks deprecated. They now point at AereOracleV2 0xca69AA961D836516010Ae669a223Ce249490ACb1 , which has the same getPrice / submit / DECIMALS signatures, so this is a drop-in change for you. Know what you are getting, because we measured both on 2026-08-01 and neither one serves a price right now: getPrice("BTC/USD") reverts on V1 with "no fresh data" (V1 has 1 registered reporter) and reverts on V2 as well (V2 has 3 registered reporters and requires 3 to be simultaneously fresh). No price feed on this chain is currently live. The reason to write against V2 anyway is that when reporters do run, V2 refuses to serve a median that a single fresh reporter could set, and V1 does not. Solidity (read in your contract) interface IAereOracle { function getPrice( bytes32 symbol) external view returns ( uint128 price, uint64 timestamp, uint256 contributors); } // 8-decimal price contract MyDApp { IAereOracle constant ORACLE = IAereOracle( 0xca69AA961D836516010Ae669a223Ce249490ACb1 ); function aereUsd() external view returns ( uint128 ) { ( uint128 p, uint64 t) = ORACLE.getPrice( "AERE/USD" ); require ( block .timestamp - t <= 5 minutes, "stale" ); return p; // scaled by 1e8 } } JS / TypeScript (ethers v6) import { JsonRpcProvider, Contract, encodeBytes32String } from "ethers" ; const ro = new JsonRpcProvider( "https://rpc.aere.network" ); const oracle = new Contract( "0xca69AA961D836516010Ae669a223Ce249490ACb1" , [ "function getPrice(bytes32) view returns (uint128, uint64, uint256)" ], ro); const [price, ts, n] = await oracle.getPrice(encodeBytes32String( "AERE/USD" )); console .log( "AERE/USD =" , Number(price) / 1e8, "from" , n, "reporters" ); Python (web3.py) from web3 import Web3 w3 = Web3(Web3.HTTPProvider( "https://rpc.aere.network" )) oracle = w3.eth.contract( address= "0xca69AA961D836516010Ae669a223Ce249490ACb1" , abi=[{ "name" : "getPrice" , "type" : "function" , "stateMutability" : "view" , "inputs" :[{ "name" : "s" , "type" : "bytes32" }], "outputs" :[{ "type" : "uint128" },{ "type" : "uint64" },{ "type" : "uint256" }]}]) sym = b "AERE/USD" .ljust(32, b "\\0" ) price, ts, n = oracle.functions.getPrice(sym).call() print (price/1e8, n) Reporter operator (write submissions) import { JsonRpcProvider, Wallet, Contract, encodeBytes32String, parseUnits } from "ethers" ; const w = new Wallet( process .env.REPORTER_KEY!, new JsonRpcProvider( "https://rpc.aere.network" )); const oracle = new Contract( "0xf0A1…F399" , [ "function submit(bytes32 symbol, uint128 price)" ], w); await oracle.submit(encodeBytes32String( "AERE/USD" ), parseUnits( "1.234" , 8)); // Run on a cron, e.g. every 60s, pulling from your data source. Median consensus Every authorized reporter can call submit(symbol, price) to record their latest reading. The oracle stores the most recent submission per (symbol, reporter) pair. When a consumer calls getPrice(symbol) , the contract: Iterates every reporter's submission for that symbol Drops any submission older than maxStaleness (default 5 minutes) Sorts the remaining values and returns the median as the canonical price Returns the newest contributor timestamp + count Median (rather than mean) makes the feed resistant to a single malicious or malfunctioning reporter publishing extreme values, they're outvoted by the rest. With n reporters, up to ⌊(n-1)/2⌋ can submit garbage without affecting the median, the same fault-tolerance bound as a Byzantine vote. Staleness window maxStaleness is owner-configurable between 30 seconds and 1 hour. Any consumer should also enforce its own freshness check after reading getPrice() , never trust a price whose timestamp is older than your application's tolerance. Symbol naming Symbols are bytes32 identifiers, conventionally short ASCII strings: AERE/USD , BTC/USD , ETH/USD , EUR/USD , etc. Use ethers.encodeBytes32String("AERE/USD") or web3.toBytes(text="AERE/USD").ljust(32, b"\\0") when calling. Become a reporter Reporter set is permissioned via onlyOwner addReporter(address) . Open an issue at git.aere.network/aere-network/aere-contracts with operator profile, infra description, and price-source attribution. Reporters earn nothing on-chain currently, incentives will arrive via the DAO grant program once governance V2 has flowing budget. --- # Research & Papers | Aere Network URL: https://aere.network/papers.html Fetched: 2026-09-15 Research & Papers | Aere Network Aere Network Research & Papers Most chains publish documents about their network. AERE publishes documents the network itself keeps honest: the flagship paper re-anchors its own fingerprint to the chain four times a day, and the evidence reports are generated by tools you can download and run against a public endpoint. Living document · self-anchoring The AERE Whitepaper The full protocol paper: QBFT consensus on chain 2800, the five NIST post-quantum precompiles, the header anchor, economics, and the honest-boundaries register. It re-anchors itself to a fresh block four times a day and prints its own verification commands; if its self-check fails, it refuses to publish. Read it PDF Changelog Machine-generated evidence Conformance report What a compliance team receives: post-quantum precompiles checked against NIST vectors, block interval, validator set and contract fingerprints, every number measured read-only from a public RPC endpoint, none written by hand. Sample report Run it yourself Execution kernel · new One verifiable pipeline, end to end The kernel that ties the pieces into one system a stranger can check: hybrid post-quantum consensus, block, execution, state transition, proof, verification. Two independent clients agree on every state root (now the fifth check in the verifier toolkit), and parallel execution is proven byte-identical to serial with a negative control. execution-kernel Run the toolkit Consensus research The post-quantum header anchor The research line behind the anchor: how a certificate of Falcon-512 validator seals is bound under the block hash, the formal consensus models, the KAT corpus, and the prior art named and dated rather than ignored. aere-research Plain-language version Specifications Protocol documentation The protocol specification, EIP compatibility matrix, reproducibility guides and validation status, written to be checked rather than believed: claims carry the block they were measured at. aere-docs Architecture, live vs planned Source & toolkits Run the code The node fork with the post-quantum precompiles and anchor patches, the smart contracts behind every deployed address, and the TypeScript SDK, all on our public forge. aere-node aere-contracts sdk-js Reference The Aere glossary Twelve terms, each explained in plain language and each tied to the live chain: what a seal certificate is, what finality means here, what a precompile does. Browse the glossary The one-minute proof # The whitepaper names its own fingerprint and the block it is anchored to. # Recompute both from your own machine: curl -sL https://aere.network/whitepaper | sed -n '/WP-CONTENT-START/,/WP-CONTENT-END/p' | sha256sum curl -s https://aere.network/whitepaper-figures.json | head -c 400 What this library is not. Nothing here is a promise of future performance, and no document claims more than the chain shows. Where a figure could not be measured, the document says NOT MEASURED instead of hiding the line; where earlier claims were wrong, the corrections are printed next to them, dated, rather than silently rewritten. About About Aere Foundation Roadmap Press & Newsroom Brand Kit Editorial Standards Build Developer Hub Documentation RPC Reference SDK Add Network Faucet Academy Grants Network Architecture Post-Quantum Stack Validators Run a Validator Network Status Audits Security Decentralization Solutions Payments DeFi Real-World Assets Infrastructure Gaming NFTs & Culture Explore Explorer Blocks Transactions Tokens Research & Papers Glossary Blog Legal Terms & Privacy Sanctions Compliance Aere Network. Chain ID 2800. Every claim on this site is checkable: rpc.aere.network --- # Payments That Stay Settled | Aere Network URL: https://aere.network/payments.html Fetched: 2026-09-15 Payments That Stay Settled | Aere Network Solutions Payments That Stay Settled Payments Deterministic finality Chain 2800 Updated 2026-08-15 Anchor certificate enforced since block 2026-08-14 3 min read A payment on chain 2800 is final in about half a second, there is no reorg to undo it, and every 128th block (every 32nd block until block 17,225,968, on 2026-09-05) since 2026-08-14 carries a post-quantum validator certificate under its hash, so within about 16 seconds it sits under post-quantum validator signatures. The receipt is built to stay provable across the migration NIST has scheduled for classical cryptography. In payments, the word settled usually comes with fine print. A card authorisation clears in seconds and can be reversed for months. On probabilistic blockchains, a merchant waits a chosen number of confirmations and accepts the residual risk that the ledger reorganises underneath them. Chain 2800, a public EVM Layer 1, removes the fine print: a block is final the moment a quorum of seven of ten validators signs it (ten validators since 2026-09-11), about half a second after your transaction enters it (block time measured at 0.566 s, re-measured 2026-09-02), and the consensus has no mechanism for taking a finalized block back. No consensus chargebacks On a probabilistic chain, finality is a probability that improves with time, and a reorg is the ledger itself issuing a chargeback: blocks both sides treated as settled are replaced, and every payment inside them is unwound. Processors compensate with confirmation-depth policies, reorg monitoring, and float held against the chain changing its mind. Chain 2800 uses QBFT consensus, where finality is a property of the protocol rather than a probability: once seven of ten validators have signed a block, it is final, and there are no reorgs by design. Deterministic sub-second finality is the performance claim of this page, and it is the one that matters for money. When the block closes, the payment is settled, and settled does not decay. A receipt that does not expire Consensus on chain 2800 is hybrid in a precise and limited sense: every 32nd block header carries a certificate of validator Falcon-512 seals bound under the block hash, live since block 13,014,000 and enforced at a minimum of three seals (f+1 of the nine validators of that time) since 2026-08-14, raised to six seals, then a full quorum of nine, at block 14,961,456 (2026-08-21); ten validators since 2026-09-11, where six is below the quorum of seven, and a node does not finalize an anchor block without it; classical ECDSA finalizes every block. (Correction 2026-08-19: the earlier statement that from block 14,050,000 every block required a six-of-nine post-quantum quorum to finalize is withdrawn; the per-block rule armed at that height is retired in the shipped code in favour of the anchor rules and changed no enforcement.) For a processor, this is about the paperwork, not the plumbing. The settlement records you show an auditor, a regulator, or a counterparty in a dispute are only as durable as the signatures beneath them, and for the classical signatures securing most chains, NIST's post-quantum migration guidance (IR 8547, initial public draft 2024) schedules deprecation after 2030 and disallowance after 2035. A payment settled on chain 2800 sits under a post-quantum anchor , so demonstrating years from now that it happened, exactly as recorded, does not rest on cryptography that has since been retired. For retention obligations measured in decades, that is the difference between a receipt and a receipt with an expiry date. The same property, applied to documents rather than payments, is described on the notarization page. Integration is the boring part, by design Chain 2800 offers full EVM compatibility at Pectra plus Fusaka parity. MetaMask connects, ethers works, hardhat and foundry compile and deploy without modification. If your team has integrated any EVM chain, they have integrated this one; the post-quantum layer lives inside consensus and asks nothing of your application code. Contracts that want post-quantum verification directly can call the five NIST verifier precompiles live since block 9,189,161, validated against official NIST vectors. The native token is AERE, with a fixed supply of 2.8 billion set at genesis and no new minting. Start at the developer hub , and read the architecture page for how the pieces fit. Honest boundaries All ten validators are operated by the Foundation today (ten since 2026-09-11). The chain is not yet decentralized and we do not describe it that way; an independent-operator program is being built. There is no completed third-party security audit yet; it is on the roadmap. We do not publish throughput figures; deterministic sub-second finality is the performance claim we stand behind. And this page describes what the chain can do and how we engage, not a deployed retail payments product: we do not offer card programs, banking services, or custody. Check the settlement layer yourself # verify the post-quantum anchor on the live chain curl -O https://aere.network/tools/verify-anchor.mjs -O https://aere.network/tools/falcon512.mjs -O https://aere.network/tools/package.json && npm install node verify-anchor.mjs # or fetch the full independent suite: 35 checks curl -O https://aere.network/tools/verifica-lantul.tar.gz tar -xzf verifica-lantul.tar.gz Three ways to work with us A payments pilot. A scoped engagement with our team: pick one bounded settlement flow, run it on chain 2800, and measure finality and operational load together before anything larger is committed. An integration. Your engineers build against the chain directly, with the EVM tooling they already use. The developer hub has the network details and examples, and we answer questions while you build. Independent verification. Do not take this page's word for anything. Run the anchor verifier, run the 35-check suite, read the research library and the sample conformance report, and only then talk to us. Write to [email protected] Next up Quantum-safe settlement The Aere glossary Finality Post Quantum Anchor Seal Certificate Falcon 512 Block Header Precompile About About Aere Foundation Roadmap Press & Newsroom Brand Kit Editorial Standards Build Developer Hub Documentation RPC Reference SDK Add Network Faucet Academy Grants Network Architecture Post-Quantum Stack Validators Run a Validator Network Status Audits Security Decentralization Solutions Payments DeFi Real-World Assets Infrastructure Gaming NFTs & Culture Explore Explorer Blocks Transactions Tokens Research & Papers Glossary Blog Legal Terms & Privacy Sanctions Compliance Aere Network. Chain ID 2800. Every claim on this site is checkable: rpc.aere.network --- # Post-Quantum Verification API | Aere Network URL: https://aere.network/pq-api.html Fetched: 2026-09-15 Post-Quantum Verification API | Aere Network Aere Network Aere Cloud Docs Status Aere Cloud · chain-native post-quantum verification Post-quantum signature verification, as an API. Live NIST FIPS 204 / 205 Falcon Chain-native Endpoint cloud.aere.network/v1/pq/verify Live since block 9,189,161 Chain 2800 Send a signature, a public key and a message; get back a verdict computed by a public blockchain’s own native precompiles: not by a library we run beside the API. Every answer carries the block height it was computed at and can be re-checked against the chain by anyone. What you can verify Scheme Standard Request fields ml-dsa-44 NIST FIPS 204 (Dilithium) publicKey, signature, message slh-dsa-128s NIST FIPS 205 (SPHINCS+) publicKey, signature, message falcon-512 Falcon (round 3) publicKey, signedMessage falcon-1024 Falcon (round 3) publicKey, signedMessage All fields are 0x -prefixed hex. The verdict names which precompile answered and at which block height, so it is reproducible against the public RPC. A real exchange POST https://cloud.aere.network/v1/pq/verify x-api-key: ak2800.. { "scheme": "ml-dsa-44", "publicKey": "0x…", "signature": "0x…", "message": "0x…" } → { "valid": true, "scheme": "ml-dsa-44", "precompile": "0x…0ae3", "block": 15220111, "chainId": 2800 } # flip one bit of the signature and the chain returns valid:false Why this is different from a library Anyone can run a post-quantum verifier in their own process. What you cannot do elsewhere is have the verdict produced by a neutral public network, at a named block height, that a counterparty can independently reproduce. On Aere the verifiers are native precompiles, live on mainnet since block 9,189,161, validated against the official NIST known-answer and ACVP vectors in both directions. The verification does not rest on trusting our servers: it rests on the chain. And the chain that answers is itself post-quantum-attested Every 128th block of chain 2800 (every 32nd until block 17,225,968, 2026-09-05) does not finalize without a certificate of at least six valid Falcon-512 validator seals bound under the block hash; six was a full quorum of the nine validators of that time, and since ten validators since 2026-09-11 it is above f+1 and below the quorum of seven. So a verdict you anchor here lives on a network whose own consensus carries post-quantum evidence, proven and independently verifiable rather than asserted. Check it yourself with the verifier tool or the live verification page . Use cases Long-lived documents and signatures that must stay verifiable past the arrival of quantum computers. Hybrid signing: attach a post-quantum signature beside a classical one, and verify both. Compliance and audit trails where a neutral, reproducible verdict matters more than a private library’s word. Get an API key Read the docs Part of Aere Cloud . The precompiles are also callable directly from any contract on chain 2800; the API is the convenience layer over them. © 2026 Aere Network · chain 2800 · Aere Cloud --- # Press Release: Aere Network Launches Aere Cloud, Commercial Infrastructure With Chain-Native Post-Quantum Verification URL: https://aere.network/press-release-aere-cloud.html Fetched: 2026-09-15 Press Release: Aere Network Launches Aere Cloud, Commercial Infrastructure With Chain-Native Post-Quantum Verification Press Release Aere Network Launches Aere Cloud: Commercial Infrastructure With Chain-Native Post-Quantum Verification FOR IMMEDIATE RELEASE Seychelles, August 23, 2026 ← Press and Media Center Seychelles, August 23, 2026. Aere Network today launched Aere Cloud , a commercial infrastructure platform on its public Layer-1 (Chain ID 2800): enterprise JSON-RPC and WebSocket endpoints, managed nodes, a blockchain data API with transfer history indexed back to the chain's earliest blocks, document notarization, and a post-quantum signature verification API whose verdicts are computed by the chain’s own native precompiles rather than by application code, so any answer can be re-checked by anyone against a public endpoint. The platform’s billing is itself an on-chain product. A subscription is one wallet transaction: payment reaches the network treasury within that same transaction, the service contract holds no funds at any point, and the only thing recorded on chain is the hash of the customer’s API key. The key itself is generated in the customer’s browser and never leaves it, so it cannot be recovered, reset, or stolen from the operator, because the operator never has it. The account console works the same way: signing in is a single wallet signature, verified through the chain’s own ecrecover precompile, with no password and no session database to breach. Everyone sells RPC. What we are selling is infrastructure you can audit from the outside: verification done by the chain itself, billing you can read on the chain, and an API key that only the customer has ever seen. If a claim on our pricing page cannot be checked from a public endpoint, we do not put it there. Liviu Hrenaru, Founder, Aere Network What is live at launch Enterprise RPC: dedicated JSON-RPC and WebSocket endpoints with per-key metering; a new chain head is pushed roughly every half second. Post-Quantum Verification API: Falcon-512, Falcon-1024, ML-DSA-44 and SLH-DSA-128s verification over HTTPS, computed by precompiles live on chain since block 9,189,161 and validated against official NIST test vectors on the live endpoint. Blockchain Data API: per-address transfer history with native transfers indexed from the chain’s earliest blocks, post-quantum anchor certificates parsed per block, validator-set data, and signed webhook deliveries. Managed nodes and notarization: operated full or archive nodes, and an open, permissionless notarization contract that holds no funds and has no owner. Self-serve subscriptions: connect a wallet on the pricing page , choose a plan, and the API key is issued in the browser. Prices are listed in US dollars. Verify it yourself The platform’s health and the chain data behind it are public: https://cloud.aere.network/v1/health answers with the current block, the status page shows live service state, and the anchor certificates the data API serves can be recomputed from raw header bytes with the open verifier at aere.network/tools . Every 32nd block on chain 2800 does not finalize without a certificate of at least six of nine valid Falcon-512 validator seals bound under its block hash, enforced since block 14,961,456 (August 21, 2026), and the data API will show you those seals on any anchor you ask for. Stated limits In keeping with the project’s practice of publishing capabilities and limits together: all nine validators are operated by the Aere Foundation today, so the chain is not yet decentralized; no completed third-party security audit exists yet; wallet and account infrastructure is offered as beta with its phase-1 limits stated on the page; and until AERE is exchange-listed, paid plans are invoiced in USDC or EUR at the published dollar prices, with on-chain settlement in AERE at a stated reference rate. Each service on the pricing page carries an honest status label, and the pages themselves say what is live, what is beta, and what is not deployed. About Aere Network Aere Network is a public, EVM-compatible Layer-1 settlement network (Chain ID 2800) built to outlast today’s cryptography: half-second deterministic finality, a fixed token supply of 2.8 billion AERE set at genesis, native NIST post-quantum signature verification, and a post-quantum certificate under every 32nd block hash. Documentation, research and source code: aere.network/papers.html . Notes to editors Chain ID 2800. Launch date: August 23, 2026. Platform: aere.network/cloud.html ; documentation: aere.network/cloud-docs.html ; status: aere.network/cloud-status.html . Post-quantum precompiles live since block 9,189,161. Media: [email protected] . Full media kit at the Press and Media Center . ### --- # Pressemitteilung: Aere Network aktiviert hybriden Post-Quanten-Konsens auf seinem öffentlichen Mainnet URL: https://aere.network/press-release-full-quantum.de.html Fetched: 2026-09-15 Pressemitteilung: Aere Network aktiviert hybriden Post-Quanten-Konsens auf seinem öffentlichen Mainnet Pressemitteilung Aere Network aktiviert hybriden Post-Quanten-Konsens auf seinem öffentlichen Mainnet ZUR SOFORTIGEN VERÖFFENTLICHUNG Seychelles, 15. August 2026 Korrektur, hinzugefügt am 19. August 2026 Korrektur, hinzugefügt am 19. August 2026. Diese Mitteilung ist ein datiertes Dokument; ihr Text unten bleibt wie veröffentlicht. Eine Aussage darin wird zurückgenommen: dass ab Block 14,050,000 kein Block ohne ein Sechs-von-neun-Post-Quanten-Quorum finalisiert wird. (Correction, dated 2026-08-19: this sentence is withdrawn. The per-block rule armed at that height is retired in the shipped code and changed no enforcement; what the chain enforces is the anchor-block certificate, whose minimum was raised to six of nine seals, a full quorum, at block 14,961,456 on 2026-08-21.) Die auf dieser Höhe scharfgeschaltete Regel pro Block (aere.falcon.forkBlock) ist im ausgelieferten Code ab Block 13,014,000 zugunsten der Anker-Regeln außer Kraft, und eine erneute Prüfung des Codes und der Kette (Blöcke zwischen Ankern tragen keine Falcon-Siegel) zeigt, dass sie nichts an der Durchsetzung geändert hat. Was Chain 2800 seit dem 14. August 2026 tatsächlich erzwingt: jeder 32. Block (Ankerblock) wird nicht finalisiert ohne ein Zertifikat aus mindestens drei gültigen Falcon-512-Validatorsiegeln (f+1 von neun), gebunden unter dem Blockhash; in der Praxis werden acht oder neun Siegel getragen; klassisches ECDSA finalisiert jeden Block. Die Kette hat bei 14,050,000 nicht angehalten. Details: /quantum.html und Whitepaper, Kapitel 3. Seychelles, 15. August 2026. Bei Block 14,050,000 hat Aere Network, ein öffentliches EVM-kompatibles Layer-1 (Chain ID 2800), den hybriden Post-Quanten-Konsens auf seinem laufenden Mainnet aktiviert: Ab dieser Höhe wird kein Block ohne ein Quorum von Falcon-512-Post-Quanten-Validatorsignaturen finalisiert, verifiziert gegen ein on-chain gebundenes Signierregister, wobei klassisches ECDSA parallel beibehalten wird. Die Chain hat für den Übergang nicht angehalten; die Blockproduktion lief im gewohnten Halbsekundenrhythmus durch die Aktivierungshöhe hindurch weiter. Nach unserem Kenntnisstand hat kein anderes öffentliches Netzwerk einen Konsens demonstriert, der die Finalisierung von Blöcken ohne Post-Quanten-Kryptographie verweigert, in einer Form, die Außenstehende unabhängig verifizieren können, über öffentliche Endpunkte, ohne dem Betreiber vertrauen zu müssen. Diese Verifizierbarkeit ist die Aussage, auf der diese Mitteilung steht, und sie ist heute überprüfbar: Ein Verifizierer aus einer einzigen Datei berechnet aus rohen Header-Bytes nach, dass jeder Anchor-Block ein Zertifikat von Falcon-512-Siegeln trägt, das unter dem Block-Hash gebunden ist, und ein herunterladbares Toolkit mit fünfunddreißig Prüfungen misst die Post-Quanten-Precompiles des Netzwerks gegen offizielle NIST-Vektoren, ausschließlich lesend, gegen einen öffentlichen RPC-Endpunkt. Die Branche hat Post-Quanten-Sicherheit als Punkt auf der Roadmap behandelt. Wir haben sie als technische Deadline behandelt. Ab Block 14,050,000 existiert die Einigung, die einen Aere-Block final macht, ohne Post-Quanten-Signaturen nicht, und jeder kann das von der eigenen Maschine aus verifizieren, ohne uns zu fragen. Liviu Hrenaru, Founder, Aere Network Was sich genau geändert hat Die fünf NIST-Post-Quanten-Verifizierer-Precompiles von Aere (Falcon-512, Falcon-1024, ML-DSA-44, SLH-DSA-128s, SHAKE256) sind seit Block 9,189,161 auf der Anwendungsebene live. Seit Block 13,014,000 trägt zusätzlich jeder 32. Blockheader ein Zertifikat von Falcon-512-Validatorsiegeln, gebunden unter dem Block-Hash, seit dem 14. August mit einem Minimum von drei Siegeln pro Anchor durchgesetzt. Block 14,050,000 hat den Bogen vollendet: Das Post-Quanten-Quorum wurde konsensblockierend, sodass ein Block ohne dieses Quorum gar nicht mehr finalisiert wird. Klassische ECDSA-Signaturen werden parallel beibehalten, ein bewusstes Hybrid: Sollte jemals eine Schwäche in einer der beiden Signaturfamilien gefunden werden, steht die andere weiterhin zwischen dem Netzwerk und einem gefälschten Block. Verifizieren Sie es selbst Führen Sie node verify-anchor.mjs von aere.network/tools aus, um die neuesten Anchor-Zertifikate zu prüfen, oder laden Sie das vollständige Toolkit unter verifica-lantul.tar.gz herunter: Es installiert nichts, kommuniziert nur mit einem öffentlichen Endpunkt und beginnt mit einem Selbsttest, der einundzwanzig absichtliche Defekte einpflanzt und jeden einzelnen davon finden muss, bevor irgendein grünes Ergebnis etwas bedeutet. Ein maschinell erzeugter Konformitätsbericht ist unter aere.network/tools/sample-conformance-report.html veröffentlicht. Offengelegte Grenzen Im Einklang mit der Praxis des Projekts, Fähigkeiten und Grenzen am selben Ort zu veröffentlichen: Alle neun Validatoren werden heute von der Aere Foundation betrieben, die Chain ist also noch nicht dezentralisiert, und ein Programm für unabhängige Betreiber ist in Entwicklung. Ein abgeschlossenes Sicherheitsaudit durch Dritte existiert noch nicht; eines steht auf der Roadmap. Aere veröffentlicht keine Durchsatzzahlen; deterministische Finalität unter einer Sekunde ist die Leistungsaussage, zu der es steht. Über Aere Network Aere Network ist ein öffentliches, EVM-kompatibles Layer-1-Abwicklungsnetzwerk (Chain ID 2800), gebaut, um die heutige Kryptographie zu überdauern: deterministische Finalität in einer halben Sekunde, ein bei der Genesis festgelegtes festes Token-Angebot von 2.8 Milliarden AERE, native NIST-Post-Quanten-Signaturverifikation und, ab Block 14,050,000, hybrider Post-Quanten-Konsens. Dokumentation, Forschung und Quellcode: aere.network/papers.html . Hinweise für Redaktionen Chain ID 2800. Aktivierungshöhe: Block 14,050,000, 15. August 2026. Anchor-Zertifikate: jeder 32. Header seit Block 13,014,000, mindestens drei Falcon-512-Siegel. Precompiles live seit Block 9,189,161, validiert gegen offizielle NIST-Testvektoren. Medienkontakt: [email protected] . Vollständiges Medienkit im Presse- und Medienzentrum . --- # Comunicado de prensa: Aere Network activa el consenso poscuántico híbrido en su red principal pública URL: https://aere.network/press-release-full-quantum.es.html Fetched: 2026-09-15 Comunicado de prensa: Aere Network activa el consenso poscuántico híbrido en su red principal pública Comunicado de prensa Aere Network activa el consenso poscuántico híbrido en su red principal pública PARA PUBLICACIÓN INMEDIATA Seychelles, 15 de agosto de 2026 Corrección, añadida el 19 de agosto de 2026 Corrección, añadida el 19 de agosto de 2026. Este comunicado es un documento fechado y su texto se conserva tal como se publicó. Se retira una afirmación: que desde el bloque 14,050,000 ningún bloque se finaliza sin un quórum poscuántico de seis de nueve. (Correction, dated 2026-08-19: this sentence is withdrawn. The per-block rule armed at that height is retired in the shipped code and changed no enforcement; what the chain enforces is the anchor-block certificate, whose minimum was raised to six of nine seals, a full quorum, at block 14,961,456 on 2026-08-21.) La regla por bloque armada a esa altura (aere.falcon.forkBlock) está, en el código distribuido, retirada desde el bloque 13,014,000 en favor de las reglas de anclaje, y una relectura del código y de la cadena (los bloques entre anclas no llevan sellos Falcon) muestra que no cambió nada en la aplicación. Lo que la cadena 2800 sí aplica desde el 14 de agosto de 2026: cada 32º bloque (bloque ancla) no se finaliza sin un certificado de al menos tres sellos Falcon-512 válidos de validadores (f+1 de nueve) vinculado bajo el hash del bloque; en la práctica se llevan ocho o nueve sellos; el ECDSA clásico finaliza cada bloque. La cadena no se detuvo en 14,050,000. Detalles: /quantum.html y el whitepaper, capítulo 3. Seychelles, 15 de agosto de 2026. En el bloque 14,050,000, Aere Network, una red pública de capa 1 compatible con EVM (Chain ID 2800), activó el consenso poscuántico híbrido en su red principal en producción: desde esa altura, ningún bloque se finaliza sin un quórum de firmas poscuánticas Falcon-512 de los validadores, verificadas contra un registro de firmantes vinculado en la cadena, manteniendo las firmas ECDSA clásicas en paralelo. La cadena no se detuvo durante la transición; la producción de bloques continuó a su ritmo normal de medio segundo a través de la altura de activación. Hasta donde sabemos, ninguna otra red pública ha demostrado un consenso que se niegue a finalizar bloques sin criptografía poscuántica en una forma que terceros puedan verificar de manera independiente, desde puntos de acceso públicos, sin confiar en el operador. Esa verificabilidad es la afirmación sobre la que se sostiene este comunicado, y puede comprobarse hoy: un verificador de un solo archivo recalcula, a partir de los bytes brutos de los encabezados, que cada bloque de anclaje lleva un certificado de sellos Falcon-512 vinculado bajo el hash del bloque, y un conjunto de herramientas descargable con treinta y cinco comprobaciones mide las precompilaciones poscuánticas de la red contra los vectores oficiales del NIST, en modo de solo lectura, contra un punto de acceso RPC público. La industria ha tratado la seguridad poscuántica como un punto de la hoja de ruta. Nosotros la tratamos como un plazo de ingeniería. Desde el bloque 14,050,000, el acuerdo que hace final un bloque de Aere no existe sin firmas poscuánticas, y cualquiera puede verificarlo desde su propia máquina, sin preguntarnos. Liviu Hrenaru, fundador, Aere Network Qué cambió, exactamente Las cinco precompilaciones de verificación poscuántica NIST de Aere (Falcon-512, Falcon-1024, ML-DSA-44, SLH-DSA-128s, SHAKE256) están activas en la capa de aplicación desde el bloque 9,189,161. Desde el bloque 13,014,000, uno de cada 32 encabezados de bloque lleva además un certificado de sellos Falcon-512 de los validadores vinculado bajo el hash del bloque, con un mínimo exigido de tres sellos por anclaje desde el 14 de agosto. El bloque 14,050,000 completó el arco: el quórum poscuántico pasó a ser bloqueante para el consenso, de modo que un bloque sin él no se finaliza en absoluto. Las firmas ECDSA clásicas se mantienen en paralelo, un híbrido deliberado: si alguna vez se encontrara una debilidad en cualquiera de las dos familias de firmas, la otra seguiría interponiéndose entre la red y un bloque falsificado. Verifíquelo usted mismo Ejecute node verify-anchor.mjs desde aere.network/tools para comprobar los certificados de anclaje más recientes, o descargue el conjunto completo de herramientas en verifica-lantul.tar.gz : no instala nada, se comunica únicamente con un punto de acceso público y comienza con una autoprueba que planta veintiún defectos deliberados y debe detectarlos todos antes de que cualquier resultado verde signifique algo. Un informe de conformidad generado automáticamente está publicado en aere.network/tools/sample-conformance-report.html . Límites declarados Siguiendo la práctica del proyecto de publicar capacidades y límites en el mismo lugar: los nueve validadores están operados hoy por la Fundación Aere, por lo que la cadena aún no está descentralizada, y un programa de operadores independientes está en desarrollo. Todavía no existe una auditoría de seguridad de terceros completada; hay una en la hoja de ruta. Aere no publica cifras de rendimiento en transacciones; la finalidad determinista en menos de un segundo es la afirmación de desempeño que respalda. Acerca de Aere Network Aere Network es una red pública de liquidación de capa 1 compatible con EVM (Chain ID 2800) construida para sobrevivir a la criptografía actual: finalidad determinista de medio segundo, una oferta fija de tokens de 2.8 mil millones de AERE establecida en el génesis, verificación nativa de firmas poscuánticas NIST y, desde el bloque 14,050,000, consenso poscuántico híbrido. Documentación, investigación y código fuente: aere.network/papers.html . Notas para los editores Chain ID 2800. Altura de activación: bloque 14,050,000, 15 de agosto de 2026. Certificados de anclaje: uno de cada 32 encabezados desde el bloque 13,014,000, mínimo de tres sellos Falcon-512. Precompilaciones activas desde el bloque 9,189,161, validadas contra los vectores de prueba oficiales del NIST. Prensa: [email protected] . Kit de prensa completo en el Centro de Prensa y Medios . --- # Communiqué de presse : Aere Network active le consensus post-quantique hybride sur son mainnet public URL: https://aere.network/press-release-full-quantum.fr.html Fetched: 2026-09-15 Communiqué de presse : Aere Network active le consensus post-quantique hybride sur son mainnet public Communiqué de presse Aere Network active le consensus post-quantique hybride sur son mainnet public POUR DIFFUSION IMMÉDIATE Seychelles, le 15 août 2026 Correction, ajoutée le 19 août 2026 Correction, ajoutée le 19 août 2026. Ce communiqué est un document daté et son texte ci-dessous est conservé tel que publié. Une affirmation en est retirée : qu'à partir du bloc 14,050,000 aucun bloc n'est finalisé sans un quorum post-quantique de six sur neuf. (Correction, dated 2026-08-19: this sentence is withdrawn. The per-block rule armed at that height is retired in the shipped code and changed no enforcement; what the chain enforces is the anchor-block certificate, whose minimum was raised to six of nine seals, a full quorum, at block 14,961,456 on 2026-08-21.) La règle par bloc armée à cette hauteur (aere.falcon.forkBlock) est, dans le code livré, retirée à partir du bloc 13,014,000 au profit des règles d'ancrage, et une relecture du code et de la chaîne (les blocs entre ancres ne portent aucun sceau Falcon) montre qu'elle n'a rien changé à l'application. Ce que la chaîne 2800 applique bien, depuis le 14 août 2026 : un bloc sur 32 (bloc d'ancrage) n'est pas finalisé sans un certificat d'au moins trois sceaux Falcon-512 valides de validateurs (f+1 sur neuf) lié sous le hachage du bloc ; en pratique huit ou neuf sceaux sont portés ; l'ECDSA classique finalise chaque bloc. La chaîne ne s'est pas arrêtée à 14,050,000. Détails : /quantum.html et le livre blanc, chapitre 3. Seychelles, le 15 août 2026. Au bloc 14,050,000, Aere Network, un Layer-1 public compatible EVM (Chain ID 2800), a activé le consensus post-quantique hybride sur son mainnet en production : depuis cette hauteur, aucun bloc n'est finalisé sans un quorum de signatures post-quantiques Falcon-512 des validateurs, vérifiées par rapport à un registre de signataires inscrit dans la chaîne, la signature ECDSA classique étant conservée en parallèle. La chaîne ne s'est pas arrêtée pour la transition ; la production de blocs a continué à son rythme normal d'une demi-seconde au passage de la hauteur d'activation. À notre connaissance, aucun autre réseau public n'a démontré un consensus qui refuse de finaliser des blocs sans cryptographie post-quantique sous une forme que des tiers peuvent vérifier de manière indépendante, depuis des points d'accès publics, sans faire confiance à l'opérateur. Cette vérifiabilité est l'affirmation sur laquelle repose ce communiqué, et elle peut être contrôlée dès aujourd'hui : un vérificateur en un seul fichier recalcule, à partir des octets bruts des en-têtes, que chaque bloc d'ancrage porte un certificat de sceaux Falcon-512 lié sous le hash du bloc, et une boîte à outils téléchargeable de trente-cinq contrôles mesure les précompilés post-quantiques du réseau par rapport aux vecteurs officiels du NIST, en lecture seule, sur un point d'accès RPC public. L'industrie a traité la sécurité post-quantique comme un point de feuille de route. Nous l'avons traitée comme une échéance d'ingénierie. Depuis le bloc 14,050,000, l'accord qui rend un bloc Aere final n'existe pas sans signatures post-quantiques, et chacun peut le vérifier depuis sa propre machine, sans nous le demander. Liviu Hrenaru, fondateur, Aere Network Ce qui a changé, précisément Les cinq précompilés de vérification post-quantique NIST d'Aere (Falcon-512, Falcon-1024, ML-DSA-44, SLH-DSA-128s, SHAKE256) sont en service au niveau de la couche applicative depuis le bloc 9,189,161. Depuis le bloc 13,014,000, chaque 32e en-tête de bloc porte en outre un certificat de sceaux Falcon-512 des validateurs lié sous le hash du bloc, avec un minimum imposé de trois sceaux par ancrage depuis le 14 août. Le bloc 14,050,000 a achevé la trajectoire : le quorum post-quantique est devenu bloquant pour le consensus, de sorte qu'un bloc qui en est dépourvu n'est pas finalisé du tout. Les signatures ECDSA classiques sont conservées en parallèle, un hybride délibéré : si une faiblesse était un jour découverte dans l'une des deux familles de signatures, l'autre se dresserait encore entre le réseau et un bloc falsifié. Vérifiez par vous-même Exécutez node verify-anchor.mjs depuis aere.network/tools pour contrôler les derniers certificats d'ancrage, ou téléchargez la boîte à outils complète à l'adresse verifica-lantul.tar.gz : elle n'installe rien, ne communique qu'avec un point d'accès public, et commence par un autotest qui plante vingt et un défauts délibérés et doit les détecter tous avant qu'un résultat vert n'ait la moindre valeur. Un rapport de conformité généré automatiquement est publié à l'adresse aere.network/tools/sample-conformance-report.html . Limites déclarées Conformément à la pratique du projet consistant à publier les capacités et les limites au même endroit : les neuf validateurs sont aujourd'hui opérés par la Fondation Aere, la chaîne n'est donc pas encore décentralisée, et un programme d'opérateurs indépendants est en développement. Aucun audit de sécurité tiers achevé n'existe à ce jour ; un audit figure sur la feuille de route. Aere ne publie aucun chiffre de débit ; la finalité déterministe en moins d'une seconde est l'affirmation de performance que le projet assume. À propos d'Aere Network Aere Network est un réseau de règlement Layer-1 public et compatible EVM (Chain ID 2800) construit pour survivre à la cryptographie d'aujourd'hui : finalité déterministe en une demi-seconde, offre de jetons fixe de 2.8 milliards d'AERE établie à la genèse, vérification native des signatures post-quantiques NIST et, depuis le bloc 14,050,000, consensus post-quantique hybride. Documentation, recherche et code source : aere.network/papers.html . Notes aux rédactions Chain ID 2800. Hauteur d'activation : bloc 14,050,000, 15 août 2026. Certificats d'ancrage : chaque 32e en-tête depuis le bloc 13,014,000, minimum trois sceaux Falcon-512. Précompilés en service depuis le bloc 9,189,161, validés par rapport aux vecteurs de test officiels du NIST. Contact médias : [email protected] . Dossier de presse complet au Centre presse et médias . --- # Press Release: Aere Network Activates Hybrid Post-Quantum Consensus on Its Public Mainnet URL: https://aere.network/press-release-full-quantum.html Fetched: 2026-09-15 Press Release: Aere Network Activates Hybrid Post-Quantum Consensus on Its Public Mainnet Press Release Aere Network Activates Hybrid Post-Quantum Consensus on Its Public Mainnet FOR IMMEDIATE RELEASE Seychelles, August 15, 2026 Correction, added August 19, 2026 Correction, added August 19, 2026. This release is a dated document and its text below is preserved as published. One statement in it is withdrawn: that from block 14,050,000 no block finalizes without a six-of-nine post-quantum quorum. The per-block quorum rule armed at that height (aere.falcon.forkBlock) is, in the shipped code, retired in favour of the anchor rules from block 13,014,000, and a re-reading of the code and of the chain, where blocks between anchors carry no Falcon seals, shows that it changed no enforcement. What chain 2800 does enforce, since 2026-08-14: every 32nd block (an anchor block) does not finalize without a certificate of at least three valid Falcon-512 validator seals (f+1 of nine) (raised at block 14,961,456, August 21, 2026: the enforced minimum is now six of nine, a full 2f+1 quorum) bound under its block hash; in practice eight or nine seals are carried; classical ECDSA finalizes every block. The chain did not stop at 14,050,000. Details: /quantum.html and the whitepaper, chapter 3. Seychelles, August 15, 2026. At block 14,050,000, Aere Network, a public EVM-compatible Layer-1 (Chain ID 2800), activated hybrid post-quantum consensus on its live mainnet: from that height, no block finalizes without a quorum of Falcon-512 post-quantum validator signatures, verified against a signer registry bound on chain, with classical ECDSA retained alongside. The chain did not stop for the transition; block production continued at its normal half-second rhythm through the activation height. To our knowledge, no other public network has demonstrated a consensus that refuses to finalize blocks without post-quantum cryptography in a form that outside parties can verify independently, from public endpoints, without trusting the operator. That verifiability is the claim this release stands on, and it is checkable today: a single-file verifier recomputes, from raw header bytes, that every anchor block carries a certificate of Falcon-512 seals bound under the block hash, and a downloadable toolkit of thirty-five checks measures the network's post-quantum precompiles against official NIST vectors, read-only, against a public RPC endpoint. The industry has treated post-quantum security as a roadmap item. We treated it as an engineering deadline. From block 14,050,000, the agreement that makes an Aere block final does not exist without post-quantum signatures, and anyone can verify that from their own machine, without asking us. Liviu Hrenaru, Founder, Aere Network What changed, precisely Aere's five NIST post-quantum verifier precompiles (Falcon-512, Falcon-1024, ML-DSA-44, SLH-DSA-128s, SHAKE256) have been live at the application layer since block 9,189,161. Since block 13,014,000, every 32nd block header additionally carries a certificate of validator Falcon-512 seals bound under the block hash, enforced at a minimum of three seals per anchor since August 14 (raised to six of nine, a full quorum, at block 14,961,456 on August 21, 2026). Block 14,050,000 completed the arc: the post-quantum quorum became consensus-blocking, so a block without it does not finalize at all. (Correction, dated 2026-08-19: this sentence is withdrawn. The per-block rule armed at that height is retired in the shipped code and changed no enforcement; what the chain enforces is the anchor-block certificate, whose minimum was raised to six of nine seals, a full quorum, at block 14,961,456 on 2026-08-21.) Classical ECDSA signatures are retained alongside, a deliberate hybrid: if a weakness were ever found in either signature family, the other still stands between the network and a forged block. Verify it yourself Run node verify-anchor.mjs from aere.network/tools to check the latest anchor certificates, or download the full toolkit at verifica-lantul.tar.gz : it installs nothing, talks only to a public endpoint, and begins with a self-test that plants twenty-one deliberate defects and must catch every one before any green result means anything. A machine-generated conformance report is published at aere.network/tools/sample-conformance-report.html . Stated limits In keeping with the project's practice of publishing capabilities and limits in the same place: all nine validators are operated by the Aere Foundation today, so the chain is not yet decentralized, and an independent-operator program is in development. No completed third-party security audit exists yet; one is on the roadmap. Aere publishes no throughput figures; deterministic sub-second finality is the performance claim it stands behind. About Aere Network Aere Network is a public, EVM-compatible Layer-1 settlement network (Chain ID 2800) built to outlast today's cryptography: half-second deterministic finality, a fixed token supply of 2.8 billion AERE set at genesis, native NIST post-quantum signature verification, and, from block 14,050,000, hybrid post-quantum consensus. Documentation, research and source code: aere.network/papers.html . Notes to editors Chain ID 2800. Activation height: block 14,050,000, August 15, 2026. Anchor certificates: every 32nd header since block 13,014,000, minimum three Falcon-512 seals. Precompiles live since block 9,189,161, validated against official NIST test vectors. Media: [email protected] . Full media kit at the Press and Media Center . --- # Comunicato stampa: Aere Network attiva il consenso ibrido post-quantistico sulla sua mainnet pubblica URL: https://aere.network/press-release-full-quantum.it.html Fetched: 2026-09-15 Comunicato stampa: Aere Network attiva il consenso ibrido post-quantistico sulla sua mainnet pubblica Comunicato Stampa Aere Network attiva il consenso ibrido post-quantistico sulla sua mainnet pubblica PER DIFFUSIONE IMMEDIATA Seychelles, 15 agosto 2026 Correzione, aggiunta il 19 agosto 2026 Correzione, aggiunta il 19 agosto 2026. Questo comunicato è un documento datato e il testo sottostante è conservato come pubblicato. Un'affermazione viene ritirata: che dal blocco 14,050,000 nessun blocco venga finalizzato senza un quorum post-quantistico di sei su nove. (Correction, dated 2026-08-19: this sentence is withdrawn. The per-block rule armed at that height is retired in the shipped code and changed no enforcement; what the chain enforces is the anchor-block certificate, whose minimum was raised to six of nine seals, a full quorum, at block 14,961,456 on 2026-08-21.) La regola per blocco armata a quell'altezza (aere.falcon.forkBlock) è, nel codice distribuito, ritirata dal blocco 13,014,000 a favore delle regole di ancoraggio, e una rilettura del codice e della catena (i blocchi tra le ancore non portano sigilli Falcon) mostra che non ha cambiato nulla nell'applicazione. Ciò che la catena 2800 applica davvero, dal 14 agosto 2026: ogni 32º blocco (blocco ancora) non viene finalizzato senza un certificato di almeno tre sigilli Falcon-512 validi dei validatori (f+1 su nove) vincolato sotto l'hash del blocco; in pratica sono portati otto o nove sigilli; l'ECDSA classico finalizza ogni blocco. La catena non si è fermata a 14,050,000. Dettagli: /quantum.html e il whitepaper, capitolo 3. Seychelles, 15 agosto 2026. Al blocco 14,050,000, Aere Network, una Layer-1 pubblica compatibile con EVM (Chain ID 2800), ha attivato il consenso ibrido post-quantistico sulla sua mainnet in esercizio: da quell'altezza, nessun blocco viene finalizzato senza un quorum di firme post-quantistiche Falcon-512 dei validatori, verificate rispetto a un registro dei firmatari vincolato on chain, con l'ECDSA classico mantenuto in parallelo. La catena non si e' fermata per la transizione; la produzione dei blocchi e' proseguita al suo normale ritmo di mezzo secondo attraverso l'altezza di attivazione. Per quanto ci risulta, nessun'altra rete pubblica ha dimostrato un consenso che rifiuta di finalizzare i blocchi senza crittografia post-quantistica in una forma che soggetti esterni possano verificare in modo indipendente, da endpoint pubblici, senza fidarsi dell'operatore. Quella verificabilita' e' l'affermazione su cui poggia questo comunicato, ed e' controllabile oggi stesso: un verificatore in un singolo file ricalcola, dai byte grezzi delle intestazioni, che ogni blocco di ancoraggio porta un certificato di sigilli Falcon-512 vincolato sotto l'hash del blocco, e un toolkit scaricabile di 35 controlli misura le precompile post-quantistiche della rete rispetto ai vettori NIST ufficiali, in sola lettura, su un endpoint RPC pubblico. L'industria ha trattato la sicurezza post-quantistica come una voce di roadmap. Noi l'abbiamo trattata come una scadenza ingegneristica. Dal blocco 14,050,000, l'accordo che rende finale un blocco Aere non esiste senza firme post-quantistiche, e chiunque puo' verificarlo dalla propria macchina, senza chiedere a noi. Liviu Hrenaru, Founder, Aere Network Che cosa e' cambiato, con precisione Le cinque precompile NIST di verifica post-quantistica di Aere (Falcon-512, Falcon-1024, ML-DSA-44, SLH-DSA-128s, SHAKE256) sono attive a livello applicativo dal blocco 9,189,161. Dal blocco 13,014,000, ogni 32a intestazione di blocco porta inoltre un certificato di sigilli Falcon-512 dei validatori vincolato sotto l'hash del blocco, imposto a un minimo di tre sigilli per ancoraggio dal 14 agosto. Il blocco 14,050,000 ha completato l'arco: il quorum post-quantistico e' diventato bloccante per il consenso, quindi un blocco che ne e' privo non viene finalizzato affatto. Le firme ECDSA classiche sono mantenute in parallelo, un ibrido deliberato: se mai venisse trovata una debolezza in una delle due famiglie di firme, l'altra continuerebbe a frapporsi tra la rete e un blocco contraffatto. Verificatelo voi stessi Eseguite node verify-anchor.mjs da aere.network/tools per controllare gli ultimi certificati di ancoraggio, oppure scaricate il toolkit completo da verifica-lantul.tar.gz : non installa nulla, dialoga soltanto con un endpoint pubblico e inizia con un autotest che pianta ventuno difetti deliberati e deve intercettarli tutti prima che qualsiasi risultato verde significhi qualcosa. Un rapporto di conformita' generato automaticamente e' pubblicato su aere.network/tools/sample-conformance-report.html . Limiti dichiarati In linea con la pratica del progetto di pubblicare capacita' e limiti nello stesso luogo: tutti i nove validatori sono gestiti oggi dalla Aere Foundation, quindi la catena non e' ancora decentralizzata, e un programma per operatori indipendenti e' in sviluppo. Non esiste ancora un audit di sicurezza di terze parti completato; e' in roadmap. Aere non pubblica cifre di throughput; la finalita' deterministica in meno di un secondo e' l'affermazione di prestazioni che sostiene. Informazioni su Aere Network Aere Network e' una rete di regolamento Layer-1 pubblica e compatibile con EVM (Chain ID 2800) costruita per durare oltre la crittografia di oggi: finalita' deterministica di mezzo secondo, un'offerta fissa di token di 2.8 miliardi di AERE stabilita alla genesi, verifica nativa delle firme post-quantistiche NIST e, dal blocco 14,050,000, consenso ibrido post-quantistico. Documentazione, ricerca e codice sorgente: aere.network/papers.html . Note per le redazioni Chain ID 2800. Altezza di attivazione: blocco 14,050,000, 15 agosto 2026. Certificati di ancoraggio: ogni 32a intestazione dal blocco 13,014,000, minimo tre sigilli Falcon-512. Precompile attive dal blocco 9,189,161, validate rispetto ai vettori di test NIST ufficiali. Contatti stampa: [email protected] . Kit stampa completo presso il Centro Stampa e Media . --- # プレスリリース:Aere Network、パブリックメインネットでハイブリッド耐量子コンセンサスを有効化 URL: https://aere.network/press-release-full-quantum.ja.html Fetched: 2026-09-15 プレスリリース:Aere Network、パブリックメインネットでハイブリッド耐量子コンセンサスを有効化 プレスリリース Aere Network、パブリックメインネットでハイブリッド耐量子コンセンサスを有効化 報道関係各位 Seychelles、2026年8月15日 訂正(2026年8月19日追記) 訂正(2026年8月19日追記)。本リリースは日付入りの文書であり、以下の本文は公表時のまま保存しています。本文中の次の記述を撤回します:「ブロック14,050,000以降、9分の6の耐量子クォーラムなしにはいかなるブロックも確定しない」。当該高さで有効化されたブロック単位の規則(aere.falcon.forkBlock)は、配布済みのコードではブロック13,014,000以降アンカー規則に置き換えられて退役しており、コードとチェーン(アンカー間のブロックはFalconシールを持たない)の再検証により、施行内容を何も変えなかったことが判明しました。チェーン2800が2026年8月14日以降実際に施行しているのは、32ブロックごと(アンカーブロック)に、ブロックハッシュの下に結び付けられた有効なFalcon-512バリデータシール3つ以上(9のうちf+1)の証明書がなければ確定しないことです。実際には8または9のシールが付いています。従来型ECDSAはすべてのブロックを確定します。チェーンは14,050,000で停止しませんでした。詳細: /quantum.html およびホワイトペーパー第3章。 (Correction, dated 2026-08-19: this sentence is withdrawn. The per-block rule armed at that height is retired in the shipped code and changed no enforcement; what the chain enforces is the anchor-block certificate, whose minimum was raised to six of nine seals, a full quorum, at block 14,961,456 on 2026-08-21.) Seychelles、2026年8月15日。 パブリックなEVM互換レイヤー1であるAere Network(チェーンID 2800)は、ブロック14,050,000において、稼働中のメインネット上でハイブリッド耐量子コンセンサスを有効化しました。この高さ以降、オンチェーンに紐付けられた署名者レジストリに対して検証されるFalcon-512耐量子バリデータ署名のクォーラムなしには、いかなるブロックも確定しません。従来型のECDSAも併せて維持されています。移行のためにチェーンが停止することはなく、ブロック生成は有効化高さをまたいで、通常どおり0.5秒間隔で継続しました。 当社の知る限り、運営者を信頼することなく、外部の第三者がパブリックエンドポイントから独立に検証できる形で、耐量子暗号なしにはブロックの確定を拒否するコンセンサスを実証したパブリックネットワークは、他に存在しません。本リリースが立脚する主張はこの検証可能性であり、それは今日この時点で確認できます。単一ファイルの検証ツールが、生のヘッダーバイトから、すべてのアンカーブロックがブロックハッシュの下に紐付けられたFalcon-512シールの証明書を保持していることを再計算します。さらに、35項目の検査からなるダウンロード可能なツールキットが、ネットワークの耐量子プリコンパイルを、読み取り専用で、パブリックRPCエンドポイントに対し、NISTの公式ベクトルと照合して測定します。 業界は耐量子セキュリティをロードマップ上の項目として扱ってきました。当社はそれをエンジニアリング上の期限として扱いました。ブロック14,050,000以降、Aereのブロックを最終のものとする合意は、耐量子署名なしには存在しません。そして誰でも、当社に尋ねることなく、自分のマシンからそれを検証できます。 Liviu Hrenaru（リヴィウ・フレナル）, Aere Network 創業者 具体的な変更点 Aereの5つのNIST耐量子検証プリコンパイル(Falcon-512、Falcon-1024、ML-DSA-44、SLH-DSA-128s、SHAKE256)は、ブロック9,189,161以降、アプリケーション層で稼働しています。ブロック13,014,000以降は、32ブロックごとのブロックヘッダーに、ブロックハッシュの下に紐付けられたバリデータのFalcon-512シールの証明書が追加で含まれており、8月14日以降はアンカーごとに最低3つのシールが強制されています。ブロック14,050,000がこの道筋を完成させました。耐量子クォーラムはコンセンサス上の必須要件となり、それを欠くブロックは一切確定しません。従来型のECDSA署名は、意図的なハイブリッドとして併せて維持されています。いずれか一方の署名方式に弱点が見つかった場合でも、もう一方がネットワークと偽造ブロックの間に立ち続けます。 ご自身での検証 aere.network/tools から node verify-anchor.mjs を実行して最新のアンカー証明書を確認するか、 verifica-lantul.tar.gz から完全なツールキットをダウンロードしてください。このツールキットは何もインストールせず、パブリックエンドポイントとのみ通信し、21件の意図的な欠陥を仕込むセルフテストから始まります。いかなる緑の結果も意味を持つ前に、そのすべてを検出しなければなりません。機械生成の適合性レポートは aere.network/tools/sample-conformance-report.html で公開されています。 明示された制約 能力と限界を同じ場所で公表するという本プロジェクトの方針に従って記します。現在、9つのバリデータはすべてAere Foundationが運営しており、したがってチェーンはまだ分散化されていません。独立オペレータのプログラムは開発中です。完了した第三者によるセキュリティ監査はまだ存在せず、ロードマップに含まれています。Aereはスループットの数値を公表していません。当社が責任を持つ性能上の主張は、サブ秒の決定論的ファイナリティです。 Aere Networkについて Aere Networkは、今日の暗号技術より長く存続するよう構築された、パブリックなEVM互換レイヤー1決済ネットワーク(チェーンID 2800)です。0.5秒の決定論的ファイナリティ、ジェネシスで定められた28億(2.8 billion)AEREの固定トークン供給量、ネイティブなNIST耐量子署名検証、そしてブロック14,050,000以降のハイブリッド耐量子コンセンサスを備えています。ドキュメント、研究、ソースコード: aere.network/papers.html 。 編集者向け注記 チェーンID 2800。有効化高さ:ブロック14,050,000、2026年8月15日。アンカー証明書:ブロック13,014,000以降、32ヘッダーごと、最低3つのFalcon-512シール。プリコンパイルはブロック9,189,161以降稼働、NIST公式テストベクトルで検証済み。報道関係のお問い合わせ: [email protected] 。メディアキット一式は プレス・メディアセンター にてご覧いただけます。 --- # Comunicado de imprensa: Aere Network ativa o consenso pós-quântico híbrido na sua mainnet pública URL: https://aere.network/press-release-full-quantum.pt.html Fetched: 2026-09-15 Comunicado de imprensa: Aere Network ativa o consenso pós-quântico híbrido na sua mainnet pública Comunicado de Imprensa Aere Network ativa o consenso pós-quântico híbrido na sua mainnet pública PARA DIVULGAÇÃO IMEDIATA Seychelles, 15 de agosto de 2026 Correção, adicionada a 19 de agosto de 2026 Correção, adicionada a 19 de agosto de 2026. Este comunicado é um documento datado e o seu texto abaixo é preservado tal como publicado. Uma afirmação é retirada: que a partir do bloco 14,050,000 nenhum bloco é finalizado sem um quórum pós-quântico de seis em nove. (Correction, dated 2026-08-19: this sentence is withdrawn. The per-block rule armed at that height is retired in the shipped code and changed no enforcement; what the chain enforces is the anchor-block certificate, whose minimum was raised to six of nine seals, a full quorum, at block 14,961,456 on 2026-08-21.) A regra por bloco armada nessa altura (aere.falcon.forkBlock) está, no código distribuído, retirada a partir do bloco 13,014,000 a favor das regras de ancoragem, e uma releitura do código e da cadeia (os blocos entre âncoras não transportam selos Falcon) mostra que não alterou nada na aplicação. O que a cadeia 2800 aplica de facto, desde 14 de agosto de 2026: cada 32.º bloco (bloco âncora) não é finalizado sem um certificado de pelo menos três selos Falcon-512 válidos de validadores (f+1 em nove) vinculado sob o hash do bloco; na prática são transportados oito ou nove selos; o ECDSA clássico finaliza cada bloco. A cadeia não parou em 14,050,000. Detalhes: /quantum.html e o whitepaper, capítulo 3. Seychelles, 15 de agosto de 2026. No bloco 14,050,000, a Aere Network, uma Layer-1 pública compatível com EVM (Chain ID 2800), ativou o consenso pós-quântico híbrido na sua mainnet em produção: a partir dessa altura, nenhum bloco é finalizado sem um quórum de assinaturas pós-quânticas Falcon-512 dos validadores, verificadas contra um registo de signatários vinculado na cadeia, com o ECDSA clássico mantido em paralelo. A cadeia não parou para a transição; a produção de blocos continuou ao seu ritmo normal de meio segundo ao atravessar a altura de ativação. Tanto quanto sabemos, nenhuma outra rede pública demonstrou um consenso que se recusa a finalizar blocos sem criptografia pós-quântica numa forma que terceiros possam verificar de modo independente, a partir de endpoints públicos, sem confiar no operador. Essa verificabilidade é a afirmação em que este comunicado se sustenta, e pode ser confirmada hoje: um verificador de ficheiro único recalcula, a partir dos bytes brutos dos cabeçalhos, que cada bloco de âncora transporta um certificado de selos Falcon-512 vinculado sob o hash do bloco, e um conjunto de ferramentas descarregável com trinta e cinco verificações mede as precompilações pós-quânticas da rede contra os vetores oficiais do NIST, apenas em leitura, contra um endpoint RPC público. A indústria tratou a segurança pós-quântica como um item de roteiro. Nós tratámo-la como um prazo de engenharia. A partir do bloco 14,050,000, o acordo que torna final um bloco Aere não existe sem assinaturas pós-quânticas, e qualquer pessoa pode verificar isso a partir da sua própria máquina, sem nos perguntar. Liviu Hrenaru, Founder, Aere Network O que mudou, exatamente As cinco precompilações de verificação pós-quântica NIST da Aere (Falcon-512, Falcon-1024, ML-DSA-44, SLH-DSA-128s, SHAKE256) estão ativas na camada de aplicação desde o bloco 9,189,161. Desde o bloco 13,014,000, cada 32.º cabeçalho de bloco transporta adicionalmente um certificado de selos Falcon-512 dos validadores vinculado sob o hash do bloco, imposto com um mínimo de três selos por âncora desde 14 de agosto. O bloco 14,050,000 completou o arco: o quórum pós-quântico tornou-se bloqueante para o consenso, pelo que um bloco sem ele não é finalizado de todo. As assinaturas ECDSA clássicas são mantidas em paralelo, um híbrido deliberado: se alguma vez fosse encontrada uma fraqueza numa das duas famílias de assinaturas, a outra continuaria a interpor-se entre a rede e um bloco forjado. Verifique por si mesmo Execute node verify-anchor.mjs a partir de aere.network/tools para verificar os certificados de âncora mais recentes, ou descarregue o conjunto de ferramentas completo em verifica-lantul.tar.gz : não instala nada, comunica apenas com um endpoint público e começa com um autoteste que planta vinte e um defeitos deliberados e tem de os detetar todos antes que qualquer resultado verde signifique alguma coisa. Um relatório de conformidade gerado por máquina está publicado em aere.network/tools/sample-conformance-report.html . Limites declarados Em conformidade com a prática do projeto de publicar capacidades e limites no mesmo lugar: os nove validadores são hoje operados pela Aere Foundation, pelo que a cadeia ainda não é descentralizada, e um programa de operadores independentes está em desenvolvimento. Ainda não existe nenhuma auditoria de segurança independente concluída; está prevista no roteiro. A Aere não publica valores de débito; a finalidade determinística abaixo do segundo é a afirmação de desempenho que a rede defende. Sobre a Aere Network A Aere Network é uma rede de liquidação Layer-1 pública e compatível com EVM (Chain ID 2800) construída para durar mais do que a criptografia de hoje: finalidade determinística de meio segundo, uma oferta fixa de tokens de 2.8 mil milhões de AERE definida na génese, verificação nativa de assinaturas pós-quânticas NIST e, a partir do bloco 14,050,000, consenso pós-quântico híbrido. Documentação, investigação e código-fonte: aere.network/papers.html . Notas aos editores Chain ID 2800. Altura de ativação: bloco 14,050,000, 15 de agosto de 2026. Certificados de âncora: cada 32.º cabeçalho desde o bloco 13,014,000, mínimo de três selos Falcon-512. Precompilações ativas desde o bloco 9,189,161, validadas contra os vetores de teste oficiais do NIST. Imprensa: [email protected] . Kit de imprensa completo no Centro de Imprensa e Media . --- # Pressemitteilung: Native NIST-Post-Quanten-Signaturverifizierung geht auf Aere Network live, erstmals bei einer öffentlichen EVM-Layer-1 URL: https://aere.network/press-release-post-quantum.de.html Fetched: 2026-09-15 Pressemitteilung: Native NIST-Post-Quanten-Signaturverifizierung geht auf Aere Network live, erstmals bei einer öffentlichen EVM-Layer-1 Pressemitteilung Native NIST-Post-Quanten-Signaturverifizierung geht auf Aere Network live, erstmals bei einer öffentlichen EVM-Layer-1 Errata, hinzugefügt am 5. September 2026 Diese Mitteilung ist ein datiertes Dokument; der Text darunter bleibt wie veröffentlicht. Korrektur, daneben gestellt statt still umgeschrieben: die weiter unten genannte Design-Obergrenze von 273.000 TPS wurde zurückgezogen. Ihre angegebene Herleitung erreicht diese Zahl nicht, und eine solche Rate wurde auf der Live-Chain nie gemessen. Den aktuellen Stand des Netzwerks beschreibt die Mitteilung vom 15. August . ZUR SOFORTIGEN VERÖFFENTLICHUNG Seychelles, 18. Juli 2026 Native Post-Quanten-Verifizierung ist live im Mainnet und offen für die Überprüfung: öffentliche Forschungsunterlagen, ein unabhängiger zweiter Client, der die Chain Byte für Byte reproduziert, und Endpunkte, die jeder überprüfen kann. MONACO, 18. Juli 2026: Aere Network, eine öffentliche EVM-kompatible Layer-1-Blockchain (Chain ID 2800), hat die native Verifizierung NIST-standardisierter Post-Quanten-Signaturen auf Protokollebene in seinem Mainnet live geschaltet, eine Fähigkeit, die nach Kenntnis des Projekts keine andere öffentliche EVM-Layer-1 bietet. Die Verifizierer gingen am 12. Juli 2026 bei Block 9.189.161 live. Heute veröffentlicht das Netzwerk die vollständigen Forschungsunterlagen dahinter, zusammen mit einem unabhängig implementierten zweiten Client, der die Chain auf jeder geprüften Blockhöhe Byte für Byte reproduziert, und öffentlichen Endpunkten, die jede Wallet selbst überprüfen kann. Was Aere ausgeliefert hat Aere hat die NIST-Post-Quanten-Verifizierer in die Engine der Chain selbst verlagert. Fünf native vorkompilierte Verträge (Precompiles), die Falcon-512, Falcon-1024, ML-DSA-44 (FIPS 204), SLH-DSA-128s (FIPS 205) und den SHAKE256-Hash (FIPS 202) abdecken, laufen zu Protokollkosten. Alle fünf bestehen die offiziellen NIST Known-Answer Tests, und eine durchgängige Falcon-Verifizierung ist im Mainnet aufgezeichnet, sodass sie jeder inspizieren kann. Das praktische Ergebnis: Ein Konto oder Smart Contract auf Aere kann eine quantenresistente Signatur verlangen, bevor es Werte bewegt, nativ statt über eine nachträglich aufgesetzte Lösung. Auch der umgebende Stack ist live. Post-Quanten-Threshold-Custody stellt Konten unter ein Komitee quantenresistenter Signierer, ohne einen einzelnen Schlüssel und ohne Administrator. Ein verwaltetes Register für Krypto-Agilität lässt das Netzwerk bei fortschreitenden Standards auf neuere Verfahren wechseln. Daneben stehen Passkey-Wallets, die Seed-Phrasen durch die Geräteentsperrung ersetzen, die Menschen ohnehin schon nutzen; Passkeys laufen auf der heutigen Standardkryptografie und werden vom selben Agilitätsregister abgedeckt. Warum es jetzt zählt Jede große Blockchain, von Bitcoin bis Ethereum, sichert Konten und Transaktionen mit Signaturen auf Basis elliptischer Kurven, und ein ausreichend leistungsfähiger Quantencomputer, der Shors Algorithmus ausführt, bricht diese Mathematik vollständig. Da Blockchains öffentlich und permanent sind, ist die Bedrohung gegenwärtig: Für die Verschlüsselung sprechen Sicherheitsbehörden von „harvest now, decrypt later" (jetzt ernten, später entschlüsseln), und bei Signaturen ist die Entsprechung noch drastischer, denn öffentliche Schlüssel, die heute aufgezeichnet werden, werden an dem Tag fälschbar, an dem die Mathematik fällt. Die Offenlegung langlebiger Schlüssel, von Treasuries über institutionelle Bestände bis hin zu hochfrequenten KI-Agenten, hat bereits begonnen. NIST hat die Post-Quanten-Signaturstandards 2024 finalisiert, und Live-Blockchains darauf zu migrieren, ist die ungelöste Hausaufgabe der Branche. Das ist die Hausaufgabe, die Aere am 12. Juli ausgeliefert hat und heute vollständig dokumentiert. Gebaut, um überprüft zu werden, nicht um geglaubt zu werden Aere vertritt die Position, dass ein Settlement-Netzwerk überprüfbar statt vertrauensbasiert sein sollte, und wendet diesen Maßstab auf sich selbst an: Die Forschung ist öffentlich. Das vollständige Paper zum Post-Quanten-Fork, die Aere Improvement Proposals und die Verifizierungsunterlagen (49 maschinell geprüfte Konsenseigenschaften, per SMT am Protokollmodell bewiesen, sowie 15 Beweise per symbolischer Ausführung an den Kernverträgen) sind auf git.aere.network/aere-network/aere-research veröffentlicht: das Paper und die Verifizierungsunterlagen unter der MIT-Lizenz, die Improvement Proposals unter CC0 der Gemeinfreiheit gewidmet. Ein zweiter, unabhängiger Client stimmt mit der Chain überein. Ein separat implementierter Client, aufgebaut auf einer anderen Codebasis in einer anderen Programmiersprache, verbindet sich mit dem Live-Netzwerk und hat die Blöcke und den World State von Aere bislang auf jeder geprüften Blockhöhe Byte für Byte reproduziert: ein Live-Lauf, verifiziert bis Block 182.777, und ein permanenter, nicht validierender Follower-Node spielt nun die gesamte Chain-Historie ab dem Genesis erneut ab. Die Daten sind verifizierbar. Ein früherer Shim zur Gebührenanzeige wurde im Juli 2026 abgeschaltet; die öffentlichen Endpunkte liefern nun den realen Gebührenmarkt der Chain, und jeder ausgelieferte Block-Header rekonstruiert seinen eigenen Block-Hash, sodass Wallets, Prüfer und Light Clients verifizieren können, statt zu vertrauen. Das Netzwerk ist im kanonischen öffentlichen Chain-Register gelistet, das von großen Wallets genutzt wird, mit zwei öffentlichen RPC-Endpunkten in geografisch getrennten Rechenzentren. Die Grenzen werden benannt. Das Validator-Set besteht heute aus sieben von der Foundation betriebenen Nodes, die alle den Besu-basierten Client des Netzwerks ausführen und zwei fehlerhafte Nodes tolerieren (Quorum fünf von sieben); der unabhängige zweite Client läuft als nicht validierender Follower, und der Weg zur Dezentralisierung ist in der Roadmap und im Whitepaper des Projekts veröffentlicht. Die Konsenssignierung im Mainnet bleibt klassisches ECDSA; die Post-Quanten-Fähigkeit liegt auf der Konto- und Anwendungsebene. Das ist eine bewusste Reihenfolge: Kontoschlüssel sind langlebig und dauerhaft on-chain exponiert, tragen also zuerst das Harvest-now-Risiko, während Validator-Schlüssel rotiert werden können und ihre Migration die an eine Prüfung gebundene Hybrid-Konsens-Arbeit ist, die weiter unten beschrieben wird. Das Live-System hat noch keine Prüfung durch Dritte abgeschlossen; die veröffentlichten Beweise und Konformitätstests sind die eigene Arbeit des Projekts und stehen jedem zum erneuten Nachvollziehen offen. So schnell, dass es sich sofort anfühlt, Ökonomie durch Code versiegelt Aere erzeugt jede halbe Sekunde einen Block, mit deterministischer Finalität: Sobald eine Transaktion in einem Block enthalten ist, ist sie final, ohne das Zählen von Bestätigungen und ohne Reorganisationen, und eine typische Überweisung kostet den Bruchteil eines Cents. Der native Token AERE hat ein festes, beim Genesis festgelegtes Angebot von 2,8 Milliarden, ohne neues Minting und ohne Insider-Freischaltungsplan, und die Genesis-Zuteilung ist on-chain für jeden einsehbar. Ein von der Foundation festgelegter Anteil der Validator-Belohnungen, derzeit 37,5 Prozent und per Code hart auf die Hälfte gedeckelt, wird in einen versiegelten Burn-Vault ohne Auszahlungspfad geleitet. Die Block-Parameter lassen eine Design-Obergrenze in der Größenordnung von 273.000 Transaktionen pro Sekunde zu; das ist eine durch die Parameter implizierte Obergrenze, keine gemessene Zahl, und der heute realisierte Durchsatz liegt weit darunter. Diese Lücke zu schließen, ist die Aufgabe der veröffentlichten Skalierungs-Roadmap, die eine parallele Ausführungs-Engine umfasst, die im Client-Fork bereits gebaut ist, aber noch nicht das Mainnet bedient. Das Netzwerk ist auch für die Maschinenökonomie gebaut: Aere402, eine x402-kompatible Zahlungsschiene, lässt KI-Agenten pro Anfrage mit Settlement im Sub-Sekunden-Bereich bezahlen, und ein On-Chain-Register für Agentenidentitäten gibt autonomer Software eine überprüfbare Grundlage. Der Weg nach vorn Auf isolierten Testnetzwerken wird an einem hybriden Post-Quanten-Konsens gearbeitet: Blöcke, die von Validatoren gleichzeitig mit klassischen und Falcon-Signaturen signiert werden, sodass die Chain selbst, nicht nur ihre Konten, auf quantenresistenter Mathematik steht. Die Entwürfe sind maschinell geprüft und öffentlich, und das Upgrade wird erst nach einer externen Prüfung ausgeliefert. Die These des Projekts ist einen Satz lang: final wie Mathematik, sicher, wenn sich die Mathematik ändert. „Jede Chain wird irgendwann auf Post-Quanten umstellen müssen. Wir sind vorangegangen und haben die Forschung, die Beweise und die Tests veröffentlicht und einen unabhängigen zweiten Client auf die Chain gestellt, sodass niemand uns irgendetwas davon glauben muss." Liviu Hrenaru, Gründer von Aere Network Über Aere Network Aere Network ist ein öffentliches, EVM-kompatibles Layer-1-Settlement-Netzwerk (Chain ID 2800), gebaut, um die heutige Kryptografie zu überdauern: deterministische Finalität in einer halben Sekunde, typische Gebühren unter einem Cent, ein festes Token-Angebot und native NIST-Post-Quanten-Signaturverifizierung live auf der Kontoebene im Mainnet, wobei sich der hybride Post-Quanten-Konsens in Entwicklung befindet und an eine externe Prüfung gebunden ist. Alles, was das Netzwerk behauptet, ist so gestaltet, dass es von jedem überprüft werden kann, vom Block-Explorer bis zu den veröffentlichten Forschungsunterlagen. Website aere.network Explorer explorer.aere.network Forschung git.aere.network/aere-network/aere-research (MIT; Improvement Proposals CC0) Whitepaper aere.network/whitepaper Presse-Center Presse- und Medienzentrum Medienkontakt: Aere Network Foundation, [email protected] . Das vollständige Medienkit, Logos und frühere Mitteilungen finden Sie im Presse- und Medienzentrum . Hinweise für Redaktionen Chain ID 2800. Deterministische Finalität in rund 0,5 Sekunden. Festes Angebot von 2,8 Milliarden AERE, beim Genesis festgelegt. Fünf aktive NIST-Post-Quanten-Precompiles auf der Kontoebene, aktiviert bei Block 9.189.161. Sieben von der Foundation betriebene Validatoren, Quorum fünf von sieben. 273.000 Transaktionen pro Sekunde sind eine durch die Block-Parameter implizierte Design-Obergrenze, keine gemessene Zahl. Die Konsenssignierung im Mainnet ist klassisches ECDSA; der hybride Post-Quanten-Konsens befindet sich in Entwicklung und ist an eine Prüfung gebunden. Eine Prüfung des Live-Systems durch Dritte ist noch nicht abgeschlossen. Ein Sprecher steht auf Anfrage für Interviews zur Verfügung. ENDE ← Zurück zum Newsroom --- # Nota de prensa: La verificación nativa de firmas poscuánticas NIST entra en funcionamiento en Aere Network, una primicia entre las Layer-1 EVM públicas URL: https://aere.network/press-release-post-quantum.es.html Fetched: 2026-09-15 Nota de prensa: La verificación nativa de firmas poscuánticas NIST entra en funcionamiento en Aere Network, una primicia entre las Layer-1 EVM públicas Nota de prensa La verificación nativa de firmas poscuánticas NIST entra en funcionamiento en Aere Network, una primicia entre las Layer-1 EVM públicas Fe de erratas, añadida el 5 de septiembre de 2026 Este comunicado es un documento fechado y su texto se conserva tal como se publicó. Corrección, indicada junto a él en lugar de reescribirlo en silencio: el techo de diseño de 273.000 TPS citado más abajo ha sido retirado. Su derivación declarada no alcanza esa cifra y nunca se ha medido tal ritmo en la cadena en producción. Para el estado actual de la red, véase el comunicado del 15 de agosto . PARA DIFUSIÓN INMEDIATA Mónaco, 18 de julio de 2026 La verificación poscuántica nativa está activa en la red principal y abierta a inspección: un registro de investigación público, un segundo cliente independiente que reproduce la cadena byte a byte y endpoints que cualquiera puede comprobar. MÓNACO, 18 de julio de 2026: Aere Network, una blockchain Layer-1 pública y compatible con EVM (Chain ID 2800), ha puesto en funcionamiento en su red principal la verificación nativa, a nivel de protocolo, de firmas poscuánticas estandarizadas por el NIST, una capacidad que, hasta donde el proyecto tiene constancia, ninguna otra Layer-1 EVM pública ofrece. Los verificadores entraron en funcionamiento el 12 de julio de 2026 en el bloque 9.189.161. Hoy la red publica el registro de investigación completo que hay tras ellos, junto con un segundo cliente implementado de forma independiente que reproduce la cadena byte a byte en cada altura comprobada, y endpoints públicos que cualquier monedero puede verificar por sí mismo. Lo que Aere ha puesto en producción Aere trasladó los verificadores poscuánticos del NIST al motor de la propia cadena. Cinco contratos precompilados nativos, que cubren Falcon-512, Falcon-1024, ML-DSA-44 (FIPS 204), SLH-DSA-128s (FIPS 205) y la función hash SHAKE256 (FIPS 202), se ejecutan al coste del protocolo. Los cinco superan los Known-Answer Tests oficiales del NIST, y una verificación Falcon de extremo a extremo queda registrada en la red principal para que cualquiera la inspeccione. El resultado práctico: una cuenta o un contrato inteligente en Aere puede exigir una firma resistente a la computación cuántica antes de mover valor, de forma nativa y no mediante un añadido. El resto de la infraestructura que la rodea también está en producción. La custodia poscuántica por umbral pone las cuentas bajo un comité de firmantes resistentes a la computación cuántica, sin una única clave y sin administrador. Un registro gobernado de agilidad criptográfica permite que la red rote hacia esquemas más nuevos a medida que evolucionan los estándares. Junto a ellos conviven los monederos con passkeys, que sustituyen las frases semilla por el desbloqueo del dispositivo que la gente ya utiliza; las passkeys funcionan con la criptografía estándar actual y quedan cubiertas por el mismo registro de agilidad. Por qué importa ahora Toda blockchain importante, desde Bitcoin hasta Ethereum, protege las cuentas y las transacciones con firmas de curva elíptica, y una computadora cuántica lo bastante potente ejecutando el algoritmo de Shor rompe esa matemática por completo. Como las cadenas son públicas y permanentes, la amenaza es de tiempo presente: en el cifrado, las agencias de seguridad la denominan «recolectar ahora, descifrar después», y en las firmas el equivalente es aún más crudo, porque las claves públicas registradas hoy se vuelven falsificables el día en que esa matemática caiga. La exposición de claves de larga duración, desde tesorerías hasta tenencias institucionales y agentes de IA de alta frecuencia, ya ha comenzado. El NIST finalizó los estándares de firma poscuántica en 2024, y migrar las blockchains en producción a esos estándares es la asignatura pendiente del sector. Esa es la tarea que Aere puso en producción el 12 de julio y que documenta hoy en su totalidad. Diseñada para comprobarse, no para creerse La posición de Aere es que una red de liquidación debe ser verificable en lugar de exigir confianza, y aplica ese mismo criterio a sí misma: La investigación es pública. El artículo completo sobre el fork poscuántico, las Propuestas de Mejora de Aere (Aere Improvement Proposals) y el registro de verificación (49 propiedades de consenso comprobadas por máquina, demostradas mediante SMT sobre el modelo del protocolo, y 15 demostraciones por ejecución simbólica sobre los contratos principales) están publicados en git.aere.network/aere-network/aere-research : el artículo y el registro de verificación bajo la licencia MIT, y las Propuestas de Mejora dedicadas al dominio público mediante CC0. Un segundo cliente independiente coincide con la cadena. Un cliente implementado por separado, construido sobre una base de código distinta y en un lenguaje de programación diferente, se conecta a la red en producción y ha reproducido los bloques y el estado global de Aere byte a byte en cada altura comprobada hasta ahora: una ejecución en vivo verificada hasta el bloque 182.777, y un nodo seguidor permanente y no validador está reproduciendo ahora todo el historial de la cadena desde el bloque génesis. Los datos son verificables. En julio de 2026 se retiró un adaptador previo que mostraba las comisiones; los endpoints públicos sirven ahora el mercado real de comisiones de la cadena, y cada cabecera de bloque servida reconstruye su propio hash de bloque, de modo que monederos, auditores y clientes ligeros pueden verificar en lugar de confiar. La red figura en el registro público canónico de cadenas que utilizan los principales monederos, con dos endpoints RPC públicos en centros de datos geográficamente separados. Los límites se declaran. El conjunto de validadores está formado hoy por siete nodos operados por la Fundación, todos ejecutando el cliente de la red derivado de Besu y tolerando dos nodos defectuosos (quórum de cinco de siete); el segundo cliente independiente funciona como seguidor no validador, y la senda hacia la descentralización está publicada en la hoja de ruta y el whitepaper del proyecto. La firma del consenso en la red principal sigue siendo ECDSA clásica; la capacidad poscuántica se encuentra en la capa de cuentas y de aplicación. Se trata de una secuenciación deliberada: las claves de cuenta son de larga duración y quedan expuestas de forma permanente en la cadena, por lo que soportan primero el riesgo de «recolectar ahora», mientras que las claves de validador pueden rotarse, y su migración es el trabajo de consenso híbrido supeditado a auditoría que se describe más abajo. El sistema en producción todavía no ha completado una auditoría de terceros; las demostraciones y las pruebas de conformidad publicadas son trabajo propio del proyecto, ofrecido para que cualquiera pueda reejecutarlo. Lo bastante rápida para sentirse instantánea, con una economía sellada por código Aere produce un bloque cada medio segundo con finalidad determinista: una vez que una transacción está en un bloque, es definitiva, sin recuentos de confirmaciones y sin reorganizaciones, y una transferencia habitual cuesta una fracción de centavo. El token nativo, AERE, tiene un suministro fijo de 2.800 millones establecido en el bloque génesis, sin nueva emisión y sin calendario de desbloqueo para allegados; la asignación inicial es visible en la cadena para que cualquiera la inspeccione. Una parte de las recompensas de los validadores fijada por la Fundación, actualmente del 37,5 por ciento y limitada por código a un máximo de la mitad, se dirige a una bóveda de quema sellada sin vía de retirada. Los parámetros de bloque admiten un techo de diseño del orden de 273.000 transacciones por segundo; ese es un techo implícito en los parámetros, no una cifra medida, y el rendimiento real de hoy está muy por debajo. Cerrar esa brecha es la tarea de la hoja de ruta de escalado publicada, que incluye un motor de ejecución en paralelo ya construido en el fork del cliente pero que aún no da servicio a la red principal. La red también está construida para la economía de las máquinas: Aere402, un raíl de pagos compatible con x402, permite que los agentes de IA paguen por solicitud con liquidación en menos de un segundo, y un registro de identidad de agentes en la cadena da al software autónomo una base verificable. El camino por delante En redes de prueba aisladas se está trabajando hacia un consenso poscuántico híbrido: bloques firmados por los validadores con firmas clásicas y Falcon a la vez, de modo que la propia cadena, y no solo sus cuentas, se sostenga sobre matemática resistente a la computación cuántica. Los diseños están comprobados por máquina y son públicos, y esa actualización solo se lanza tras una auditoría externa. La tesis del proyecto cabe en una frase: definitiva como las matemáticas, segura cuando las matemáticas cambian. «Toda cadena tendrá que dar el paso a lo poscuántico tarde o temprano. Nosotros lo dimos primero, y publicamos la investigación, las demostraciones y las pruebas, y pusimos un segundo cliente independiente en la cadena, para que nadie tenga que fiarse de nuestra palabra en nada de ello.» Liviu Hrenaru, fundador de Aere Network Acerca de Aere Network Aere Network es una red de liquidación Layer-1 pública y compatible con EVM (Chain ID 2800) construida para sobrevivir a la criptografía actual: finalidad determinista en medio segundo, comisiones habituales por debajo de un centavo, un suministro de token fijo y verificación nativa de firmas poscuánticas NIST activa en la capa de cuentas de la red principal, con un consenso poscuántico híbrido en desarrollo y supeditado a una auditoría externa. Todo lo que la red afirma está diseñado para que cualquiera lo compruebe, desde el explorador de bloques hasta el registro de investigación publicado. Sitio web aere.network Explorador explorer.aere.network Investigación git.aere.network/aere-network/aere-research (MIT; propuestas de mejora CC0) Whitepaper aere.network/whitepaper Sala de prensa Sala de prensa y centro de medios Contacto de prensa: Aere Network Foundation, [email protected] . Para el kit de prensa completo, logotipos y notas anteriores, visite la Sala de prensa y centro de medios . Notas para los editores Chain ID 2800. Finalidad determinista de aproximadamente 0,5 segundos. Suministro fijo de 2.800 millones de AERE, establecido en el bloque génesis. Cinco precompilados de criptografía poscuántica NIST activos en la capa de cuentas, activados en el bloque 9.189.161. Siete validadores operados por la Fundación, con quórum de cinco de siete. Las 273.000 transacciones por segundo son un techo de diseño implícito en los parámetros de bloque, no una cifra medida. La firma del consenso en la red principal es ECDSA clásica; el consenso poscuántico híbrido está en desarrollo y supeditado a una auditoría. Todavía no se ha completado ninguna auditoría externa del sistema en producción. Hay un portavoz disponible para entrevistas a petición. FIN ← Volver a la sala de prensa --- # Communiqué de presse : La vérification native des signatures post-quantiques NIST entre en service sur Aere Network, une première pour une Layer-1 EVM publique URL: https://aere.network/press-release-post-quantum.fr.html Fetched: 2026-09-15 Communiqué de presse : La vérification native des signatures post-quantiques NIST entre en service sur Aere Network, une première pour une Layer-1 EVM publique Communiqué de presse La vérification native des signatures post-quantiques NIST entre en service sur Aere Network, une première pour une Layer-1 EVM publique POUR DIFFUSION IMMÉDIATE Seychelles, le 18 juillet 2026 La vérification post-quantique native est en service sur le mainnet et ouverte à l'inspection : un dossier de recherche public, un second client indépendant qui reproduit la chaîne octet pour octet, et des points d'accès que chacun peut vérifier par lui-même. MONACO, le 18 juillet 2026 : Aere Network, une blockchain Layer-1 publique compatible EVM (Chain ID 2800), a mis en service sur son mainnet la vérification native, au niveau du protocole, des signatures post-quantiques normalisées par le NIST, une capacité que, à la connaissance du projet, aucune autre Layer-1 EVM publique ne propose. Les vérificateurs sont entrés en service le 12 juillet 2026, au bloc 9 189 161. Aujourd'hui, le réseau publie l'intégralité du dossier de recherche qui les sous-tend, accompagné d'un second client implémenté de façon indépendante qui reproduit la chaîne octet pour octet à chaque hauteur vérifiée, et de points d'accès publics que n'importe quel portefeuille peut vérifier par lui-même. Ce qu'Aere a livré Aere a déplacé les vérificateurs post-quantiques du NIST au cœur même du moteur de la chaîne. Cinq contrats précompilés natifs, couvrant Falcon-512, Falcon-1024, ML-DSA-44 (FIPS 204), SLH-DSA-128s (FIPS 205) et la fonction de hachage SHAKE256 (FIPS 202), s'exécutent au coût du protocole. Tous les cinq passent les Known-Answer Tests officiels du NIST, et une vérification Falcon de bout en bout est enregistrée sur le mainnet pour que chacun puisse l'inspecter. Résultat concret : un compte ou un contrat intelligent sur Aere peut exiger une signature résistante au quantique avant de déplacer de la valeur, nativement plutôt qu'au moyen d'un ajout rapporté. La pile environnante est elle aussi en service. La garde à seuil post-quantique place les comptes sous le contrôle d'un comité de signataires résistants au quantique, sans clé unique ni administrateur. Un registre d'agilité cryptographique gouverné permet au réseau de basculer vers de nouveaux schémas à mesure que les normes évoluent. À leurs côtés figurent les portefeuilles à passkey, qui remplacent les phrases de récupération par le déverrouillage de l'appareil que les gens utilisent déjà ; les passkeys reposent sur la cryptographie standard d'aujourd'hui et relèvent de ce même registre d'agilité. Pourquoi c'est important dès maintenant Chaque grande blockchain, de Bitcoin à Ethereum, sécurise les comptes et les transactions au moyen de signatures à courbe elliptique, et un ordinateur quantique suffisamment puissant exécutant l'algorithme de Shor brise purement et simplement ces mathématiques. Parce que les chaînes sont publiques et permanentes, la menace est au présent : les agences de sécurité désignent sa version applicable au chiffrement par l'expression « récolter maintenant, déchiffrer plus tard », et pour les signatures l'analogie est plus brutale encore, car les clés publiques enregistrées aujourd'hui deviennent falsifiables le jour où les mathématiques s'effondrent. L'exposition des clés à longue durée de vie, des trésoreries aux avoirs institutionnels en passant par les agents d'IA à haute fréquence, a déjà commencé. Le NIST a finalisé les normes de signature post-quantique en 2024, et y migrer les blockchains en production est le devoir non résolu du secteur. C'est ce devoir qu'Aere a accompli le 12 juillet, et qu'il documente intégralement aujourd'hui. Conçu pour être vérifié, pas pour être cru La position d'Aere est qu'un réseau de règlement devrait être vérifiable plutôt que digne de confiance, et il se tient lui-même à cette exigence : La recherche est publique. L'article complet sur le fork post-quantique, les Aere Improvement Proposals et le dossier de vérification (49 propriétés de consensus vérifiées par machine, prouvées par SMT sur le modèle du protocole, et 15 preuves par exécution symbolique sur les contrats principaux) sont publiés à l'adresse git.aere.network/aere-network/aere-research : l'article et le dossier de vérification sous licence MIT, et les Improvement Proposals versées au domaine public sous CC0. Un second client indépendant s'accorde avec la chaîne. Un client implémenté séparément, bâti sur une base de code différente dans un langage de programmation différent, se connecte au réseau en production et a reproduit les blocs et l'état global d'Aere octet pour octet à chaque hauteur vérifiée jusqu'à présent : une exécution en direct vérifiée jusqu'au bloc 182 777, et un nœud suiveur permanent, non validant, rejoue désormais l'intégralité de l'historique de la chaîne depuis le bloc de genèse. Les données sont vérifiables. Un ancien correctif d'affichage des frais a été retiré en juillet 2026 ; les points d'accès publics servent désormais le véritable marché des frais de la chaîne, et chaque en-tête de bloc servi reconstitue son propre hash de bloc, de sorte que les portefeuilles, les auditeurs et les clients légers peuvent vérifier au lieu de faire confiance. Le réseau est référencé dans le registre public canonique des chaînes utilisé par les grands portefeuilles, avec deux points d'accès RPC publics situés dans des centres de données géographiquement distincts. Les limites sont énoncées. L'ensemble des validateurs compte aujourd'hui sept nœuds opérés par la Fondation, tous exécutant le client dérivé de Besu du réseau et tolérant deux nœuds défaillants (quorum de cinq sur sept) ; le second client indépendant fonctionne comme suiveur non validant, et la trajectoire de décentralisation est publiée dans la feuille de route et le livre blanc du projet. La signature de consensus sur le mainnet reste en ECDSA classique ; la capacité post-quantique se situe au niveau des comptes et des applications. Il s'agit d'un séquencement délibéré : les clés de compte ont une longue durée de vie et sont exposées en permanence sur la chaîne, elles portent donc en premier le risque « récolter maintenant », tandis que les clés des validateurs peuvent être renouvelées, et leur migration correspond au travail de consensus hybride, conditionné à un audit, décrit ci-dessous. Le système en production n'a pas encore fait l'objet d'un audit par un tiers ; les preuves publiées et les tests de conformité sont le fruit du travail du projet lui-même, que chacun est libre de ré-exécuter. Assez rapide pour paraître instantané, une économie scellée par le code Aere produit un bloc toutes les demi-secondes, avec une finalité déterministe : une fois qu'une transaction figure dans un bloc, elle est définitive, sans décompte de confirmations ni réorganisations, et un transfert type coûte une fraction de centime. Le jeton natif, AERE, dispose d'une offre fixe de 2,8 milliards établie à la genèse, sans nouvelle émission ni calendrier de déblocage réservé aux initiés, et l'allocation de genèse est visible sur la chaîne pour que chacun puisse l'inspecter. Une part des récompenses de validateur fixée par la Fondation, actuellement de 37,5 pour cent et plafonnée à la moitié par le code, est acheminée vers un coffre de destruction (burn) scellé, sans voie de retrait. Les paramètres de bloc admettent un plafond théorique de l'ordre de 273 000 transactions par seconde ; il s'agit d'un plafond induit par les paramètres, non d'une valeur mesurée, et le débit réellement atteint aujourd'hui lui est très inférieur. Combler cet écart est la tâche de la feuille de route de mise à l'échelle publiée, qui comprend un moteur d'exécution parallèle déjà intégré au fork du client mais ne servant pas encore le mainnet. Le réseau est aussi conçu pour l'économie des machines : Aere402, un rail de paiement compatible x402, permet aux agents d'IA de payer à la requête avec un règlement en moins d'une seconde, et un registre d'identité d'agents sur la chaîne donne aux logiciels autonomes une assise vérifiable. La suite Des travaux sont en cours, sur des réseaux de test isolés, vers un consensus post-quantique hybride : des blocs signés par les validateurs à la fois avec des signatures classiques et Falcon, afin que la chaîne elle-même, et non plus seulement ses comptes, repose sur des mathématiques résistantes au quantique. Les conceptions sont vérifiées par machine et publiques, et cette mise à niveau ne sera déployée qu'après un audit externe. La thèse du projet tient en une phrase : définitif comme les mathématiques, sûr quand les mathématiques changent. « Chaque chaîne devra tôt ou tard passer au post-quantique. Nous l'avons fait en premier, et nous avons publié la recherche, les preuves et les tests, et mis un second client indépendant sur la chaîne, pour que personne n'ait à nous croire sur parole. » Liviu Hrenaru, fondateur d'Aere Network À propos d'Aere Network Aere Network est un réseau de règlement Layer-1 public et compatible EVM (Chain ID 2800) conçu pour survivre à la cryptographie actuelle : finalité déterministe en une demi-seconde, frais généralement inférieurs à un centime, offre de jetons fixe et vérification native des signatures post-quantiques du NIST en production au niveau des comptes sur le mainnet, avec un consensus post-quantique hybride en cours de développement et conditionné à un audit externe. Tout ce que le réseau affirme est conçu pour être vérifié par quiconque, de l'explorateur de blocs au dossier de recherche publié. Site web aere.network Explorateur explorer.aere.network Recherche git.aere.network/aere-network/aere-research (MIT ; improvement proposals CC0) Livre blanc aere.network/whitepaper Espace presse Espace presse et médias Contact presse : Aere Network Foundation, [email protected] . Pour le dossier de presse complet, les logos et les communiqués précédents, consultez l' Espace presse et médias . Note à l'intention des rédactions Chain ID 2800. Finalité déterministe d'environ 0,5 seconde. Offre fixe de 2,8 milliards d'AERE, fixée à la genèse. Cinq précompilés de cryptographie post-quantique NIST en service au niveau des comptes, activés au bloc 9 189 161. Sept validateurs opérés par la Fondation, quorum de cinq sur sept. Les 273 000 transactions par seconde correspondent à un plafond théorique induit par les paramètres de bloc, non à une valeur mesurée. La signature de consensus sur le mainnet est en ECDSA classique ; le consensus post-quantique hybride est en cours de développement et conditionné à un audit. Aucun audit du système en production par un tiers n'a encore été réalisé. Un porte-parole est disponible pour des entretiens sur demande. FIN ← Retour à la salle de presse --- # Press Release: Native NIST Post-Quantum Signature Verification Goes Live on Aere Network, a Public EVM Layer-1 First URL: https://aere.network/press-release-post-quantum.html Fetched: 2026-09-15 Press Release: Native NIST Post-Quantum Signature Verification Goes Live on Aere Network, a Public EVM Layer-1 First Press Release Native NIST Post-Quantum Signature Verification Goes Live on Aere Network, a Public EVM Layer-1 First Errata, added August 15, 2026 This release is a dated document and its text below is preserved as published. Two corrections, stated next to it rather than silently rewritten: (1) the phrase "tolerating two faulty nodes (quorum six of nine)" was wrong on the date of publication, when the validator set was seven with a commit quorum of five; the set grew to nine, with quorum six, on August 9, 2026. (2) The 273,000 TPS design ceiling cited in the notes has since been withdrawn: its stated derivation does not reach that number, as recorded on the architecture page. For the network's current state, see the August 15 release . FOR IMMEDIATE RELEASE Seychelles, July 18, 2026 Native post-quantum verification is live on mainnet and open to inspection: a public research record, an independent second client that reproduces the chain byte for byte, and endpoints anyone can check. MONACO, July 18, 2026: Aere Network, a public EVM-compatible Layer-1 blockchain (Chain ID 2800), has brought native, protocol-level verification of NIST-standardized post-quantum signatures live on its mainnet, a capability that, to the project's knowledge, no other public EVM Layer-1 offers. The verifiers went live on July 12, 2026, at block 9,189,161. Today the network publishes the complete research record behind them, along with an independently implemented second client that reproduces the chain byte for byte at every height checked, and public endpoints any wallet can verify for itself. What Aere shipped Aere moved the NIST post-quantum verifiers into the engine of the chain itself. Five native precompiled contracts, covering Falcon-512, Falcon-1024, ML-DSA-44 (FIPS 204), SLH-DSA-128s (FIPS 205), and the SHAKE256 hash (FIPS 202), run at protocol cost. All five pass the official NIST Known-Answer Tests, and an end-to-end Falcon verification is recorded on mainnet for anyone to inspect. The practical result: an account or smart contract on Aere can require a quantum-resistant signature before it moves value, natively rather than through a bolt-on. The surrounding stack is live too. Post-quantum threshold custody puts accounts under a committee of quantum-resistant signers, with no single key and no administrator. A governed crypto-agility registry lets the network rotate to newer schemes as standards evolve. Passkey wallets sit alongside these post-quantum mechanisms, replacing seed phrases with the device unlock people already use; passkeys run on today's standard cryptography and fall under the same agility registry. Why it matters now Every major blockchain, from Bitcoin to Ethereum, secures accounts and transactions with elliptic-curve signatures, and a sufficiently powerful quantum computer running Shor's algorithm breaks that mathematics outright. Because chains are public and permanent, the threat is present-tense: for encryption, agencies call the threat "harvest now, decrypt later," and for signatures the analogue is starker, because public keys recorded today become forgeable the day the mathematics falls. The exposure of long-lived keys, from treasuries to institutional holdings to high-frequency AI agents, has already begun. NIST finalized the post-quantum signature standards in 2024, and migrating live blockchains to them is the industry's unsolved homework. That is the homework Aere shipped on July 12 and is documenting in full today. Built to be checked, not believed Aere's position is that a settlement network should be verifiable rather than trusted, and it holds itself to that standard: The research is public. The full paper on the post-quantum fork, the Aere Improvement Proposals, and the verification record (49 machine-checked consensus properties SMT-proved over the protocol model, plus 15 symbolic-execution proofs over the core contracts) are published at git.aere.network/aere-network/aere-research : the paper and the verification record under the MIT license, and the improvement proposals dedicated to the public domain under CC0. A second, independent client agrees with the chain. An independently implemented client, built on a different codebase in a different programming language, connects to the live network and has reproduced Aere's blocks and world state byte for byte at every height checked so far. A live run has been verified through block 182,777, and a permanent, non-validating follower node is now replaying the full chain history from genesis. The data is verifiable. An earlier fee-display shim was retired in July 2026; the public endpoints now serve the chain's real fee market, and every served block header reconstructs its own block hash, so wallets, auditors, and light clients can verify rather than trust. The network is listed in the canonical public chain registry used by major wallets, with two public RPC endpoints in geographically separate data centers. The post-quantum claim is checkable in two commands. Ask the network what is active: eth_config against https://rpc.aere.network returns the fork's activationTime of 1783820272 and names the five live precompiles at 0x0AE1 through 0x0AE5 . Block 9,189,161 is the first block whose timestamp is at or after that activation time, which anyone can derive by binary search over block timestamps. That block holds no transactions, because a fork activation is a configuration change rather than a transaction, so its significance is its timestamp and not its contents. To confirm the precompiles are executing right now, measure gas rather than reading return values: a live precompile consumes gas and an address with nothing at it consumes none, while both can return empty data. Calibrated against the IDENTITY precompile, whose cost the EVM specification fixes exactly, Falcon-512 measures 40,000 gas and Falcon-1024 measures 75,000, matching the constants published in the client source. The full method, with commands and output, is at aere.network/quantum.html . The limits are stated. The validator set is seven Foundation-operated nodes today, all running the network's Besu-derived client and tolerating two faulty nodes (quorum six of nine); the independent second client runs as a non-validating follower, and the decentralization path is published in the project's roadmap and whitepaper. Mainnet consensus signing remains classical ECDSA; the post-quantum capability is at the account and application layers. That is deliberate sequencing: account keys are long-lived and permanently exposed on-chain, so they carry the harvest-now risk first, while validator keys can be rotated, and their migration is the audit-gated hybrid-consensus work described below. The live system has not yet completed a third-party audit; the published proofs and conformance tests are the project's own work, offered for anyone to re-run. Fast enough to feel instant, economics sealed by code Aere produces a block every half second with deterministic finality: once a transaction is in a block, it is final, with no confirmation counts and no reorganizations, and a typical transfer costs a fraction of a cent. The native token, AERE, has a fixed supply of 2.8 billion set at genesis, with no new minting and no insider unlock schedule, and the genesis allocation is visible on-chain for anyone to inspect. A Foundation-set share of validator rewards, currently 37.5 percent and hard-capped at half by code, is routed to a sealed burn vault with no withdrawal path. The block parameters allow a design ceiling on the order of 273,000 transactions per second; that ceiling is implied by the parameters, not a measured figure, and today's realized throughput is far below it. Closing that gap is the job of the published scaling roadmap, which includes a parallel-execution engine already built in the client fork but not yet serving mainnet. The network is built for the machine economy as well: Aere402, an x402-compatible payment rail, lets AI agents pay per request with sub-second settlement, and an on-chain agent identity registry gives autonomous software a verifiable footing. The road ahead On isolated test networks, work is underway toward hybrid post-quantum consensus: blocks signed by validators with both classical and Falcon signatures at once, so the chain itself, not just its accounts, stands on quantum-resistant mathematics. The designs are machine-checked and public, and the upgrade ships only after an external audit. The project's thesis is one sentence long: final as math, safe when the math changes. "Every chain will have to go post-quantum eventually. We went first, and we published the research, the proofs, and the tests, and put an independent second client on the chain, so nobody has to take our word for any of it." Liviu Hrenaru, founder of Aere Network About Aere Network Aere Network is a public, EVM-compatible Layer-1 settlement network (Chain ID 2800) built to outlast today's cryptography: half-second deterministic finality, typical fees below a cent, a fixed token supply, and native NIST post-quantum signature verification live at the account layer on mainnet, with hybrid post-quantum consensus under development and gated on an external audit. Everything the network claims is designed to be checked by anyone, from the block explorer to the published research record. Website aere.network Explorer explorer.aere.network Research git.aere.network/aere-network/aere-research (MIT; improvement proposals CC0) Whitepaper aere.network/whitepaper Press Center Press and Media Center Media contact: Aere Network Foundation, [email protected] . For the full media kit, logos, and past releases, visit the Press and Media Center . Notes to editors Chain ID 2800. Roughly 0.5-second deterministic finality. Fixed supply of 2.8 billion AERE, set at genesis. Five live NIST post-quantum cryptography precompiles at the account layer, activated at block 9,189,161. Seven Foundation-operated validators, quorum six of nine. 273,000 transactions per second is a design ceiling implied by the block parameters, not a measured figure. Mainnet consensus signing is classical ECDSA; hybrid post-quantum consensus is under development and audit-gated. No third-party audit of the live system has been completed yet. A spokesperson is available for interviews on request. ENDS ← Back to newsroom --- # Comunicato stampa: La verifica nativa delle firme post-quantistiche NIST è attiva su Aere Network, una prima per una Layer-1 EVM pubblica URL: https://aere.network/press-release-post-quantum.it.html Fetched: 2026-09-15 Comunicato stampa: La verifica nativa delle firme post-quantistiche NIST è attiva su Aere Network, una prima per una Layer-1 EVM pubblica Comunicato stampa La verifica nativa delle firme post-quantistiche NIST è attiva su Aere Network, una prima per una Layer-1 EVM pubblica Errata corrige, aggiunta il 5 settembre 2026 Questo comunicato è un documento datato e il testo sottostante è conservato come pubblicato. Correzione, indicata accanto anziché riscritta in silenzio: il tetto di progetto di 273.000 TPS citato più sotto è stato ritirato. La derivazione dichiarata non raggiunge quella cifra e un tale ritmo non è mai stato misurato sulla catena in produzione. Per lo stato attuale della rete si veda il comunicato del 15 agosto . PER DIFFUSIONE IMMEDIATA Seychelles, 18 luglio 2026 La verifica nativa post-quantistica è attiva sulla mainnet ed è aperta all'ispezione: una documentazione di ricerca pubblica, un secondo client indipendente che riproduce la catena byte per byte ed endpoint che chiunque può controllare. MONACO, 18 luglio 2026: Aere Network, una blockchain Layer-1 pubblica compatibile con la EVM (Chain ID 2800), ha reso attiva sulla propria mainnet la verifica nativa, a livello di protocollo, delle firme post-quantistiche standardizzate dal NIST, una funzionalità che, per quanto risulta al progetto, nessun'altra Layer-1 EVM pubblica offre. I verificatori sono stati attivati il 12 luglio 2026 al blocco 9.189.161. Oggi la rete pubblica la documentazione di ricerca completa che li sottende, insieme a un secondo client implementato in modo indipendente che riproduce la catena byte per byte a ogni altezza verificata, e a endpoint pubblici che qualsiasi wallet può verificare da sé. Che cosa ha rilasciato Aere Aere ha spostato i verificatori post-quantistici del NIST nel motore stesso della catena. Cinque contratti precompilati nativi, che coprono Falcon-512, Falcon-1024, ML-DSA-44 (FIPS 204), SLH-DSA-128s (FIPS 205) e la funzione hash SHAKE256 (FIPS 202), funzionano al costo di protocollo. Tutti e cinque superano i Known-Answer Test ufficiali del NIST, e una verifica Falcon end-to-end è registrata sulla mainnet, a disposizione di chiunque voglia esaminarla. Il risultato pratico: un account o uno smart contract su Aere può richiedere una firma resistente ai quanti prima di trasferire valore, in modo nativo anziché tramite un'aggiunta esterna. Anche lo stack circostante è attivo. La custodia a soglia post-quantistica pone gli account sotto il controllo di un comitato di firmatari resistenti ai quanti, senza alcuna chiave singola e senza amministratore. Un registro governato di agilità crittografica permette alla rete di passare a schemi più recenti man mano che gli standard evolvono. Accanto a questi meccanismi si collocano i wallet con passkey, che sostituiscono le seed phrase con lo sblocco del dispositivo che le persone già usano; le passkey funzionano con la crittografia standard di oggi e ricadono sotto lo stesso registro di agilità. Perché è importante adesso Ogni blockchain importante, da Bitcoin a Ethereum, protegge account e transazioni con firme a curva ellittica, e un computer quantistico sufficientemente potente che esegue l'algoritmo di Shor scardina completamente quella matematica. Poiché le catene sono pubbliche e permanenti, la minaccia è già attuale: le agenzie di sicurezza chiamano la versione relativa alla cifratura "harvest now, decrypt later" (raccogli ora, decifra dopo), e per le firme l'analogia è ancora più netta, perché le chiavi pubbliche registrate oggi diventano falsificabili il giorno in cui quella matematica cade. L'esposizione delle chiavi a lunga durata, dalle tesorerie ai patrimoni istituzionali agli agenti IA ad alta frequenza, è già iniziata. Il NIST ha finalizzato gli standard per le firme post-quantistiche nel 2024, e migrare a tali standard le blockchain in produzione è il compito ancora irrisolto del settore. È il compito che Aere ha assolto il 12 luglio, e che oggi documenta integralmente. Costruita per essere verificata, non creduta La posizione di Aere è che una rete di regolamento debba essere verificabile anziché degna di fiducia, e applica questo criterio a se stessa: La ricerca è pubblica. Il documento completo sul fork post-quantistico, le Aere Improvement Proposal e la documentazione di verifica (49 proprietà di consenso verificate automaticamente, dimostrate con SMT sul modello di protocollo, e 15 dimostrazioni tramite esecuzione simbolica sui contratti principali) sono pubblicati all'indirizzo git.aere.network/aere-network/aere-research : il documento e la documentazione di verifica con licenza MIT, e le Improvement Proposal dedicate al pubblico dominio con CC0. Un secondo client indipendente concorda con la catena. Un client implementato separatamente, costruito su una base di codice diversa e in un diverso linguaggio di programmazione, si connette alla rete attiva e ha riprodotto i blocchi e lo stato globale di Aere byte per byte a ogni altezza finora verificata: un'esecuzione dal vivo verificata fino al blocco 182.777, e un nodo follower permanente e non validante sta ora rieseguendo l'intera storia della catena dal blocco di genesi. I dati sono verificabili. Un precedente livello di adattamento per la visualizzazione delle commissioni è stato dismesso nel luglio 2026; gli endpoint pubblici ora riflettono il mercato reale delle commissioni della catena, e ogni intestazione di blocco servita ricostruisce il proprio hash di blocco, così che wallet, revisori e light client possano verificare anziché fidarsi. La rete è elencata nel registro pubblico canonico delle catene utilizzato dai principali wallet, con due endpoint RPC pubblici in datacenter geograficamente distinti. I limiti sono dichiarati. L'insieme dei validatori è oggi composto da sette nodi gestiti dalla Foundation, che eseguono tutti il client della rete derivato da Besu e tollerano due nodi guasti (quorum di cinque su sette); il secondo client indipendente funziona come follower non validante, e il percorso verso la decentralizzazione è pubblicato nella roadmap e nel whitepaper del progetto. La firma del consenso sulla mainnet resta ECDSA classica; la funzionalità post-quantistica è a livello di account e di applicazione. Si tratta di una sequenza deliberata: le chiavi degli account sono a lunga durata e permanentemente esposte on-chain, quindi sono le prime a farsi carico del rischio "harvest now", mentre le chiavi dei validatori possono essere ruotate, e la loro migrazione è il lavoro sul consenso ibrido, subordinato ad audit, descritto più avanti. Il sistema in produzione non ha ancora completato un audit di terze parti; le dimostrazioni e i test di conformità pubblicati sono opera del progetto stesso, messi a disposizione affinché chiunque possa rieseguirli. Abbastanza veloce da sembrare istantanea, economia sigillata dal codice Aere produce un blocco ogni mezzo secondo, con finalità deterministica: una volta che una transazione è in un blocco, è definitiva, senza conteggi di conferme e senza riorganizzazioni, e un trasferimento tipico costa una frazione di centesimo. Il token nativo, AERE, ha una fornitura fissa di 2,8 miliardi stabilita alla genesi, senza nuove emissioni e senza piani di sblocco riservati agli insider, e l'allocazione iniziale è visibile on-chain e chiunque può esaminarla. Una quota delle ricompense dei validatori stabilita dalla Foundation, attualmente pari al 37,5 percento e limitata dal codice a un massimo della metà, viene indirizzata a un caveau di burn sigillato, privo di qualsiasi via di prelievo. I parametri di blocco ammettono un tetto di progetto dell'ordine di 273.000 transazioni al secondo; si tratta di un tetto implicito nei parametri, non di un valore misurato, e il throughput effettivamente realizzato oggi è di gran lunga inferiore. Colmare quel divario è il compito della roadmap di scalabilità pubblicata, che include un motore di esecuzione parallela già realizzato nel fork del client ma non ancora operativo sulla mainnet. La rete è costruita anche per l'economia delle macchine: Aere402, un canale di pagamento compatibile con x402, consente agli agenti IA di pagare per singola richiesta con regolamento in meno di un secondo, e un registro on-chain delle identità degli agenti offre al software autonomo una base verificabile. La strada da percorrere È in corso, su reti di test isolate, il lavoro verso un consenso ibrido post-quantistico: blocchi firmati dai validatori con firme classiche e Falcon contemporaneamente, così che la catena stessa, e non solo i suoi account, poggi su una matematica resistente ai quanti. Le specifiche progettuali sono verificate automaticamente e pubbliche, e quell'aggiornamento verrà rilasciato solo dopo un audit esterno. La tesi del progetto sta in una sola frase: definitiva come la matematica, sicura quando la matematica cambia. "Ogni catena dovrà prima o poi diventare post-quantistica. Noi lo abbiamo fatto per primi, e abbiamo pubblicato la ricerca, le dimostrazioni e i test, e messo un secondo client indipendente sulla catena, così che nessuno debba fidarsi della nostra parola su nulla." Liviu Hrenaru, fondatore di Aere Network Informazioni su Aere Network Aere Network è una rete di regolamento Layer-1 pubblica e compatibile con la EVM (Chain ID 2800) costruita per sopravvivere alla crittografia odierna: finalità deterministica in mezzo secondo, commissioni tipiche inferiori a un centesimo, una fornitura di token fissa e verifica nativa delle firme post-quantistiche NIST attiva a livello di account sulla mainnet, con un consenso ibrido post-quantistico in fase di sviluppo e subordinato a un audit esterno. Tutto ciò che la rete afferma è progettato per poter essere verificato da chiunque, dall'explorer dei blocchi alla documentazione di ricerca pubblicata. Sito web aere.network Explorer explorer.aere.network Ricerca git.aere.network/aere-network/aere-research (MIT; improvement proposal CC0) Whitepaper aere.network/whitepaper Sala stampa Centro stampa e media Contatto stampa: Aere Network Foundation, [email protected] . Per il kit stampa completo, i loghi e i comunicati precedenti, visita il Centro stampa e media . Note per la redazione Chain ID 2800. Finalità deterministica in circa 0,5 secondi. Fornitura fissa di 2,8 miliardi di AERE, stabilita alla genesi. Cinque precompilati attivi di crittografia post-quantistica NIST a livello di account, attivati al blocco 9.189.161. Sette validatori gestiti dalla Foundation, quorum di cinque su sette. 273.000 transazioni al secondo è un tetto di progetto implicito nei parametri di blocco, non un valore misurato. La firma del consenso sulla mainnet è ECDSA classica; il consenso ibrido post-quantistico è in fase di sviluppo e subordinato ad audit. Nessun audit di terze parti del sistema in produzione è ancora stato completato. Un portavoce è disponibile per interviste su richiesta. FINE ← Torna alla sala stampa --- # プレスリリース：Aere Network、NIST標準ポスト量子署名のネイティブ検証をメインネットで稼働：公開EVMレイヤー1における先駆けの成果 URL: https://aere.network/press-release-post-quantum.ja.html Fetched: 2026-09-15 プレスリリース：Aere Network、NIST標準ポスト量子署名のネイティブ検証をメインネットで稼働：公開EVMレイヤー1における先駆けの成果 プレスリリース Aere Network、NIST標準ポスト量子署名のネイティブ検証をメインネットで稼働：公開EVMレイヤー1における先駆けの成果 訂正（2026年9月5日追記） 本リリースは日付付きの文書であり、以下の本文は公開時のまま保存しています。黙って書き換える代わりに、ここに訂正を併記します：本文中で言及している毎秒273,000トランザクションという設計上限は撤回されました。示された導出はその数値に達しておらず、そのような処理速度が本番チェーンで測定されたことは一度もありません。ネットワークの現状は 8月15日のリリース をご覧ください。 即時リリース モナコ、2026年7月18日 報道・メディアセンター → ネイティブなポスト量子検証がメインネットで稼働し、誰でも検査できる状態にあります。公開された研究記録、チェーンをバイト単位で再現する独立した第2のクライアント、そして誰もが確認できるエンドポイントです。 モナコ、2026年7月18日： 公開EVM互換レイヤー1ブロックチェーン（チェーンID 2800）であるAere Networkは、NISTが標準化したポスト量子署名のプロトコルレベルでのネイティブ検証をメインネットで稼働させました。これは、同プロジェクトが把握する限り、他のどの公開EVMレイヤー1も提供していない機能です。検証器は2026年7月12日、ブロック9,189,161で稼働を開始しました。本日、ネットワークはその背後にある完全な研究記録を、確認したすべての高さでチェーンをバイト単位で再現する独立実装の第2クライアント、およびあらゆるウォレットが自ら検証できる公開エンドポイントとともに公開します。 Aereが実装したもの Aereは、NISTのポスト量子検証器をチェーンそのもののエンジンへ組み込みました。Falcon-512、Falcon-1024、ML-DSA-44（FIPS 204）、SLH-DSA-128s（FIPS 205）、およびSHAKE256ハッシュ（FIPS 202）を対象とする5つのネイティブなプリコンパイル済みコントラクトが、プロトコルコストで動作します。5つすべてが公式のNIST Known-Answer Test（既知解テスト）に合格しており、エンドツーエンドのFalcon検証がメインネット上に記録され、誰でも検査できます。実用上の効果は明快です。Aere上のアカウントやスマートコントラクトは、価値を移動する前に耐量子署名を要求できます。しかも後付けの仕組みによってではなく、ネイティブにです。 周辺のスタックも稼働しています。ポスト量子しきい値カストディは、単一の鍵も管理者も存在せず、耐量子署名者の委員会の管理下にアカウントを置きます。ガバナンス管理された暗号アジリティレジストリにより、標準の進化に合わせてネットワークはより新しい方式へ移行できます。パスキーウォレットもこれらのポスト量子機構と並んで利用でき、シードフレーズを、人々が普段使っているデバイスのロック解除に置き換えます。パスキーは今日の標準的な暗号技術で動作し、同じアジリティレジストリの対象となっています。 なぜ今それが重要なのか ビットコインからイーサリアムまで、あらゆる主要なブロックチェーンは楕円曲線署名でアカウントとトランザクションを保護しており、ショアのアルゴリズムを実行する十分に強力な量子コンピューターは、その数学的基盤を完全に破ります。ブロックチェーンは公開かつ永続的であるため、この脅威は現在進行形です。暗号化については、セキュリティ機関はこの脅威を「今すぐ収集し、後で復号する（harvest now, decrypt later）」と呼びますが、署名における対応する問題はさらに深刻です。今日記録された公開鍵は、その数学的基盤が崩れる日に偽造可能になるからです。長期間有効な鍵（トレジャリーから機関投資家の保有資産、高頻度で動作するAIエージェントまで）の露出はすでに始まっています。NISTは2024年にポスト量子署名の標準を確定しましたが、稼働中のブロックチェーンをそれらへ移行することは、業界の未解決の宿題です。それこそが、Aereが7月12日に実装し、本日その全容を文書化している宿題です。 信じるためではなく、検証するために構築 Aereの立場は、決済ネットワークは信頼されるのではなく検証可能であるべきだというものであり、その基準を自らにも課しています。 研究は公開されています。 ポスト量子フォークに関する完全な論文、Aere改善提案（Aere Improvement Proposals）、および検証記録（プロトコルモデル上でSMTにより証明された49個の機械検証済みコンセンサス特性と、コアコントラクト上での15個のシンボリック実行証明）が git.aere.network/aere-network/aere-research で公開されています。論文と検証記録はMITライセンスのもとで、改善提案はCC0によりパブリックドメインに提供されています。 第2の独立したクライアントがチェーンと一致します。 異なるプログラミング言語の異なるコードベース上に別個に実装されたクライアントが、稼働中のネットワークに接続し、これまでに確認したすべての高さでAereのブロックとワールドステートをバイト単位で再現しました。ライブ実行はブロック182,777まで検証され、また、恒久的な非検証フォロワーノードが現在、ジェネシスからのチェーン履歴全体を再生しています。 データは検証可能です。 以前の手数料表示用シムは2026年7月に廃止されました。公開エンドポイントは現在、チェーンの実際の手数料市場を提供しており、提供される各ブロックヘッダーは自らのブロックハッシュを再構成するため、ウォレット、監査人、ライトクライアントは信頼する代わりに検証できます。ネットワークは主要なウォレットで使用される標準的な公開チェーンレジストリに登録されており、地理的に離れたデータセンターに2つの公開RPCエンドポイントを備えています。 限界も明示されています。 バリデータセットは現在、7つのFoundation運用ノードで構成され、そのすべてがネットワークのBesu派生クライアントを実行し、2つの障害ノードを許容します（定足数は7分の5）。独立した第2クライアントは非検証フォロワーとして動作し、分散化への道筋はプロジェクトのロードマップとホワイトペーパーで公開されています。メインネットのコンセンサス署名は依然として従来型のECDSAであり、ポスト量子機能はアカウント層およびアプリケーション層にあります。これは意図的な順序付けです。アカウント鍵は長期間有効で、オンチェーンに永続的に露出しているため、「今すぐ収集する」リスクを最初に負います。一方、バリデータ鍵はローテーション可能であり、その移行は下記で述べる、監査を要件とするハイブリッドコンセンサスの取り組みです。稼働中のシステムはまだ第三者監査を完了していません。公開されている証明と適合性テストはプロジェクト自身の成果であり、誰でも再実行できるように提供されています。 瞬時に感じられる速さ、コードで封印された経済設計 Aereは0.5秒ごとに1ブロックを生成し、決定論的ファイナリティを備えています。トランザクションがひとたびブロックに入れば、それは確定であり、確認回数もリオーグ（再編成）もありません。通常の送金コストは1セントの数分の1です。ネイティブトークンであるAEREは、ジェネシスで設定された28億の固定供給量を持ち、新規発行もインサイダー向けのアンロックスケジュールもありません。ジェネシスの割り当てはオンチェーンで誰でも検査できます。バリデータ報酬のうちFoundationが設定する取り分は、現在37.5パーセントで、コードにより上限が半分に固定されており、引き出し経路のない封印されたバーン用ボールトへ送られます。 ブロックパラメータは、毎秒約273,000トランザクションのオーダーの設計上限を許容します。これはパラメータから導かれる上限であって測定値ではなく、今日の実現スループットはそれをはるかに下回ります。その差を埋めることは、公開されているスケーリングロードマップの役割です。同ロードマップには、クライアントのフォーク内にすでに構築済みだが、まだメインネットでは稼働していない並列実行エンジンが含まれます。ネットワークはマシンエコノミー（機械経済）のためにも構築されています。x402互換の決済レールであるAere402は、AIエージェントがリクエストごとにサブ秒の決済で支払うことを可能にし、オンチェーンのエージェントIDレジストリは自律型ソフトウェアに検証可能な基盤を与えます。 今後の展望 隔離されたテストネットワーク上で、ハイブリッドポスト量子コンセンサスに向けた作業が進行中です。すなわち、バリデータが従来型署名とFalcon署名の両方で同時にブロックへ署名することで、アカウントだけでなくチェーンそのものが耐量子の数学的基盤の上に立つようにするものです。その設計は機械検証済みで公開されており、このアップグレードは外部監査を経てはじめて出荷されます。プロジェクトのテーゼは一文で言い表せます。数学のように確定的で、その数学が変わっても安全であること。 「どのチェーンもいずれはポスト量子へ移行しなければなりません。私たちは真っ先にそれを実行し、研究、証明、そしてテストを公開し、独立した第2のクライアントをチェーン上に配置しました。そのどれについても、誰も私たちの言葉を鵜呑みにする必要がないようにするためです。」 リヴィウ・フレナル（Liviu Hrenaru）、Aere Network 創業者 Aere Networkについて Aere Networkは、今日の暗号技術より長く存続するために構築された、公開・EVM互換のレイヤー1決済ネットワーク（チェーンID 2800）です。0.5秒の決定論的ファイナリティ、通常1セント未満の手数料、固定されたトークン供給量、そしてメインネット上のアカウント層で稼働するNIST標準ポスト量子署名のネイティブ検証を備え、ハイブリッドポスト量子コンセンサスは開発中で外部監査を要件としています。ネットワークが主張するすべての事柄は、ブロックエクスプローラーから公開された研究記録まで、誰でも検証できるように設計されています。 ウェブサイト aere.network エクスプローラー explorer.aere.network 研究 git.aere.network/aere-network/aere-research （MIT、改善提案はCC0） ホワイトペーパー aere.network/whitepaper 報道センター 報道・メディアセンター 報道関係お問い合わせ先： Aere Network Foundation、 [email protected] 。メディアキット、ロゴ、過去のリリースについては、 報道・メディアセンター をご覧ください。 編集者への注記 チェーンID 2800。 約0.5秒の決定論的ファイナリティ。 ジェネシスで設定された28億AEREの固定供給量。 アカウント層で稼働する5つのNISTポスト量子暗号プリコンパイル。ブロック9,189,161で有効化。 Foundation運用の7つのバリデータ、定足数は7分の5。 毎秒273,000トランザクションは、ブロックパラメータから導かれる設計上限であり、測定値ではありません。 メインネットのコンセンサス署名は従来型のECDSA。ハイブリッドポスト量子コンセンサスは開発中で、監査を要件とします。 稼働中のシステムに対する第三者監査はまだ完了していません。 ご要望に応じて、取材にはスポークスパーソンが対応いたします。 以上 ← ニュースルームに戻る --- # Comunicado de Imprensa: Verificação Nativa de Assinaturas Pós-Quânticas NIST Entra em Funcionamento na Aere Network, uma Estreia numa Layer-1 EVM Pública URL: https://aere.network/press-release-post-quantum.pt.html Fetched: 2026-09-15 Comunicado de Imprensa: Verificação Nativa de Assinaturas Pós-Quânticas NIST Entra em Funcionamento na Aere Network, uma Estreia numa Layer-1 EVM Pública Comunicado de Imprensa Verificação Nativa de Assinaturas Pós-Quânticas NIST Entra em Funcionamento na Aere Network, uma Estreia numa Layer-1 EVM Pública Errata, adicionada a 5 de setembro de 2026 Este comunicado é um documento datado e o texto abaixo é preservado tal como foi publicado. Correção, colocada ao lado em vez de reescrita em silêncio: o teto de conceção de 273.000 TPS citado abaixo foi retirado. A derivação apresentada não chega a esse valor e tal ritmo nunca foi medido na cadeia em produção. Para o estado atual da rede, veja o comunicado de 15 de agosto . PARA DIVULGAÇÃO IMEDIATA Mónaco, 18 de julho de 2026 Centro de Imprensa e Media → A verificação pós-quântica nativa está ativa na mainnet e aberta a inspeção: um registo de investigação público, um segundo cliente independente que reproduz a cadeia byte a byte e endpoints que qualquer pessoa pode verificar. MÓNACO, 18 de julho de 2026: A Aere Network, uma blockchain pública Layer-1 compatível com a EVM (Chain ID 2800), ativou na sua mainnet a verificação nativa, ao nível do protocolo, de assinaturas pós-quânticas padronizadas pelo NIST, uma capacidade que, tanto quanto é do conhecimento do projeto, nenhuma outra Layer-1 EVM pública oferece. Os verificadores entraram em funcionamento a 12 de julho de 2026, no bloco 9.189.161. Hoje, a rede publica o registo de investigação completo por trás deles, juntamente com um segundo cliente implementado de forma independente que reproduz a cadeia byte a byte em todas as alturas verificadas, e endpoints públicos que qualquer carteira pode verificar por si própria. O que a Aere lançou A Aere moveu os verificadores pós-quânticos do NIST para o motor da própria cadeia. Cinco contratos pré-compilados nativos, abrangendo Falcon-512, Falcon-1024, ML-DSA-44 (FIPS 204), SLH-DSA-128s (FIPS 205) e a função de hash SHAKE256 (FIPS 202), correm ao custo do protocolo. Os cinco passam nos Known-Answer Tests oficiais do NIST, e uma verificação Falcon ponta a ponta está registada na mainnet para qualquer pessoa inspecionar. O resultado prático: uma conta ou um contrato inteligente na Aere pode exigir uma assinatura resistente à computação quântica antes de mover valor, de forma nativa e não através de um complemento acoplado. A restante pilha tecnológica também está ativa. A custódia de limiar pós-quântica coloca as contas sob um comité de signatários resistentes à computação quântica, sem uma chave única e sem administrador. Um registo governado de agilidade criptográfica permite que a rede migre para esquemas mais recentes à medida que os padrões evoluem. As carteiras com passkeys situam-se ao lado destes mecanismos pós-quânticos, substituindo as seed phrases pelo desbloqueio de dispositivo que as pessoas já utilizam; as passkeys funcionam sobre a criptografia padrão atual e estão abrangidas pelo mesmo registo de agilidade. Porque é que isto importa agora Todas as grandes blockchains, do Bitcoin ao Ethereum, protegem contas e transações com assinaturas de curva elíptica, e um computador quântico suficientemente poderoso a executar o algoritmo de Shor quebra por completo essa matemática. Como as cadeias são públicas e permanentes, a ameaça é atual: no caso da encriptação, as agências de segurança chamam-lhe "colher agora, decifrar depois" (harvest now, decrypt later), e, no caso das assinaturas, o equivalente é ainda mais grave, porque as chaves públicas registadas hoje tornam-se falsificáveis no dia em que a matemática cair. A exposição de chaves de longa duração, de tesourarias a posições institucionais e a agentes de IA de alta frequência, já começou. O NIST finalizou os padrões de assinatura pós-quântica em 2024, e migrar as blockchains em funcionamento para esses padrões é o trabalho de casa que a indústria ainda tem por resolver. É esse o trabalho de casa que a Aere entregou a 12 de julho e que documenta na íntegra hoje. Concebida para ser verificada, não para ser acreditada A posição da Aere é que uma rede de liquidação deve ser verificável em vez de exigir confiança, e aplica esse critério a si própria: A investigação é pública. O artigo completo sobre o fork pós-quântico, as Propostas de Melhoria da Aere (Aere Improvement Proposals) e o registo de verificação (49 propriedades de consenso verificadas por máquina, provadas por SMT sobre o modelo do protocolo, e 15 provas de execução simbólica sobre os contratos principais) estão publicados em git.aere.network/aere-network/aere-research : o artigo e o registo de verificação sob a licença MIT, e as Propostas de Melhoria dedicadas ao domínio público através da CC0. Um segundo cliente, independente, concorda com a cadeia. Um cliente implementado separadamente, construído sobre uma base de código diferente e numa linguagem de programação diferente, liga-se à rede em funcionamento e reproduziu os blocos e o estado global (world state) da Aere byte a byte em todas as alturas verificadas até agora: uma execução ao vivo verificada até ao bloco 182.777, e um nó seguidor permanente e não validador está agora a repetir todo o histórico da cadeia desde a génese. Os dados são verificáveis. Uma camada anterior de apresentação de taxas (shim) foi desativada em julho de 2026; os endpoints públicos servem agora o mercado real de taxas da cadeia, e cada cabeçalho de bloco servido reconstrói o seu próprio hash de bloco, para que carteiras, auditores e light clients possam verificar em vez de confiar. A rede consta do registo público canónico de cadeias usado pelas principais carteiras, com dois endpoints RPC públicos em centros de dados geograficamente separados. Os limites são declarados. O conjunto de validadores é atualmente de sete nós operados pela Fundação, todos a executar o cliente da rede derivado do Besu e a tolerar dois nós em falha (quórum de cinco em sete); o segundo cliente independente funciona como seguidor não validador, e o caminho de descentralização está publicado no roadmap e no whitepaper do projeto. A assinatura de consenso na mainnet continua a ser ECDSA clássica; a capacidade pós-quântica situa-se na camada de conta e de aplicação. Trata-se de um faseamento deliberado: as chaves de conta têm longa duração e estão permanentemente expostas na cadeia, pelo que são as primeiras a carregar o risco de "colher agora", enquanto as chaves de validador podem ser rodadas, e a sua migração é o trabalho de consenso híbrido, condicionado a auditoria, descrito mais abaixo. O sistema em produção ainda não concluiu uma auditoria por terceiros; as provas publicadas e os testes de conformidade são trabalho do próprio projeto, disponibilizados para qualquer pessoa voltar a executar. Rápida ao ponto de parecer instantânea, com uma economia selada por código A Aere produz um bloco a cada meio segundo, com finalidade determinística: assim que uma transação está num bloco, é final, sem contagens de confirmações e sem reorganizações, e uma transferência típica custa uma fração de cêntimo. O token nativo, AERE, tem um fornecimento fixo de 2,8 mil milhões (2.800.000.000) definido na génese, sem nova emissão e sem calendário de desbloqueio para insiders, e a alocação de génese é visível na cadeia para qualquer pessoa inspecionar. Uma parte das recompensas dos validadores, definida pela Fundação, atualmente de 37,5 por cento e limitada por código a um máximo rígido de metade, é encaminhada para um cofre de queima selado, sem qualquer via de levantamento. Os parâmetros de bloco admitem um teto de conceção da ordem das 273.000 transações por segundo; trata-se de um teto implícito nos parâmetros, não de um valor medido, e o débito efetivo de hoje está muito abaixo desse valor. Fechar essa lacuna é a tarefa do roadmap de escalabilidade publicado, que inclui um motor de execução paralela já construído no fork do cliente, mas que ainda não serve a mainnet. A rede foi também construída para a economia das máquinas: o Aere402, uma via de pagamento compatível com o x402, permite que agentes de IA paguem por pedido com liquidação em menos de um segundo, e um registo de identidade de agentes na cadeia dá ao software autónomo uma base verificável. O caminho a seguir Em redes de teste isoladas, está em curso trabalho rumo a um consenso híbrido pós-quântico: blocos assinados pelos validadores com assinaturas clássicas e Falcon em simultâneo, para que a própria cadeia, e não apenas as suas contas, assente em matemática resistente à computação quântica. O desenho é verificado por máquina e é público, e a atualização só é lançada após uma auditoria externa. A tese do projeto cabe numa frase: final como a matemática, segura quando a matemática muda. "Todas as cadeias terão, mais cedo ou mais tarde, de se tornar pós-quânticas. Nós fomos os primeiros, e publicámos a investigação, as provas e os testes, e colocámos um segundo cliente independente na cadeia, para que ninguém tenha de confiar apenas na nossa palavra sobre nada disto." Liviu Hrenaru, fundador da Aere Network Sobre a Aere Network A Aere Network é uma rede de liquidação Layer-1 pública e compatível com a EVM (Chain ID 2800), construída para durar mais do que a criptografia atual: finalidade determinística em meio segundo, taxas típicas abaixo de um cêntimo, um fornecimento fixo de tokens e verificação nativa de assinaturas pós-quânticas NIST ativa na camada de conta, na mainnet, com consenso híbrido pós-quântico em desenvolvimento e condicionado a auditoria externa. Tudo aquilo que a rede afirma foi concebido para ser verificado por qualquer pessoa, do explorador de blocos ao registo de investigação publicado. Website aere.network Explorador explorer.aere.network Investigação git.aere.network/aere-network/aere-research (MIT; propostas de melhoria CC0) Whitepaper aere.network/whitepaper Centro de Imprensa Centro de Imprensa e Media Contacto para imprensa: Aere Network Foundation, [email protected] . Para o kit de imprensa completo, logótipos e comunicados anteriores, visite o Centro de Imprensa e Media . Notas para a redação Chain ID 2800. Finalidade determinística de cerca de 0,5 segundos. Fornecimento fixo de 2,8 mil milhões de AERE, definido na génese. Cinco contratos pré-compilados de criptografia pós-quântica NIST ativos na camada de conta, ativados no bloco 9.189.161. Sete validadores operados pela Fundação, quórum de cinco em sete. As 273.000 transações por segundo são um teto de conceção implícito nos parâmetros de bloco, não um valor medido. A assinatura de consenso na mainnet é ECDSA clássica; o consenso híbrido pós-quântico está em desenvolvimento e condicionado a auditoria. Ainda não foi concluída qualquer auditoria por terceiros do sistema em produção. Um porta-voz está disponível para entrevistas mediante solicitação. FIM ← Voltar à sala de imprensa --- # Aere Network - Press and Media Center URL: https://aere.network/press.html Fetched: 2026-09-15 Aere Network - Press and Media Center Aere Network - Press and Media Center Newsroom, media kit, and an honest fact sheet for a public EVM Layer 1 built to be checked, not believed. Half-second finality, typical fees below a cent, and a research record anyone can check: Aere Network is the settlement layer built for the day today's cryptography breaks. This page gives journalists, editors, and aggregators everything in one place, our live feeds, boilerplate, a verifiable fact sheet, logo assets, and a direct press contact. Latest news Current press release Aere Network Launches Aere Cloud: Commercial Infrastructure With Chain-Native Post-Quantum Verification Seychelles, August 23, 2026. Enterprise RPC, managed nodes, blockchain data with native transfer history back to the chain’s earliest blocks, and a post-quantum verification API computed by the chain’s own precompiles. Subscriptions settle on-chain with no custody: payment reaches the treasury in the same transaction, and only the hash of an API key ever touches the chain. Prices in US dollars; every claim checkable from a public endpoint. Read the press release Visit the newsroom Previous releases: Hybrid post-quantum consensus on mainnet (August 15, 2026, with dated correction) · Native NIST post-quantum signature verification live on mainnet (Seychelles, July 18, 2026) The Aere Network newsroom publishes original engineering updates, explainers, and official press releases. How it sources, dates, and corrects its content is described in our editorial standards . Subscribe and ingest our feeds Aere Network runs as an owned press wire. Every post is available in machine-readable form for journalists, editors, and news aggregators. Point your reader or ingestion pipeline at any of the endpoints below. RSS Standard RSS 2.0 feed of the newsroom, updated as posts publish. aere.network/feed.xml JSON Feed JSON Feed 1.1 for modern readers and programmatic ingestion. aere.network/feed.json Google News sitemap News sitemap for search and news-aggregator discovery. aere.network/news-sitemap.xml Aggregators: the RSS and JSON feeds advertise a WebSub hub, so you can receive push updates rather than polling. For syndication questions, email [email protected] . Media kit: boilerplate Approved, ready-to-use descriptions of Aere Network. Every statement below is already published on our about page and in the current press release; please use them as written and do not add claims beyond them. One line Aere Network is a public, EVM-compatible Layer 1 blockchain (Chain ID 2800) with native NIST post-quantum signature verification live at the account layer on mainnet. Short, about 50 words Aere Network is a public, EVM-compatible Layer 1 blockchain (Chain ID 2800) operated by the Aere Foundation. It produces a block every half second with deterministic finality, charges a fraction of a cent for a typical transfer, and offers native, protocol-level verification of NIST-standardized post-quantum signatures at the account layer, live on mainnet. Standard, about 120 words Aere Network is a public, EVM-compatible Layer 1 settlement network (Chain ID 2800), operated by the Aere Foundation and built to outlast today's cryptography. It runs the Ethereum Virtual Machine with QBFT consensus on a Besu-derived client, producing a block every half second with deterministic finality and no reorganizations on finalized blocks; a typical transfer costs a fraction of a cent. Its defining feature is quantum readiness at the account layer: five native precompiles for NIST-standardized post-quantum signatures, activated on mainnet on July 12, 2026 at block 9,189,161, all passing the official NIST Known-Answer Tests. The native token AERE has a fixed supply of 2.8 billion set at genesis, with no new minting. Mainnet consensus signing remains classical ECDSA today; hybrid post-quantum consensus is under development and gated on an external audit. The live system has not yet completed a third-party audit. Everything Aere claims is designed to be checked by anyone. Fact sheet These figures match our about page and the current press release exactly. Where a number is a design ceiling rather than a measured rate, we say so. Network Public, EVM-compatible Layer 1 blockchain, Chain ID 2800; standard Ethereum JSON-RPC Consensus QBFT (Hyperledger Besu engine), ten Foundation-operated validators, quorum seven of ten, tolerating three faulty nodes Finality About 0.5-second blocks, deterministic finality, no reorganizations on finalized blocks Fees A typical transfer costs a fraction of a cent Token AERE, fixed supply of 2.8 billion set at genesis, no new minting Post-quantum Five native NIST PQC precompiles live at the account and application layer, activated on mainnet at block 9,189,161 (July 12, 2026) PQC schemes Falcon-512, Falcon-1024, ML-DSA-44 (FIPS 204), SLH-DSA-128s (FIPS 205), SHAKE256 (FIPS 202); all pass the official NIST Known-Answer Tests Throughput The 273,000 TPS design ceiling has been withdrawn (2026-09-05); measured throughput is published with its date on /benchmarks Operator Aere Foundation, non-profit-style steward of the protocol; leadership listed publicly Verify Block explorer, one-click network add, public research repository, and whitepaper Honest caveats, stated in the same place as the capabilities Mainnet consensus signing is classical ECDSA today. The post-quantum capability is at the account and application layer, not in consensus. Hybrid post-quantum consensus is under development on isolated test networks and is gated on an external audit. The 273,000 TPS figure has been withdrawn (2026-09-05): its stated derivation does not reach that number, and no such rate has ever been measured on the live chain. The validator set is nine Foundation-operated nodes; the decentralization path is published in the roadmap and whitepaper. The live system has not yet completed a third-party audit. The published proofs and conformance tests are the project's own work, offered for anyone to re-run. Block explorer Add the network Whitepaper Research (MIT; improvement proposals CC0) Assets Official Aere Network logo files, served directly from this site. These are the only official marks; please do not fabricate or alter them. Square brand mark PNG, 1000 x 1000. Used as the site icon and in structured data. Open PNG Horizontal logo lockup PNG, 1750 x 400. Used in the site header and footer. Open PNG Brand usage: use the Aere Network marks to identify Aere Network and coverage of the project. Do not stretch, recolor, or otherwise alter them, and do not use them to imply a partnership, endorsement, or affiliation that does not exist. Full color and spacing guidance is on the brand kit . Leadership and ownership Team and leadership Aere Network is founded and led by Liviu Hrenaru, Founder and CEO, with a distributed team of protocol engineers and open-source contributors working in the open under the AERE Foundation. About the Foundation Foundation and funding The Aere Foundation stewards the protocol and treasury on-chain. Ownership and funding are documented publicly, with no off-chain equity or private sale. View the Foundation · Ownership and funding Press contact Press and media enquiries [email protected] Operated by the Aere Foundation. We read press and media requests at this address and respond during European business hours. For interviews, background, or clarification on any published claim, include the page URL and the specific claim. Newsroom Editorial standards About Contact Aere Network is a technology project. Nothing on this site is investment advice or a solicitation to buy or sell any asset. --- # Quantum Exposure Report | Aere Network URL: https://aere.network/quantum-exposure-report.html Fetched: 2026-09-15 Quantum Exposure Report | Aere Network Aere Quantum Exposure Report An exposure report your auditor can re-run without us Most quantum-readiness reports are an opinion with a logo on it. This one carries the command that reproduces it, so the person who reviews your work next year can run it against a node they operate themselves and get the same answer, or a documented difference. What you get A measurement, per address. What was measured, and what the tool refused to settle on its own. Those are different, and the report never blurs them. The exact command that reproduces it , with --rpc pointing wherever you like. Nothing in the report depends on trusting us. A digest manifest , so a report that has been edited after delivery is detectable. An on-chain anchor of the report digest, signed under a post-quantum validator certificate, with a public verifier you run yourself. Answers in the wording of the published criteria (NIST IR 8547 and CNSA 2.0), phrased as criteria and never as a certification. Price Free scan, one address 0 Verdict and the reachable post-quantum verifiers. No account needed. Report 149 EUR One report: PDF, JSON, manifest, anchored certificate, questionnaire annexes. Portfolio, up to 50 addresses 490 EUR The same, aggregated, with prioritisation. Monitoring 99 EUR / month Re-scan on change, alert on regression. Reseller licence, for audit firms 990 EUR / year Unlimited reports under your own brand. Your client can still reproduce every one of them. Prices exclude VAT, which is handled by the payment processor as merchant of record. What this report does not claim, written before you buy We are not an accredited audit firm , and this is not an accredited audit. It measures the on-chain slice: bytecode and what it can reach. Repositories, TLS, dependencies, key custody and HSMs are out of scope. It does not say compliant with NIST . It says measured against the criteria published in NIST IR 8547 . Compliance is a statement only an accredited body can make. A post-quantum verifier called from a transaction that is itself authorised with ECDSA gives no post-quantum security. The adversary forges the outer transaction. Anyone selling you the opposite can be taken apart in five minutes, and we would rather you heard it here. "Harvest now, decrypt later" does not apply to signatures. A signature is public and is not harvested. The threat that applies to a chain is retroactive rewriting of history with keys recovered later, which is a different and more serious problem. No legal effect is promised. What an anchored digest means in court depends on jurisdiction. The chain this anchors to has one operator and no external security audit yet. We publish that ourselves, on the decentralisation page , with the measurements. The report's value does not rest on trusting that chain: it rests on you being able to re-run the measurement. Why us Because the tooling was built to measure our own chain first, and it is unkind to it. The same scanner that produces your report produces our public findings register, including the ones that make us look bad. A vendor whose tool has never returned a red verdict about the vendor is selling you a brochure. The verifier for the anchored certificate is public, installs nothing, and accepts your own node: node verifica-certificat.mjs certificate.json --rpc https://your-node . Five deliberately falsified certificates were planted against it and all five were rejected. The scanner itself is public and installs nothing: git.aere.network/aere-network/pqc-migration-toolkit . Clone it, point it at a node you operate, and measure your own addresses without us. If your number differs from ours, that difference is the interesting part. Start with the free scan Send the address you want measured. You get the verdict and the open questions at no cost and with no account, and you decide afterwards whether the full report is worth 149 EUR. Request the free scan Payment is handled by a merchant of record. Never in AERE tokens: the token is not listed and has no liquidity, and paying for a compliance report in an illiquid token would be a bad idea for you. About About Aere Foundation Roadmap Press & Newsroom Brand Kit Editorial Standards Build Developer Hub Documentation RPC Reference SDK Add Network Faucet Academy Grants Network Architecture Post-Quantum Stack Validators Run a Validator Network Status Audits Security Decentralization Solutions Payments DeFi Real-World Assets Infrastructure Gaming NFTs & Culture Explore Explorer Blocks Transactions Tokens Research & Papers Glossary Blog Legal Terms & Privacy Sanctions Compliance Aere Network. Chain ID 2800. Every claim on this site is checkable: rpc.aere.network --- # Quantum-Safe Settlement | Aere Network URL: https://aere.network/quantum-safe-settlement.html Fetched: 2026-09-15 Quantum-Safe Settlement | Aere Network Solutions Quantum-Safe Settlement Institutions Compliance Chain 2800 Updated 2026-08-15 Verified at block 13,923,216 2 min read A public settlement ledger whose block record carries post-quantum evidence you can verify yourself, in under a minute, against a public endpoint. Every signature securing a public blockchain today rests on elliptic-curve cryptography, and NIST has already scheduled its retirement: classical 112-bit schemes are deprecated after 2030 and disallowed after 2035 (NIST IR 8547). For a settlement ledger the danger is not tomorrow's traffic but yesterday's record: a ledger publishes its public keys and signatures forever, so an adversary who later recovers old keys can sign new statements about old history. Regulators have begun asking institutions for migration plans now, not at the deadline. What Aere Network settles differently Chain 2800 is a public EVM Layer‑1 with half-second deterministic finality whose block record carries post-quantum evidence bound under the block hash itself . Since block 13,014,000, every 128th block (every 32nd block until block 17,225,968, on 2026-09-05) header embeds a certificate of Falcon‑512 signatures from the validator set over the parent block, and a 32-byte digest of that certificate sits inside the hashed part of the header. Strip or alter the certificate and the block hash no longer verifies. Since 2026‑08‑14 every node enforces a minimum of three seals per anchor block; at block 14,961,456 (2026‑08‑21) the enforced minimum was raised to six of nine, a full quorum at that size; ten validators since 2026-09-11. Five post-quantum verifiers (Falcon‑512, Falcon‑1024, ML‑DSA‑44, SLH‑DSA‑128s, SHAKE256) run as native precompiles, live since block 9,189,161 and validated against NIST test vectors, so accounts and applications can bind authorization to post-quantum keys today, with no protocol change. Do not take our word for any of this The claim above is checkable by anyone, against a public endpoint, in under a minute. The verifier below recomputes the binding digest independently, from raw RLP, and refuses politely when it does not match. It has a proven red path: pointed at pre-enforcement history it fails on thin certificates, and with a tampered domain string it fails on every digest. Working with us We work with institutions that need to show a quantum-safe settlement story to a regulator, an auditor, or a board. An engagement starts with verification, not slides: your team runs the verifier against our chain, then we map your settlement flows onto post-quantum authorization together. The chain is EVM at Ethereum parity, so existing tooling, wallets and audits carry over. Honest boundaries, stated up front: since 2026-08-14 consensus on chain 2800 does not finalize an anchor block (every 32nd) without at least three valid post-quantum (Falcon-512) validator seals, f+1 of the nine validators of that time (raised at block 14,961,456, August 21, 2026, to six seals, then a full 2f+1 quorum of nine; since the set grew to ten on 2026-09-11 the enforced minimum is still six, above f+1 but below the ten-validator quorum of seven), with classical ECDSA finalizing every block (corrected 2026-08-19: not a per-block quorum); the validator set is Foundation-operated while the independent-operator program is built; and no external security audit has been completed yet. Each of these is on the public roadmap with its date, and this page will state each change only after the chain itself shows it. Verify it yourself curl -O https://aere.network/tools/verify-anchor.mjs -O https://aere.network/tools/falcon512.mjs -O https://aere.network/tools/package.json && npm install node verify-anchor.mjs # VERIFIED: 20/20 anchor blocks carry a post-quantum certificate # bound under the block hash, each with at least 6 Falcon-512 seals (the quorum enforced since 2026-08-21; earlier anchors carry at least 3). Talk to the Foundation Next up The post-quantum stack, layer by layer The Aere glossary Post Quantum Anchor Falcon 512 Seal Certificate Finality Validator Signer Registry About About Aere Foundation Roadmap Press & Newsroom Brand Kit Editorial Standards Build Developer Hub Documentation RPC Reference SDK Add Network Faucet Academy Grants Network Architecture Post-Quantum Stack Validators Run a Validator Network Status Audits Security Decentralization Solutions Payments DeFi Real-World Assets Infrastructure Gaming NFTs & Culture Explore Explorer Blocks Transactions Tokens Research & Papers Glossary Blog Legal Terms & Privacy Sanctions Compliance Aere Network. Chain ID 2800. Every claim on this site is checkable: rpc.aere.network --- # The Post-Quantum Stack | Aere Network URL: https://aere.network/quantum-stack.html Fetched: 2026-09-15 The Post-Quantum Stack | Aere Network Aere Network Aere Cloud Docs Status Network The Post-Quantum Stack Chain 2800 Verifiable Updated 2026-08-15 Verified at block 13,924,980 3 min read Six layers, from a signature primitive an account can call today to a consensus rule under which every 128th block (every 32nd block until block 17,225,968, on 2026-09-05) does not finalize without a post-quantum validator certificate. Each layer states what is live, what is still validating, and the number that backs it. Layer 1 Live Verification primitives Five post-quantum verifiers callable by any contract or any eth_call. Falcon-512, Falcon-1024, ML-DSA-44, SLH-DSA-128s and SHAKE256 run as native precompiles at addresses 0x0AE1 through 0x0AE5. They have been live on mainnet since block 9,189,161 and are validated against the published NIST test vectors on-chain. Five algorithms rather than one is the point: a contract can pick a lattice scheme or a hash-based scheme at runtime, so no application is hostage to a single family. Live since block 9,189,161 · 5 addresses · NIST-vector checked Layer 2 Live Account and application authorization Any account or contract can bind its authorization to a post-quantum key today, with no protocol change. Because the primitives are on-chain, a smart account verifies a Falcon or SLH-DSA signature the same way it verifies anything else. This is the additive layer: adopting post-quantum authorization is a contract deployment, not a fork, and it touches no operator. The honest boundary, stated plainly: a post-quantum check invoked from a transaction still authenticated by classical ECDSA inherits ECDSA's exposure. The durable posture is to move the account's own authorization onto a post-quantum key. No protocol change · EVM at Ethereum parity Layer 3 Live The block record The block hash itself covers a post-quantum certificate of the validator set. Since block 13,014,000, every 32nd block header carries a certificate of Falcon-512 signatures from the validators over the parent block, and a 32-byte digest of that certificate sits inside the hashed part of the header. Strip or alter the certificate and the block hash no longer verifies. Since 2026-08-14 every node enforces a minimum of three seals per anchor block, raised to six seals, then a full quorum of nine, at block 14,961,456 (2026-08-21); ten validators since 2026-09-11, where six is below the quorum of seven; the cap is nine since 2026-08-16, and certificates in practice carried all nine (ten validators since 2026-09-11). Live since block 13,014,000 · min 3 seals · digest under the block hash Layer 4 Live The signer registry The nine signing keys are bound on-chain in an immutable contract anyone can read. The registry that says which key belongs to which validator is not shared configuration a node could quietly change. Its keccak is held in the storage of an immutable contract at 0x5214F0e53899Dad805ef3AdF0624F5e49d2a5EB5, deployed with no writable path, so the binding cannot be altered after the fact. You can read the bound hash yourself with eth_getStorageAt and compare it to the manifest. 9 entries · immutable contract · readable via eth_getStorageAt Layer 5 Live Consensus finality A consensus rule under which every 128th block (every 32nd block until block 17,225,968, on 2026-09-05) (an anchor block) does not finalize without at least three valid post-quantum validator seals (raised at block 14,961,456, August 21, 2026, to six seals, then a full 2f+1 quorum of nine; since the set grew to ten on 2026-09-11 the enforced minimum is still six, above f+1 but below the ten-validator quorum of seven) under its hash. Correction 2026-08-19: the per-block post-quantum quorum rule armed fleet-wide at block 14,050,000 (aere.falcon.forkBlock) is, in the shipped code, retired in favour of the anchor rules from 13,014,000 and changed no enforcement; the earlier claim that every block required it to finalize is withdrawn, and what is enforced is the anchor certificate above. Apart from anchor blocks, consensus signatures are classical ECDSA under QBFT , and this page said so. At and after it, the finality of every block depends on a certificate of validator Falcon signatures: a node presented with a block that lacks one will not accept it. Ten keyed validators (since 2026-09-11) give the layer a real fault margin (f=3), which is why the arming guard refuses a smaller set. This page states the switch as live because the chain itself shows it: anchor certificates at and past the height, checkable with the verifier tool on this site. Anchor certificate enforced since 2026-08-14 · six seals since block 14,961,456 (2026-08-21), a full quorum of the nine validators then; ten validators since 2026-09-11 · all nine carried in practice at the time Layer 6 Validating Independent cross-check A second, separately built client re-validates the chain and refuses what it cannot verify. A second client , an independently implemented Nethermind fork, validates chain 2800 alongside the producing client. Because it enforces the rules on its own predicate, it has twice stopped at divergences it refused to accept rather than following silently: exactly the assurance a second implementation exists to provide. It produces no mainnet blocks yet; putting a second client into the producing set is a deliberate, founder-supervised step, because a bug in a producing client can halt a live chain. Validates live chain 2800 · producing set remains single-client See each layer yourself # the block record (Layer 3): recompute the digest bound under the block hash curl -O https://aere.network/tools/verify-anchor.mjs && node verify-anchor.mjs # the primitives (Layer 1): replay NIST vectors in your browser, read-only open https://aere.network/quantum-verify.html For regulated finance Next up Verify the primitives in your browser The Aere glossary Post Quantum Anchor Precompile Falcon 512 Seal Certificate Signer Registry Client Diversity About About Aere Foundation Roadmap Press & Newsroom Brand Kit Editorial Standards Build Developer Hub Documentation RPC Reference SDK Add Network Faucet Academy Grants Network Architecture Post-Quantum Stack Validators Run a Validator Network Status Audits Security Decentralization Solutions Payments DeFi Real-World Assets Infrastructure Gaming NFTs & Culture Explore Explorer Blocks Transactions Tokens Research & Papers Glossary Blog Legal Terms & Privacy Sanctions Compliance Aere Network. Chain ID 2800. Every claim on this site is checkable: rpc.aere.network --- # The Post-Quantum Stack | Aere Network URL: https://aere.network/quantum.html Fetched: 2026-09-15 The Post-Quantum Stack | Aere Network Aere Network Aere Cloud Docs Status Network The Post-Quantum Stack Chain 2800 Verifiable Updated 2026-08-15 Verified at block 13,924,980 3 min read Six layers, from a signature primitive an account can call today to a consensus rule under which every 128th block (every 32nd block until block 17,225,968, on 2026-09-05) does not finalize without a post-quantum validator certificate. Each layer states what is live, what is armed, and the number that backs it. Layer 1 Live Verification primitives Five post-quantum verifiers callable by any contract or any eth_call. Falcon-512, Falcon-1024, ML-DSA-44, SLH-DSA-128s and SHAKE256 run as native precompiles at addresses 0x0AE1 through 0x0AE5. They have been live on mainnet since block 9,189,161 and are validated against the published NIST test vectors on-chain. Five algorithms rather than one is the point: a contract can pick a lattice scheme or a hash-based scheme at runtime, so no application is hostage to a single family. Live since block 9,189,161 · 5 addresses · NIST-vector checked Layer 2 Live Account and application authorization Any account or contract can bind its authorization to a post-quantum key today, with no protocol change. Because the primitives are on-chain, a smart account verifies a Falcon or SLH-DSA signature the same way it verifies anything else. This is the additive layer: adopting post-quantum authorization is a contract deployment, not a fork, and it touches no operator. The honest boundary, stated plainly: a post-quantum check invoked from a transaction still authenticated by classical ECDSA inherits ECDSA's exposure. The durable posture is to move the account's own authorization onto a post-quantum key. No protocol change · EVM at Ethereum parity Layer 3 Live The block record The block hash itself covers a post-quantum certificate of the validator set. Since block 13,014,000, every 32nd block header carries a certificate of Falcon-512 signatures from the validators over the parent block, and a 32-byte digest of that certificate sits inside the hashed part of the header. Strip or alter the certificate and the block hash no longer verifies. Since 2026-08-14 every node enforces a minimum of three seals per anchor block, raised to six seals, then a full quorum of nine, at block 14,961,456 (2026-08-21); ten validators since 2026-09-11, where six is below the quorum of seven; since 2026-08-16 the cap is nine, and certificates in practice carried all nine (ten validators since 2026-09-11). Live since block 13,014,000 · min 3 seals · digest under the block hash Layer 4 Live The signer registry The nine signing keys are bound on-chain in an immutable contract anyone can read. The registry that says which key belongs to which validator is not shared configuration a node could quietly change. Its keccak is held in the storage of an immutable contract at 0x5214F0e53899Dad805ef3AdF0624F5e49d2a5EB5, deployed with no writable path, so the binding cannot be altered after the fact. You can read the bound hash yourself with eth_getStorageAt and compare it to the published manifest : the verifier below does exactly that, and also checks every key against the validator's own signature over it. 9 entries · immutable contract · readable via eth_getStorageAt Layer 5 Live Consensus finality Live: since 2026-08-14 every 128th block (every 32nd block until block 17,225,968, on 2026-09-05) does not finalize without a certificate of at least three valid post-quantum validator seals (raised at block 14,961,456, August 21, 2026, to six seals, then a full 2f+1 quorum of nine; since the set grew to ten on 2026-09-11 the enforced minimum is still six, above f+1 but below the ten-validator quorum of seven) under its hash. Correction 2026-08-19: the per-block post-quantum quorum rule armed at block 14,050,000 (aere.falcon.forkBlock) is, in the shipped code, retired in favour of the anchor rules from 13,014,000 and changed no enforcement; the earlier claim that every block required it to finalize is withdrawn, and what is enforced is the anchor certificate above. Apart from anchor blocks, consensus signatures are classical ECDSA under QBFT , and this page says so. At and after it, the finality of every block depends on a certificate of validator Falcon signatures: a node presented with a block that lacks one will not accept it. Ten keyed validators (since 2026-09-11) give the layer a real fault margin (f=3), which is why the arming guard refuses a smaller set. The chain shows it: the switch is live, and the verifier below checks the record that proves it. Anchor certificate enforced since 2026-08-14 · six seals since block 14,961,456 (2026-08-21), a full quorum of the nine validators then; ten validators since 2026-09-11 · all nine carried in practice at the time Layer 6 Validating Independent cross-check A second, separately built client re-validates the chain and refuses what it cannot verify. A second client , an independently implemented Nethermind fork, validates chain 2800 alongside the producing client. Because it enforces the rules on its own predicate, it has twice stopped at divergences it refused to accept rather than following silently: exactly the assurance a second implementation exists to provide. It produces no mainnet blocks yet; putting a second client into the producing set is a deliberate, founder-supervised step, because a bug in a producing client can halt a live chain. Validates live chain 2800 · producing set remains single-client See each layer yourself # Layers 3 and 4: recompute the digest bound under the block hash, then verify every Falcon-512 seal against the on-chain-pinned key manifest curl -O https://aere.network/tools/verify-anchor.mjs -O https://aere.network/tools/falcon512.mjs -O https://aere.network/tools/package.json && npm install && node verify-anchor.mjs # the primitives (Layer 1): replay NIST vectors in your browser, read-only open https://aere.network/quantum-verify.html For regulated finance Next up Verify the primitives in your browser The Aere glossary Post Quantum Anchor Precompile Falcon 512 Seal Certificate Signer Registry Client Diversity About About Aere Foundation Roadmap Press & Newsroom Brand Kit Editorial Standards Build Developer Hub Documentation RPC Reference SDK Add Network Faucet Academy Grants Network Architecture Post-Quantum Stack Validators Run a Validator Network Status Audits Security Decentralization Solutions Payments DeFi Real-World Assets Infrastructure Gaming NFTs & Culture Explore Explorer Blocks Transactions Tokens Research & Papers Glossary Blog Legal Terms & Privacy Sanctions Compliance Aere Network. Chain ID 2800. Every claim on this site is checkable: rpc.aere.network --- # Real-World Asset Tokenization | Aere Network URL: https://aere.network/real-world-assets.html Fetched: 2026-09-15 Real-World Asset Tokenization | Aere Network Solutions Tokenization with receipts that outlive the cryptography Real-world assets Long-horizon proof Chain 2800 Updated 2026-08-15 Anchor certificate enforced since block 2026-08-14 3 min read A tokenized asset is worth exactly what its proof is worth. On chain 2800, the record lives under a consensus that will not finalize a block without post-quantum signatures, so the registry stays verifiable for the life of the asset, not the life of a key. A tokenized bond matures in thirty years. A property title changes hands once a decade. A fund share must remain provable to a supervisor for as long as the fund exists. When a real-world asset moves on chain, the token inherits the lifetime of the asset, and the whole construction rests on one thing: that the record of who holds what, and the documents that say why, can still be verified at maturity, not only at issuance. Assets live for thirty years. ECDSA does not. For the classical elliptic-curve signatures that secure most public ledgers, NIST's post-quantum migration guidance (IR 8547, initial public draft 2024) schedules deprecation after 2030 and disallowance after 2035, sooner than the maturity of many assets being tokenized onto them. Once that cryptography falls, an adversary who recovers old validator keys could, in principle, re-sign an alternative history. At that point a registry you meant to hold for decades stops being a proof and becomes an argument. For a payment this is tomorrow's problem. For a thirty-year asset it is a design flaw, present at issuance. What the ledger underneath provides Chain 2800 is a public EVM Layer 1 with deterministic finality : a block is final when a quorum of seven of ten validators signs it (ten validators since 2026-09-11), and the QBFT consensus produces no reorganizations by design. Blocks arrive about every half second, 0.566 seconds as re-measured on 2026-09-02. For an asset registry this means a transfer is settled when it is included, and it stays settled. Consensus is hybrid in a precise and limited sense: since block 13,014,000 every 128th header (every 32nd header until block 17,225,968, on 2026-09-05) carries a certificate of validator Falcon-512 seals bound under the block hash itself, with a minimum of three seals (f+1 of the nine validators of that time) enforced since 2026-08-14, raised to six seals, then a full quorum of nine, at block 14,961,456 (2026-08-21); ten validators since 2026-09-11, where six is below the quorum of seven, so an anchor block without it does not finalize; classical ECDSA finalizes every block. (Correction 2026-08-19: the earlier statement that from block 14,050,000 every block required a six-of-nine post-quantum quorum to finalize is withdrawn; the per-block rule armed at that height is retired in the shipped code in favour of the anchor rules and changed no enforcement.) The record your asset lives in is not waiting for a migration; the post-quantum evidence is already in the blocks. The full layer-by-layer picture is on the quantum stack page. The same durability is available at the account and contract level. Five NIST post-quantum verifier precompiles have been live since block 9,189,161: Falcon-512, Falcon-1024, ML-DSA-44, SLH-DSA-128s and SHAKE256, each validated against the official NIST vectors. A transfer-agent contract or an issuer workflow can require a post-quantum signature on its own operations, on chain, today. Everything else is standard EVM at Pectra and Fusaka parity, so MetaMask, ethers, and hardhat or foundry work unchanged, and the native token AERE has a fixed supply of 2.8 billion set at genesis, with no new minting. Notarization and attestation, the other half of an asset A real-world asset is never just a token. It is a prospectus, a valuation report, a custody attestation, an insurance certificate: a document trail that has to remain provably unaltered for as long as the asset exists. Our post-quantum notarization anchors a document's hash on chain 2800 without the file ever leaving your hands, and the timestamp inherits the durability of the ledger itself. The mechanism is not a promise: this network's own whitepaper re-anchors its content hash on a fresh block four times a day, publicly verifiable right now. Honest boundaries All ten validators are operated by the Foundation today (ten since 2026-09-11). The chain is not yet decentralized and we do not describe it that way; an independent-operator program is being built. No third-party security audit has been completed yet; one is on the roadmap. Our performance claim is deterministic sub-second finality, and we do not publish throughput figures. And this page describes what the chain can do and how we would engage alongside you: it is not a deployed retail product, and we do not offer card programs, banking, or custody as our product. We would rather you learn the limits from us than from a hostile reader. Ways to work with us The path for regulated issuers is the quantum-safe tokenization pilot , described alongside our other engagements on the regulated finance page: your asset, tokenized, with post-quantum evidence in the block record, not only at the application layer. It starts the way every engagement with us starts, with verification instead of slides. Your team runs the public toolkit against the live chain, checks our claims yourself, and receives a reproducible conformance report of the kind you can generate with the same tools. Then, and only then, we map your asset and its document trail onto the ledger together. Builders can start on the developer hub today. Verify the record yourself curl -O https://aere.network/tools/verify-anchor.mjs -O https://aere.network/tools/falcon512.mjs -O https://aere.network/tools/package.json && npm install node verify-anchor.mjs # recomputes the post-quantum binding digest of recent # anchor blocks from raw bytes, independently of us. # the full toolkit, 35 checks against the public chain: # precompiles vs NIST vectors, block interval, validator set. curl -O https://aere.network/tools/verifica-lantul.tar.gz tar -xzf verifica-lantul.tar.gz && cd verifica-lantul node verifica.mjs Write to us: [email protected] Next up Quantum-safe settlement, in depth The Aere glossary Post Quantum Anchor Seal Certificate QBFT Finality Falcon 512 Precompile About About Aere Foundation Roadmap Press & Newsroom Brand Kit Editorial Standards Build Developer Hub Documentation RPC Reference SDK Add Network Faucet Academy Grants Network Architecture Post-Quantum Stack Validators Run a Validator Network Status Audits Security Decentralization Solutions Payments DeFi Real-World Assets Infrastructure Gaming NFTs & Culture Explore Explorer Blocks Transactions Tokens Research & Papers Glossary Blog Legal Terms & Privacy Sanctions Compliance Aere Network. Chain ID 2800. Every claim on this site is checkable: rpc.aere.network --- # AERE Developer Docs, RPC, SDK, integration URL: https://aere.network/rpc-docs.html Fetched: 2026-09-15 AERE Developer Docs, RPC, SDK, integration Developer docs Build on AERE, EVM-compatible Layer 1, chain ID 2800, 0.5-second blocks, QBFT consensus. Quick reference Public RPC https://rpc.aere.network copy https://rpc2.aere.network copy WebSocket wss://wss.aere.network copy Chain ID 2800 (0xAF0) Native token AERE (18 decimals) Explorer explorer.aere.network Indexer API api.aere.network Add to MetaMask Click the button below or visit aere.network/addnetwork : Add AERE Network to wallet Public RPC endpoints Two independent public RPC endpoints are available for redundancy, hosted in separate datacenters. Both are open and rate-limited per IP, and both serve the same chain. Point your client at either, or list both in your wallet for automatic failover if one is unreachable. Endpoint Auth Rate limit rpc.aere.network none per-IP rpc2.aere.network none per-IP What these endpoints serve, and what they do not Both public endpoints are pruning full nodes , not archive nodes. That distinction changes what you can ask them, so it is written down here rather than left for you to discover. Every number in this section was re-measured against both endpoints on 2026-08-02 : 511 blocks deep answers, 512 does not, on rpc.aere.network and on rpc2.aere.network . The command that measured it is in the SDK and you can run it yourself, below. An archive node that does not have this limit exists and is being prepared for exposure. History that is always available Blocks, transactions, receipts, logs and the validator set go back to block 0 . Anything derived from a block body or a receipt is available at any depth: eth_getBlockByNumber , eth_getBlockByHash , eth_getTransactionByHash , eth_getTransactionReceipt , eth_getBlockReceipts , eth_getLogs , qbft_getValidatorsByBlockNumber . World state: a rolling window of about 512 blocks Account and contract state is retained for roughly the most recent 512 blocks , which at the measured 566 ms block interval (re-measured 2026-09-02) is about 4 minutes 25 seconds of chain. Beyond that the state has been pruned and the node cannot answer. This applies to eth_getBalance , eth_getCode , eth_getStorageAt , eth_call , eth_getProof and eth_getTransactionCount . The window is an operational fact of a pruning node, and it is a real edge rather than a fixed fence: the chain head advances while your request is in flight, so a block that was 511 deep when you looked it up can be 512 deep by the time the node reads it. Leave yourself a margin of a few blocks, or simply read at latest . The one behaviour you must code around Outside the window, most methods say so plainly. eth_getBalance , eth_getCode and eth_getStorageAt return null ; eth_getProof returns error -32000 World state unavailable ; eth_call returns an error. eth_getTransactionCount does not. Outside the window it returns 0x0 , which is a well formed value and is indistinguishable from an account that has never sent a transaction. If your code reads a nonce at a historical block and trusts the answer, it will silently conclude that an active account has never signed anything. This is the single most important thing to know about these endpoints, so here it is with a reproducible example you can run right now: # Block 8,236,382 contains a transaction from this address with nonce 123,063. # Read it straight out of the block body, which is available at any depth: curl -s https://rpc.aere.network -H 'content-type: application/json' \ -d '{"jsonrpc":"2.0","id":1,"method":"eth_getTransactionByHash","params": ["0xbfd3620dc705cc1dbf5bf747c02f71f0d4f68227ab8b5ccafe3de15955587ce3"]}' # -> "from":"0xbeb33d20dfbbd49ec7ac1f617667f1f02dfd6465", "nonce":"0x1e0b7" (123,063) # Now ask for that same account's nonce AT that block. The state is long gone: curl -s https://rpc.aere.network -H 'content-type: application/json' \ -d '{"jsonrpc":"2.0","id":1,"method":"eth_getTransactionCount","params": ["0xbeb33d20dfbbd49ec7ac1f617667f1f02dfd6465","0x7dad5e"]}' # -> "result":"0x0" WRONG. The correct answer is "unavailable", not zero. # eth_getBalance, at the same address and the same block, is honest about it: # -> "result":null Three rules follow, and they are cheap to apply: Read state at latest or pending . Wallets, nonce management and balance display need nothing else, and at latest every method here is correct. If you must pin a historical block, check the depth first , and treat anything outside the window as unavailable rather than as a value. Do not default a missing read to 0 . Never test a nonce for zero on a historical block. If you need to prove an account has never transacted, ask at latest , or scan block bodies, which are retained forever. The @aere/sdk ships StateWindowReader , which applies all three for you. It returns a value or throws; it never returns a placeholder. import { StateWindowReader, StateWindowError } from "@aere/sdk" ; const reader = new StateWindowReader((m, p) => provider.send(m, p)); await reader.getTransactionCount(addr); // latest: fine await reader.getTransactionCount(addr, 8236382 ); // throws StateWindowError, never returns 0 // Do not trust the number above, measure it yourself against the endpoint: await reader.measureWindow(); // { head, deepestOkDepth: 511, firstFailDepth: 512 } The SDK also ships the proof itself, so you do not have to take the paragraph above on faith. It reads the true nonce out of a block body, shows the raw call returning the false zero, shows the guard turned off handing that zero to a caller, then shows the guard turned on refusing. It exits non-zero if any of that stops being true: node dist/test/state-window-live.js https://rpc.aere.network ANCHOR block 8236382 body says 0xbeb33d20… signed with nonce 123063 STEP 1 PLANTED FAILURE eth_getTransactionCount returns a false zero -> "0x0" STEP 2 NEGATIVE CONTROL guard disabled, getTransactionCount answered 0 STEP 3 THE GUARD StateWindowError requested-block-outside-window STEP 4 MEASURE 511 answers, 512 refused RESULT: PASS Which calls work at any depth, and which do not This table is measured against both endpoints, not copied from a Besu manual. Everything in the green half reads from a block body, a receipt or the header chain, all of which are kept from block 0. Everything in the red half reads the world-state trie, which is pruned. Method At any depth Outside the 512-block window it returns eth_getBlockByNumber yes the block eth_getBlockByHash yes the block eth_getTransactionByHash yes the transaction, including its real nonce eth_getTransactionReceipt yes the receipt eth_getBlockReceipts yes every receipt in the block eth_getLogs yes the logs, within a 5,000-block span qbft_getValidatorsByBlockNumber yes the validator set at that height eth_getBalance no result: null eth_getCode no result: null eth_getStorageAt no result: null eth_getProof no -32000 World state unavailable eth_call no -32603 Internal error eth_getTransactionCount no "0x0" , and that is the false answer described above The nonce row is the only one where the endpoint returns a value it does not have. Every other pruned read either says null or raises an error. If you take one thing from this page, take that row. Namespaces and limits, as actually served Item rpc.aere.network rpc2.aere.network ETH, NET, WEB3, QBFT enabled enabled txpool_* enabled not enabled, -32604 debug_*, trace_*, admin_*, miner_* not exposed not exposed eth_getLogs at most 5,000 blocks between fromBlock and toBlock , otherwise -32005 . A span of exactly 5,000 is accepted; 5,001 is refused. World state depth 512 blocks, roughly 4m25s Tracing is switched off, and here is what that costs you The debug_ and trace_ namespaces are not exposed on either public endpoint. That is a deliberate choice, and it has a real price for you. Stating the choice without stating the price would be dishonest, so both are here. Why A single debug_traceBlockByNumber re-executes every transaction in a block with an instrumented EVM and can allocate hundreds of megabytes for one response. On an open, unauthenticated endpoint that is a denial of service anyone can trigger from a laptop, and these two endpoints also carry wallets, the explorer and every integration on the network. Half a second of block time leaves no slack to absorb it. admin_ and miner_ are off for the more obvious reason: they mutate a node the public does not own. The cost, stated plainly You cannot get an opcode-level or call-level trace of a historical transaction from these endpoints. You cannot reconstruct internal calls or value transfers that left no log. You cannot dump a contract's storage range. A post-mortem on a failed transaction is harder here than on a chain that exposes tracing publicly. There is one more cost, and it is the subtle one. The error you get back does not tell you the namespace was switched off. Measured on both endpoints: You call You get JSON-RPC id debug_traceTransaction -32601 Method not found null trace_block -32601 Method not found null admin_peers -32601 Method not found null eth_totallyMadeUpMethod -32601 Method not found echoed txpool_besuStatistics on rpc2 -32604 Method not enabled echoed -32604 Method not enabled is what a node says when it has a method and has chosen not to serve it. That is the honest code, and rpc2 uses it for txpool_ . The debug_ and trace_ methods do not get that code; they get -32601 Method not found , the same code an invented method gets, which reads as if the method never existed. So: a -32601 on a debug_ or trace_ call is a policy decision, not a statement about the chain. The data those methods would read is present on the network. It is simply not offered here. What you get instead These are on the public endpoints today, measured, and they cover most of what people actually reach for tracing to do. Instead of Use What it gives you debug_traceCall eth_simulateV1 Many calls in one simulated block, each with its own status, gasUsed, logs and decoded revert reason. traceTransfers: true emits a synthetic Transfer log for plain value movement, at pseudo-address 0xeee…eee , so internal transfers stop being invisible. debug_traceCall with overrides eth_simulateV1 + stateOverrides Rewrite balances, nonces, code or individual storage slots for the simulation only, then run the call against that world. This is the closest public substitute for a full tracing session. debug_traceCall eth_call The full revert reason, not just a failure flag. See below. debug_storageRangeAt eth_createAccessList Exactly which accounts and storage slots a call touches, plus its gas. debug_traceBlock eth_getBlockReceipts Status, gas and every log for every transaction in the block, at any depth. a trusted state read eth_getProof A Merkle proof against the state root at latest , which you can verify yourself instead of trusting us. A revert on this chain comes back decoded, which is the single most common reason to want a trace: curl -s https://rpc.aere.network -H 'content-type: application/json' \ -d '{"jsonrpc":"2.0","id":1,"method":"eth_call","params": [{"from":"0x0000000000000000000000000000000000000001", "to":"0x7e84d7d66d5da4cfE46Da67CDEeB05B323e1f5e8", "data":"0x23b872dd…"},"latest"]}' {"error":{"code":3, "message":"Execution reverted (WAERE: insufficient balance)", "data":"0x08c379a0…"}} # The message carries the Solidity revert string, and data is the ABI-encoded # Error(string) so you can decode custom errors yourself. And if you genuinely need opcode-level tracing, take it. The chain is not the obstacle, the shared endpoint is: # genesis.json and the chain spec are public. Run a node, enable everything, # and trace against your own hardware instead of ours. besu --network-id=2800 --genesis-file=genesis.json \ --data-storage-format=BONSAI \ --rpc-http-enabled --rpc-http-api=ETH,NET,WEB3,QBFT,DEBUG,TRACE,TXPOOL # For historical state as well, add: --sync-mode=FULL --data-storage-format=FOREST The archive node An archive node for chain 2800 exists and is fully synced . It holds world state at every height from block 0, and it answers debug_ and trace_ . It is not yet reachable from the public internet, and this section says exactly where it stands rather than promising a date we have not earned. Measured 2026-08-02 Full sync from block 0, eth_syncing false, head tracking the public endpoints in the same second. A verifier walks 20 sampled heights spanning block 1 to block 11,000,000, asks each for eth_getBalance , eth_getCode and eth_getStorageAt , and carries every answer back to a state root that both public endpoints independently confirm. 20 of 20 heights judged, 0 failures, 0 unproven answers. Pointed at a public pruning endpoint, the same verifier reports 81 failures and exits non-zero, which is how we know the check is capable of failing. At block 8,236,382 the archive answers nonce 123,064 , matching what the block body proves; the public endpoints answer 0x0 . What is left is exposure, not construction: a public listener, a TLS certificate and a rate limit in front of a node that already has the data. We are not publishing a launch date, because the work that remains is a decision rather than an engineering task, and a date we invent is worth nothing to you. What we will commit to is that this section gets updated the day it changes, and that the endpoint will not be announced until the same verifier passes against it from outside our network. If historical state or tracing is blocking you now, say so at git.aere.network and we will prioritise accordingly. In the meantime the two public endpoints are deliberately tuned to stay fast for the common case, and running your own node with --sync-mode=FULL gives you the same history on your own hardware. SDK quickstart JavaScript / TypeScript (@aere/sdk) // not yet on public npm, install from the public source: npm install git+https://git.aere.network/aere-network/sdk-js.git ethers import { AereClient } from "@aere/sdk" ; const aere = new AereClient({ rpc: "https://rpc.aere.network" }); // Read state const portfolio = await aere.getPortfolio( "0x0243A4f47D44b40b65D33f20329dE20D00c6f3C3" ); console .log(portfolio); // Watch incoming transfers aere.watchTransfersTo(myAddr, (event) => { console .log( "got" , event.value, "AERE from" , event.from); }); Plain ethers v6 import { JsonRpcProvider, Contract, parseEther } from "ethers" ; const provider = new JsonRpcProvider( "https://rpc.aere.network" ); const blockNum = await provider.getBlockNumber(); // Read an ERC-20 (WAERE) const waere = new Contract( "0x7e84d7d66d5da4cfE46Da67CDEeB05B323e1f5e8" , [ "function totalSupply() view returns (uint256)" ], provider ); const sup = await waere.totalSupply(); Python (web3.py) from web3 import Web3 w3 = Web3(Web3.HTTPProvider( "https://rpc.aere.network" )) print ( "chain id:" , w3.eth.chain_id) # 2800 print ( "latest:" , w3.eth.block_number) Indexer REST API Hosted at https://api.aere.network . CORS open. Read-only. Path Description GET /api/stats Latest indexed block + total tx count GET /api/blocks Recent blocks (limit/offset) GET /api/block/:id Block by number or hash + tx list GET /api/transactions Recent transactions GET /api/tx/:hash Single tx + receipt GET /api/address/:addr Recent activity for address GET /api/token/:addr/holders ERC-20 holders + balances GET /api/token/:addr/transfers Recent Transfer events GET /api/token/:addr/stats Total transfer count GET /api/mempool Pending-tx snapshot (last 5 min) GET /api/mempool/stream Server-Sent Events feed of new pending tx Contracts Production contract addresses are bundled in @aere/sdk . The full list, with read methods, is on the dApp dashboard . Source code All AERE Network code is hosted at git.aere.network (self-hosted Gitea, GitHub mirror is rate-limited): aere-contracts , Solidity contracts for chain 2800, each deployed address checkable on-chain aere-research , post-quantum vectors, known-answer tests, formal models, benchmark harness aere-docs , protocol specifications and reproduction instructions sdk-js , @aere/sdk JS/TS client Neobank reference backend , Express reference for BaaS / fintech integrations Revision rpc-docs-v2-2026-08-02. Every endpoint behaviour on this page was measured against rpc.aere.network and rpc2.aere.network on 2026-08-02, not taken from a client manual. A dated copy of this revision is kept at rpc-docs-v2-2026-08-02.html and is not edited again, so that anything you quote from it stays quotable. Previous revision: 2026-07-20. --- # Enterprise RPC | Aere Network URL: https://aere.network/rpc.html Fetched: 2026-09-15 Enterprise RPC | Aere Network Aere Network Aere Cloud Docs Status Aere Cloud · JSON-RPC & WebSocket RPC that scales with your traffic. Live HTTP & WebSocket Per-plan limits Archive Endpoint cloud.aere.network/v1/rpc WebSocket wss (keyed) Chain 2800 A dedicated JSON-RPC endpoint on chain 2800, sized to your traffic instead of shared with the world. Full eth/net/web3 namespaces plus read-only QBFT, keyed and metered against your on-chain subscription, with a WebSocket feed pushing a new head roughly every half second. What you get Full JSON-RPC: eth_* , net_* , web3_* , plus read-only QBFT methods. Vote-writing methods are refused on every tier. WebSocket subscriptions ( eth_subscribe ) for new heads and logs, keyed with the same API key. Rate limits by plan: 150 req/s on Build, 500 on Scale; a free trial key at 25 req/s. Archive access and full historical state, subject to the 512-block state window on shared reads. One call, one key curl -s https://cloud.aere.network/v1/rpc \\ -H "x-api-key: ak2800.." -H "content-type: application/json" \\ -d '{"jsonrpc":"2.0","id":1,"method":"eth_blockNumber","params":[]}' → {"jsonrpc":"2.0","id":1,"result":"0x…"} Verified against the chain, not a password Your key’s hash lives in an on-chain subscription contract; the gateway checks every request against it and fails closed if the chain cannot be reached. There is no server-side account table to breach. The official SDK wraps every method, or use any Ethereum tooling that speaks JSON-RPC. Get an API key Read the docs Part of Aere Cloud . Live status you compute in your own browser: /cloud-status.html . © 2026 Aere Network · chain 2800 · Aere Cloud --- # Independent Validator Program | Aere Network URL: https://aere.network/run-a-validator-program.html Fetched: 2026-09-15 Independent Validator Program | Aere Network Decentralization Independent Validator Program Published 2026-08-15 Set today: 9 validators, all Foundation-operated Target: 9 to 21, with independent operators Aere states plainly on every page that it is not yet decentralized: all ten validators are operated by the Foundation, so the honest answer to "how many independent parties must agree to stop this chain" is one. This page is how that changes, and what it takes to hold a seat. Why this is the most important page on this site Aere has properties few public chains have: hybrid post-quantum consensus that refuses to finalize an anchor block without at least three valid Falcon-512 validator seals, a certificate of those seals bound under the block hash every 128 blocks (every 32 until block 17,225,968, on 2026-09-05), enforced since 2026-08-14 (raised at block 14,961,456, August 21, 2026, to six seals, which was then a full 2f+1 quorum of nine; ten validators since 2026-09-11, so six is above f+1 and below the quorum of seven); two independently implemented clients that agree, both readable from public endpoints. None of that fixes operator concentration. A chain with excellent cryptography and one operator is a well-built database, and we would rather write that sentence ourselves than have it written about us. What an operator runs Requirement Bar Client Either implementation. Running the second client (the Nethermind-derived one) is preferred and counts toward diversity, because a set where every node runs the same code has one bug away from a halt. Machine 8 cores, 16 GB RAM, NVMe with headroom for the header growth published in our disk figures. Bare metal or dedicated instance, not shared burstable. Network Static public address, devp2p reachable, 100 Mbit symmetric or better, under 150 ms to at least four existing validators. Independence Different operator entity, different hosting provider and different country from any existing seat. Two seats behind the same provider do not count as two operators, and we will not pretend otherwise. Keys Two: the classical secp256k1 node key and a Falcon-512 key, generated by you, on your machine. The Foundation never sees either private key. Your public Falcon key is published in the signer registry, which is anchored on chain. Availability 99.5 percent monthly, measured by the chain rather than by self-report: your address either appears among block committers or it does not. Upgrades Apply coordinated activations within the published window. Activation heights are announced with the runbook, and the network has a documented coordinated-postponement path if an operator cannot make a window. How a seat is granted, and how it is lost Admission is a validator-set vote under QBFT, executed at a block height announced in advance. Before the vote, a candidate runs as a non-validating follower for at least fourteen days, and the follower's agreement with the chain is measured, not asserted: same block hashes at every height checked. Removal uses the same mechanism, and the published grounds are narrow and mechanical, not editorial: sustained unavailability below the bar, refusal to apply a coordinated activation, or signing conflicting messages at the same height. There is no stake to post and no on-chain slashing today, and we say that rather than implying an economic guarantee that does not exist. What binds an operator is a published agreement and the fact that the seat is visible: every committer address is readable from any endpoint, by anyone, forever. What you get A seat on a chain whose consensus is post-quantum, before that becomes a requirement rather than a differentiator. Your organisation named in the public signer registry, anchored on chain, as one of the parties that must agree for the network to move. Direct access to the engineering that runs it, not a support queue. What you do not get, stated in the same breath: there is no payment for holding a seat today, no token grant attached to this program, and no completed third-party security audit of the live system yet. One is on the roadmap and its results will be published in full whatever they say. Check us before you talk to us # the chain's post-quantum anchor, verified from raw header bytes curl -O https://aere.network/tools/verify-anchor.mjs node verify-anchor.mjs # the full independent toolkit: 35 checks, installs nothing, # and starts with a self-test that plants 21 defects and must catch all of them curl -O https://aere.network/tools/verifica-lantul.tar.gz tar -xzf verifica-lantul.tar.gz && cd verifica-lantul node autotest.mjs && node verifica.mjs The honest state of this program. As of publication it has zero independent operators. It is published now, before there is anyone to announce, because a decentralization path that exists only in a roadmap slide is not a path. The first seats will be granted to operators who can run the second client, since client diversity and operator diversity are two different fragilities and this network currently has both. Apply for a seat: [email protected] About About Aere Foundation Roadmap Press & Newsroom Brand Kit Editorial Standards Build Developer Hub Documentation RPC Reference SDK Add Network Faucet Academy Grants Network Architecture Post-Quantum Stack Validators Run a Validator Network Status Audits Security Decentralization Solutions Payments DeFi Real-World Assets Infrastructure Gaming NFTs & Culture Explore Explorer Blocks Transactions Tokens Research & Papers Glossary Blog Legal Terms & Privacy Sanctions Compliance Aere Network. Chain ID 2800. Every claim on this site is checkable: rpc.aere.network --- # @aere/sdk, Official AERE Network SDK URL: https://aere.network/sdk.html Fetched: 2026-09-15 @aere/sdk, Official AERE Network SDK @aere/sdk The official TypeScript client wrapping every deployed AERE Network contract, built on ethers v6, MIT licensed. It is the only published AERE SDK today; the Rust, Python and Go clients described below are not yet published. Source at git.aere.network/aere-network/sdk-js . Languages 4 TS, Rust, Py, Go Peer dep ethers ^6.13.0 (TS) PQC signing live ML-DSA, SLH-DSA License MIT What this SDK is: a thin, fully-typed layer over ethers v6 with the deployed mainnet addresses, ABIs, and ergonomic helpers for every protocol, staking, lending, stablecoin, swap, identity, bridge, Lightning, ZK rollup, faucet. What it is NOT: a wallet or a custodial platform. It signs only with keys you provide. Four official SDKs AERE publishes one client library today (TypeScript, sdk-js) and has three more (Rust, Python, Go) not yet published. All four are designed to speak the chain's JSON-RPC and contract ABIs. They differ in how much of the post-quantum signing path each language can offer today, and we state that honestly rather than implying parity. TypeScript full The reference client, documented on this page. Wraps every deployed contract on ethers v6, with signing and verification helpers. full contract API coverage read + write via ethers v6 signing / verification helpers Rust full Full parity for backend and infrastructure use, including the post-quantum signing path. full contract API coverage envelope + JSON-RPC client PQC keygen / sign / verify Python pqc Contract client plus a real post-quantum signing path, keygen, sign, and verify for ML-DSA-44 and SLH-DSA-128s, live-proven on chain 2800. envelope + JSON-RPC client ML-DSA-44 keygen / sign / verify SLH-DSA-128s keygen / sign / verify Falcon signing not offered Go client Envelope, JSON-RPC client, and key generation. PQC signing is deferred because Go's standard post-quantum library does not expose the FIPS internal signer. envelope + JSON-RPC client key generation PQC signing deferred Falcon signing not offered Honest capability note: Falcon signing is not offered in the Python or Go SDKs, because no maintained library in either language emits the Bouncy-Castle-compatible compressed Falcon signature body that AERE's on-chain verifier expects. There is no Java SDK. Install The package is not yet on public npm. Install it straight from the source repository on git.aere.network: $ npm install git+https://git.aere.network/aere-network/sdk-js.git ethers $ yarn add git+https://git.aere.network/aere-network/sdk-js.git ethers $ pnpm add git+https://git.aere.network/aere-network/sdk-js.git ethers Or use ethers directly with the addresses + ABIs from addresses.ts if you don't want the wrapper. Quickstart Live playground Module reference Recipes Addresses Read-only client (no signer) import { AereClient } from '@aere/sdk' ; const aere = new AereClient(); // defaults to https://rpc.aere.network const head = await aere.getBlockNumber(); const bal = await aere.getNativeBalance( '0x0243A4f47D44b40b65D33f20329dE20D00c6f3C3' ); const validators = await aere.getValidators(); console .log( 'head:' , head, 'foundation:' , bal, 'validators:' , validators.length); With a signer (sends transactions) import { AereClient } from '@aere/sdk' ; import { parseEther } from 'ethers' ; const aere = new AereClient({ privateKey: process .env.PK }); // Lock 100 AERE for 30 days. Tier 0 is 10% APY on-chain, but the // AereLockedStaking reward pool is UNFUNDED (balance 0), so no yield // is payable today and maturity returns principal only. const tx = await aere.staking.lockTier30(parseEther( '100' )); await tx.wait(); // Write KYC attestation on-chain (attestor-only) const oneYear = Math.floor(Date.now() / 1000) + 365 * 86400; await aere.identity.addClaim(userAddr, 'kyc-tier-1' , reportHash, oneYear); Browser wallet (MetaMask) import { BrowserProvider } from 'ethers' ; import { AereClient } from '@aere/sdk' ; const provider = new BrowserProvider(window.ethereum); await provider.send( 'eth_requestAccounts' , []); const signer = await provider.getSigner(); const aere = new AereClient({ signer }); const tx = await aere.staking.lockTier90(parseEther( '500' )); Pick an example and click Run . Code executes against https://rpc.aere.network from your browser using ethers v6 (the same calls the SDK wraps). Edit freely, output shows below. Example getBlockNumber + chainId getNativeBalance(addr) getValidators (QBFT set) WAERE.totalSupply + balanceOf Staking tier APYs + lock count AereOracle.getPrice + reporters AereIdentity.isAttestor check Genesis wallet balances Watch incoming tx (60s) Code (editable) ▶ Run Output Click Run to execute. Sandbox: code runs in your browser tab via new Function against an injected ethers namespace. No keys are sent anywhere. Switch examples to repopulate the editor. Each handle is a typed wrapper around an ethers Contract . Use .contract to access the underlying ethers instance for advanced operations. aere.waere Wrapped native AERE (ERC-20). Wrap/unwrap AERE for DEX use. 0x7e84d7d66d5da4cfE46Da67CDEeB05B323e1f5e8 balanceOf(addr) deposit(amountWei) withdraw(amountWei) transfer(to, amount) aere.staking Liquidity-lock staking (AereLockedStaking). 4 tiers: 30/90/180/365 days at 10/15/22/30% APY on-chain. The reward pool is unfunded (balance 0), so no yield can be paid today and a lock returns principal only. 0x21108c28A849b05aE6b7a3a5bc435C9Bc897E7Ad lock(tier, {value}) lockTier30 / 90 / 180 / 365 withdraw(lockId), earlyExit(lockId) getLocks(user) pendingRewards(user, lockId) aere.swap V2-style AMM with router. Add/remove liquidity, swap tokens. router 0x7526B2E5526EfA84018378b60F2844Dad77523D8 addLiquidityAERE(token, amt, …) swapExactAEREForTokens(min, path, …) swapExactTokensForAERE(amt, min, path, …) getPair(t0, t1), reservesOf(pair) aere.identity DID / KYC attestation registry. Off-chain claim hashes pinned on-chain. 0x658dD2CD1F798AAb19fEc8FF69A270B2d192CaD1 addClaim(subject, type, hash, expires) getClaim(claimId) hasValidClaim(subject, type) aere.bridge Federated 2-of-N cross-chain bridge. 0x7eDa66cd93baAE19530839Bbb28ee36aC8aFAd68 lock(targetChain, recipient, amount) unlock(srcChain, srcTx, amount, sigs) threshold(), guardians() aere.faucet Not funded, balance 0. The contract is deployed and callable, but every claim reverts. There is currently no public way to obtain AERE. 0xDdBe942aD9eB0F3E7C541BdCF7CC2cfA29d35aE4 drip() dripAmount() / cooldown() aere.oracle Multi-reporter median price feed (8 decimals). The V1 address below is deprecated : it could serve a median controlled by a single fresh reporter. Write new code against AereOracleV2 0xca69AA961D836516010Ae669a223Ce249490ACb1 , same signatures. Measured 2026-08-01, neither serves a price yet: V1 has 1 registered reporter and V2 requires 3 fresh. 0xf0A13823A4bFa86358Fe30aaf1f44A36AcbCf399 getPrice(symbol) submit(symbol, price), reporters only reporterCount(), symbolCount() Watch incoming AERE transfers (event stream) Subscribe to native and ERC-20 transfers to a given address, useful for deposit detection in fintech and neobank integrations. const aere = new AereClient(); await aere.watchTransfersTo( '0xUser…' , (event) => { console .log( 'incoming' , event.amount, 'from' , event.from, 'tx' , event.txHash); }); Build a portfolio summary Aggregate all balances + active locks for an address in one call. const p = await aere.getPortfolio( '0xUser…' ); // { // nativeAere: bigint, // waere: bigint, // aereUSD: bigint, // stakingLocks: [...], // lending: { supplied, borrowed, ltv }, // identity: { hasKYC, claims: [...] } // } Reporter cron, submit oracle price import { encodeBytes32String, parseUnits } from 'ethers' ; const aere = new AereClient({ privateKey: process .env.REPORTER_KEY }); setInterval( async () => { const price = await fetchExternalPrice(); // your data source const tx = await aere.oracle.submit( encodeBytes32String( 'AERE/USD' ), parseUnits(price.toString(), 8) ); console .log( 'submitted' , tx.hash); }, 60_000); All mainnet addresses bundled in AERE_MAINNET from @aere/sdk/addresses . Chain ID 2800 . --- # Search · AERE Block Explorer URL: https://aere.network/search.html Fetched: 2026-09-15 Search · AERE Block Explorer Chain ID 2800 · AERE Mainnet Search the chain. Paste a block number, transaction hash, or address, we'll take you straight to it. Look up → Number Block number , e.g. 4288396 opens that block's contents. 0x · 66 chars Transaction hash , opens the transaction detail, status, and receipt. 0x · 42 chars Address or contract , opens balance, nonce, and history. --- # Security, AERE Network URL: https://aere.network/security.html Fetched: 2026-09-15 Security, AERE Network Security AERE Network's security posture, consensus guarantees, on-chain safeguards, infrastructure hardening, and how to report a vulnerability. Security at AERE Network is built in layers: Byzantine-fault-tolerant consensus at the protocol level, an on-chain security contract for real-time monitoring, hardened infrastructure with runtime intrusion detection, and a responsible disclosure program open to the research community. Consensus security Consensus Hyperledger Besu, QBFT AERE Network runs Hyperledger Besu with the QBFT (Quorum Byzantine Fault Tolerant) consensus algorithm. QBFT provides: Instant finality. A block is final the moment it is included. There are no probabilistic confirmations, no reorg risk, and no need to wait for multiple block confirmations before treating a transaction as settled. Byzantine fault tolerance. The network tolerates up to ⌊(n−1)/3⌋ faulty or malicious validators without compromising safety or liveness, where n is the total validator count. Finality No reorgs by design Unlike proof-of-work chains where the "longest chain" rule allows forks and reorgs, QBFT validators reach explicit agreement before a block is committed. A transaction confirmed in a block cannot be reversed by a competing chain tip. This makes AERE Network suitable for applications that need strong settlement guarantees, payments, on-chain records, cross-chain bridges, without requiring downstream wait periods. On-chain security contract AereSecurity 0xaD305e4D91e0a9160Bd338Fd1ecb2Ee1645daC44 The AereSecurity contract at 0xaD305e…daC44 provides on-chain runtime monitoring capabilities for the AERE Network ecosystem. It can be queried by other contracts or off-chain systems for real-time network health signals. All interactions with this contract are publicly visible on the AERE Explorer . Infrastructure security Runtime Falco runtime monitoring All validator and infrastructure nodes run Falco , an open-source runtime security tool that detects anomalous system calls, unexpected process execution, and container escape attempts in real time. Alerts are routed to the operations team with automated escalation paths. Images Container image scanning Every container image used in the validator and API infrastructure is scanned for known CVEs before deployment. Images are pinned to specific digests, not floating tags, so deployments are reproducible and cannot silently pull updated, potentially compromised images. Backups 3-2-1 immutable backups Chain data and configuration follow a 3-2-1 backup strategy: 3 copies, across 2 different storage types, with 1 copy stored off-site. Backup destinations use immutable (WORM) storage where supported, preventing backup tampering or ransomware deletion. Isolation Isolated validator infrastructure Validator nodes are isolated from public-facing API infrastructure at the network level. Validator RPC endpoints are not exposed to the internet. Peer-to-peer consensus traffic is restricted to known validator IPs via firewall allowlists, minimising the attack surface for eclipse and DDoS attacks. Audit roadmap Honest status: Formal third-party smart-contract audits by external security firms are planned and on the AERE Network roadmap. No external audits have been completed to date. We will publish audit reports in full when they are available, we will not claim an audit that has not occurred. Internal security review , Core contracts reviewed adversarially by hand and backed by machine-checked formal (z3 SMT) proofs of the key solvency and no-theft invariants, 120-plus proved properties across the contract set, each with counterexample controls. A repo-wide sweep confirms the set contains no selfdestruct, no delegatecall, no upgrade proxy, and no admin-withdrawal path, which is the concrete, checkable meaning of the no-rug property. This is internal review plus formal verification of the contract logic, not a substitute for the external audit below; issues found this way (including a threshold-committee duplicate-key bug) were fixed and redeployed. Runtime monitoring deployed , Falco, image scanning, and backup hardening in place on all production infrastructure. External smart-contract audit (planned) , Formal audit of core contracts (AereSecurity, AereOracle, DAO, token) by an independent security firm. Scope and firm to be announced. Report will be published in full. Bug bounty program (deployed on-chain, reward pool not yet funded) , AereBugBountyVault is deployed on-chain at 0x253fDCb248649396CBDaD320F81869A570d69cD3 (permissionless claim, Foundation triage, 5% maximum single payout in WAERE). The reward pool is not yet funded, so no payouts can be made yet; the Foundation will fund it and formally open the program around the first external audit. Honest status, in plain terms These are the honest answers to the questions people most often get wrong about AERE. Each one is scope-labeled and verifiable on chain 2800. A machine-readable claim to evidence map lives at /claim-evidence.json , and you can replay the post-quantum checks yourself at /quantum.html . Does AERE use post-quantum consensus? Yes, in a hybrid and limited form since 2026-08-14: every 128th block (every 32nd block until block 17,225,968, on 2026-09-05) (an anchor block) does not finalize without a certificate of at least three valid Falcon-512 validator seals (f+1 of the nine validators of that time) (raised at block 14,961,456, August 21, 2026, to six seals, then a full 2f+1 quorum of nine; since the set grew to ten on 2026-09-11 the enforced minimum is still six, above f+1 but below the ten-validator quorum of seven) under its hash, with classical secp256k1 ECDSA finalizing every block under Hyperledger Besu QBFT (corrected 2026-08-19: not a per-block quorum). Post-quantum cryptography also lives at the account and application layer: five NIST post-quantum precompiles (Falcon-512, Falcon-1024, ML-DSA-44, SLH-DSA-128s, and SHAKE256) have run on-chain since block 9,189,161, so any contract or account can require a quantum-resistant signature. An external audit of the hybrid consensus layer is still ahead. Is the 273,000 TPS figure a measured mainnet number? No, and it has been withdrawn (2026-09-05): it was a design ceiling implied by the block parameters under ideal conditions, never a measurement of chain 2800, and its stated derivation does not reach that number. What the live network delivers today is 0.5-second deterministic finality and sub-cent fees; measured throughput is published with its date and method on the benchmarks page at https://aere.network/benchmarks.html. How decentralized is AERE today? The validator set is ten Foundation-operated nodes (since 2026-09-11), tolerating three faulty nodes at a quorum of seven of ten. The network is not yet decentralized. The published path admits independent operators and grows the set from nine toward twenty-one. The live network runs one production client, Hyperledger Besu; a patched second client is complete on an isolated testnet but is not in the live validator set. Have the smart contracts been audited by a third party? Not yet. The published proofs and conformance tests are the project's own internal work, offered for anyone to re-run: an internal adversarial review, machine-checked SMT proofs of the solvency and no-theft invariants, and a Slither static-analysis report. An external firm engagement or public contest is planned. Treat the contracts accordingly until a named third-party audit is published. Are the post-quantum precompiles really live, and can I check without a wallet? Yes. They have been active on chain 2800 since the fork activationTime 1783820272 (2026-07-12) at the reserved band 0x0AE1 to 0x0AE5, and you can verify them with read-only calls that need no wallet and no gas. Call eth_config and the node itself returns that activation time and the live precompile list. Block 9,189,161 is the first block at or after that timestamp; it contains no transactions, because a fork activation is a configuration change and not a transaction, so do not expect to find anything by opening that block. To prove the precompiles are executing right now, measure gas: a live precompile consumes gas and an address with nothing at it consumes none. For example, the SHAKE256 precompile at 0x0AE5 returns the exact NIST Known-Answer-Test digest for the empty message. The quantum page at https://aere.network/quantum.html replays the full KAT and ACVP vector set live in your browser. Can I get AERE today? There is no public way to obtain AERE right now. There is no public sale and no exchange listing, and the faucet holds a zero balance, so every claim reverts. A new address can add the network and make read-only calls, but it cannot yet send a transaction that needs gas. Is the outbound light client trustless or quantum-safe? Neither. It is trust-minimized: its security reduces to a 2f+1 quorum of Foundation-operated validators being honest (six of nine at its deployment; since the validator set grew to ten on 2026-09-11 it verifies only blocks sealed by that earlier set until it is re-anchored), which is an operator assumption rather than an economic one. The seals are classical secp256k1 ECDSA and the proof wrap is classical BN254 Groth16, so it is not quantum-safe. It is an interop-layer component and does not change or gate consensus. Responsible disclosure Report a vulnerability If you discover a security vulnerability in the AERE Network protocol, smart contracts, infrastructure, or any official tooling, please report it responsibly before public disclosure. We will acknowledge your report, investigate promptly, and, where appropriate, credit you publicly. What to include in your report: A clear description of the vulnerability and its potential impact Steps to reproduce or a proof-of-concept (private, not exploited on mainnet) Affected component, contract address, repository, or infrastructure layer Your preferred contact method for follow-up Please allow reasonable time for triage and patching before any public disclosure. We commit to acknowledging reports within 5 business days. Contact paths: [email protected] Open an issue on aere-contracts For critical vulnerabilities affecting live funds or validator safety, please use email and mark the subject line [SECURITY] . Do not post exploit details in public channels until a fix is deployed. --- # DeFi on AERE Network URL: https://aere.network/solutions-defi.html Fetched: 2026-09-15 DeFi on AERE Network DeFi on AERE Network Decentralised exchanges, lending markets, and staking vaults deserve a chain that can keep up. AERE is an EVM-compatible Layer 1 built for the throughput and cost profile that DeFi actually needs. AERE runs a live EVM mainnet (Chain ID 2800). Any Solidity contract that deploys on Ethereum, Polygon, or Avalanche deploys on AERE without modification, the same tools, the same ABIs, the same developer workflow. Why AERE for DeFi 01 Near-instant settlement AERE reaches transaction finality in roughly half a second under normal conditions. For an automated market maker or an on-chain order book, the difference between sub-second and twelve-second blocks is not cosmetic, it determines whether arbitrage bots can hold spreads tight and whether liquidation logic fires before a position turns insolvent. Fast blocks keep price discovery honest. 02 Negligible transaction fees Gas on AERE is denominated in AERE, the native token, and costs are a fraction of a cent per interaction under ordinary load. For protocols where users compound yield, rebalance positions, or vote on governance proposals, actions that fee-sensitive users avoid on high-cost chains, affordable execution changes the product experience entirely. Builders can also design protocols that call multiple contracts in a single transaction without worrying that fees will deter real users. 03 Full EVM compatibility and live infrastructure AERE ships an oracle contract (AereOracleV2, deployed and verifiable on-chain) designed to take the median across multiple registered reporters, with staleness and quorum guards that refuse to serve a price they cannot stand behind; its first feed, AERE/USD, activates with market listing, because publishing a price for an unlisted asset would be an invented number, a requirement for any lending or derivatives protocol. A block explorer, a public RPC endpoint, and a keyed chain-data API (Aere Cloud) are already operational. A staking contract, governance module, and standard token registry are deployed and auditable. You are not building on a testnet or a fork with missing infrastructure, the chain is live and the core DeFi primitives are in place. What you can build The EVM environment means the full design space is open. Common starting points on AERE include automated market makers with custom fee tiers, peer-to-peer lending pools with oracle-driven liquidations using AereOracle price feeds, liquid staking wrappers for AERE itself, yield aggregators that compound positions across multiple protocols, and on-chain governance contracts tied to the AERE DAO module. If it runs on an EVM chain, it runs on AERE. The AERE developer grants program funds DeFi infrastructure directly. Projects that deploy production-grade AMMs, lending markets, or staking primitives on AERE are eligible for grant funding from the ecosystem treasury as defined in whitepaper §6.2. The grants process is fully public and milestone-based, no equity, no token claw-backs. Start building Add AERE Network to your wallet and development environment: Chain ID 2800 , RPC https://rpc.aere.network , native token AERE . The documentation covers contract deployment, oracle integration, and the full list of deployed system contracts. Read the docs → Apply for a grant Block explorer ↗ --- # Gaming on AERE Network URL: https://aere.network/solutions-gaming.html Fetched: 2026-09-15 Gaming on AERE Network Gaming on AERE Network Blockchain gaming has a throughput problem and a fee problem. AERE solves both. High transaction volume, fast block times, and costs so low that microtransactions are viable, the chain designed for interactive applications where every player action may touch the ledger. AERE supports EVM-compatible smart contracts and the full ERC-721 / ERC-1155 NFT standard suite out of the box. In-game items, characters, land parcels, and achievement tokens are first-class on-chain objects, tradeable, composable, and owned by players, not servers. Why AERE for gaming 01 Throughput that games actually need A game with active players generates transaction volume that would congest a slow-finality chain within minutes of launch. AERE is built for high-throughput workloads. Block times are short and consistent, which means that in-game events, item drops, crafting, trading, match results, can be written on-chain in near real time rather than batched into slow settlement windows. The chain does not require Layer 2 workarounds just to handle the baseline activity of a mid-sized game. 02 Microtransactions at negligible cost In traditional web3 gaming, gas fees make small transactions economically irrational. Spending $2 in fees to record a $0.10 in-game purchase is a non-starter for players. On AERE, each transaction costs a fraction of a cent in AERE fees. This makes microtransactions viable: consumables, small upgrades, entry fees, and in-game currency transfers can all settle on-chain without fee friction destroying the user experience. The game economy can be fully on-chain rather than a hybrid of off-chain databases and expensive on-chain snapshots. 03 NFT-native infrastructure AereNFT, AERE's native NFT contract, and the on-chain marketplace are live on mainnet. EIP-2981 royalty standards are supported, meaning game studios can configure royalty splits that are enforced at the contract level on every secondary sale. ERC-1155 multi-token contracts allow a single deployment to manage an entire game's item catalogue, fungible currencies alongside non-fungible equipment or collectibles. The block explorer indexes NFT transfers in real time, and the indexer API exposes ownership and history data for front-end integration. What you can build The combination of fast finality, low fees, and live NFT infrastructure opens the full game design space: fully on-chain games where every state transition is a transaction, hybrid games where off-chain computation settles outcome proofs on-chain, item marketplaces with royalty enforcement, loot systems that generate randomness through on-chain entropy, guild treasuries managed by multi-sig, and achievement systems where milestones are verified on-chain and transferable between games. The AERE grants program funds gaming projects that contribute to the ecosystem. Studio-grade integrations, open-source game SDKs, and on-chain game infrastructure are all eligible categories. Grant decisions are fast for smaller project scopes and public throughout the process. Start building Connect your game to AERE: Chain ID 2800 , RPC https://rpc.aere.network , native token AERE . The documentation includes deployed NFT contract addresses, the marketplace ABI, and quickstart examples for Unity and browser-based integrations. Read the docs → Apply for a grant Block explorer ↗ --- # Infrastructure & Tooling, AERE Network URL: https://aere.network/solutions-infrastructure.html Fetched: 2026-09-15 Infrastructure & Tooling, AERE Network Infrastructure & Tooling Every healthy blockchain needs operators, tooling authors, and infrastructure providers beyond the core team. AERE is open infrastructure, run a node, serve RPC, build indexers, or operate oracle reporters. The grants program pays for work that strengthens the network. AERE is an EVM-compatible Layer 1. The network software, node configuration guide, and system contract source code are published at git.aere.network . Public infrastructure endpoints are maintained by the Foundation; community operators can run independent nodes and serve the ecosystem. Live public endpoints Service Endpoint Protocol JSON-RPC https://rpc.aere.network HTTPS / ETH RPC WebSocket wss://wss.aere.network WebSocket / ETH RPC Block explorer https://explorer.aere.network Web / REST Data API (keyed, free trial) https://cloud.aere.network/v1 REST JSON Source code https://git.aere.network Gitea / Git Infrastructure roles 01 Run a node or RPC provider The AERE node software is available on Gitea. Running a full node contributes to network resilience and allows projects that need guaranteed RPC availability to self-host. The node exposes the standard Ethereum JSON-RPC interface, any tooling that works with geth or Besu works with an AERE node. Community operators who run stable public or private RPC services are eligible for infrastructure grants. The ideal state for the network is multiple independent RPC providers so that no single operator is a dependency for the ecosystem. 02 Build indexers and data services The Foundation runs a keyed chain-data API at cloud.aere.network/v1 (chain head, validator set, and the post-quantum anchor certificates, with a free trial key). Full historical indexing of logs, transactions, and token transfers is an open infrastructure need, not yet served. Additional indexers, with specialised schemas for DeFi events, NFT transfer histories, or identity attestation lookups, would materially improve the developer experience for application builders. Subgraph-compatible indexers (The Graph protocol or self-hosted equivalents), event-driven databases, and analytics dashboards are all open infrastructure needs. The chain-data API is open for integration; building a compatible or complementary service is a well-scoped grant project. 03 Operate oracle reporters AereOracle uses a multi-reporter median model, the more independent reporters submit price data, the more robust and manipulation-resistant the feed becomes. Reporter status is granted by the Foundation after a review of the operator's infrastructure, price-source attribution, and submission reliability. There is no on-chain reward currently; incentives will be introduced through the DAO grant budget once governance V2 is live. Operators interested in becoming reporters should open an issue on the AERE contracts repository at git.aere.network with their operator profile and planned price sources. Grants for infrastructure builders Infrastructure grants are among the most straightforward to approve in the AERE program. Clear scope, a demonstrable prior work record, and a deliverable that the ecosystem can use, that is the bar. Open-source RPC libraries, wallet connection adapters, bridge adapters connecting AERE to other chains, developer CLI tools, and monitoring dashboards are all eligible. Quick-build grants ($1k, $5k) have a seven-day approval window. Larger infrastructure projects ($5k, $25k) are milestone-based with a fourteen-day review. Start building Network details: Chain ID 2800 , native token AERE . Node software and system contract source code are at git.aere.network . The documentation covers node setup, the indexer API schema, oracle reporter onboarding, and the full list of deployed system contracts. Read the docs → Apply for a grant Source code ↗ --- # NFTs & Digital Culture, AERE Network URL: https://aere.network/solutions-nft.html Fetched: 2026-09-15 NFTs & Digital Culture, AERE Network NFTs & Digital Culture The NFT infrastructure on AERE is live, not planned. AereNFT and an on-chain marketplace are deployed on mainnet. Mint a collection today without waiting for infrastructure to catch up. AereNFT implements ERC-721 with EIP-2981 royalty support. The marketplace contract is deployed and operational on AERE mainnet. Royalty percentages and recipient addresses are set at collection deployment and enforced at the contract level on every secondary sale through the marketplace, no trusted off-chain enforcement required. Why AERE for NFTs 01 Minting costs that do not deter creators On congested high-fee chains, minting a collection of any meaningful size requires either absorbing significant upfront costs as a creator or passing fees to collectors as a barrier to entry. On AERE, minting a single token or an entire collection costs a fraction of a cent per transaction. This changes the economics for independent artists, small studios, and community projects, the cost to experiment and launch is essentially zero, and the cost to airdrop to a community is not a budget line that requires planning. Creating and distributing digital work should not require a financial cushion. On AERE, it does not. 02 On-chain royalties that actually enforce EIP-2981 is the royalty standard that embeds creator payment terms into the NFT contract itself. When a token sells through the AERE marketplace, the royalty split is computed and distributed at the contract level, no marketplace policy, no off-chain agreement, no trust in the platform operator. The royalty percentage and the recipient address are set when the collection is deployed and cannot be overridden by the marketplace contract. For creators building a sustainable income from secondary sales, contract-level enforcement is the only kind that reliably works. 03 Speed and composability for dynamic NFTs NFTs that evolve, game items that gain attributes, art pieces that change over time, collectibles with on-chain provenance trails, require a chain where updating metadata or recording interactions is fast and affordable. AERE's sub-second finality and negligible update costs make on-chain NFT state changes practical. Combined with full EVM composability, AERE NFTs can interact with DeFi protocols (collateralise your NFT for a loan), gaming contracts (use your NFT as a character in a game), and identity systems (attach an AereIdentity attestation to a soulbound token). The ecosystem is a single shared state space. For creators and collectors Artists, musicians, photographers, and digital creators can deploy a collection on AERE using the AereNFT contract directly or through any ERC-721-compatible deployment tool. The block explorer provides a public view of every collection, transfer, and sale event, a permanent, tamper-proof provenance record for every piece. Collectors can hold and trade AERE NFTs using any EVM-compatible wallet with AERE Network added. The AERE grants program funds cultural and creative projects as well as technical ones. NFT collections that build community or demonstrate novel use of the chain's composability features are eligible for quick-build grants. The application is public and the process is transparent. Start building Add AERE to your wallet: Chain ID 2800 , RPC https://rpc.aere.network , native token AERE . The documentation covers the AereNFT contract address, deployment parameters, royalty configuration, and how to list a collection on the marketplace. Read the docs → Apply for a grant Block explorer ↗ --- # Payments & Enterprise, AERE Network URL: https://aere.network/solutions-payments.html Fetched: 2026-09-15 Payments & Enterprise, AERE Network Payments & Enterprise Fintech products and enterprise settlement systems need a blockchain that behaves like infrastructure, predictable, fast, and efficient enough that fees never become a line item on a per-transaction basis. AERE is built to those requirements. AERE is built to be the settlement layer for consumer payment applications, including non-custodial crypto card neobanks: the settlement leg of card payments, stablecoin transfers, and on-chain receipts is designed to clear on AERE mainnet with sub-second finality and predictable fees. The chain is live production infrastructure, not a testnet; payment programs on top of it are being onboarded and are not yet public. Why AERE for payments 01 Finality in roughly half a second Payment products live and die by confirmation speed. A card terminal, an invoice, or a remittance flow cannot tell a customer "your payment is pending for 12 minutes." AERE reaches finality in roughly half a second under normal network load, which is fast enough for point-of-sale and near-instant enough for the settlement leg of cross-border transfers. Applications can treat a confirmed AERE block as settled without waiting for additional confirmations. 02 Fees that do not erode margins Transaction fees on AERE are a fraction of a cent per operation. For a payments business routing thousands of settlements per day, fee predictability and absolute cost both matter. AERE's fee structure is stable and low by design, the chain is not competing for block space in the same way as a general-purpose congested network. You can model unit economics on AERE without including a "blockchain fee" reserve that grows with usage. 03 EVM-native and integrates with existing stacks AERE is fully EVM-compatible. Any smart contract written in Solidity for ERC-20 stablecoins, payment splitting, escrow, or subscription billing deploys without modification. Standard Ethereum tooling, Hardhat, Foundry, ethers.js, web3.py, works out of the box. Enterprises that have already integrated EVM infrastructure can add AERE as a network with a single RPC endpoint change. Wallet integrations that support MetaMask or WalletConnect work with AERE immediately. Enterprise settlement architecture AERE supports the full stack required for a modern fintech settlement layer: ERC-20 stablecoins as payment instruments, atomic smart contract execution for multi-party settlement, on-chain receipts that are publicly verifiable without exposing sensitive business data, and the AereIdentity system for on-chain KYC attestations that allow compliant flows without rebuilding identity verification from scratch. For enterprise integrators who need a private communication channel before going public, the AERE Foundation can be reached through the contact information in the documentation. For projects with a clear build plan, the grants program provides milestone-based funding, particularly relevant for infrastructure that benefits multiple fintech products building on the chain. Start building Connect to AERE: Chain ID 2800 , RPC https://rpc.aere.network , WebSocket wss://wss.aere.network . The documentation covers stablecoin deployment, the AereIdentity attestation system, and smart contract patterns for payment flows. Read the docs → Apply for a grant Block explorer ↗ --- # Institutions & Real-World Assets, AERE Network URL: https://aere.network/solutions-rwa.html Fetched: 2026-09-15 Institutions & Real-World Assets, AERE Network Institutions & Real-World Assets Tokenising real-world assets requires more than a fast chain. It requires a compliance-friendly architecture that institutions can actually use, on-chain identity attestations, EVM composability, and a settlement layer with predictable costs and near-instant finality. AereIdentity is a live on-chain attestation system deployed on AERE mainnet. It allows accredited verifiers to write KYC, accreditation, and jurisdiction flags to an address without exposing underlying personal data on-chain. Smart contracts can read these attestations at execution time to enforce access control, no off-chain oracle call required. Why AERE for institutions and RWA 01 On-chain KYC and accreditation via AereIdentity Regulated asset tokenisation requires that only verified participants can hold or transact certain tokens. AereIdentity enables this at the smart contract level. A verifier, a licensed KYC provider or the issuer's own compliance infrastructure, writes an attestation to an address: this wallet has passed KYC, or this wallet is an accredited investor in jurisdiction X. The token contract reads that attestation on every transfer and reverts if the recipient lacks the required flag. The personal data never touches the chain; only a boolean or a jurisdiction code does. This is a deployed, functioning system on AERE mainnet today. 02 Tokenisation on an EVM-compatible chain Real-world asset tokenisation projects, covering debt instruments, real estate fractional ownership, fund shares, or commodity receipts, are primarily built in Solidity and target EVM chains because the tooling, auditing ecosystem, and institutional familiarity already exist there. AERE is fully EVM-compatible: every standard token framework (ERC-20, ERC-3643, ERC-1400 patterns) deploys without modification. The compliance logic that financial institutions require can be encoded directly in the token contract using the same patterns their legal and technical teams already review. 03 Settlement finality and cost that scale with volume Institutional settlement workflows, secondary market trades, coupon distributions, redemption events, involve high transaction counts at precise timing. AERE's sub-second finality means settlement events execute and confirm in near real time rather than accumulating pending across slow block windows. Fees are stable and small, so cost models for high-volume settlement legs do not require buffering for fee spikes. The public RPC endpoint and WebSocket feed allow institutional back-office systems to subscribe to on-chain events in real time without requiring a dedicated node. Architecture overview for RWA issuers A typical RWA deployment on AERE combines three layers: a permissioned token contract (ERC-20 or partition-based) that enforces transfer restrictions via AereIdentity reads, an issuance and redemption module that controls minting and burning against off-chain custodian confirmation, and a distribution contract that handles on-chain coupon or dividend payments to verified holders. All three layers are composable with existing AERE infrastructure, the oracle for on-chain pricing, the DAO module for governance of token parameters, and the block explorer for public auditability of the cap table. The AERE Foundation is open to discussing institutional pilot programmes. Strategic grants of up to $100k are available for RWA infrastructure that benefits the broader ecosystem, with DAO oversight and public milestones. Start building Chain ID 2800 , RPC https://rpc.aere.network , WebSocket wss://wss.aere.network . The documentation covers AereIdentity contract addresses, the attestation write API for verifiers, and example permissioned token contracts. Read the docs → Apply for a grant Block explorer ↗ --- # Solutions | Aere Network URL: https://aere.network/solutions.html Fetched: 2026-09-15 Solutions | Aere Network Aere Network Built for money that has to stay settled Need this measured for your own contracts? The Aere Quantum Exposure Report measures them and hands you the command to reproduce it on your own node. Free scan for one address. Everything below rests on two properties of chain 2800: a block is final in about half a second with no reorgs by design, and since 2026-08-14 every 128th block (every 32nd block until block 17,225,968, on 2026-09-05) does not finalize without a post-quantum validator certificate under its hash. Pick the door that matches your problem. Regulated finance Prove it to your regulator The post-quantum migration testbed: exercise Falcon, ML-DSA and SLH-DSA on a live public chain and take home a reproducible conformance report. Private deployments and pilots for teams under NIST migration mandates. Start with verification, not slides Payments Payments that stay settled Settled in about half a second, no reorg to undo it, and the receipt sits under a post-quantum anchor. No consensus chargebacks, no confirmation-depth policies, no float held against the ledger changing its mind. How settlement works here Tokenization Receipts that outlive the cryptography Assets live for decades; NIST has scheduled classical signatures for retirement well inside that horizon. A register on chain 2800 stays provable across that migration, which is the property a tokenized asset actually needs. The time-horizon problem, solved Settlement Quantum-safe settlement Why a settlement ledger needs post-quantum evidence in the block record itself, not only at the application layer, and exactly what ours carries at every 128th header (every 32nd header until block 17,225,968, on 2026-09-05). The pitch, in depth Notarization Timestamps that outlive their cryptography Anchor a document hash on chain 2800 and get a proof of existence whose durability does not depend on the algorithms that made it. No file leaves your hands. Notarize a document The foundation Six layers, measured The whole post-quantum stack, layer by layer, each marked live or validating, each with the number that backs it and the block it went live at. See what is real Honest boundaries, before you pick a door. All ten validators are operated by the Foundation today (ten validators since 2026-09-11); the chain is not yet decentralized and no page here says otherwise. There is no completed third-party security audit yet. We publish no throughput figures; deterministic sub-second finality is the performance claim we stand behind. Every page above states its own limits in the same place it states its capabilities. Talk to us: [email protected] About About Aere Foundation Roadmap Press & Newsroom Brand Kit Editorial Standards Build Developer Hub Documentation RPC Reference SDK Add Network Faucet Academy Grants Network Architecture Post-Quantum Stack Validators Run a Validator Network Status Audits Security Decentralization Solutions Payments DeFi Real-World Assets Infrastructure Gaming NFTs & Culture Explore Explorer Blocks Transactions Tokens Research & Papers Glossary Blog Legal Terms & Privacy Sanctions Compliance Aere Network. Chain ID 2800. Every claim on this site is checkable: rpc.aere.network --- # AERE Locked Staking, Liquidity Lock Tiers URL: https://aere.network/stake-v2.html Fetched: 2026-09-15 AERE Locked Staking, Liquidity Lock Tiers AERE Locked Staking Home Delegated Staking Explorer Liquidity Lock Staking Lock AERE for a fixed term. Per whitepaper §3.3. The APY rates below are real on-chain constants, but the reward reserve that pays them is currently empty, so no yield can be paid today. ⚠ The reward reserve is unfunded. No yield can be paid today. The APY constants are real and this contract is live and callable, but the reserve holds nothing, so a lock made now earns you nothing. While the reserve cannot cover principal plus reward, withdraw() at maturity reverts; your principal stays recoverable at any time via earlyExit() , which forfeits the reward. Do not lock expecting a return. Contract 0x21108c28…97E7Ad Min stake 1 AERE Reward reserve (pays the APY) … Choose a tier 30 days … Short lock · liquidity-friendly 90 days … Quarterly lock 180 days … Semi-annual lock 365 days … Annual lock · highest yield Amount (AERE) Connect Wallet Stake Your active locks Connect your wallet to see your locks. Refresh --- # AERE Staking, fixed-term locks on AereLockedStaking URL: https://aere.network/stake.html Fetched: 2026-09-15 AERE Staking, fixed-term locks on AereLockedStaking AERE Staking Home Whitepaper Add Network Explorer Stake AERE Lock AERE for a fixed term. The tier rates below are real on-chain constants, but the reward reserve that pays them is currently empty, so no yield can be paid today. Any holder can stake, staking earns yield, it does not make you a validator. ⚠ The reward reserve is unfunded. No yield can be paid today. The APY constants are real and this contract is live and callable, but the reserve holds nothing, so a lock made now earns you nothing. While the reserve cannot cover principal plus reward, withdraw() at maturity reverts; your principal stays recoverable at any time via earlyExit() , which forfeits the reward. Do not lock expecting a return. Staking earns yield, not a validator seat. AERE runs Hyperledger Besu QBFT consensus. Validators are admitted by a governance vote of the existing validator set, not by staking or bonding, and there is no on-chain slashing. Staking here is a yield product for any AERE holder. Learn how validators are admitted at aere.network/run-a-validator . , Reward reserve (pays the APY) 1 AERE Minimum stake None Slashing Tier APYs and the reward reserve are read live from AereLockedStaking 0x2110…E7Ad on Chain 2800. The reserve is the balance held above outstanding principal, and it is what can actually pay yield. Early exit forfeits reward and returns principal only. No unbonding delay, no slash risk. Connect Wallet Stake Your locks Choose a tier 30 days , Short lock · liquidity-friendly 90 days , Quarterly lock 180 days , Semi-annual lock 365 days , Annual lock · highest tier rate Amount (AERE) Stake Reward accrues over the lock term and is paid in AERE on maturity, out of the reward reserve. While that reserve is empty no reward can be paid and withdraw() at maturity reverts. Early exit forfeits reward and returns principal only, there is no unbonding delay and no slashing. Your active locks. Claim on maturity, or early-exit for principal only. Connect wallet to view. Refresh Other ways to earn on AERE Locked staking tiers (this page) carry a fixed APY constant for a fixed term on AereLockedStaking , but the reward reserve is unfunded, so nothing is payable today. sAERE is an ERC-4626 staking receipt ( 0xA212…50b0 ) that earns a variable staker-yield from the AereSink fee split. Neither product makes you a validator, and neither carries slashing risk. --- # Staking & Validator Rewards, AERE URL: https://aere.network/staking-rewards.html Fetched: 2026-09-15 Staking & Validator Rewards, AERE Staking & validator rewards AERE runs Hyperledger Besu QBFT, deterministic 0.5s finality, no mining, no hash power, no proof-of-work. You earn by staking AERE or by operating a validator. Yield is variable and tracks chain activity; it is never a promised daily amount. There is nothing to mine. AERE has no miners, no hashrate, and no proof-of-work. Participation is on-chain staking: deposit into the sAERE ERC-4626 vault for a liquid receipt, lock AERE for a fixed term in AereLockedStaking , or run a QBFT validator . Every surface below maps to a contract address you can call on chain 2800. Most used ERC-4626 receipt sAERE liquid staking Variable yield Mechanical accrual, no promised APY Deposit WAERE, receive a liquid sAERE receipt Rate rises as the AereSink routes protocol revenue in Monotonic rate, only flat or up No lock-up, redeem any time Immutable: no admin, no upgrade proxy 0xA2125bE9C6fd4196D9F94757Df18B3a2A5e650b0 Open sAERE dashboard Fixed-term locks AereLockedStaking 10%, 30% APY By lock term, set at deploy. Reward reserve unfunded: not payable today Reward reserve is empty: no yield can be paid today. The rates below are real on-chain constants, but the contract holds nothing to pay them with, so a lock made now returns principal only. 30-day lock, 10% APY 90-day lock, 15% APY 180-day lock, 22% APY 365-day lock, 30% APY Principal-only early exit · 1 AERE minimum 0x21108c28A849b05aE6b7a3a5bc435C9Bc897E7Ad View lock terms Run a node QBFT validator Validator reward Per-block validator reward remainder after burn Besu QBFT validators secure the chain 37.5% of the validator reward burned; remainder to validator The burn takes a share of the validator coinbase reward, not gas fees and not the EIP-1559 base fee 10 Foundation validators today (f=3, quorum 7-of-10) Public path to 21 No hash power, deterministic 0.5s finality Validator policy Economics sealed by code. 37.5% of the validator reward is burned, a Foundation-set rate hard-capped at 50%, into a sealed vault and owner-less AereSink flywheel with no admin, no proxy, and no withdrawal path. Fixed 2.8B supply, zero new minting. One operator runs all ten validators today (ten validators since 2026-09-11) and the admin keys sit with a single Foundation account; read the Foundation page before you call that trustless. The AereSink, where staking yield comes from Protocol revenue on chain 2800 flows through the immutable AereSink router, split three ways at fixed percentages set at deploy. There is no admin, no proxy, and no withdrawal path. Bucket Split What it does BURN 15% Sent to 0x…dEaD, permanently removed from supply BUYBACK-and-burn 40% Buys WAERE and burns it STAKER-YIELD 45% Buys WAERE into the sAERE vault, lifting the conversion rate AereSink contract: 0x69581B86A48161b067Ff4E01544780625B231676 . This 3-bucket split is separate from, and on top of, the 37.5% validator-reward burn routed into the sealed vault. Yields are variable and depend on on-chain fee flow, staking participation, and network conditions. Fixed-term APYs for AereLockedStaking are contract parameters verifiable on chain 2800, not guarantees of future value. Nothing here is a promised daily payout. Crypto involves risk; review the Risk Factors and the sAERE classification memo before staking. Not financial advice. --- # AereSubscriptions, Recurring on-chain payments URL: https://aere.network/subscriptions.html Fetched: 2026-09-15 AereSubscriptions, Recurring on-chain payments AereSubscriptions Coming soon. This feature is built and on the AERE roadmap, its on-chain contracts are not yet deployed. Actions are disabled until launch. Pre-approve a per-period charge to a merchant; the merchant pulls a payment once per period. Cancel anytime by setting your ERC-20 allowance to zero or calling cancel(id) . Works with any ERC-20 deployed on AERE Network. Registry AereSubscriptions 0xE6827547…89e3c875 Total subscriptions , Your address , Connect Wallet Refresh Subscribe to a merchant Merchant address Token (ERC-20) Amount per period Period (seconds) End time (unix seconds, 0 = open-ended) Subscribe You also need to approve() the AereSubscriptions contract for the token at least up to the per-period amount. Your subscriptions Connect wallet to see. --- # AereSwap, V2 AMM on AERE Network URL: https://aere.network/swap.html Fetched: 2026-09-15 AereSwap, V2 AMM on AERE Network AereSwap V2-style automated market maker. Auto-wraps native AERE via WAERE. 0.3% LP fee. Slippage-protected single-call swaps via the live router. 🌱 Launching soon, liquidity not yet seeded. The AereSwap router and factory are live on chain 2800, but no liquidity pairs exist yet, so swaps have no route. Quotes and the Swap action are disabled until the first pool is seeded. AereSwapRouter 0x7526B2E5…77523D8 AereSwapFactory 0xf0a8df7B…0e84DC WAERE 0x7e84d7d6…e1f5e8 Pool reserves , Connect Wallet From AERE (native) ERC-20… Balance: , ↓ To (estimated) ERC-20… AERE (native) Balance: , Swap (available at launch) Slippage tolerance: 0.5% · Deadline: 1 hour. If "no route", a pool must be seeded first (use the Add Liquidity tab when it ships, or call the router's addLiquidityAERE directly). --- # Token · AERE Block Explorer URL: https://aere.network/token.html Fetched: 2026-09-15 Token · AERE Block Explorer Token Token detail. Name, supply, holders, and transfers, read straight from the contract on AERE. Total supply Decimals precision Holders indexed addresses Transfers indexed events Top holders # Address Balance Recent transfers Tx hash From → To Amount --- # AERE Tokens & NFTs, Token tracker URL: https://aere.network/tokens.html Fetched: 2026-09-15 AERE Tokens & NFTs, Token tracker AERE Tokens & NFTs Every ERC-20 and ERC-721 known to be deployed on AERE Network. Add your token by submitting a PR to git.aere.network/aere-network/sdk-js . ERC-20 Tokens NFT Collections Address Lookup Token Symbol Address Total supply Holders Transfers Decimals Loading… Collection Symbol Address Total supply Loading… Look up any contract Paste a contract address; if it's an ERC-20 or ERC-721 we'll detect it and show its metadata. Useful for verifying tokens before interacting with them. Lookup , --- # AERE chain 2800 post-quantum conformance evidence (sample report) URL: https://aere.network/tools/sample-conformance-report.html Fetched: 2026-09-15 AERE chain 2800 post-quantum conformance evidence (sample report) SAMPLE REPORT · REAL MEASUREMENTS AERE chain 2800: post-quantum conformance evidence generated 2026-09-11T14:09:07.410Z · endpoint https://rpc.aere.network · 630 read-only RPC calls in 53.7s · every number below was measured by the toolkit, none written by hand 38 PASS 0 FAIL 6 NOT MEASURED How to read this. A PASS means the live chain matched an expectation written down before the chain was asked. A NOT MEASURED line is not a confirmation: it names something this toolkit cannot decide from a public endpoint, and it is listed instead of hidden. The toolkit refuses to report green unless its own self-test, which plants twenty-one deliberate defects, catches every one first. 0. The endpoint PASS 1 · FAIL 0 · NOT MEASURED 0 check claim expected observed verdict lant.chainId the endpoint serves the chain this toolkit is written about 2800 2800 PASS 1. Post-quantum precompiles on the live chain PASS 17 · FAIL 0 · NOT MEASURED 1 check claim expected observed verdict pqc.punct-final.corp-mare this endpoint accepts a request large enough to carry an SLH-DSA verification (~11.8 KB of calldata). A failure HERE is about the endpoint in front of the node, not about the chain accepts 12000 bytes of calldata accepts 12000 bytes of calldata PASS pqc.calibrare.identity gas ruler calibrated on the identity precompile 0x04 at the Yellow Paper price 15+3*ceil(len/32) 21 21 PASS pqc.gaz.FALCON512 0x0000000000000000000000000000000000000ae1 burns exactly the gas its published source declares for a 64-byte input 40000 40000 PASS pqc.gaz.FALCON1024 0x0000000000000000000000000000000000000ae2 burns exactly the gas its published source declares for a 64-byte input 75000 75000 PASS pqc.gaz.MLDSA44 0x0000000000000000000000000000000000000ae3 burns exactly the gas its published source declares for a 64-byte input 55000 55000 PASS pqc.gaz.SLHDSA128S 0x0000000000000000000000000000000000000ae4 burns exactly the gas its published source declares for a 64-byte input 350000 350000 PASS pqc.control.adresa-goala an address in the same band with nothing behind it burns 0 extra gas, so a nonzero charge above is not an artefact of the method 0 0 PASS pqc.testnet-only.MLKEM768_TESTNET_ONLY 0x0000000000000000000000000000000000000ae6 is TESTNET ONLY and is NOT active on this chain 0 0 PASS pqc.testnet-only.HASHTOPOINT_TESTNET_ONLY 0x0000000000000000000000000000000000000ae7 is TESTNET ONLY and is NOT active on this chain 0 0 PASS pqc.falcon512.kat 0x0AE1 accepts every reference Falcon-512 signature and rejects every one-bit mutation of it (8 accept, 8 reject) 8/8 8/8 PASS pqc.mldsa44.acvp 0x0000000000000000000000000000000000000ae3 agrees on every vector, accepts and rejects alike (3 accept, 12 reject) -- NIST wrote the reject cases, not us 3/12 3/12 PASS pqc.slhdsa128s.acvp 0x0000000000000000000000000000000000000ae4 agrees on every vector, accepts and rejects alike (2 accept, 12 reject) -- NIST wrote the reject cases, not us 2/12 2/12 PASS pqc.shake256.acvp 0x0AE5 reproduces every NIST ACVP SHAKE-256 digest byte for byte (139 vectors) 139 139 PASS pqc.shake256.oracol-local the toolkit's own pure-JS SHAKE256 agrees with NIST on the same vectors, so a chain match is a three-way agreement and not two copies of one mistake 0 0 PASS pqc.falcon1024.parametru-gresit 0x0AE2 rejects a Falcon-512 input, so it is not a stub that answers 1 to anything 0x0000000000000000000000000000000000000000000000000000000000000000 0x0000000000000000000000000000000000000000000000000000000000000000 PASS pqc.falcon1024.executa 0x0AE2 returns a full 32-byte word rather than the empty 0x an absent address returns 66 66 PASS pqc.falcon1024.acvp 0x0000000000000000000000000000000000000ae2 agrees on every vector, accepts and rejects alike (2 accept, 3 reject) -- the accept vectors carry a NIST round-3 attribution this kit passed through without verifying, and the reject vectors are our own bit-flips, because NIST publishes no Falcon suite 2/3 2/3 PASS pqc.consens whether block sealing uses a post-quantum signature null null NOT MEASURED 2. Block interval, measured PASS 5 · FAIL 0 · NOT MEASURED 2 check claim expected observed verdict interval.banda every one of 4 disjoint 2000-block windows near the head gives a block interval inside the stated band 0.56 .. 0.63 s 0.5920 .. 0.5985 s PASS interval.banda-masurabila the declared band is wider than what 2000-block windows can resolve, so a verdict on it is a statement about the chain rather than about timestamp truncation > 0.00100 s, which is 2/K 0.07000 s PASS interval.imprastiere the 4 windows disagree by 0.00650 s, so the rate is quoted as +/- 0.00325 s, dominated by the disagreement between windows; with that margin included the figure still fits inside the declared band, so one number honestly describes this sample 0.56 .. 0.63 s 0.59088 .. 0.59737 s PASS interval.viata-nu-este-acum the genesis-to-head lifetime average (0.60895 s) and the current rate (0.59413 s) are distinguishable measurements -- they are apart by 4.6 times the sum of their margins -- so the current rate must never be published as the chain's lifetime speed, nor the other way round > 0.00650 s apart, which is 2x the margins summed 0.01483 s apart PASS interval.regimuri the chain has run at more than one speed: a 2000-block window at height 1000000 gives 1.00000 s against 0.59413 s now, which is why one average over the whole life describes neither > 0.00750 s apart 0.40587 s apart PASS interval.cauza why the current rate is what it is, and whether it will hold null null NOT MEASURED interval.varianta-reala how much of the window-to-window spread is a real change of speed and how much is sampling noise null null NOT MEASURED 3. Validator set, read out of headers PASS 7 · FAIL 0 · NOT MEASURED 1 check claim expected observed verdict validatori.numar every one of 200 sampled headers publishes the same validator count 10 10 PASS validatori.set-stabil the validator MEMBERSHIP is byte-identical across all 200 sampled headers 1 1 PASS validatori.cvorum-sigilii every sampled block carries at least the QBFT quorum of committed seals (ceil(2*10/3) = 7) >= 7 7..7 PASS validatori.propunator-membru the proposer of every sampled block is a member of the validator set that same block publishes 200 200 PASS validatori.recensamant distinct proposers actually seen producing blocks in the sample -- configured is not the same as producing 10 10 PASS validatori.lungime-sigiliu committed seals are 65 bytes, the classical secp256k1 ECDSA r||s||v shape -- this chain's consensus is NOT post-quantum 65 65 PASS validatori.rpc-vs-antet the qbft_getValidatorsByBlockNumber RPC method agrees with what the headers themselves carry -- if these ever differ, believe the headers 0x1bd5514286f5602a6762b0075266379d29af1c9d,0x4bf6f91d84b37454544279cba152581ed6820044,0x5f50fc4e1b129bbd5e6e9f80c57680b0b4a86eb0,0x97473985d04723299559f49b856effb47d7abfad,0xb5e768cb3117ea25175f51aa956b48691025c2a8,0xc3314fd768bb68b986e80c0a14175f6f72630d7a,0xd38cb62a38c1d4a5fccef6bee0f2e177ec3c9aa2,0xdf09b32c761620c5be77da398b97a64f03c3980c,0xe13aa491abbc1252dd714e7ca0e55717a2143eaf,0xf73bbbd26a82dbc769066550d8d4585eab2fc00d 0x1bd5514286f5602a6762b0075266379d29af1c9d,0x4bf6f91d84b37454544279cba152581ed6820044,0x5f50fc4e1b129bbd5e6e9f80c57680b0b4a86eb0,0x97473985d04723299559f49b856effb47d7abfad,0xb5e768cb3117ea25175f51aa956b48691025c2a8,0xc3314fd768bb68b986e80c0a14175f6f72630d7a,0xd38cb62a38c1d4a5fccef6bee0f2e177ec3c9aa2,0xdf09b32c761620c5be77da398b97a64f03c3980c,0xe13aa491abbc1252dd714e7ca0e55717a2143eaf,0xf73bbbd26a82dbc769066550d8d4585eab2fc00d PASS validatori.cine-le-opereaza who operates these 10 keys null null NOT MEASURED 4. On-chain contract fingerprints PASS 5 · FAIL 0 · NOT MEASURED 1 check claim expected observed verdict amprente.chainid the endpoint being questioned is the chain this manifest was built against 2800 2800 PASS amprente.citiri-instabile no registered address answered the same pinned read-only eth_getCode two different ways during this run. A failure HERE is about the endpoint, not about the chain: it means a caller doing one read and believing it would have been told something false 0 0 PASS amprente.neschimbate all 185 registered contracts still carry exactly the runtime code the manifest recorded 0 0 PASS amprente.sursa-publicata the number of live contracts whose runtime code is byte-for-byte the output of a published compiled artifact 34 34 PASS amprente.sursa-fara-metadata the number of live contracts that match a published artifact only once the Solidity metadata trailer is stripped 7 7 PASS amprente.restul source provenance of the other 144 live registered contracts null null NOT MEASURED 5. Kernelul de executie, acord intre clienti PASS 2 · FAIL 0 · NOT MEASURED 1 check claim expected observed verdict kernel.acord the Besu endpoint and the Nethermind endpoint report an IDENTICAL state root for every one of 16 recent blocks, both directions agree agree (16 blocks) PASS kernel.lant each agreed block links to its parent on both clients, so the shared state roots sit on one continuous chain links links ok PASS kernel.dovezi a public execution-proof endpoint exists so a stranger can also check the validity proof over each window null null NOT MEASURED 5. Endpoint behaviour during the run PASS 1 · FAIL 0 · NOT MEASURED 0 check claim expected observed verdict punct-final.raspunsuri-nereusite this endpoint answered every one of 630 read-only questions on the first attempt, with no transport failure, no HTTP 5xx and no -32603. A failure HERE is about the endpoint, not the chain. 0 answer(s) only arrived after a retry, and 0 never arrived at all -- a caller who asked once and believed what came back would have been misled in the first case and stuck in the second 0 0 PASS Reproduce this report yourself The toolkit is a single download, installs nothing, and talks only to a public RPC endpoint. Node 18 or newer. curl -O https://aere.network/tools/verifica-lantul.tar.gz tar -xzf verifica-lantul.tar.gz && cd verifica-lantul node autotest.mjs # prove the toolkit can say NO node verifica.mjs --json report.json node genereaza-raport-conformitate.cjs report.json my-report.html Questions, or a run scoped to your own compliance requirements: [email protected] with subject "Post-quantum migration testbed". --- # AERE Validators, Live consensus state URL: https://aere.network/validators.html Fetched: 2026-09-15 AERE Validators, Live consensus state Live validator state All ten validators are operated by the Foundation today (ten validators since 2026-09-11), and this page does not pretend otherwise. The path to independent operators is the Independent Validator Program . connecting… · QBFT consensus, 0.5-second blocks, … validators · refreshed every 5s Public head , Validators online , BFT fault tolerance , Block age , Loading state… Validator address Status Loading… Source: rpc.aere.network via qbft_getValidatorsByBlockNumber · QBFT requires ⌈2N/3⌉ validators to finalize a block. Fault tolerance derived from live set. --- # Verified Contracts, AERE Network URL: https://aere.network/verified-contracts.html Fetched: 2026-09-15 Verified Contracts, AERE Network AERE Network, Chain ID 2800 Verified Contracts Independent, reproducible proof that the on-chain runtime bytecode of each contract listed on this page matches its published Solidity source. This uses a Sourcify-style bytecode and metadata comparison: the code running at each address is fetched with eth_getCode and compared byte for byte against the compiled artifact, with constructor immutables and library links masked and the embedded metadata hash checked. 34 Contracts checked 32 Full match 2 Partial match 0 No match, of the 34 checked What this page covers, and what it does not. This is a sample, not the whole deployment. Measured on 2026-08-01 against chain 2800: the canonical address registry ( sdk-js/src/addresses.ts ) holds 191 entries , of which 185 have live runtime code and 6 are the plain genesis accounts. The table below covers 34 of those 185. A contract that is not in the table has not been checked here, and its absence is not a pass. The No match count of zero is a statement about the 34 rows on this page only. Our own internal review of 2026-08-01 measured 28 live contracts whose runtime bytecode does not reproduce from this public repository , 20 of them canonical, and six of those have no candidate source in the tree at all. None of those 28 are rows below. Closing that gap, so that the reproducible set and the canonical set are the same set, is open work and we are stating it here rather than letting the four tiles above imply it is finished. What full and partial mean Full match The on-chain executable bytecode and the embedded metadata hash are byte-identical to the compiled artifact. This proves the exact source and compiler settings in this repository were deployed. Partial match The executable bytecode is byte-identical, but the trailing metadata hash differs. The deployed logic is this source, recompiled with slightly different metadata, for example a different set of surrounding source files, file paths, or comments in the compilation unit. No match The executable bytecode itself differs. The deployed code is not this source. Results Contract Address Status Compiler On-chain metadata hash Source metadata hash Post-quantum cryptography AereFalcon512Verifier NIST Falcon-512 lattice signature verifier, fully on-chain 0x4E8e9682329e646784fB3bd01430aA4bA54D8fFC Partial match 0.8.23+commit.f704f362 viaIR opt 1 6c9a7bfa03…5939be6d cd81e3d0ba…31986387 AereConsensusPQCAttestor Application-layer Falcon-512 attestation contract that records post-quantum attestations over finalised heights. It sits beside QBFT and is not part of it: block sealing and QBFT voting on chain 2800 are classical secp256k1 ECDSA and this contract does not change that. Measured live 2026-08-01, 4,050 bytes of runtime code. 0xf3681Aa6444F79562683C26f9d5c369A479c87dD Full match immutables 0.8.23+commit.f704f362 viaIR opt 1 74051ff8b9…b05f2682 74051ff8b9…b05f2682 AerePQCVerifier WOTS+ hash-based post-quantum signature verifier 0x1cE2949e8cE3f1A77b178aF767a4455c08ec6F82 Full match 0.8.23+commit.f704f362 viaIR opt 1 5c564f4210…77bc7afd 5c564f4210…77bc7afd AereLatticeVerifier Lattice ring-arithmetic verification core (n=74 demo) 0x60c06E6A3CC201B46A16650be096C6E45424dfD9 Full match 0.8.23+commit.f704f362 viaIR opt 1 2947eec885…80b671b6 2947eec885…80b671b6 Zero-knowledge AereZKMLVerifier Private MNIST inference verifier via SP1 Groth16 0xf1BF15d5018a35D21FBB4Ec868f062DF7C06783c Full match immutables 0.8.23+commit.f704f362 viaIR opt 1 ebe088ab99…c9eb27ed ebe088ab99…c9eb27ed AereProofAggregator Recursive SP1 proof aggregation (N inner proofs -> 1). DEPRECATED V1. It counted the folded inner-program keys but never required them to be registered, so an aggregation over an unvetted inner program was recorded as if it were legitimate. Both of its historical records are genuine and no funds are involved. Superseded by AereProofAggregatorV2 0x944dE720D6C9696Bdf10b6E2F00dd21ABB1A2b4C, which rejects an unregistered inner program outright, measured live on 2026-08-01 with 4,663 bytes of runtime code. Integrate against V2. 0x6a260238890E740dB12b371E0C5d17a2470F84C5 Partial match immutables 0.8.23+commit.f704f362 viaIR opt 1 b053aa6fb7…2cbe2894 640b750573…005f2e31 AereZKScreen v3 sanctions-screening ZK verifier (root-binding soundness fix) 0x3A097A459FD26aC79573aCB5adB51430e473C2f1 Full match immutables 0.8.23+commit.f704f362 viaIR opt 1 a0802ed2ff…0280db46 a0802ed2ff…0280db46 AereCompliancePoolSP1Verifier SP1 verifier binding for compliant privacy pool 0xE2D3fa91b680E835c971761ba75Fde0204AEF95E Full match immutables 0.8.23+commit.f704f362 viaIR opt 1 64d09e02a5…9b62238d 64d09e02a5…9b62238d AereAIProof EIP-712 signed AI attestation registry (signatures, not zk proofs) 0xFf92c669AbF4C1DAE31eBFCC017764036d9D97e6 Full match immutables 0.8.23+commit.f704f362 viaIR opt 1 5cafa033f2…01c85cd8 5cafa033f2…01c85cd8 Confidential compute AereConfidentialCompute Threshold-MPC (BGW / Shamir over BN254) result verifier 0x2120350c124e4Cae2C9FfBB6E4942DB1d380c287 Full match immutables 0.8.23+commit.f704f362 viaIR opt 1 640d23958c…ed12bb08 640d23958c…ed12bb08 DePIN AereComputeMarketV2 DePIN compute coordination + settlement rail V2 0x33E3B06A7344f0B201fdD11B18bC244c84dbca32 Full match immutables 0.8.23+commit.f704f362 viaIR opt 1 1fa92765c5…6da6f345 1fa92765c5…6da6f345 AereComputeMarket DePIN compute market V1 (kept live) 0xf0c8178a5d9feb0f70C5f184e79edeEDaddcF350 Full match immutables 0.8.23+commit.f704f362 viaIR opt 1 7a09a7a8c7…e90900de 7a09a7a8c7…e90900de Flywheel sAERE ERC-4626 staked-AERE receipt with 7-day drip 0xA2125bE9C6fd4196D9F94757Df18B3a2A5e650b0 Full match immutables 0.8.23+commit.f704f362 viaIR opt 1 6766bd507d…4bf55c62 6766bd507d…4bf55c62 AereSink Immutable 3-bucket fee router (burn/buyback/yield) 0x69581B86A48161b067Ff4E01544780625B231676 Full match immutables 0.8.23+commit.f704f362 viaIR opt 1 104b00d0a6…8090f9b6 104b00d0a6…8090f9b6 AereCoinbaseSplitterV2 Block-reward splitter into fee sink 0x8C1A48eFA57b66fEE743A00E3899c29ad3Fd27b4 Full match immutables 0.8.23+commit.f704f362 viaIR opt 1 2fd7b49c78…b5405680 2fd7b49c78…b5405680 Compliance AereCompliancePool Sanctions-gated + Travel-Rule compliant privacy pool (DEPRECATED V1 — use AereCompliancePoolV2 0xB144…3465) 0x79735c31F289F7A4d6Be3E02aaB70B544796D41d Full match immutables 0.8.23+commit.f704f362 viaIR opt 1 d6707147af…b694c577 d6707147af…b694c577 AereSanctionsRegistry OFAC-style Merkle sanctions registry 0xb7d235718D99560F6EA4Fc5eAea2F8a306A3Cacf Full match 0.8.23+commit.f704f362 viaIR opt 1 59c8ae4a5e…a0f1f307 59c8ae4a5e…a0f1f307 AereTravelRuleHashRegistry FATF Travel-Rule hash commitments 0xcF0E2e010E6e4506672019b1e570874AEeBC4c84 Full match 0.8.23+commit.f704f362 viaIR opt 1 9bc7899804…e6c21bca 9bc7899804…e6c21bca AereForensicEventRegistry Forta-style forensic event registry 0x4a7526A068e5DDE9788f6571E4A99095b14C6fff Full match 0.8.23+commit.f704f362 viaIR opt 1 15de53259f…26a69bc7 15de53259f…26a69bc7 ChainalysisOracleWrapper Chainalysis-compatible sanctions oracle wrapper 0x1B7Be82C80f368f75Cb3807B1bc05E86A498f85c Full match 0.8.23+commit.f704f362 viaIR opt 1 cfdd35b443…df54fd5c cfdd35b443…df54fd5c AereAttestationGateway Attestation gateway 0x9bdacA8dfF39Fc688e8D3c4bbA13bCFC0580c325 Full match immutables 0.8.23+commit.f704f362 viaIR opt 1 b495cf3eac…5ce97c7c b495cf3eac…5ce97c7c AereBestExReceipt MiCA Article 78 best-execution receipts 0x3c80BD6fa0d9a2274c7fBD5943B5EC03313D92d7 Full match immutables 0.8.23+commit.f704f362 viaIR opt 1 fc2dd9d20e…c688d1c1 fc2dd9d20e…c688d1c1 Settlement AereSettlementHub Settlement hub into fee sink. DEPRECATED V1 , two audited defects: a permissionless residual sweep could push a live intent's parked funds into the sink and brick the settlement, and an unclaimed deposit had no refund or timeout path. It holds no value. Superseded by AereSettlementHubV2 0xAe1c8F4d8d14BDE6121aCD525Af5A93f52946F41, measured live on 2026-08-01 with 7,995 bytes of runtime code. Do not route new deposits or intents to V1. 0x2a02fD80c16293D2B5D8a295F31D1a6E6a582c02 Full match immutables 0.8.23+commit.f704f362 viaIR opt 1 7da334b9dc…fd93a82a 7da334b9dc…fd93a82a AereStateChannels Bidirectional payment channels, 24h challenge 0x64488eda27fA5b55A277ac8D386E169DC78cd7b6 Full match immutables 0.8.23+commit.f704f362 viaIR opt 1 3974330c0e…05486a1f 3974330c0e…05486a1f Agentic AereAgent Machine-account registry (prepaid, rate-limited) (DEPRECATED V1 — use AereAgentV2 0x3FAc…4490) 0xE96396B4b596B3A74e4195Be12aADd5257863536 Full match immutables 0.8.23+commit.f704f362 viaIR opt 1 8e33bc1665…f607b6af 8e33bc1665…f607b6af AERE402Facilitator x402-compatible EIP-712 payment facilitator (DEPRECATED V1 — use AERE402FacilitatorV2 0xFC2f…91de) 0xbA6e6700D629a5E3C885778a42885a944CA84E56 Full match immutables 0.8.23+commit.f704f362 viaIR opt 1 ccd4b7d558…2cf73985 ccd4b7d558…2cf73985 Security AereBugBountyVault Bug-bounty payout vault, 5% max 0x253fDCb248649396CBDaD320F81869A570d69cD3 Full match immutables 0.8.23+commit.f704f362 viaIR opt 1 2b30d09b42…be9d615b 2b30d09b42…be9d615b Rollups AereRaaSFactory Permissionless rollup-as-a-service factory (DEPRECATED V1, use AereRaaSFactoryV2 0xB7F8…39Ab) 0x8C1b0018ab8C4299a75621a4BdD3cF26971B26Cd Full match immutables 0.8.23+commit.f704f362 viaIR opt 1 50803ccd1f…d47fef6c 50803ccd1f…d47fef6c Accounts AereDelegate7702 EIP-7702 delegation target (V1 deprecated, drainable; superseded by AereDelegate7702V2 0xC6d18e0Ce1B6467d952e31315505E0190a4A3310) 0x5673D92080efbd0987402E9335c14200d0a5EaeF Full match 0.8.23+commit.f704f362 viaIR opt 1 970d0ebc79…c06ad4a5 970d0ebc79…c06ad4a5 AereDelegationRegistry Delegation registry 0x6c25c07D134713b6C2F8E19D807423f022903D63 Full match 0.8.23+commit.f704f362 viaIR opt 1 0b5d4124b2…859d3062 0b5d4124b2…859d3062 Lending AereInsuranceFund Insurance fund, 7-day cooldown 0x5Ab95C549c2A2b07913Df7edD4a16fd108B7CAAC Full match immutables 0.8.23+commit.f704f362 viaIR opt 1 eb2fcbb11c…9778237b eb2fcbb11c…9778237b AereNavOracle NAV oracle 0xC8D12E44f10b03477330b35115b432750831fEBD Full match 0.8.23+commit.f704f362 viaIR opt 1 4bdbd5c9e0…51a6a229 4bdbd5c9e0…51a6a229 AereLendingOracle Multi-source lending price oracle 0xc0f18A567067F1B84BDf75eDEbFaDdCBb70A4C49 Full match 0.8.23+commit.f704f362 viaIR opt 1 76aa88d1e6…fa5a6e58 76aa88d1e6…fa5a6e58 AereLendingMarket Isolated sAERE/WAERE lending engine (proof market) 0x2C2d39dB711C0A33De04Dc74b1E22f4760FD4bb0 Full match immutables 0.8.23+commit.f704f362 viaIR opt 1 62a3884814…92e8f4c9 62a3884814…92e8f4c9 Download the full verification manifest (JSON) Reproduce this yourself Every result on this page is reproducible from the public source tree against the public RPC. No trust in AERE is required. # from aerenew/contracts, using the committed Hardhat build artifacts node scripts/verify-onchain-source.js # verify a single address against a specific artifact node scripts/verify-onchain-source.js \ --address 0x4E8e9682329e646784fB3bd01430aA4bA54D8fFC \ --artifact artifacts/contracts/pqc/AereFalcon512Verifier.sol/AereFalcon512Verifier.json \ --name AereFalcon512Verifier The verifier has zero external dependencies. It reads deployedBytecode from the committed artifact, fetches eth_getCode from https://rpc.aere.network , masks immutables and library links from the compiler build-info, parses the CBOR metadata trailer, and reports full, partial, or no match. Rebuild this page with node scripts/gen-verified-page.js . Honest limitations This is a bytecode and metadata match , the same method Sourcify uses. It proves the deployed runtime bytecode corresponds to the published source. It does not re-run the Solidity compiler in this page, and it is not a formal audit of the source logic. Full versus partial. A full match binds the exact metadata hash, so the precise source, comments, and settings are pinned. A partial match proves identical executable logic while the metadata trailer differs, which is expected when a contract was compiled in a different unit at deploy time. Both are honestly labelled above, none are hidden. Immutables and libraries. Constructor immutables, such as a token or verifier address baked in at deploy, and any library link addresses are masked before comparison, following the Sourcify convention, since they are deploy-time values rather than source. Scope. This covers AERE's own flagship and audit-pass-stack contracts. Vendored third-party verifiers deployed from their own upstream build, such as the Succinct SP1 Groth16 verifier, are consumed by the contracts here but are not re-derived from this repository. Follow-up. A full hosted Sourcify or Blockscout verification instance, which recompiles from standard-JSON input and serves per-contract source browsing, is a larger piece of infrastructure and is planned separately. Generated 2026-07-10T05:20:46.305Z Chain ID 2800 Snapshot at block 8873713, not re-measured RPC https://rpc.aere.network Method: Sourcify-style bytecode and metadata match --- # AereVesting, Linear vesting with cliff URL: https://aere.network/vesting.html Fetched: 2026-09-15 AereVesting, Linear vesting with cliff AereVesting Coming soon. This feature is built and on the AERE roadmap, its on-chain contracts are not yet deployed. Actions are disabled until launch. Linear release with optional cliff. Each grant tracks beneficiary, total amount, start time, cliff, duration, revocability. The owner (the Foundation account, a single-key EOA today; a multisig is roadmap) can revoke revocable grants, vested-but-unclaimed tokens stay claimable, unvested tokens return to the owner. Vesting registry AereVesting Not yet deployed Total grants , Native AERE in contract , Your address , Connect Wallet Refresh Look up grants Search , Grant lifecycle Owner creates grant ──► start time cliff linear vest end │ │ │ │ Beneficiary balance: 0 ──────────► 0 ─────────► proportional─► totalAmount call release() to claim vested Optional: owner.revoke() ──► unvested portion returns to owner; vested-but-unclaimed remains claimable by beneficiary. Use cases: - Foundation alloc 180M AERE released over 4 years with 1-year cliff - Team grants (4yr / 1yr cliff) - Investor lock-ups - Bug-bounty payouts - Market-maker incentives --- # AERE Network Whitepaper URL: https://aere.network/whitepaper.html Fetched: 2026-09-15 AERE Network Whitepaper AERE Network Whitepaper · Chain ID 2800 Dark Whitepaper · Chain ID 2800 · 0xAF0 AERE Network A non-custodial EVM Layer 1 built for settlement that stays safe when the cryptography changes. Final as math, safe when the math changes. 0xAF0 0.5s finality QBFT · single-slot · post-quantum verifiers Consensus 0.5s single-slot BFT Execution EVM Pectra + Fusaka Supply 2.8B fixed, no inflation Chain ID 2800 PQC verifiers 6 on-chain Version 2.1.172 Status 2026-09-14 Foundation · Seychelles Print or save as PDF Version and verification Version 2.1.172 Content last changed 2026-09-14 Figures measured at block 18,570,666 Measured at 2026-09-14 19:33:13 UTC Content hash (SHA-256) 05c8edac4b654c592464becaef623955fa2331fe99f3ea168c35182656abf38b Document hash (SHA-256) ada20b0701d832477f929b935a751ed24566805450200887904297837e18957b Editorial hash (SHA-256) 313d610ad2b29a72c12e237b932f58f7d93edef95ca8ad8d8a0a6e6a644b117f Recompute the content hash yourself. This command fetches the published page, extracts the delimited content region, the measured figures, the table of contents and the nine chapters, and hashes exactly that. It is the hash of what this whitepaper claims, and edits to the surrounding page cannot move it: curl -sL https://aere.network/whitepaper | sed -n '//,//p' | tr -d '\r' | sha256sum To verify the exact bytes of the whole page instead, remove this version block (so the hash cannot depend on itself) and hash the rest. This stricter hash moves on any edit anywhere in the page, including ones that do not touch the whitepaper's content: curl -sL https://aere.network/whitepaper | sed '//,//d' | tr -d '\r' | sha256sum How this version number works. The version changes only when the content changes. It is not a date stamp and must never be incremented on a schedule. A number that moves every day whether or not anything was written tells a reader nothing; a number that moves only on substance, and can be checked by hashing the document, tells them everything. Three hashes, because they answer three different questions. The content hash proves the whitepaper's claims are the ones we published, and is the one to check first. The document hash proves you are reading the exact bytes we published, and it moves whenever anything moves, including a refreshed on-chain figure or a cosmetic page edit. The editorial hash ignores the generated figures entirely, so it moves only when the writing, structure or claims change. That last one is tied to the version number, which is why refreshing a measurement does not manufacture a new version. Every figure marked as measured in this document is read from a public node by scripts/generate-whitepaper-figures.mjs and carries the block height it was read at. Values that cannot be read from a node, such as the fixed genesis supply or the throughput ceiling, are labelled as specification rather than presented as measurements. If the node cannot be read, the generator refuses to build rather than republish a stale number. Full version history and hashes · Machine-readable figures (JSON) Measured on chain These figures are not typed by hand. They are read from a public AERE node and regenerated, all at one pinned block height so the set is internally consistent. Every value below was read at block 18,570,666 , at 2026-09-14 19:33:13 UTC . If the node cannot be read, the build fails rather than republishing a stale number. Chain ID 2800 Measured Block interval 593.6 ms Measured Base fee 1 Gwei Measured Validators 10 Measured Fault tolerance f = 3 Measured Nakamoto coefficient 1 Specification PQC precompiles live 5 Measured Burn rate 37.5 % Measured Burn cap 50 % Measured Lifetime burned 0.137352 AERE Measured Total supply 2,800,000,000 Specification Throughput ceiling 273,000 TPS Withdrawn 2026-08-19 Consensus is hybrid at every 128th block (every 32nd block until block 17,225,968, on 2026-09-05). The 10 validators sign every block with secp256k1 ECDSA under QBFT; since 2026-09-04 every 128th block (every 32nd block until block 17,225,968, on 2026-09-05) additionally carries a hybrid post-quantum certificate, Falcon-512 and SLH-DSA-SHA2-128s seals of at least six validators (of ten since 2026-09-11), bound under the block hash. Post-quantum cryptography is also available at the account and application layer, through the precompiles below. All 10 validators are Foundation-operated, which is why the Nakamoto coefficient above is stated as 1 and marked as specification: a node can prove there are nine distinct addresses, it cannot prove they are independently run. Post-quantum verifiers, proved live rather than asserted. Mainnet-live at block 18,570,666 : 0x0AE1, 0x0AE2, 0x0AE3, 0x0AE4, 0x0AE5 , active since the AerePQC fork, whose activationTime of 1783820272 the network reports directly through eth_config ; block 9,189,161 is the first block whose timestamp is at or after it. That block contains no transactions, because a fork activation is a client configuration change and not a transaction, so its significance is its timestamp rather than its contents, and it is not the place to look for evidence. Verified as not present on mainnet, and therefore testnet-only: 0x0AE6, 0x0AE7 . Presence is measured by gas differential against a control address holding no code. An address that charges more than the control ran code; one that charges exactly the control did not. A returned value alone would prove nothing, because a live precompile given malformed input and an address that does not exist both return empty. Measured at latest on both public endpoints, in gas above the codeless control: Falcon-512 40,000, Falcon-1024 75,000, ML-DSA-44 55,000, SLH-DSA-128s 350,000, SHAKE256 60 plus 12 per 32-byte word, and 0x0AE6 and 0x0AE7 exactly zero. The probe is calibrated first against the IDENTITY precompile at 0x04, whose cost the EVM specification fixes at 15 plus 3 per word, and it reproduces that formula exactly. Those five figures are the literal gas constants in the client source, so the measurement and the published code can be compared line for line. The burn, at its true scale. The burn takes 37.5 percent of the validator coinbase reward , capped by contract at 50 percent. It is not a base-fee burn. Lifetime burned to date is 0.137352 AERE, which is 0.049 parts per billion of supply, or 0.0000000049 percent. Validator coinbase revenue is effectively zero, so there is almost nothing for the burn to take a share of. AERE is not deflationary today , and the burn should be read as mechanism that is live and correct, not as supply pressure that is currently meaningful. The splitter contracts' own cumulative counters agrees with the vault balance, which is the cross-check that keeps this number honest. Block interval, target against measured. The configured QBFT target is 500 ms. The measured long-run mean is 593.6 ms, taken over a 20,000 block window ending at the measurement block, so the figure is stable rather than an artefact of whichever handful of blocks was sampled. The window deliberately includes degraded periods: a validator outage, for example, makes every rotation absorb a round-change timeout and pushes this mean well above the target until the validator returns, and the figure is published anyway, because a measurement that excluded the bad hours would be an advertisement. Where this document describes blocks or finality as sub-second, it is describing the configured target; whether the network currently delivers it is decided by this measured figure, not by the target. Throughput. The 273,000 TPS figure once given as an architectural ceiling implied by the block parameters has been withdrawn: its stated derivation does not reach that number, and no such rate has ever been measured on the live chain. Contents Overview and Thesis Architecture and Consensus On-Chain Post-Quantum Verification Zero-Knowledge and Verifiability Accounts and Onboarding Fair Ordering and Interoperability Identity, Compliance, Privacy Token Economics and the Flywheel Governance, Roadmap, Limits 01 Overview Overview and Thesis What AERE is, the thesis that shapes every subsystem, and the current state of the network stated plainly, so that nothing downstream reads as spin. Chain 2800 · genesis-v2 2026-05-07 · companion deep-dives: docs/ROADMAP-PHASES.md , research/pqc-onchain-verification.md AERE Network is an EVM-compatible Layer 1 blockchain designed for one job done to a high standard: settlement that is fast, final, and durable against the cryptographic transition the whole industry is walking toward. Parameter Value Network AERE Network mainnet, chain ID 2800 ( 0xAF0 ) Consensus QBFT on Hyperledger Besu and, since 2026-09-11, one Nethermind validator; ten validators (f=3, quorum 7-of-10), 0.5-second blocks (measured mean 0.557 s on 2026-08-01), single-slot BFT finality Execution EVM, Ethereum-parity ruleset (Pectra plus Fusaka) Supply 2,800,000,000 AERE, fixed at genesis-v2 (2026-05-07), no inflation Status date 2026-08-02 Source of truth for addresses sdk-js/src/addresses.ts Foundation (owner of most Ownable contracts; 73 of the 80 registry contracts that answer owner() return it, 7 return other single-key accounts, and none returns a timelock, measured 2026-09-14 ) 0x0243A4f47D44b40b65D33f20329dE20D00c6f3C3 On reading this document Every contract address in this document is copied verbatim from the canonical registry sdk-js/src/addresses.ts . Contracts that are deployed and demonstrated but not yet promoted into that registry are named by contract and artifact rather than by canonical address. Every live capability names the contract that backs it; every capability that is not yet live is labelled in development or roadmap with the honest dependency that unlocks it. The tone is deliberate: a young, single-operator chain earns trust by being precise about what is real and what is planned, and every claim here is meant to be checked on-chain rather than taken on faith. Companion deep-dives cited throughout this document, each of which carries its own honesty preamble and its own verbatim address list: the phased roadmap ( docs/ROADMAP-PHASES.md ), the post-quantum research paper ( research/pqc-onchain-verification.md ), and the six subsystem specifications under research/specs/ covering the zero-knowledge stack, the anti-MEV mempool, account abstraction, parallel execution, identity and compliance, and the flywheel economics. This overview summarizes and frames; the companion documents carry the full depth, the exact on-chain transaction hashes, and the per-contract trust boundaries. Abstract AERE Network is an EVM-compatible Layer 1 blockchain, chain ID 2800, built on Hyperledger Besu with QBFT consensus. It is designed for one job done to a high standard: settlement that is fast, final, and durable against the cryptographic transition the whole industry is walking toward. Blocks are produced every half second and reach single-slot Byzantine-fault-tolerant finality in well under a second, so a confirmed transaction does not later reorganize away. The execution environment tracks Ethereum's own ruleset through the Pectra and Fusaka hard forks, giving functional parity with Ethereum mainnet, so contracts, wallets, and tooling that work on Ethereum work here unchanged. Supply is fixed at 2,800,000,000 AERE, set at genesis and never inflated; the token economics run on a burn-and-yield flywheel funded by real fees, not on new issuance. What distinguishes AERE from a conforming EVM chain is a suite of post-quantum signature verifiers that run on-chain today at the application and account layer. Full, spec-complete verifiers for the hash-based schemes WOTS+, XMSS, and SLH-DSA (FIPS 205), and the lattice schemes Falcon-512, Falcon-1024, and ML-DSA-44 (FIPS 204), each validated bit-for-bit against official NIST Known-Answer-Test and ACVP vectors, are deployed as ordinary immutable contracts. We are not aware of any other public chain that verifies all of these on-chain. This capability is the concrete meaning of the AERE thesis, "Final as math, safe when the math changes." We are equally clear about what AERE is not yet. The network runs ten validators, all operated by the Foundation, on two clients (nine Besu, one Nethermind since 2026-09-11), only three-fault Byzantine tolerance today (quorum seven of ten), no external security audit, thin real usage, and no exchange listing. Consensus is hybrid post-quantum in a precise and limited sense, since 2026-08-14: classical secp256k1 ECDSA QBFT finalizes every block, and every 128th block (every 32nd block until block 17,225,968, on 2026-09-05) (an anchor block) must additionally carry a certificate of at least three valid Falcon-512 validator seals (f+1 of the nine validators of that time) (raised at block 14,961,456, August 21, 2026, to six seals, then a full 2f+1 quorum of nine; since the set grew to ten on 2026-09-11 the enforced minimum is still six, above f+1 but below the ten-validator quorum of seven) or it is rejected. Correction published 2026-08-19: this document previously stated that from block 14,050,000 every block required a 2f+1 (six-of-nine) post-quantum quorum to finalize. The per-block Falcon quorum rule armed at that height is, in the shipped code, retired in favour of the anchor rules from block 13,014,000, and a re-reading of the code and of the chain (non-anchor blocks carry no Falcon seals) shows it changed no enforcement; that statement is withdrawn. What is enforced is the anchor certificate described here. Since block 13,014,000 the block hash itself covers a post-quantum certificate: every 128th block (every 32nd block until block 17,225,968, on 2026-09-05) carries, inside the hashed part of its header, a 32-byte digest that binds Falcon-512 seals from the validators. Since 2026-08-14 every node enforces a minimum of three seals per anchor block; three is f+1 for this set, the guarantee that at least one honest validator signed. At block 14,961,456 (August 21, 2026) the enforced minimum was raised to six of nine, a full 2f+1 quorum at that size; the set grew to ten on 2026-09-11 and the minimum stays six, below the new quorum of seven. Since 2026-08-16 the cap is nine and, measured on 2026-08-19 across the most recent anchors, certificates carry eight or nine seals, all nine signers appearing (measured before the set grew to ten on 2026-09-11). The key manifests behind those seals are published at /pq/manifests/, pinned in an immutable on-chain contract, and a public tool verifies every seal cryptographically from a public RPC endpoint alone. That binds a post-quantum certificate into the chain's hash structure so it cannot be stripped or altered without changing the hash; it does not make block production post-quantum. These are stated plainly at the front so that nothing downstream reads as spin. The rest of this whitepaper describes a real, working foundation and an honest, gated path to change each of those facts in turn. The thesis: final as math, safe when the math changes Two words in that thesis carry the whole design. Fig 1.1 The thesis, in two halves: deterministic finality now, and a migration path before the cryptography breaks Final as math QBFT single-slot BFT finality n-1 n n+1 supermajority commit final on commit, no reorg final in well under 0.5s + 0.5s Safe when the math changes migrate account keys before the break secp256k1 Shor-breakable migrate Falcon / ML-DSA / SLH-DSA quantum-durable account and settlement layer, not consensus What it shows. The left half is deterministic finality: a QBFT block is final the moment a supermajority commits it, so there is no confirmation-depth wait and no deep-reorg probability. The right half is durability: because a public ledger permanently exposes keys and signatures, AERE lets accounts migrate to post-quantum keys before a cryptographically relevant quantum computer exists. The honest scope, drawn in amber, is that this durability is at the account and settlement layer; consensus signatures remain classical. Final as math. AERE uses QBFT, a Byzantine-fault-tolerant consensus protocol, not longest-chain proof-of-work or probabilistic proof-of-stake. Under BFT finality, once a supermajority of validators commits a block, that block is final by the protocol's own rules: there is no confirmation-depth heuristic to wait through and no probability of a deep reorganization that quietly rewrites a settled transaction. Finality is a mathematical property of the commit, reached here in a single slot in well under a second. For a settlement layer this is the point. A payment or a trade that the chain calls final is final, and downstream systems can act on it immediately rather than waiting out a reorg window. Safe when the math changes. The security of today's account signatures rests on the hardness of the elliptic-curve discrete logarithm, which Shor's algorithm solves in polynomial time on a sufficiently large quantum computer. A public ledger is uniquely exposed to this because it publishes, permanently and to everyone, the two artifacts an attacker most wants: account public keys and the signatures made under them. Signatures are public, so nothing needs to be harvested and decrypted here; the ledger-specific threat is retroactive forgery. The break can come years later, when a cryptographically relevant quantum computer exists, and it applies retroactively to any account whose key material is already public: a recovered key can sign new statements about old history. (Harvest-now-decrypt-later, by contrast, threatens encrypted data, which a ledger also carries wherever payloads are confidential.) AERE's response is to make the chain able to verify post-quantum signatures now, so that users can migrate account and settlement authorization onto quantum-resistant keys well before the break arrives. Hash-based schemes (WOTS+, XMSS, SLH-DSA) rest only on the pre-image and collision resistance of their hash functions, which a quantum adversary attacks only with Grover's quadratic speedup, absorbed by parameter sizing. Lattice schemes (Falcon, ML-DSA) rest on structured-lattice problems for which no efficient quantum algorithm is known. AERE verifies both families on-chain today. The honest boundary, restated because it matters, is that this durability is at the account and settlement layer; consensus signatures remain classical, and making consensus itself post-quantum is a separate, explicitly approved decision, delivered through coordinated per-node activation heights rather than a re-genesis, and never a silent implication of the thesis. Design philosophy Five commitments shape every part of the system described in the chapters that follow. Additive, not invasive. Post-quantum security can be introduced at two very different layers. Changing consensus so that validators sign blocks with a post-quantum scheme touches the client, the gossip and finality protocols, and every operator. Changing the account and settlement layer is additive: a contract that verifies a Falcon or SLH-DSA signature deploys like any other contract, and a smart account can bind its authorization to a post-quantum key with no protocol change at all. AERE takes the additive path deliberately, which is what lets it offer a usable quantum-resistant primitive today while leaving consensus untouched. The post-quantum research paper ( research/pqc-onchain-verification.md ) develops this argument and its limits in full. Parity with Ethereum, not a private dialect. AERE tracks Ethereum's ruleset rather than forking away from it. Pectra and Fusaka are both active, so the chain has EIP-7702 account delegation, the EIP-2537 BLS precompiles, the RIP-7951 secp256r1 precompile for native passkey verification, transient storage, and the EIP-7825 per-transaction gas cap of 16,777,216 (2 24 ) gas. AERE keeps that cap deliberately rather than leaning on an unbounded local gas limit, so the chain stays a functional peer of Ethereum mainnet and its constraints are honest ones that mainnet contracts also face. One measurement note, because this number is used as a reference point elsewhere in the document: the cap is a client-level transaction validation rule, and it is not readable from chain state. It has not been measured here, since the only conclusive test is broadcasting a transaction above the cap. What is measured is the block gas limit in the live header, 9,007,199,254,740,991, so the 2 24 figure is a client rule rather than something derivable from the block limit. The account-abstraction spec ( research/specs/spec-account-abstraction.md ) details how the wallet layer is built on these features. Immutable, ownerless where it matters. The post-quantum verifiers, the burn-and-yield router, and the burn endpoint are deployed with no owner, no admin, and no upgrade path. They are pure logic: given the inputs, they return the same decision every time, and no key can change that. Ownership concentration is a real weakness of the current network, discussed below, but it is bounded: the contracts that carry the core guarantees cannot be altered by the Foundation or anyone else. Where a contract does have an owner, this whitepaper names that owner as the Foundation account and does not pretend otherwise. Fixed supply, real-fee flywheel, no adaptive issuance. Total supply is 2,800,000,000 AERE, capped at genesis-v2 and never increased. No mechanism in the system mints new tokens. The supply-reduction and staking-yield mechanism is an immutable three-bucket revenue router, AereSink 0x69581B86A48161b067Ff4E01544780625B231676 , which splits fee inflow on a fixed 15 / 40 / 45 basis across burning AERE, buying back and burning AERE, and lifting the exchange rate of the liquid-staking receipt sAERE 0xA2125bE9C6fd4196D9F94757Df18B3a2A5e650b0 . AERE is not deflationary today, and this whitepaper does not describe it as such. The router is live, immutable and ownerless, and it burns strictly in proportion to validator coinbase reward. That reward is currently zero, for two independent reasons given in full in Chapter 6: the genesis QBFT configuration declares no blockreward , and the 1 Gwei base fee is destroyed by EIP-1559 rather than paid to the proposer. Lifetime burned to date is 0.13735259 AERE against a fixed supply of 2,800,000,000 AERE, readable at any time as the balance of AereFeeBurnVault 0x696afDF4f814e6Fd6aa45CE14C498ed9375fB2c6 . We publish that figure rather than imply a larger one. Staking rewards are a finite, reserve-funded subsidy today, with the intended end-state that real protocol-fee volume, not the reserve, pays stakers. The flywheel spec ( research/specs/spec-flywheel-economics.md ) states the exact formulas and reserve mechanics. AERE is the network's only token; there is no stablecoin issuance and no second asset. Honesty as a credibility asset. A young, small, single-operator chain earns trust by being precise about what is real and what is planned, not by rounding up. Every live capability in this whitepaper names the contract that backs it, with the address copied verbatim from the canonical registry. Every not-yet-live capability is labelled in development or roadmap and states the honest dependency that unlocks it: code, money, people, or a founder signature. Contracts that are deployed but not yet promoted into the canonical registry are referred to by name and artifact rather than having their addresses printed as canonical. This discipline is not decoration; it is the reason a reader can check the claims rather than take them on faith. Current state, stated plainly This is what runs on mainnet 2800 today. It is a complete and real foundation. It is not a decentralized or audited one yet, and both halves of that sentence are stated here so nothing downstream has to walk anything back. A complete, real foundation 0.5-second blocks, single-slot BFT finality (halved mid-chain at block 2,137,652) EVM parity: Pectra at block 2,075,341, Fusaka at block 2,106,597 Fixed supply of 2,800,000,000 AERE across six genesis wallets Six NIST KAT-validated post-quantum verifiers live on-chain Deployed stack: WAERE, staking, sAERE and AereSink, a proven lending engine, a multi-prover zk surface, a rollup validity anchor Not decentralized or audited yet Ten validators, one operator (Foundation), three-fault Byzantine tolerance at n=10 (quorum 7-of-10) Two producing clients since 2026-09-11: nine Besu validators and one Nethermind validator; until then the second client only validated and followed mainnet No external audit of contracts or client changes yet Thin usage, no listing, no fiat on-ramp; PQC scope is not consensus What is live and working. Besu QBFT with 0.5-second blocks, halved from one second mid-chain at block 2,137,652, and single-slot BFT finality. The EVM ruleset is Pectra, activated at block 2,075,341, plus Fusaka, activated at block 2,106,597, for functional parity with Ethereum mainnet. Supply is fixed at 2,800,000,000 AERE across six genesis wallets (100M Strategic Investor, 180M Foundation, 1.4B Reserve (scheduled), 560M Ecosystem Reserve, 420M Team Reserve, 140M Airdrop Reserve). The deployed and Foundation-controlled stack includes the wrapped token WAERE, the staking pool, the sAERE and AereSink flywheel plumbing, a lending engine proven end to end on a proof market, a multi-prover zero-knowledge verification surface behind a route-by-selector gateway, and a rollup validity anchor, AereRollupValidity 0x38772063572DF94E90351e44ccbBEefD5F497fbd , whose first epoch was recorded from a real SP1 Groth16 proof. A design ceiling on the order of 273,000 transactions per second was once derived from the block parameters; that figure has been withdrawn (its stated derivation does not reach it), it was never a measured or sustained figure, and realized throughput on the live network is a small fraction of it. The post-quantum verifier suite. This is the genuinely differentiated part of the current state, and it is worth stating precisely: we are not aware of any other public EVM Layer-1 that exposes five NIST post-quantum signature schemes as native precompiles on mainnet, selectable at runtime by any contract or any eth_call , at a published public RPC endpoint. Not a testnet, not a demonstration contract, not an announcement of intent. Post-quantum signature verification as such is no longer unique to AERE, and this document says so rather than pretending otherwise: other public chains shipped it during 2026 (QoreChain announced a fully post-quantum mainnet transaction on 2026-07-02; Algorand runs native Falcon accounts on mainnet since August 2026). What we still know of no other public chain doing is stated in the consensus chapter: a post-quantum validator certificate under the block hash, and post-quantum seals carried on every consensus message (emitted by all validators since 2026-09-02, ten of them since 2026-09-11; enforcement of those seals is not yet armed), both verified independently by a second client implementation. Five precompiles went live at block 9,189,161 and have been serving traffic since: Falcon-512 at 0x0AE1 , Falcon-1024 at 0x0AE2 , ML-DSA-44 at 0x0AE3 , SLH-DSA-128s at 0x0AE4 and SHAKE256 at 0x0AE5 . Five algorithms rather than one is the substantive part of the design: a contract can select a lattice scheme or a hash-based scheme at runtime, so an application is not hostage to a single family surviving cryptanalysis. Two further precompiles, ML-KEM-768 and a Falcon hash-to-point helper, exist on testnet only and are deliberately not counted here. Six full, spec-complete, official NIST KAT-validated verifiers run on-chain: the hash-based WOTS+ (AerePQCVerifier), XMSS-SHA2_10_256 (AereXmssVerifier), and SLH-DSA-SHA2-128s (AereSphincsVerifier), all three of which record on-chain, alongside the lattice schemes Falcon-512 (AereFalcon512Verifier), which also records on-chain, and Falcon-1024 (AereFalcon1024Verifier) and ML-DSA-44 / Dilithium2 (AereMLDSA44Verifier). Chapter 3 carries the full table with each contract's verbatim address, cryptographic family, and on-chain status. We are not aware of any other public chain that verifies all of these on-chain. Two of the six used to be the honest catch. Falcon-1024 (a full record transaction costs roughly 21.7M gas) and ML-DSA-44 (roughly 52.9M gas) both exceed the 2 24 per-transaction cap in pure Solidity, so their pure-Solidity verifiers stay read-only eth_call references. Their cryptography is identical to the recorded schemes and demonstrated against the same official vectors; the only obstacle was the execution budget. That obstacle is removed by a native-precompile path that was built and KAT-validated on an isolated Besu 26.4.0 scratch fork (chain ID 28099) and then activated on mainnet 2800 by the AerePQC fork at block 9,189,161 (2026-07-12). On mainnet every scheme now records within the cap, with measured verify-and-record gas of Falcon-512 86,336, Falcon-1024 145,496, ML-DSA-44 351,050, SLH-DSA-SHA2-128s 558,276, and SHAKE256 21,470, all far under 16,777,216, and all NIST KAT vectors including negatives pass (41 of 41 accept and reject cases). Activation was a coordinated client-only hard fork with no re-genesis that also carried the extended EIP-2935 block-hash lookback (an 8191-block window); it added the precompiles and EIP-2935 only and did not change consensus, and Block-STM parallel execution was not part of it and remains a testnet demonstration. Since 2026-08-14 AERE mainnet consensus is hybrid in a precise and limited sense: every 128th block (every 32nd block until block 17,225,968, on 2026-09-05) (an anchor block) does not finalize without a certificate of at least three valid Falcon-512 validator seals (f+1 of the nine validators of that time) (raised at block 14,961,456, August 21, 2026, to six seals, then a full 2f+1 quorum of nine; since the set grew to ten on 2026-09-11 the enforced minimum is still six, above f+1 but below the ten-validator quorum of seven) under its block hash, with classical ECDSA (secp256k1) QBFT finalizing every block; post-quantum verification is also available as on-chain precompiles. The verifier suite is already usable, not merely readable: a post-quantum ERC-4337 smart account whose sole owner is a Falcon-512 key, and a hybrid authorizer that requires both a secp256k1 and a Falcon-512 signature over the same hash, both record on-chain. The research paper carries the full method, the committed fixtures, and the per-scheme gas analysis. The weaknesses, without softening. These are facts about the network as it stands, not risks in the abstract. Ten validators, one operator. All ten validators are held and run by the Foundation. With n=10 (since 2026-09-11) the tolerated Byzantine faults is three (quorum 7-of-10), so the chain now survives three simultaneous validator outages, but all ten are one operator. This is not a decentralized network today. Two producing clients since 2026-09-11. AERE produced every mainnet block with a single execution client, Besu, until 2026-09-11, when the second client joined the validator set. A second, independent client (a patched Nethermind on a different codebase) has validated and followed live chain 2800 and would cross-check a consensus-relevant divergence at runtime; as of 2026-08-10 it is stalled behind the head, and the gap is published rather than hidden, and it is now complete enough to reach QBFT consensus with Besu as an equal validator, but that was proven on an isolated testnet only. It produces no mainnet blocks, so client diversity on the live network does not exist today and is not claimed. No external audit yet. The contracts and the client changes have not undergone a third-party security audit. Internal audit discipline has found and fixed numbered findings tracked in the registry, and the verifiers are validated against official NIST vectors and independent reimplementations, but that is not a substitute for an external audit and is not presented as one. Thin usage. These are recently deployed primitives with limited real traffic. The demonstrations cited throughout are genuine on-chain transactions and eth_call results, not production load. No listing and no fiat on-ramp. There is no centralized-exchange listing and no fiat on-ramp. The native order-book market map is empty, so price discovery for AERE does not exist on a public venue yet. Post-quantum scope is not consensus. Restated once more because it is the easiest claim to overstate: the verifiers, the hybrid authorizer, and the post-quantum account all sit above consensus. Consensus is hybrid post-quantum in the limited, anchor-certificate sense described in chapter 3, since 2026-08-14, by a separate, explicitly approved activation; nothing in the application-layer chapters of this whitepaper is what did that. Since block 13,014,000 the block hash itself covers a post-quantum certificate: every 128th block (every 32nd block until block 17,225,968, on 2026-09-05) carries, inside the hashed part of its header, a 32-byte digest that binds Falcon-512 seals from the validators. Since 2026-08-14 every node enforces a minimum of three seals per anchor block; three is f+1 for this set, the guarantee that at least one honest validator signed. At block 14,961,456 (August 21, 2026) the enforced minimum was raised to six of nine, a full 2f+1 quorum at that size; the set grew to ten on 2026-09-11 and the minimum stays six, below the new quorum of seven. Since 2026-08-16 the cap is nine and, measured on 2026-08-19 across the most recent anchors, certificates carry eight or nine seals, all nine signers appearing (measured before the set grew to ten on 2026-09-11). The key manifests behind those seals are published at /pq/manifests/, pinned in an immutable on-chain contract, and a public tool verifies every seal cryptographically from a public RPC endpoint alone. That binds a post-quantum certificate into the chain's hash structure so it cannot be stripped or altered without changing the hash; it does not make block production post-quantum. The roadmap ( docs/ROADMAP-PHASES.md ), consolidated in Chapter 9, is the plan to change each of these facts in order, with the gate for every change named and none of them reached by announcement. How to read this whitepaper The chapters that follow move from this overview into the subsystems, each of which has a dedicated companion specification that carries the engineering depth this overview deliberately omits. The post-quantum verification layer is developed in research/pqc-onchain-verification.md . The wallet and onboarding layer, including passkey accounts, the paymasters, EIP-7702 delegation, and the post-quantum smart account, is in spec-account-abstraction.md . The proof-verification surface, covering SP1, RISC Zero, the storage-proof coprocessor, and the attestation registry, is in spec-zk-stack.md . The fair-ordering and settlement work is in spec-antimev-mempool.md , the throughput work in spec-parallel-execution.md , the regulatory and identity layer in spec-identity-compliance.md , and the token mechanics in spec-flywheel-economics.md . The phased path from today's single-operator network to an independent validator set, binding on-chain governance, and native post-quantum precompiles is set out in docs/ROADMAP-PHASES.md and summarized in Chapter 9. Read all of it against the tone set here. Every claim in this whitepaper is meant to be checkable on-chain, and it will read as accurate only for as long as it stays that way. 02 Foundations Architecture and Consensus Deterministic QBFT finality, honest Ethereum parity, and a real, self-verifying parallel-execution engine that runs in the rollup layer while the base layer stays deliberately sequential. Chain 2800 · Besu QBFT · companion deep-dive: spec-parallel-execution AERE is an EVM Layer-1 with chain ID 2800. Its architecture is deliberately conservative where correctness matters and deliberately forward-leaning where the execution budget allows. The chain runs a single, well-understood consensus engine; it tracks Ethereum's EVM ruleset feature-for-feature so that any tool, contract, or auditor familiar with mainnet is immediately at home; and it invests its novelty in two places that do not compromise base-layer safety: an application-layer post-quantum verifier suite (covered in Chapter 3) and a real, benchmarked parallel-execution engine that runs today in the rollup layer while the base layer stays deliberately sequential. This chapter describes the consensus, the finality model, the EVM upgrade posture, and the parallel-execution work, and it is honest about what is centralized, what is unproven at scale, and what is roadmap. The design thesis that runs through all of it is simple: final as math, safe when the math changes. Consensus: Hyperledger Besu with QBFT AERE's base layer is Hyperledger Besu running QBFT (Quorum Byzantine Fault Tolerant) consensus. QBFT is a proof-of-authority, leader-based BFT protocol: a known validator set takes turns proposing blocks, and a block is committed once a supermajority of validators has signed off on it in the prepare and commit rounds. There is no mining, no probabilistic longest-chain rule, and no reorg risk under honest-majority assumptions. When a block commits, it is final. Fig 2.1 QBFT single-slot finality: propose, prepare, commit, final, all inside one 0.5-second slot one 0.5-second slot Propose leader broadcasts block Prepare supermajority signs Commit supermajority commits Final no reorg Validator set today n = 10, all Foundation-operated Honest counterweight: at n = 10, tolerated faults f = floor((n-1)/3) = 3. The chain now survives two simultaneous validator outages. Validators sign QBFT messages with secp256k1 and, since 2026-09-01, with post-quantum seals. What it shows. A QBFT block is final the moment the validator quorum commits it, not after N confirmations, so there is no settlement lag and no reorg window. Halving the block period to 0.5 seconds halves time to finality directly. The amber band states the honest counterweight: with nine Foundation-operated validators of a single operator, fault tolerance is two, per-block finality rests on classical ECDSA, and post-quantum seals ride on every consensus message since 2026-09-01 with a hybrid certificate at every anchor since 2026-09-04. Two properties follow directly from this choice, and both are stated plainly rather than dressed up. First, finality is deterministic and immediate. A QBFT block is final the moment it is committed by the validator quorum, not "final after N confirmations" the way a proof-of-work or Nakamoto-style chain is. There is no settlement lag to wait out and no economic-finality heuristic to reason about. This is the "final as math" half of the thesis: settlement on AERE is a property of the consensus algorithm, not a probability that grows over time. Second, and this is the honest counterweight, AERE today runs ten validators (since 2026-09-11), and all ten keys are held and operated by the Foundation. For a QBFT set of size n, the tolerated Byzantine or crash faults are f = floor((n - 1) / 3), which at n = 10 (since 2026-09-11) equals three, with a quorum of seven of ten. In plain terms: the chain now survives two simultaneous validator outages, but with one operator there is no operator diversity yet. This is a permissioned, single-operator network at the consensus layer. It is a complete and real foundation, but it is not a decentralized one, and nothing in this chapter should be read as claiming otherwise. The expansion to nine (2026-08-09) and to ten (2026-09-11, the first Nethermind validator) is already done; the remaining path from ten validators to twenty-one, under an independent-operator Validator Charter, is the subject of the phased roadmap; it is roadmap, not a live property. Consensus signatures: classical per block, post-quantum by layers Per-block finality still rests on classical secp256k1 QBFT signatures. Since block 13,014,000 every anchor block additionally carries a post-quantum certificate of validator seals under its block hash (hybrid Falcon-512 and SLH-DSA-SHA2-128s since 2026-09-04, at least six validators per scheme, of ten since 2026-09-11); since 2026-09-01 every QBFT message also carries a post-quantum seal of its author, and from blocks 17,250,000 (commit), 17,400,000 (proposal), 17,550,000 (round change) and 17,700,000 (prepare), armed on 2026-09-05, a message without a valid seal is refused. AERE's post-quantum work at the application and account layer is separate from, and older than, this. Any statement that AERE has post-quantum consensus would be false, and the architecture is explicit about that boundary. Machine-checked safety and liveness AERE's QBFT safety and liveness are formally modeled and checked. A z3 SMT model (44 checks, kept in formal-consensus/ ) proves QBFT agreement, that no two conflicting blocks can finalize against a Byzantine adversary, with quorum intersection proven for every set size N, and proves liveness under partial synchrony. The model also covers the post-quantum Falcon quorum extension: the pre-activation certificate is machine-checked to be a strict no-op on classical consensus, and the fleet-size guard for the per-block blocking post-quantum mode, nine keyed validators, is verified (that per-block mode is modelled and guarded, but not the mode enforced on mainnet, where the anchor certificate is; see the correction in this chapter). The honest boundary. This is a bounded model check of the consensus design , not of the Besu client bytecode, and it assumes partial synchrony. Since 2026-08-14 the Falcon certificate in anchor headers is enforced at a minimum of three seals (f+1 of the nine validators of that time), raised to six, then a full 2f+1 quorum of nine, at block 14,961,456 (2026-08-21); since the set grew to ten on 2026-09-11 the minimum is still six, below the new quorum of seven: mainnet QBFT does not finalize an anchor block without it, with classical ECDSA (secp256k1) seals finalizing every block. (Correction 2026-08-19: the earlier claim that a Falcon quorum blocks every block from 14,050,000 is withdrawn; that rule is retired in the shipped code and changed no enforcement.) A formal model of the design is also not an external security audit of the contracts or the chain, which is a separate, still-pending step. Sub-second deterministic finality AERE runs a 0.5-second block time. The chain launched with one-second blocks and was moved to 0.5-second blocks by a mid-chain QBFT parameter change at block 2,137,652, applied without a re-genesis. Measured on 2026-08-01 across the last 100,000 blocks at the head, the mean interval is 0.557 seconds, and the validator set read from the chain at the same head is seven. Because QBFT finalizes on commit rather than by accumulation of work, halving the block period halves the time to finality directly: a transaction is final in well under a second from inclusion, with no confirmation count to wait through. It is worth being precise about what this figure is and is not. The 0.5-second block period and single-slot commit are the source of AERE's sub-second finality claim, and that claim is about latency to irreversibility, not about throughput. Any headline peak-throughput number for the chain (the 273,000 TPS figure that appeared in AERE's broader materials as a design ceiling) has been withdrawn, because its stated derivation does not reach that number. It has never been a measured result, and it is not asserted as one here. Throughput and finality are separate axes, and this chapter only makes the finality claim, which follows mechanically from QBFT plus the block period. EVM upgrade posture: Pectra and Fusaka parity AERE deliberately keeps its EVM ruleset at functional parity with Ethereum mainnet rather than forking off into a bespoke dialect. Two hard forks are activated on chain 2800: Pectra (the Prague and Cancun feature set) activated at Unix time 1780189051, block 2,075,341, on 2026-05-31. Fusaka (Osaka) activated at Unix time 1780220351, block 2,106,597, later the same day. Correction of 2026-08-02, because these two numbers were published wrong for months. Earlier editions of this document gave the heights as 2,075,363 and 2,106,606. Both forks are gated by timestamp rather than by block number, so the height has to be read off the chain, and when it was, both published figures were too high, by 22 and 9 blocks. The corrected heights above were re-derived independently at head: 2,075,341 is the first block whose header carries a requestsHash field and also the first whose timestamp reaches pragueTime , and 2,106,597 is the first whose timestamp reaches osakaTime . The activation timestamps themselves were always right; only the block numbers derived from them were not. Pectra activation 2,075,341 block Fusaka activation 2,106,597 block 0.5s block change 2,137,652 block Per-tx gas cap 16,777,216 2 24 , EIP-7825 Parity is a strategic choice, not an incidental one. It means AERE is a functional peer of mainnet: the same compilers, the same wallet libraries, the same audit assumptions, and the same precompile addresses all carry over unchanged. The trade AERE accepts for that parity is that it inherits mainnet's constraints too, most notably a per-transaction gas cap, and it keeps that cap on purpose rather than papering over it with an unbounded local gas limit. Pectra brings, among other changes, EIP-7702 (EOA delegation, the native account-abstraction primitive), the EIP-2537 BLS12-381 precompiles at addresses 0x0b through 0x11, EIP-1153 transient storage (TSTORE and TLOAD), EIP-5656 (MCOPY), EIP-6780 (the revised SELFDESTRUCT semantics), and EIP-2935 (the historical block-hash contract). Two Pectra items are neutralized honestly because AERE is a QBFT chain with no separate consensus layer: EIP-4788 (parent beacon block root) returns 0x0, and EIP-7516 (BLOBBASEFEE) returns 0 because there are no blobs. Fusaka adds the two features that matter most to AERE's actual product surface: RIP-7951 , a secp256r1 (P-256) verification precompile at address 0x100. P-256 is the curve behind platform passkeys: Apple Face ID and Touch ID and the Secure Enclave, Windows Hello, Android biometric keystores, YubiKeys, and the EU Digital Identity Wallet. Verifying a P-256 signature in hand-written Solidity costs on the order of 250,000 gas; the native precompile does it for roughly 3,450 gas, about two orders of magnitude cheaper. This precompile is what makes native passkey-authenticated smart accounts practical on AERE rather than merely possible, and it is the direct precedent AERE cites for its own proposed native post-quantum precompiles. EIP-7825 , a per-transaction gas cap of 2 24 = 16,777,216 gas, independent of the block gas limit. AERE keeps this cap deliberately. It is the single most load-bearing constant in the chain's design because it draws a hard line between what a state-changing transaction can do and what only a read-only eth_call can do. That distinction is exactly what governs which of AERE's on-chain post-quantum verifiers record a result in a mined pure-Solidity transaction and which record only through the native precompiles that the AerePQC fork made live (Chapter 3), and it is also the ceiling that AERE's parallel-execution and precompile roadmap is measured against. The SHA-256 precompile at 0x02 is also present and is used heavily by the hash-based verifiers. The important architectural point is that AERE gets these primitives the same way mainnet does, at the same addresses, so nothing about AERE's account, passkey, or post-quantum surface depends on a nonstandard EVM. Execution model and parallel execution Since 2026-09-05 the block processor on all nine Besu mainnet validators is our own Block-STM-style multi-version engine inside the Besu fork, selected by a switch and proven on real chain-2800 blocks against the canonical state root, with a recorded negative control. In practice it executes sequentially, because mainnet blocks carry at most one transaction (re-measured 2026-09-10: one transaction across 120 headers sampled from the latest 3,000 blocks), so it changes no measurement today and no throughput figure is derived from it. The three artifacts below are proof-of-approach for the parallel-execution claims; they are separate from that engine, and none of them is mainnet-active. (1) A parallel state-commit rewrite. The Besu Bonsai world-state commit phase (the state-root hashing that follows execution) was rewritten and proven bit-identical to the stock client four independent ways, including re-importing 253 real exported chain-2800 blocks with zero root mismatch. This is the strongest real-data evidence in this area and the nearest-term candidate for a rolling validator upgrade after audit, since its output is byte-for-byte the same. (Its multi-threaded variant was measured to anti-scale, so the shipped candidate is the single-threaded rewrite.) (2) A real parallel EVM. aere-parallel-evm runs real EVM bytecode through revm under a Block-STM multi-version-memory scheduler, proven bit-identical to sequential revm on real AERE contract bytecode: the WAERE ERC-20 and a constant-product AMM, with concurrent conflicting writes to a shared reserve slot, in-block CREATE , and reverts, at 1 to 32 worker threads. Beyond synthetic genesis, it now also executes REAL AERE mainnet blocks against live fork state: pinning the chain state at block N minus 1 over the public RPC, it replays block N in parallel and proves the result bit-identical to the canonical chain by matching every transaction's on-chain receipt, including gas used, the logs (down to a value embedded from the block timestamp), and the success or revert outcome. That makes it a validating parallel execution client on real chain-2800 state, not merely a synthetic benchmark. It now also computes a real Ethereum post-state root over its execution output, cross-checked byte-for-byte against reth's own Merkle-Patricia implementation and against real chain-2800 canonical account and storage roots proven with eth_getProof witnesses (EIP-161 empty-account handling included), which is the execution-and-commit core a block producer needs; the honest remaining pieces for full block production are a sparse post-state trie (the witness plumbing is already in place), the receipts root and header assembly, and a faithful fee model. It is correct today, a genuine parallel EVM rather than a synthetic model. On throughput the result is now a real net speedup, honestly scoped. The dominant cost was not the per-attempt context rebuild (that was fixed first) but two spurious-write hot keys that turned even genuinely-disjoint transactions into all-to-all conflicts: the block coinbase, which revm reads and writes on every transaction, and any shared contract account, which revm marks touched on any storage write. This is the well-known Block-STM-over-EVM coinbase problem. Bypassing the coinbase read and skipping unchanged-account writes, both proven state-preserving and guarded so they can never commit a wrong state, removes the false conflicts. On a compute-heavy, many-users, disjoint-storage workload (the realistic one-shared-ERC-20-or-AMM, many-callers pattern, roughly 100,000 gas and up per transaction) aere-parallel-evm then runs bit-identical to sequential at up to about 7x on sixteen cores, with zero speculative aborts, crossing over sequential at two threads. The result holds under a real fee market as well: with a non-zero basefee and per-transaction priority fees, a commutative-coinbase accumulator (the block reward captured as an order-independent per-transaction delta, materialized lazily only for the rare transaction that actually reads the beneficiary) keeps the coinbase from becoming a shared hot key, so the same compute-heavy workloads still run about 6 to 7x on sixteen cores with zero aborts and bit-identical to sequential revm, coinbase balance included. Stated precisely: this is still a benchmark of the real engine, not yet L1-integrated, and cheap sub-30,000-gas transfers or genuinely-contended workloads do not benefit. A correct engine with a real, honestly-scoped throughput result. (3) The scheduling proof. aere-block-stm is a from-scratch, zero-dependency Rust implementation of the Block-STM optimistic-concurrency algorithm (Gelashvili et al., arXiv:2203.06871, the same design family behind Aptos, Sui, and Monad): multi-version memory, speculative execution, validation, abort-and-retry. It is proven near-linear over a SYNTHETIC state model (balances and storage slots, four transaction kinds), which validates the concurrency control itself; artifact (2) is what marries that control to a real EVM. The near-linear figures below are that synthetic benchmark, not real-EVM throughput. Fig 2.2 Block-STM speedup versus single-threaded sequential, by workload profile, over the SYNTHETIC scheduling benchmark (16-core box, 20,000-tx batches). Not real-EVM throughput; see artifact (2), aere-parallel-evm, for the real-EVM engine. sequential oracle Block-STM, many cores roots must match: 6,000 / 0 mismatch 10x 7.5x 5x 2.5x 0 1x sequential baseline 8.6x low-conflict 9.3x medium-conflict 4.6x high-conflict 0.73x single-counter no parallelism to find Single-machine microbenchmarks of the executor. Not a network throughput number and not a TPS claim. What it shows. Low- and medium-conflict batches reach roughly 8.6x and 9.3x over single-threaded sequential; a high-conflict batch still reaches about 4.6x. The pathological batch, where every transaction increments the same slot, has no available parallelism, so Block-STM correctly serializes it and runs slightly slower (about 0.73x) because it pays for aborted speculation. That worst case is drawn openly. Every run also checks the parallel state root against a sequential oracle: 6,000 comparisons, zero mismatches. Three properties make this more than a benchmark toy. It is self-verifying. There is exactly one implementation of what a transaction does, and it is driven two ways: once by a sequential oracle that applies transactions in strict index order (the definition of the correct answer) and once by the parallel executor. Because both share the same transaction-semantics function, the parallel result can differ from the sequential result only if the concurrency control is wrong. Every run executes the batch both ways and refuses to emit a state root unless the two match, so a concurrency bug cannot silently produce a bad commitment. Its correctness is proven, not asserted. A harness runs six workload profiles across 200 randomized batches at five thread counts each, 6,000 comparisons in total, including deliberately adversarial fully-conflicting workloads (an all-hot profile and a brutal single-counter profile). The reported result is zero mismatches: the Block-STM committed state equals the sequential oracle in every case. Because the workloads are generated by a seedable PRNG, any case is exactly replayable. Its measured speedup is honest, including the cases that look bad. On a 16-core box, with 20,000-transaction batches carrying a realistic simulated per-transaction compute cost, low-conflict and medium-conflict batches reach roughly 8.6x and 9.3x speedup versus single-threaded sequential execution. A high-conflict batch still reaches about 4.6x because only a fraction of its transactions touch the hot slot. A pathological batch in which every transaction increments the same slot has no available parallelism at all; Block-STM correctly serializes it and is actually slightly slower than sequential (about 0.73x) because it pays for aborted speculation. That worst case is stated openly, because no correct parallel executor can beat sequential when there is nothing to parallelize. A separate worker-count scaling run on execution-bound load is near-linear, at 1.94x, 3.61x, 6.19x, and 9.38x on 2, 4, 8, and 16 workers, each result bit-identical to sequential; that is an execution-phase win, and an end-to-end throughput win still needs real execution-heavy load plus a parallel commit. These are single-machine microbenchmarks of the executor. They are not a network throughput number and not a TPS claim. The concrete place this executor runs is AERE's rollup layer. A TypeScript wrapper in the rollup sequencer serializes the prior L2 state slice and the ordered batch, shells out to the executor, and gets back a keccak256 state root; the execute path runs the batch both in parallel and sequentially and throws if they diverge, so a bad root can never reach the chain. That root is what a sequencer proposes on-chain. The rollup stack is AERE's Rollup-as-a-Service system: the canonical factory AereRaaSFactoryV2 at 0xB7F8c754AC3155197d76f01857172bBd5a5F39Ab (bonded in WAERE 0x7e84d7d66d5da4cfE46Da67CDEeB05B323e1f5e8 , with fees routed to AereSink at 0x69581B86A48161b067Ff4E01544780625B231676 ) deploys a fixed per-rollup settlement contract, and the sequencer proposes each epoch's root there under an optimistic challenge window. Because the executor guarantees the parallel result equals sequential execution, the committed root is deterministic and reproducible, which is precisely what makes it safe as a rollup commitment and what would make a fraud proof constructible by re-running the same binary. Two on-chain anchors accompany the executor. The first is AereBlockSTMRegistry at 0x98E2C3e615841919d173D8FF642514c5902E8A28 , an opt-in, advisory-only registry where a contract publishes the storage-slot read and write hints for its own function selectors so a scheduler can reduce aborts. It is metadata only: it holds no funds, changes no execution semantics, has no admin over anyone else, and a wrong hint costs at most one extra abort. Critically, the registry has no runtime effect on mainnet today, because parallel execution is not mainnet-active; the Block-STM client is implemented with serial-equivalence correctness proven and demonstrated on testnet, and it was not part of the AerePQC mainnet fork, so it is not an unbuilt someday but also not yet on mainnet. The second anchor is a validity anchor. The bounded-VM AereRollupValidity at 0x38772063572DF94E90351e44ccbBEefD5F497fbd verifies SP1 Groth16 validity proofs that AERE's deterministic rollup executor transitioned one state root to another by applying a specific batch, routed through the SP1VerifierGateway at 0x9ca479C8c52C0EbB4599319a36a5a017BCC70628 , and its epoch 0 was recorded on-chain from a real proof. It has since been superseded by a full-EVM validity anchor. The step that carries the real proof is AereEVMValidityBatch at 0x49D30a5999eA5b7f6eFf12196AB006316683Ff3C , which recorded and verified a 16-block batch of real chain-2800 blocks (9111008 to 9111023) in a single Groth16 proof through the same gateway, a step up from the earlier single-block AereEVMValidity at 0x1f2CB0ebDBb21500e99868DbF1dB3abCcDd7DF26 , both verifying SP1 proofs of a real revm (via rsp / sp1-reth) executing genuine chain-2800 blocks. Both of those are in the canonical registry, and both are superseded there by anchors that bind the proven block to QBFT canonical history: AereEVMValidityV2 0x4884ad6617e320735b65D31915d1aBC884768D9B (2,852 bytes of live code) and AereEVMValidityBatchV2 0xe154B8993FB54dB4418e03ef4a04894f29E690aE (3,425 bytes). The honest reading of that pair is precise: the V2 anchors are the current ones by design, and neither has recorded a proof yet, so the demonstrated batch above remains the strongest thing actually proven on chain. Honest scope of the parallel-execution work The Block-STM microbenchmark executor models a bounded set of four transaction kinds (Transfer, Sweep, Increment, and a constant-product AMM swap) over a balance-and-storage map, and its correctness harness proves that specific executor, not arbitrary EVM bytecode. Two things that used to sit here have moved. Validity now proves a real full EVM through AereEVMValidityBatch 0x49D30a5999eA5b7f6eFf12196AB006316683Ff3C , a real revm inside the SP1 zkVM with a 16-block batch of real chain-2800 blocks proved and verified on-chain in one Groth16 proof, a proof-of-approach scaling toward production rather than a live continuous sequencer. Block-STM is implemented in the forked client with serial-equivalence correctness proven and near-linear execution-phase scaling to 9.38x at 16 workers; it remains a testnet demonstration, was not part of the AerePQC mainnet fork, and is not mainnet-active, with throughput tuning ongoing. What remains genuinely ahead is wiring a live mempool into the executor end to end and a general on-chain fraud-proof verifier for the optimistic settlement path. The honest scope of the parallel-execution work is drawn tightly. The Block-STM microbenchmark executor models a bounded set of four transaction kinds (Transfer, Sweep, Increment, and a constant-product AMM swap) over a balance-and-storage map, and its correctness harness proves that specific executor, not arbitrary EVM bytecode. Two things that used to sit on the roadmap here are now built and proven. First, validity no longer covers only the bounded VM: the full-EVM batch validity anchor AereEVMValidityBatch 0x49D30a5999eA5b7f6eFf12196AB006316683Ff3C verifies SP1 Groth16 proofs of a real revm (via rsp / sp1-reth) executing genuine chain-2800 blocks, and a 16-block batch (blocks 9111008 to 9111023) has been proved and verified on-chain in one Groth16 proof through the SP1 gateway, a step up from the earlier single-block AereEVMValidity 0x1f2CB0ebDBb21500e99868DbF1dB3abCcDd7DF26 , so AERE now proves real full-EVM execution rather than a fixed transaction set. The remaining honest scope is that this is a proof-of-approach scaling toward production, not a live continuous sequencer, and transaction density is low because node state is pruned. Second, Block-STM is implemented in AERE's forked execution client with serial-equivalence correctness proven, the parallel result bit-identical to sequential and scaling near-linearly to 9.38x at 16 workers on execution-bound load, and demonstrated on testnet, so moving parallel execution into the base client is no longer a paper item; it was not part of the AerePQC mainnet fork and is not yet mainnet-active, and throughput tuning is ongoing. What remains genuinely ahead is wiring a live mempool into the executor end to end and a general on-chain fraud-proof verifier for the optimistic settlement path. For the full derivation of the scheduler, the multi-version memory, the correctness harness, the benchmark methodology, and the settlement flow, see the companion specification spec-parallel-execution . Client diversity: a complete second client, proven on an isolated testnet Testnet For most of its life AERE ran a single execution client, Besu, and that was stated plainly as a limitation: a consensus-relevant bug in one client has no independent implementation to cross-check against. That work is now complete on an isolated test network, and the boundary below states exactly what that does and does not mean for mainnet. AERE has a second, independent execution client on a different codebase and language: a patched Nethermind 1.39.0 (a .NET client, versus the Java Besu producers) taught AERE's QBFT header and seal validation rules and wired to the five AerePQC precompiles. It peered with the live validators over devp2p, followed live chain 2800, and independently validated the full chain to genesis with zero invalid seals. It also full-state syncs from AERE's exact genesis rather than merely checking headers: it rebuilds world state and re-executes real chain-2800 blocks to the exact real-chain state roots, block for block. The five post-quantum precompiles execute byte-for-byte identically inside this second client, with 27 of 27 NIST KAT vectors accepting and rejecting correctly. One result here deserves more emphasis than it has previously been given. Two independently written execution clients now agree on block hash and state root across the post-quantum activation block itself. Besu and Nethermind were compared at five heights spanning block 9,189,161 and produced identical values at every one. A hard fork that changes execution behavior is exactly where a second implementation is most likely to diverge, and the point of having one is to catch precisely that. Very few networks at Aere's stage can make this statement about a fork they have already shipped, and it is checkable by anyone who syncs either client. The correct scope for the claim is verification, not production, and the boundary below states that scope exactly. On an isolated test network the second client no longer merely follows: it reaches QBFT consensus together with Besu as an equal validator . Both clients propose in turn, exchange Proposal, Prepare, Commit and RoundChange votes over Besu's own istanbul /100 devp2p sub-protocol, and every committed block carries a quorum of committed seals signed by both clients' validator keys, rather than one client producing solo while the other follows. Two fixes completed the work. The first is a Besu-style vote relay : the engine consumed a peer's vote locally but never re-broadcast it, which is harmless on a full mesh but fatal on a sparse one, because a vote on the quorum-critical path died at the non-relaying node and a mixed set stalled whenever Nethermind signatures were needed to reach quorum. Holding the topology fixed and flipping only the relay turned every stall into progress (0 blocks to 26 and 0 to 20 in the two exactly-quorum scenarios), with zero forks. The second is the safety-critical acceptor-side round-change locking : an acceptor now rejects an equivocating proposer that proposes a conflicting value at a later round without a valid round-change certificate. Three distinct equivocation attacks are proven rejected, a legitimate re-proposal is accepted, and a paired control with the rule disabled shows the same attack accepted, which isolates the fix as exactly what prevents the fork. The rules are machine-checked as well as tested: an automated prover confirms that two different blocks can never both reach a commit quorum. A four-validator set at fault tolerance one survives the loss of a validator. The honest boundary on client diversity This is not client diversity on the live network, and the phrase "full client diversity" is not claimed for AERE mainnet. Every consensus result above, both clients proposing, the cross-client seal quorums, the vote relay, the acceptor locking and the machine-checked proofs, was obtained on an isolated test network with empty blocks , not on mainnet. On live chain 2800 Besu remains the sole producer of every block ; the second client independently re-validates that history, and because it enforces the chain's rules on its own it has also twice stopped at divergences it refused to accept, which is exactly the cross-check a second predicate exists to provide; it produces nothing. Putting a second client into the live validator set is a deliberate, founder-supervised step that has not been taken, precisely because a bug in a producing client can halt or fork a live chain; it stays gated behind extended soaking and review (Chapter 9, Phase 4). Consensus cryptography is hybrid in the producing client in the anchor-certificate sense: every 128th block (every 32nd block until block 17,225,968, on 2026-09-05) must carry at least three valid Falcon-512 validator seals (f+1 of the nine validators of that time) (raised at block 14,961,456, August 21, 2026, to six seals, then a full 2f+1 quorum of nine; since the set grew to ten on 2026-09-11 the enforced minimum is still six, above f+1 but below the ten-validator quorum of seven) under its hash, alongside classical secp256k1 ECDSA on every block; the second client independently re-validates the chain, certificates included. So the honest statement today is a single-producer mainnet with a second validating client, and a complete second client proven in consensus on testnet, a real step most single-client networks never take, stated without overclaiming what is live. Architectural honesty AERE's architecture is strong where it is standard and modest where it is new. The consensus is a mature BFT engine giving genuine deterministic sub-second finality, and it now runs on ten Foundation-operated validators (since 2026-09-11) with f=3 fault tolerance (commit quorum 7-of-10), on two producing execution clients (nine Besu validators and one Nethermind validator, the second independent client that until 2026-09-11 only validated chain 2800 and reached consensus with Besu on an isolated testnet), and a single operator, so that fault tolerance is against node outages rather than a dishonest operator. The EVM is at honest mainnet parity, which is a feature: no surprises for tooling or auditors. The parallel-execution engine is real, self-verifying, and benchmarked; since 2026-09-05 our own Block-STM-style block processor is switched on on all nine Besu mainnet validators, proven on real chain-2800 blocks with a recorded negative control, and it changes no measurement today because blocks carry at most one transaction (re-measured 2026-09-10); validity is proven for a real full EVM through AereEVMValidity rather than limited to a bounded VM. There has been no external audit, usage is thin, and there is no exchange listing. Each of these limitations is named here on purpose, because for a young chain the accuracy of the description is itself part of the architecture. The subsequent chapters build on this base: Chapter 3 on the post-quantum verifier suite, and the companion specifications on the anti-MEV mempool, account abstraction, parallel execution, identity and compliance, and the fee flywheel. 03 The Differentiator On-Chain Post-Quantum Signature Verification A live suite of six NIST post-quantum verifiers running on AERE's own EVM, now recording end to end on mainnet since the AerePQC fork put the native precompiles live, with the one honest boundary stated plainly: this is verification, not consensus. Chain 2800 · Besu QBFT · companion deep-dive: research/pqc-onchain-verification.md Final as math, safe when the math changes AERE's settlement promise has two halves. The first is that a transaction is final in well under a second, because QBFT gives single-slot BFT finality: settlement is as final as the math that orders it. The second half is what this chapter is about. Settlement has to stay safe when the math underneath today's signatures changes. Almost every account on almost every chain is secured by secp256k1 ECDSA, whose security reduces to the hardness of the discrete-logarithm problem, and Shor's algorithm solves that problem in polynomial time on a sufficiently large quantum computer. AERE's answer is to make the chain able to verify post-quantum signatures on its own EVM, today, so that account and settlement authorization can move onto quantum-resistant keys long before a cryptographically relevant quantum computer exists. Final as math, safe when the math changes. The threat is timing, not a machine that runs today The reason to act now is not a quantum computer that can break ECDSA today. It is the asymmetry between when data is captured and when it can be attacked. A public ledger publishes, permanently and to everyone, the two artifacts an attacker wants most: account public keys and the signatures made under them. An adversary can record the chain today and, at any later date when the hardware arrives, recover private keys from the exposed public keys and forge transactions against any account whose key material is already public. For an immutable public ledger that recording step is free and is already happening. Nothing is decrypted here, signatures are public; this is the ledger's analogue of the harvest-now, decrypt-later posture, retroactive forgery from exposed public keys, and it is why a chain that expects to still be securing value in a decade should be able to verify post-quantum signatures well before it is forced to. Fig 3.1 Harvest-now, decrypt-later: why the window opens before the machine exists exposure window · capture is free, break is retroactive today years later Keys + signatures published, captured free CRQC arrives Shor breaks ECDSA Retroactive forge any still-classical key AERE: migrate to PQC keys now before the break What it shows. The capture step is available today and permanent; the break can arrive years later and applies retroactively to any account whose key material is already public. AERE's response is to make migration to post-quantum keys possible now, ahead of the break, not to claim a quantum computer exists today. Post-quantum schemes remove the lever Shor's algorithm pulls. Hash-based signatures (WOTS+, XMSS, SLH-DSA) rest only on the pre-image and collision resistance of a hash function; the best known quantum attack is Grover's, a quadratic speedup that standard parameter sizing absorbs. Lattice signatures (Falcon, ML-DSA) rest on structured-lattice problems for which no efficient quantum algorithm is known. Making the chain able to check these natively is the precondition for the migration. Why the account and settlement layer, and not consensus Post-quantum security can enter at two very different layers, and AERE is explicit about which one it has built. Changing consensus so that validators sign blocks with a post-quantum scheme is invasive: it touches the client, the gossip and finality protocols, and every operator. Changing the account and settlement layer is additive: a contract that verifies a Falcon or SLH-DSA signature deploys like any other contract, and a smart account can bind its authorization to a post-quantum key with no protocol change at all. AERE takes the additive path. Everything in this chapter lives above consensus. Consensus itself was changed separately and later, and the design was first proven on an isolated 4-validator QBFT testnet on which every validator Falcon-512-signs each block's commit hash and gossips its seal inside its QBFT Commit message, so each block embeds a gossiped, verified 2f+1 quorum certificate of distinct valid Falcon-512 seals that every node re-verifies on import, blocking any post-fork block that lacks a valid quorum. Across two healthy runs (229 and 215 blocks) every post-fork block carried a valid 3-of-4 certificate with zero rejects, the full upstream consensus unit-test suite stayed green, the negative tests failed closed, and the block hash stayed byte-identical to upstream, while the classical secp256k1 ECDSA seal stayed the decisive liveness seal throughout. That testnet demonstration was then carried to mainnet 2800 in the anchor form: the seal registry is bound on-chain through an immutable anchor contract (nine entries, checkable with eth_getStorageAt and with the published manifests), and since 2026-08-14 an anchor block (every 32nd) does not finalize without a certificate of at least three valid Falcon-512 validator seals (f+1 of the nine validators of that time) (raised at block 14,961,456, August 21, 2026, to six seals, then a full 2f+1 quorum of nine; since the set grew to ten on 2026-09-11 the enforced minimum is still six, above f+1 but below the ten-validator quorum of seven), with classical ECDSA finalizing every block. Correction published 2026-08-19: this document previously stated that from block 14,050,000 every block required a 2f+1 (six-of-nine) post-quantum quorum to finalize. The per-block Falcon quorum rule armed at that height is, in the shipped code, retired in favour of the anchor rules from block 13,014,000, and a re-reading of the code and of the chain (non-anchor blocks carry no Falcon seals) shows it changed no enforcement; that statement is withdrawn. What is enforced is the anchor certificate described here. The honest scope is stated at the front and repeated at the close: application-layer and account-layer quantum resistance is live, consensus is hybrid post-quantum only in the anchor-certificate sense since 2026-08-14, not purely post-quantum, and none of it has yet been audited by a third party. Honest boundary: application and account layer, not consensus Everything in this chapter sits above consensus. Consensus became hybrid post-quantum, in the anchor-certificate sense of chapter 3, by separate, explicitly approved activations (the anchor at block 13,014,000, the three-seal minimum from 2026-08-14), delivered through coordinated per-node activation heights rather than a re-genesis; nothing in this chapter is what did that, and nothing here should be read as implying it. The live verifier suite The suite spans both families NIST is standardizing for signatures: the stateful and stateless hash-based schemes, and the structured-lattice schemes. Each verifier is an ordinary immutable contract with no owner, no admin, and no upgrade path. Given a public key, a message, and a signature it returns exactly the accept-or-reject decision the reference implementation returns, no more. Every address below is copied verbatim from the canonical registry ( sdk-js/src/addresses.ts ). Fig 3.2 Six spec-complete verifiers, live on chain 2800 Hash · one-time WOTS+ AerePQCVerifier 0x1cE2949e8cE3f1A77b178aF767a4455c08ec6F82 Records on-chain Hash · many-time XMSS-SHA2_10_256 AereXmssVerifier · RFC 8391 0x77b14E264D0bb08d304d4e0E527F0fCdFc88B112 Records on-chain Hash · stateless SLH-DSA-SHA2-128s AereSphincsVerifier · FIPS 205 0xAfFc9F8d950969b46b54e77758BbFf7e000c87e6 Records on-chain Lattice · NTRU Falcon-512 AereFalcon512Verifier 0x4E8e9682329e646784fB3bd01430aA4bA54D8fFC Records on-chain Lattice · NTRU Falcon-1024 AereFalcon1024Verifier 0xF0aFA59BaB2058e4B6e6B424b7f76750F1F66e36 Records via precompile Lattice · module ML-DSA-44 AereMLDSA44Verifier · FIPS 204 0xf1F7A6Acd82D5DAf9AF3166a2F736EE52C5F85AE Records via precompile What it shows. The full suite with each contract's verbatim canonical address, cryptographic family, and honest on-chain status. All six schemes record a result in a mined transaction on mainnet: four record in pure Solidity, and Falcon-1024 and ML-DSA-44 record through the native precompiles that went live with the AerePQC fork (block 9,189,161), for the reason set out in the gas-cap section below. The hash family builds from one primitive. WOTS+ (AerePQCVerifier) is the one-time building block: it splits the 256-bit message hash into 64 base-16 digits plus a three-digit checksum, advances each supplied element to the end of its keccak256 chain, and accepts when the hash of the 67 chain-ends matches the committed public key. The checksum defeats the obvious forgery, since raising any message digit lowers the checksum and reversing that would require inverting keccak256. XMSS-SHA2_10_256 (AereXmssVerifier) is the honest many-time extension, reproducing the RFC 8391 verify path exactly: recover the WOTS+ leaf from the signature, walk a height-10 SHA-256 Merkle authentication path to a candidate root, and accept when that root equals the published long-term root. SLH-DSA-SHA2-128s (AereSphincsVerifier) is the FIPS 205 standardization of SPHINCS+ in its smallest-signature parameter set, and unlike XMSS it is stateless: a few-times FORS layer selects a hypertree leaf pseudo-randomly, so one key signs an effectively unbounded number of messages with no signer state. The verifier implements FIPS 205 Algorithm 20 end to end, including the one load-bearing subtlety that separates FIPS 205 from round-3 SPHINCS+, the base_2^12 big-endian FORS index extraction, and the validation discussion below returns to why that detail is provable. The lattice family carries the differentiated weight. Falcon-512 (AereFalcon512Verifier) performs the full NTRU hash-and-sign check on-chain: it streams SHAKE256 to rejection-sample the challenge polynomial, decodes the 897-byte NIST public key and the 615-byte compressed signature with the reference comp_decode , recomputes the short vector by a negacyclic convolution over an in-contract number-theoretic transform, and accepts if and only if the squared l2 norm is at most the acceptance bound. Falcon-1024 (AereFalcon1024Verifier) is structurally identical at ring degree 1024. ML-DSA-44 (AereMLDSA44Verifier) implements the FIPS 204 module-lattice Fiat-Shamir-with-aborts verifier for Dilithium2: it samples the 4x4 matrix directly in the NTT domain via SHAKE128 rejection sampling, recomputes the commitment, and checks the challenge match and the infinity-norm bound. Two composite primitives turn the verifiers from read-only checks into usable authorization, and are covered below: AereHybridAuth at 0xc20390C9656ECe1AE37603c84E395bC898b3FAA1 , and AerePQCAccountFactory at 0xd5315Ea7caa60d320c4f34b1bEd70dd9cc02CE58 . A precursor lattice core, AereLatticeVerifier at 0x60c06E6A3CC201B46A16650be096C6E45424dfD9 , implements ring arithmetic at a reduced degree (n=74) and is a demonstration core only; the spec-complete Falcon-512 verifier supersedes it for real use. Why the verifiers can be trusted: KAT and ACVP conformance A verifier is only as trustworthy as the vectors it is checked against, so each scheme is validated bit-for-bit against official, externally sourced fixtures that are committed to the repository. Validation runs in both directions: the valid vectors must accept, and the crafted-invalid vectors (tampered message, signature component, or key) must reject with the exact accept-or-reject pattern the reference produces. Falcon-512 and Falcon-1024 are checked against the Falcon round-3 NIST submission KAT response files; the Falcon-512 vector 0, for instance, carries a squared norm of 28,308,410 against the bound 34,034,726 and the on-chain verifier returns the same decision as the reference crypto_sign_open . ML-DSA-44 is validated against the NIST ACVP ML-DSA-sigVer-FIPS204 vectors, test group 8, where all 15 cases (3 valid plus 12 crafted-invalid) reproduce NIST's expected results, cross-checked by an independent from-scratch Python FIPS 204 verifier that also matches 15 of 15. SLH-DSA-SHA2-128s is validated against ACVP SLH-DSA-sigVer-FIPS205 test group 31, all 14 cases (2 valid plus 12 crafted-invalid). That SLH-DSA cross-check is the most instructive in the suite: the reference C matches 14 of 14 only after correcting the FORS index extraction to the FIPS 205 base_2^b decoding, and the unpatched reference matches only 12 of 14, failing exactly the two valid vectors. That isolates the single behavioral change between round-3 SPHINCS+ and standardized SLH-DSA and confirms the on-chain contract implements the standardized form. XMSS is validated against the deterministic vector from the XMSS reference implementation, cross-checked by independent Python and JavaScript reimplementations of the RFC 8391 path. The companion research paper enumerates the fixture files and their SHA-256 digests. The honest boundary: the EIP-7825 per-transaction gas cap AERE keeps Fusaka's EIP-7825 cap, which limits any single transaction to 2 24 = 16,777,216 gas regardless of the block gas limit, deliberately, so the chain stays a functional peer of Ethereum mainnet rather than leaning on an unbounded local gas limit. That cap draws a precise and honest line through the suite. A verifier that records its result on-chain must complete the entire verification, plus the storage write and event, within 16,777,216 gas. A read-only eth_call is not a transaction and is not subject to the cap. Four of the six schemes fit under the cap and record a full verification in an ordinary pure-Solidity transaction. The recorded figures are taken from committed deployment records, not projection: XMSS at 1,561,963 gas, SLH-DSA-SHA2-128s at 1,812,066 gas, and Falcon-512 at 10,492,455 gas, with WOTS+ dominated by a bounded number of short keccak256 chains. Two schemes do not fit in pure Solidity. A state-changing Falcon-1024 verification in Solidity lands at roughly 21.7M gas and ML-DSA-44 at roughly 52.9M gas (52,934,073, local estimate), both above the cap, because in pure Solidity their cost is dominated by SHAKE computed inside the EVM over a larger ring or a rejection-sampled matrix, so their pure-Solidity verifiers stay read-only references reachable via eth_call against the same official vectors. The path that removes the limitation, the native precompiles, is now live on mainnet: as of the AerePQC fork (block 9,189,161, 2026-07-12) the native Falcon-1024 and ML-DSA-44 precompiles record the same verification on-chain within the cap, as the native-precompile section below sets out. This was always a limitation of the pure-Solidity execution budget, not of the cryptography. Fig 3.3 Verify-and-record gas: pure Solidity vs the native precompile, against the 16,777,216 cap over the per-tx cap 0 6.7M 27M 37M 47M EIP-7825 cap 16,777,216 Falcon-512 records on mainnet 10,492,455 gas · Solidity 86,336 gas · precompile (0.51% of cap) Falcon-1024 records via precompile ~21.7M gas · exceeds cap 145,496 gas · precompile (0.87% of cap) ML-DSA-44 records via precompile 52,934,073 gas · Solidity, exceeds cap 351,050 gas · precompile (2.09% of cap) Solidity, records Solidity, exceeds cap Native precompile (live on mainnet 2800) What it shows. Bars are drawn on one linear gas axis, so the precompile results are the near-invisible green slivers at the left edge, which is the point: Falcon-1024 drops from roughly 21.7M gas to 145,496 gas, and ML-DSA-44 from 52,934,073 gas to 351,050 gas. Both Solidity bars cross the dashed EIP-7825 cap; both precompile results sit under 2.1% of it. Falcon-512 already records in pure Solidity at 10,492,455 gas, under the cap. Precompile figures are measured on mainnet 2800, live since the AerePQC fork (block 9,189,161). From verifier to wallet: hybrid auth and a post-quantum smart account The verifiers are not left as read-only curiosities. AereHybridAuth ( 0xc20390C9656ECe1AE37603c84E395bC898b3FAA1 ) authorizes an action only if both a secp256k1 ECDSA signature and a NIST Falcon-512 signature verify over the same 32-byte hash, with the Falcon leg delegated to the live Falcon-512 verifier. This is the conservative migration posture: an account stays as safe as classical ECDSA against today's adversaries while adding a post-quantum requirement, so that neither a broken curve nor a broken lattice alone suffices to forge. Its live authorize transaction used 10,299,873 gas, under the cap. AerePQCAccountFactory ( 0xd5315Ea7caa60d320c4f34b1bEd70dd9cc02CE58 ) goes further: it is a CREATE2 factory that deploys an ERC-4337 v0.7 smart account whose sole owner is a Falcon-512 public key with no classical ECDSA fallback, where both the validateUserOp path and the EIP-1271 isValidSignature path are decided by the live verifier. A sample account owned by a real Falcon-512 key sits at 0xa42a5e7F72E46BadC11367650Ec34D676194326f , and a full user operation through it used 10,278,313 gas, also recorded on-chain and under the cap. That is the practical result of Phase 1: not just a verifier that can check a post-quantum signature, but a wallet whose authorization is quantum-resistant end to end at the account layer. The native precompile path: live on mainnet as of the AerePQC fork The reason Falcon-1024 and ML-DSA-44 do not fit in pure Solidity is almost entirely the cost of computing SHAKE and SHA-256-family sponge functions inside the EVM. Fusaka already demonstrates the fix for a different primitive: RIP-7951 exposes secp256r1 verification as a native precompile at a fixed cost roughly two orders of magnitude below the Solidity equivalent. The same approach applied to the extendable-output functions and the lattice inner loops moves every scheme in this suite under the cap. That workstream is built, proven, and now live on mainnet. AERE forked Hyperledger Besu v26.4.0 and added native precompiles that wrap the Bouncy Castle 1.83 BCPQC verifiers (not FIPS-validated; no published third-party audit is known) already on the client classpath, introducing zero new dependencies and zero hand-rolled cryptography. The precompiles for SHAKE256, Falcon-512, Falcon-1024, ML-DSA-44, and SLH-DSA-SHA2-128s were validated bit-for-bit against the same official NIST KAT and ACVP fixtures the pure-Solidity verifiers pass, in both directions, including all the negative vectors (41 of 41 accept and reject cases), first on an isolated scratch chain (chain ID 28099) and then activated on mainnet 2800 by the AerePQC fork at block 9,189,161 (2026-07-12), where they now live at the reserved band 0x...0AE1 to 0x...0AE5. The measured full verify-and-record transactions, in gasUsed, are: Falcon-512 86,336, Falcon-1024 145,496, ML-DSA-44 351,050, SLH-DSA-SHA2-128s 558,276, and SHAKE256 21,470, all far under the 16,777,216 cap. The two schemes that were view-only in pure Solidity now record on-chain with wide margin: Falcon-1024 drops from roughly 21.7M gas to 145,496 gas (0.87% of the cap) and ML-DSA-44 from roughly 52.9M gas to 351,050 gas (2.09% of the cap), while Falcon-512 falls from 10,492,455 gas to 86,336. Fig 3.4 Fork-precompile architecture: the AerePQC fork activated the native precompiles on mainnet 2800 Mainnet 2800 Besu QBFT · live · untouched consensus signs classical secp256k1 PURE-SOLIDITY VERIFIERS WOTS+ · records XMSS · records SLH-DSA-128s · records Falcon-512 · records Falcon-1024 · records (precompile) ML-DSA-44 · records (precompile) all 6 record on mainnet: 4 in Solidity, 2 via the native precompiles (live) Scratch fork 28099 Besu 26.4.0 + native precompiles wraps Bouncy Castle 1.83 · 0 new crypto ALL RECORD, KAT-VALIDATED BOTH WAYS SHAKE256 21,470 Falcon-512 86,336 Falcon-1024 145,496 ML-DSA-44 351,050 SLH-DSA-128s 558,276 every scheme records within the cap, now live on mainnet 2800 all far under 16,777,216 live client-only hard fork no re-genesis block 9,189,161 What it shows. The precompiles were built and KAT-validated on an isolated scratch fork (chain ID 28099), then activated on mainnet 2800 by the AerePQC fork at block 9,189,161 (2026-07-12), a coordinated client-only hard fork with no re-genesis that added behavior only at the otherwise-empty precompile addresses. The gate is drawn open on purpose: the precompiles are live. An independent external audit of the client changes is still outstanding (see Chapter 9). Live on mainnet as of the AerePQC fork The candor here is deliberate and non-negotiable. The precompiles were proven first on an isolated scratch fork and are now live on AERE mainnet chain 2800: the AerePQC fork activated them at block 9,189,161 (2026-07-12) as a coordinated client-only hard fork with no re-genesis and no state migration, adding precompile behavior only at otherwise-empty addresses and also activating the extended EIP-2935 block-hash lookback (an 8,191-block window) in the same fork. One honest caveat belongs here rather than in a footnote: between blocks 9,182,380 and 9,189,160 the chain deviates from EIP-2935 as written, because Besu skips the history write on proof-of-authority chains lacking the three request-contract addresses. It is deterministic, it is upstream Besu behavior rather than a local patch, and it is identical across the clients we have compared, but an integrator reading the specification would not predict it, so the range is published in Chapter 9.4. The fork added the precompiles and EIP-2935 only; it did not change consensus, and Block-STM parallel execution was not part of it and remains a testnet demonstration. The accurate statement about mainnet now is that all six schemes record on-chain: four in pure Solidity, and Falcon-1024 and ML-DSA-44 through the native precompiles. Since 2026-08-14 AERE mainnet consensus is hybrid in a precise and limited sense: every 128th block (every 32nd block until block 17,225,968, on 2026-09-05) (an anchor block) does not finalize without a certificate of at least three valid Falcon-512 validator seals (f+1 of the nine validators of that time) (raised at block 14,961,456, August 21, 2026, to six seals, then a full 2f+1 quorum of nine; since the set grew to ten on 2026-09-11 the enforced minimum is still six, above f+1 but below the ten-validator quorum of seven) under its block hash, with classical ECDSA (secp256k1) QBFT finalizing every block; post-quantum verification is also available as on-chain precompiles. The one caveat that stays: an independent external audit of the client changes is still outstanding (see the roadmap in Chapter 9). Crypto-agility: swapping a scheme with no redeploy Live "Safe when the math changes" is only credible if a scheme can be replaced without rewriting every contract that depends on it, so AERE makes that concrete with two small deployed contracts. AereCryptoRegistry ( 0xaE6fC596bb3eCcbf5c5D02D67B0Ef065b3Afbaa5 ) is an on-chain algorithm registry that maps an algorithmId to a record of {verifier, status, gas, successor} , and its resolveActive() view follows the successor chain so a caller always lands on the currently active verifier for a scheme. When a scheme is deprecated the registry owner marks it and points its successor at the replacement, and every reader that resolves through the registry migrates on its next call. Naming that owner correctly matters, because this is the authority the whole agility story rests on: measured on 2026-08-01, owner() on both the registry and the authorizer returns an operational deployment account rather than the Foundation account. Both are scheduled to move to governance, and until they do, the scheme-swap authority sits with an operational key rather than with the Foundation or with a vote. AereHybridAuthorizer ( 0x168F2A6a3071e7654CF1784a6f5d7BC8e1a582E0 ) routes every signature check through resolveActive , so swapping the verifier behind a post-quantum scheme migrates all of its consumers at once, with no redeploy on their side. The boundary is drawn exactly. Routing to a scheme that is already registered, or to a new contract verifier, needs no fork, because it is a registry write the Foundation can make. Adding a brand-new native precompile still requires a supervised client hard fork, of the kind that activated the PQC precompiles at block 9,189,161. Crypto-agility here means the account and application layer can adopt a new or successor scheme without redeploying its consumers, not that consensus or the client can be re-parameterized from a contract call. Limitations, stated plainly An on-chain post-quantum claim is easy to overstate, so the boundaries are drawn explicitly. Above consensus, not in it. The capabilities in this chapter are at the application and account layer. Consensus is hybrid post-quantum in the anchor-certificate sense since 2026-08-14, by a separate activation; nothing in this chapter is what did that. Centralized network today. The network runs ten validators under a single operator, on two execution clients (nine Besu, one Nethermind since 2026-09-11), with only three-fault Byzantine tolerance at n=10 (quorum 7-of-10), and the roadmap phases are the plan to change each of those facts in order. Validated, not externally audited. The verifiers are validated against official NIST vectors and cross-checked by independent reimplementations, which is strong evidence of functional correctness, but they have not undergone a third-party security audit yet; KAT conformance establishes that the accept-or-reject decision matches the reference on the tested vectors, not that every malformed-encoding edge case is handled. Thin usage. These are recently deployed primitives exercised by genuine on-chain transactions and eth_call results, not production load. Scheme-specific caveats. The XMSS verifier checks a signature against a given root; it does not and cannot enforce the signer's one-time-per-leaf state, so signing security still depends on the off-chain signer never reusing a leaf index. Only the smallest parameter sets are on-chain for ML-DSA (44) and SLH-DSA (SHA2-128s), and only the internal interfaces are verified, not the external-context or pre-hash wrappers. The AereLatticeVerifier core is a reduced-degree (n=74) demonstration, not a spec-complete scheme. The breadth claim, hedged not headlined With those caveats stated honestly, and to the best of our present knowledge, we are not aware of any other public chain that verifies all of these on-chain. The full derivation, the fixture digests, the per-scheme gas accounting, and the precompile receipts are in the companion research paper, research/pqc-onchain-verification.md . Chapter 3 contract registry (verbatim, chain 2800) Scheme Contract Address Family Status WOTS+ (one-time) AerePQCVerifier 0x1cE2949e8cE3f1A77b178aF767a4455c08ec6F82 Hash records XMSS-SHA2_10_256 AereXmssVerifier 0x77b14E264D0bb08d304d4e0E527F0fCdFc88B112 Hash records SLH-DSA-SHA2-128s AereSphincsVerifier 0xAfFc9F8d950969b46b54e77758BbFf7e000c87e6 Hash records Falcon-512 AereFalcon512Verifier 0x4E8e9682329e646784fB3bd01430aA4bA54D8fFC Lattice (NTRU) records Falcon-1024 AereFalcon1024Verifier 0xF0aFA59BaB2058e4B6e6B424b7f76750F1F66e36 Lattice (NTRU) records (precompile) ML-DSA-44 / Dilithium2 AereMLDSA44Verifier 0xf1F7A6Acd82D5DAf9AF3166a2F736EE52C5F85AE Lattice (module) records (precompile) Hybrid ECDSA + Falcon-512 AereHybridAuth 0xc20390C9656ECe1AE37603c84E395bC898b3FAA1 Composite records PQC smart-account factory AerePQCAccountFactory 0xd5315Ea7caa60d320c4f34b1bEd70dd9cc02CE58 Composite records Every address above is copied verbatim from the canonical registry sdk-js/src/addresses.ts . AereLatticeVerifier ( 0x60c06E6A3CC201B46A16650be096C6E45424dfD9 ) is a reduced-degree (n=74) demonstration core, superseded by AereFalcon512Verifier for real use. 04 Verifiability Zero-Knowledge and Verifiability A multi-prover, route-by-selector, verify-then-record surface on mainnet 2800: two zkVMs, a KZG path, a generated Halo2 verifier, real recursion, and five application verifiers, each with its honest edge. Chain 2800 · companion deep-dive: research/specs/spec-zk-stack.md If the AERE thesis is "final as math, safe when the math changes," this is the chapter where "final as math" stops being a slogan and becomes a contract call. A zero-knowledge proof lets one party convince another that a computation ran correctly and produced a claimed output, without the verifier re-running that computation and often without the prover revealing its inputs. AERE hosts a working surface of these verifiers directly on mainnet 2800, so an ordinary account can hand proof bytes to an ordinary EVM contract, receive a cryptographic accept-or-reject verdict, and have that verdict recorded permanently. The full engineering treatment, with every verification path, trust boundary, and measured cost, lives in the companion document research/specs/spec-zk-stack.md ; this chapter summarizes what the stack is, what each piece actually proves, and where the honest edges are. Four framings hold everything below in place. First, this is an application and account layer capability, not a consensus feature. None of the verifiers here change how AERE produces or finalizes blocks; consensus is hybrid post-quantum in the anchor-certificate sense (chapter 3) by a separate mechanism, and these verifiers are not it. The verifiers are ordinary contracts that add verifiable computation on top of the chain, not inside consensus. Second, the network is small and centralized today: ten validators under a single operator, two clients (Besu and, since 2026-09-11, Nethermind), no external audit, and thin on-chain usage of these verifiers (single-digit proof records for most of them). That is the baseline against which the engineering should be read, not a footnote to it. Third, addresses are printed verbatim from the canonical registry sdk-js/src/addresses.ts . An earlier edition of this chapter withheld the hex for several verifiers that were then awaiting promotion into that registry, and that is out of date: measured on 2026-08-01, the KZG verifier, the Halo2 verifier, the zkML verifier, the recursion aggregator and the state-root anchor are all in the canonical registry and all carry live code, so their addresses are printed below. Where the registry marks an address as superseded, this chapter says so and names the replacement instead of quietly citing the old one. Fourth, the honest breadth claim is narrow: AERE hosts a multi-prover verification surface (SP1, RISC Zero, a raw KZG precompile path, and 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. One shape: route by selector, verify then record Every proof system in the stack follows the same two-layer pattern, and understanding it once explains the whole surface. The lower layer is a concrete verifier: an SP1 Groth16 or Plonk verifier, a RISC Zero Groth16 verifier, a generated Halo2 verifier, or the EIP-4844 point-evaluation precompile. Each takes proof bytes plus public inputs and either returns cleanly or reverts. The canonical SP1 and RISC Zero verifiers follow the Succinct and RISC Zero convention of returning nothing and reverting on an invalid proof, so AERE's wrapper contracts consistently catch that revert and translate it into a typed error, and a caller never mistakes empty return data for a pass. Fig 4.1 The verification surface: applications verify then record, routers route by 4-byte selector, concrete verifiers stay immutable Applications · verify then record AereProofRegistry verify, then record permissionless attestations 0x0A9b09...517Ee zkML MNIST 97.98% zk-KYC ZKScreen v3 storage-proof coprocessor rollup validity epoch 0 recorded recursion: proofs of proofs ~390k gas whether folding 3 or 10 AereAIProof: signed provenance, not zk Route by first 4 bytes · version selector SP1VerifierGateway 0x9ca479...70628 · add or freeze routes RiscZeroVerifierRouter 0x3f7015...6a249C Concrete verifiers · immutable, revert on invalid SP1 Groth16 v6.1.0 ~300k gas SP1 Plonk v6.1.0 no per-circuit setup RISC Zero Groth16 risc0 5.0.0-rc.1 KZG precompile 0x0A Halo2 generated Honest edges: RISC Zero canonical recording needs one Foundation addVerifier tx (corrected stack is the live path); the Halo2 SRS is a local dev setup, not a ceremony; boxes marked V2 supersede an earlier version named in the text. What it shows. Application verifiers and the attestation registry hold only a router address, so a new prover version plugs in upstream with a single owner call and no downstream migration. Each concrete verifier a route points at is immutable, so what a frozen route computes cannot change. The honest limit, measured on the live bytecode on 2026-08-01, is that the route owner also chooses which contract a selector resolves to: the SP1 gateway carries addRoute and freezeRoute, the RISC Zero router carries addVerifier and removeVerifier, and the routes in use are not frozen today. The guarantee therefore holds against the verifier a route already points at, not against the party that owns the route. The amber strip lists the honest edges carried verbatim in the sections below. The upper layer routes and attests. Concrete verifiers sit behind routers keyed on the first four bytes of the proof, a version selector. SP1VerifierGateway 0x9ca479C8c52C0EbB4599319a36a5a017BCC70628 routes an SP1 proof to the correct SP1 verifier version by its leading selector and refuses frozen routes. RiscZeroVerifierRouter 0x3f7015BC3290e63F7EC68ecF769b00aB296a249C routes a RISC Zero seal the same way. Because routing is by selector, a new prover version is added with a single owner call on the router, and downstream application contracts that hold only the router address need no migration when a new prover ships. AERE's application verifiers all hold the gateway or router address rather than a concrete verifier, precisely for that reason. On top of the routers, AereProofRegistry 0x0A9b09677DbE995ACfC0A28F0033e68F068517Ee records each successful verification as a permanent, event-indexed attestation with permissionless program registration. The mechanism is real and the usage is thin, so the number is published beside it: measured on 2026-08-01 the canonical registry holds one registered program and one recorded proof. The provers: SP1 and RISC Zero SP1 (Succinct Labs) is a RISC-V zkVM. A guest Rust program compiles to an ELF, and its verification key binds that exact ELF; a proof then attests that the guest ran to completion on some private witness and committed a specific public output. Groth16 gives constant-size proofs at roughly 300k gas to verify; Plonk avoids a per-circuit trusted setup at somewhat higher cost. Both route through the same gateway above, with the production Groth16 verifier at SP1VerifierGroth16_v6_1_0 0xb5456d48bFdA70635c13b6CBE1Ad0310Dc0171aD , the retained prior version at SP1VerifierGroth16_v6_0_0 0xa9BD3020bC9a9614F9e2BC1618153c9fB1890ca6 , and Plonk at SP1VerifierPlonk_v6_1_0 0x24a7a85E6D9A2b120F2730880bE7283dFB14d29B . Every AERE application verifier in this stack that says "SP1" verifies through this one gateway, whose owner adds or freezes routes. Each concrete verifier behind a route is immutable, so what a frozen route computes cannot change; what the owner does control is which contract a selector resolves to, and the SP1 routes in use are not frozen today. RISC Zero is a second RISC-V zkVM, included so the stack is genuinely multi-prover rather than single-vendor. A receipt attests that a guest with a given image ID produced a journal with a given digest. This is also where the stack is most honest about its own history. The originally deployed RISC Zero verifier, retained on chain as RiscZeroGroth16Verifier_DEPRECATED 0x95cB30f3bdb3187f39203A9907bf707Aef07a1FD , was bootstrapped with a non-canonical control root that matches no released risc0 version, so it could never route a genuine receipt and every real seal reverted. The fix deployed a corrected verifier, RiscZeroGroth16Verifier 0xb6fD00D88Bf8B08d6371d2D98E0e239B89Ab5B9D , carrying the genuine control root and selector for risc0 5.0.0-rc.1. A self-owned corrected stack, RiscZeroVerifierRouter_Corrected 0x62b96F7211F832f47d8Fc0D8317D5867B0Af43E5 and AereProofRegistry_Corrected 0x174F616E2048A71408E2491791ef77cd6913bbEf , was deployed at the time to record a real RISC Zero factorization proof, and it remains on chain. Two corrections to the earlier edition of this text belong here in plain sight rather than in a footnote. First, the canonical addVerifier transaction described previously as staged and unsigned was in fact executed: measured on 2026-08-01, the canonical router 0x3f7015BC3290e63F7EC68ecF769b00aB296a249C resolves selector 0xef6cb709 to the corrected verifier 0xb6fD00D88Bf8B08d6371d2D98E0e239B89Ab5B9D (4,664 bytes of live code), and AereProofRegistry.risc0Router() returns that same canonical router, so canonical RISC Zero recording is wired and live rather than roadmap. Second, that router, the registry and the SP1 gateway were described as Foundation-owned; owner() on all three does not return the Foundation account. They sit today under an operational deployment account and are scheduled to move to governance, which is tracked in Chapter 9. Recording the bug rather than quietly redeploying is deliberate, and the full trace lives in the spec. The attestation registry AereProofRegistry is the single log that both verifies and records proofs from SP1 and RISC Zero. It verifies first (delegating to the gateway or router, which revert on an invalid proof), then writes a record and emits an event indexed by program, so off-chain consumers can subscribe to exactly the program they care about. Program registration is permissionless: anyone registers their own SP1 verification key or RISC Zero image ID under a human-readable name. The Foundation can disable a malicious program but cannot disable a legitimate one, and disabling never retroactively invalidates a proof already recorded. View-only twins give the verdict without writing a record, for callers that need the answer but not a permanent attestation. Because the registry holds the gateway and router rather than concrete verifiers, a future prover version plugs in upstream with no registry migration. Commitment primitives: KZG and Halo2 Two more verifiers extend the surface from zkVM proofs to polynomial-commitment proofs. AereKZGVerifier 0x6596307BD8f54d9A91FE364EBC3e594F200AC862 (1,988 bytes of live code, in the canonical registry as of 2026-08-01) forwards a 192-byte input to the EIP-4844 point-evaluation precompile at address 0x0A and proves that a blob polynomial committed to by a 48-byte KZG commitment evaluates to a claimed value at a claimed point. It enforces both the precompile success flag and the exact canonical 64-byte return, so no empty account or stray contract can satisfy it by chance, then records the opening append-only with no owner and no admin. The honest scope is that this verifies a KZG opening; it does not by itself prove that a particular blob was posted for a particular transaction, and QBFT produces no blobs, so this is a verification primitive available to applications rather than a data-availability layer the chain itself uses. AereHalo2CubicVerifier 0x414Cfe640B2770856d3D7262a7a3729f5c07dC55 (4,804 bytes of live code, in the canonical registry as of 2026-08-01) with its companion AereHalo2ProofAnchor (deployed, address in contracts/deployments/halo2-cubic.json , and the one contract in this group still absent from the canonical registry) verifies a real Halo2 proof for a small standard-PLONK circuit, generated by the privacy-scaling-explorations Solidity verifier generator with the verifying key embedded in bytecode, and the anchor records each accepted proof append-only. The load-bearing caveat here is stated plainly: the KZG structured reference string was generated locally on the AERE build server, not from a public multi-party trusted-setup ceremony. That is sufficient to demonstrate that AERE can host and verify a real Halo2 proof on chain. It is not production-grade for a value-bearing circuit, where a ceremony SRS would be required, and replacing the dev SRS is an explicit roadmap item before any Halo2 circuit secures value. Recursion: proofs of proofs AereProofAggregatorV2 0x944dE720D6C9696Bdf10b6E2F00dd21ABB1A2b4C (4,663 bytes of live code) is where the stack demonstrates recursion. It supersedes the first aggregator 0x6a260238890E740dB12b371E0C5d17a2470F84C5 , which the canonical registry now marks as deprecated because it counted the folded inner program keys without requiring them to be registered, so a fold containing an unregistered inner program was recorded rather than rejected. V2 requires every folded inner key to be an allowed program and reverts otherwise. Both contracts are live; the earlier one is left on chain and holds no funds. An aggregation guest recursively verifies N inner SP1 proofs inside the zkVM and commits a single composite digest binding every inner verification key and public-values hash. The on-chain contract recomputes that composite byte-for-byte from the supplied inner arrays, requires it to equal the proof's public values, and then verifies one Groth16 proof through the SP1 gateway. Two real aggregations are recorded on the first aggregator, a three-proof fold of distinct statements and a ten-proof scale fold, with the recognized inner-program count matching in each case, and V2 carries one recorded aggregation of its own (measured 2026-08-01: two records on the deprecated contract, one on V2). The measured point is that verifying the aggregate on chain costs roughly 390k gas whether folding three inner proofs or ten, so verification cost stays essentially flat as the folded set grows. The proving side is not free, and the artifacts record it honestly (hundreds of seconds of off-chain proving for the scale fold), but constant on-chain verification cost is exactly what recursion buys, and it is the mechanism by which many statements can settle behind one succinct check. Fig 4.2 Recursion: many proofs fold into one, and the on-chain verification cost stays flat N inner SP1 proofs proof 1 proof 2 proof N AereProofAggregator recursively verifies N inner proofs inside the SP1 zkVM commits one composite digest recomputed byte-for-byte on-chain On-chain one Groth16 verified via the SP1 gateway ~390k gas Constant on-chain cost, whatever the fold size fold 3 proofs ~390k gas fold 10 proofs ~390k gas On-chain verification stays flat; off-chain proving does not, taking hundreds of seconds for the ten-proof fold. Two real folds, a three-proof and a ten-proof, are recorded on chain 2800. What it shows. An aggregation guest recursively verifies N inner SP1 proofs inside the zkVM and commits a single composite digest; the chain recomputes that digest byte-for-byte and verifies one Groth16 proof. On-chain cost stays essentially flat at roughly 390k gas whether the fold binds three inner proofs or ten, which is exactly what recursion buys. The proving side is not free, and the artifacts record that honestly. Applied verifiability The primitives above become useful through five application verifiers, each proving something a settlement layer actually needs. Fig 4.3 The five application verifiers, each with the honest edge it carries zkML AereZKMLVerifier proves MNIST inference on a private input 97.98% measured test accuracy edge: one small model, one dataset zk-KYC / compliance AereZKScreen v3 off-chain screen to an on-chain clearance flag, no personal data edge: over-18 program registered (2026-08-01) one Foundation signature Storage proof AereStorageProofVerifier a slot held a value at a given state root edge: does not prove that root is canonical (the caller's job) Rollup validity AereEVMValidity a full-EVM state transition, final the instant it verifies edge: proof-of-approach on small real blocks, not at scale AereAIProof signed provenance anchors who signed what about an AI inference signature-based, not zero-knowledge (named as such) Reading the cards top line: what it proves green: a measured result amber: the honest edge each is a real deployed verifier What it shows. The five application verifiers gathered in one view, each with the honest edge stated verbatim in the sections above. Four are zero-knowledge; AereAIProof is signature-based provenance and is labelled as such so the distinction is never blurred. Green marks a measured result, amber the honest edge. zkML. AereZKMLVerifier 0xf1BF15d5018a35D21FBB4Ec868f062DF7C06783c (3,658 bytes of live code, in the canonical registry) proves that a machine-learning model classified a private input without revealing that input. The reference model is a genuinely trained, quantized MNIST digit classifier whose forward pass runs inside the SP1 zkVM on a private image, exposing only the predicted digit, with the weight hash recomputed inside the zkVM. One boundary was previously stated too broadly and matters to integrators: the recording path verifyAndRecord checks that the model is registered and binds the chain id, the caller and the model hash, while the plain verify view checks only the proof and the input length and records nothing. Only the recording path supports the stronger statement that the classification came from the registered model. Its measured accuracy, recorded on-chain for transparency, is 97.98 percent on the MNIST test set. The honest scope is that this proves inference integrity for one small model on one dataset. It is a real measured classifier, not a hand-picked toy, and it makes no claim about large models. zk-KYC and zk-compliance. AereZKScreen 0x3A097A459FD26aC79573aCB5adB51430e473C2f1 proves that a user passed an off-chain compliance screen inside the zkVM and anchors only a clearance flag, so no personal data touches the chain. Its soundness core is a root-binding check: each program binds a Foundation-set authorized root, and the proof must match it, which is what stops a prover from proving membership in an allowlist of their own making. The version history in the registry records that earlier deployments had exactly that class of hole, and the current v3 is the fix, a candid detail preserved rather than erased. Alongside it, AereCompliancePoolSP1Verifier 0xE2D3fa91b680E835c971761ba75Fde0204AEF95E is the production SP1 verifier for a compliance-preserving shielded withdrawal, consumed by AereCompliancePoolV2 0xB144c923572E5Ac1B6B961C4ccfec36917173465 , which currently holds zero deposits. Grouped with these for completeness is AereAIProof 0xFf92c669AbF4C1DAE31eBFCC017764036d9D97e6 , which is signature-based provenance, not zero-knowledge: it anchors signed statements about AI inferences and proves who signed what, not a hidden computation. It is named as such so the distinction is never blurred. Storage-proof coprocessor. AereStorageProofVerifierV2 0x487021f9aE018657B7335ADC6Fc254717751a1Dd (3,160 bytes of live code) proves that, at a given state root, a specific account's storage slot held a specific value. It supersedes the first storage-proof verifier 0xF9a1A183bEb3147D88dA5927301683fEbFb9362E , which the canonical registry marks as deprecated because anchored and unanchored submissions shared one record key, so a record established through the anchored path could be displaced by one submitted through the unanchored path. V2 keeps the two apart and its canonical read returns the anchored record only. The earlier contract is immutable, holds no funds and is left on chain; do not read it as canonical. The SP1 guest RLP-decodes and hash-chains the real Merkle-Patricia proof of AERE's state trie, walking from state root to storage root to value with no Foundation-seeded side tree. A first real proof was recorded on chain against the earlier contract, and during the migration that same proof was replayed onto V2 and accepted by its verification path. The precise reading, because it is the whole point of the fix: replaying it through the unbound path left it in the submitter's own namespace, so V2's canonical read still reports nothing, exactly as designed. V2 holds no anchored record today, and establishing one needs a fresh proof anchored inside the anchor's block-hash reach. The primitive carries the single most important caveat honestly: the verifier proves the value against the given root, but it does not prove that the root is the canonical root of that block. That canonicity is the caller's job. The companion AereStateRootAnchorV2 0x0b959402283c0D2B9db4FfD7823f99782462e488 (2,652 bytes of live code, in the canonical registry, and the only writer whose submissions the verifier treats as anchored) is the building block that closes that gap, recovering a block hash strictly from the BLOCKHASH opcode. Chain 2800 served BLOCKHASH for the last 256 blocks, and the EIP-2935 history contract that extends that lookback to an 8191-block window is live on mainnet, deployed with the AerePQC fork (block 9,189,161, 2026-07-12) alongside the post-quantum precompiles. Measured on 2026-08-01 it carries 83 bytes of code and the window was walked end to end: offsets of 1, 255 and 8,190 blocks behind the head each return the canonical block hash reported by eth_getBlockByNumber , and 8,191 blocks back is the last that answers. One honest gap remains and is named rather than implied: the consumer contract that would use that window, AereHistoryStateRootAnchorV2 0x4C1F9daD515c7990b65F9833960CA4315216330C , reads back an immutable VERIFIER() of 0xF9a1A183bEb3147D88dA5927301683fEbFb9362E , the deprecated verifier above, so the extended-lookback path is deployed but not yet wired to the corrected verifier. Repointing it needs a fresh deployment, and until then the trustless canonicity available in practice is the 256-block anchor path, not the 8191-block one. Rollup validity anchor. AERE records SP1 Groth16 validity proofs that its deterministic executor transitioned one state root to the next by applying a committed batch, and unlike an optimistic rollup with a challenge window, an epoch recorded here is final the instant the proof verifies. The first anchor, the bounded-VM AereRollupValidity 0x38772063572DF94E90351e44ccbBEefD5F497fbd , recorded its epoch 0 from a real proof over a fixed four-kind transaction set. It has since been superseded by a full-EVM validity anchor, AereEVMValidity 0x1f2CB0ebDBb21500e99868DbF1dB3abCcDd7DF26 , which verifies SP1 proofs of a real revm (via rsp / sp1-reth) executing genuine chain-2800 blocks; two real blocks have been proved and verified on-chain through the SP1 gateway. This is the most literal expression of "final as math" in the stack, and it now proves real full-EVM execution rather than a bounded VM. The current anchors bind that proof to the canonical chain: AereEVMValidityV2 0x4884ad6617e320735b65D31915d1aBC884768D9B verifies an SP1 proof that a block's EVM execution is valid and ties it to the QBFT-canonical block at that height, and AereEVMValidityBatchV2 0xe154B8993FB54dB4418e03ef4a04894f29E690aE extends the same check across a batch of consecutive blocks. The honest remaining scope is that AereEVMValidity is a proof-of-approach on small real blocks today; scaling it to full-throughput production rollup batches is ongoing, and nothing built on it should imply a production-scale validity rollup yet. Honest scope of the whole surface What it is not, stated so nothing reads as spin: it is not a consensus feature, it does not run on an audited or decentralized network yet, and its Halo2 SRS is a dev setup. Two former boundaries have moved: its rollup validity proof now covers a real full EVM through AereEVMValidity rather than a bounded VM, a proof-of-approach on small real blocks still being scaled to production batches; and trustless storage-proof canonicity beyond the 256-block window is addressed by AERE's extended EIP-2935 lookback to an 8191-block window, now live on mainnet as of the AerePQC fork (block 9,189,161). Honest scope and what is next Taken together, the stack is a route-by-selector, verify-then-record surface spanning two zkVMs, a KZG precompile path, a generated Halo2 verifier, real recursion, and five application verifiers, with a permissionless attestation registry binding them. What it is not, stated so nothing reads as spin: it is not a consensus feature, it does not run on an audited or decentralized network yet, and its Halo2 SRS is a dev setup. Two boundaries that used to sit here have moved: its rollup validity proof now covers a real full EVM (a real revm inside the SP1 zkVM, verified on mainnet through AereEVMValidity ) rather than a bounded VM, as a proof-of-approach on small real blocks that is still being scaled to production batches; and trustless storage-proof canonicity beyond the 256-block window is addressed by AERE's extended EIP-2935 lookback to an 8191-block window, now live on mainnet as of the AerePQC fork (block 9,189,161). Two more items that used to head the roadmap are done and are removed rather than left to age: the canonical registry can already record RISC Zero proofs, because the router transaction described earlier as unsigned was executed and the route resolves live, and the verifiers that were awaiting promotion are in sdk-js/src/addresses.ts , with only AereHalo2ProofAnchor still outside it. The near-term roadmap is what is left: promote that last anchor into the registry, replace the Halo2 dev SRS with a ceremony SRS before any value-bearing circuit, repoint the 8191-block history anchor at the corrected storage-proof verifier, commission the first external audit of the now-live native PQC client changes, and scale the full-EVM validity prover from small real blocks to production rollup batches. Every measured figure quoted above is a single-run value drawn from a repository artifact rather than a benchmarked average, and every claim here is meant to be checked against the source, not taken on trust. That is the point of a verifiability stack, and it is the same discipline the rest of this whitepaper holds itself to: final as math, and honest about which math is not finished yet. 05 The First Five Minutes Accounts and Onboarding An account you unlock with a fingerprint and no seed phrase, a first transaction you pay for with no native AERE, and an honest map of which parts are live, source-complete, or roadmap. Chain 2800 · companion deep-dive: spec-account-abstraction The hardest problem in crypto is not throughput or finality. It is the first five minutes. A new user is handed twelve random words, told that losing them means losing everything and that sharing them means the same, asked to buy a native token from somewhere else before they can do anything at all, and then left to sign an opaque hex blob with no way to know what it does. AERE treats that experience as a bug to be engineered away, not a rite of passage. The account layer is where the network's thesis, final as math, safe when the math changes, has to meet an actual human with a phone. This chapter describes how a person gets an AERE account with no seed phrase, transacts without holding any native AERE, upgrades an existing wallet in place, hardens it with session keys and social recovery, gives a non-fungible token its own wallet, and, at the far edge of the roadmap, binds authorization to a post-quantum key. The companion specification spec-account-abstraction carries the byte-level detail; here we summarize what is live, what is source-complete but not yet deployed, and where the seams honestly are. What the chain gives the wallet layer Two protocol features do the heavy lifting, and both arrive from the network's EVM ruleset, Pectra plus Fusaka, which targets functional parity with Ethereum mainnet. The first is the secp256r1 (P-256) verification precompile introduced by RIP-7951, present unconditionally at address 0x100 from the Fusaka activation block onward. P-256 is the curve that every consumer secure enclave already speaks: Apple Face ID and Touch ID, Windows Hello, Android biometric keystores, hardware keys such as YubiKey, and the EU Digital Identity Wallet. Before this precompile, checking one of those signatures inside a contract meant running the curve arithmetic in Solidity, which is prohibitively expensive. With it, the check is a single native call cheap enough to run on every transaction. That one change is what makes a passkey a first-class on-chain signer, and it is what lets a user authorize account operations with a fingerprint instead of a mnemonic. The second is EIP-7702, which lets an existing externally owned account sign an authorization that makes it execute a designated contract's code while remaining controlled by its original key. This is the upgrade-in-place primitive: a plain wallet can gain batching, session keys, and passkey support without moving a single token to a new address. One constraint from the chain shapes the designs below and is worth stating up front. AERE's own EntryPoint keeps a strictly sequential, single-dimension nonce per sender rather than the two-dimensional nonce keys canonical ERC-4337 uses to route between signature validators. Accounts that want to switch validators therefore route on a signature prefix byte instead of a nonce key. It is a small thing, but it is the kind of honest seam this document prefers to name rather than paper over. Passkey smart accounts (live) Live The production onboarding path is a passkey smart account: a contract wallet whose owners can be WebAuthn P-256 keys, ordinary key-based accounts, or a mix of both. A user creates one with the same biometric gesture they already use to unlock their phone. There is no seed phrase to record, because the private key never leaves the device's secure element and is never expressible as words. Fig 5.1 Onboarding without a seed phrase and without native AERE: passkey to a sponsored first transaction The first five minutes Biometric gesture passkey in secure enclave no seed phrase Factory PasskeyAccountFactoryV2 counterfactual address WebAuthn verify RIP-7951 @ 0x100 ~3,450 gas Onboarding paymaster sponsors first ops no native AERE held First transaction final on-chain The private key never leaves the secure element and is never expressible as words. The user authorizes with a fingerprint, not a mnemonic, and needs no native AERE to make the first move. Sponsorship runs through a Foundation-hosted relayer today. What it shows. The two protocol primitives (the RIP-7951 P-256 precompile at 0x100 and the paymaster stack) combine so a person creates an account with a biometric gesture and transacts with no native token. The counterfactual factory means funds can be sent to a wallet before it is deployed. The honest seam: sponsorship and relaying currently depend on a Foundation-hosted relayer, and the two-EntryPoint split described below is real. Accounts on this line are minted by AerePasskeyAccountFactoryV2 at 0x5FFa9a6487DA4641a1A1e7900ff2bD4525D34fdA , a deterministic factory that can compute an account's address before it exists, so funds can be sent to a wallet that has not yet been deployed. Each account is pinned to the account-facing EntryPoint, AereEntryPointV2 at 0x8D6f40598d552fF0Cb358b6012cF4227B86aF770 . The original single-owner factory, AerePasskeyAccountFactory at 0xfB0eF980667A79Fe1AB69c5f2d512118F1B30739 , remains on chain for its first demo account only. One correction belongs here in plain sight: our own canonical registry now flags the live V2 factory as flawed in the signature-validation path of the accounts it produces, and says new wallets should not be created on it. A corrected factory, AerePasskeyAccountFactoryV2Fixed 0x8FA2B45D63EBaa4551A55d7f33a82d597e423428 , is deployed with 9,675 bytes of live code and is inert until a supervised swap points the product surfaces at it. Until that swap lands, read the passkey wallet line as in migration rather than as settled, and treat the address above as the historical factory rather than as a recommendation. Under the hood, WebAuthn verification is a precompile-only port of Coinbase's webauthn-sol library. It rejects malleable signatures, confirms the assertion is a genuine webauthn.get response, reconstructs the challenge and binds it to the on-chain operation, requires a verified user gesture (a biometric or PIN, not a bare presence tap), and finally calls the 0x100 precompile. The ownership model stores each owner as raw bytes, a key-based account or a P-256 public key, and every owner-management action must arrive as an authenticated self-call, so no outside party can add or remove owners. Any single owner can manage the set, and the set can never be emptied. That is the account's recovery story in its shipped form: keep at least one owner, and pre-register a backup key, for example a hardware wallet, so that losing the primary passkey does not lose the account. Guardian-based recovery is a separate module discussed further down. An account can authorize a call three ways, all resolving through the same signature-verification routine: the standard ERC-4337 path driven by a bundler, a direct passkey path where the Foundation relayer (or the user) submits the call without a bundler, and EIP-1271, which lets the wallet produce contract signatures accepted by Permit2, OpenSea, Snapshot, and ordinary dapp logins. Each path binds its signature to this account, this chain, and this exact call, so a signature can never be replayed elsewhere. The EntryPoint, stated honestly AERE actually ships two EntryPoint contracts, and integrators should know the difference. AereEntryPointV2 is the account-facing coordinator: it runs the canonical validate-then-execute batch flow, computes the standard operation hash bound to the chain, keeps per-account deposits, and emits the standard events that bundlers and indexers subscribe to. It is shaped so external bundlers such as Pimlico, Stackup, or ZeroDev can target it, while AERE runs its own relayer during bootstrap. Alongside it, a lightweight AereEntryPoint at 0x19773ba45287A64B05d0BCBD59D1371BF51Bd5D2 carries the deposit-and-stake surface that the paymasters bind to. A named seam: two EntryPoints The honest consequence, spelled out in the companion spec, is that the account-facing EntryPoint charges a sponsoring paymaster's deposit but does not itself invoke that paymaster's policy checks; gasless sponsorship therefore currently runs through the relayer plus lightweight-EntryPoint path where the policy hook is actually called. Unifying the two into a single EntryPoint that validates both account and paymaster in one batch is a tracked roadmap item. We would rather document the seam than imply a byte-for-byte reimplementation that does not yet exist. Gas that feels like it is not there "Gasless" on AERE means the user needs no native AERE to transact. Fees on the network are negligible to begin with, and the paymaster stack removes even that friction by letting the Foundation, a dapp, the user's own stake, or an ordinary token cover the cost. Four paymasters are live, all sharing a common base and each enforcing its own sponsorship policy. First touch Onboarding AereOnboardingPaymaster 0x4058E406475Dbed7056Aee0c808f293F05fEa879 Sponsors a hard-capped number of ops per address under a sitewide daily ceiling for Sybil resistance. Live Dapp-funded App factory AereAppPaymasterFactory 0xEC22603E8712cBc5c31E53370D10f1a80CcB4DF0 Any dapp permissionlessly deploys and funds its own paymaster from its own treasury. Live Pay-in-token Token V2 AereTokenPaymasterV2 0x217f56a5b0C7f35abe4D2fff924A6c13B85d7243 Settle fees in a whitelisted token at an oracle price with a bounded markup. Live Stake-for-tx Stake quota V2 AereStakeQuotaPaymasterV2 0xE50464ca7E8E7F542D1816B3172a2330cFE384E8 A user's effective AERE stake buys a daily quota of sponsored operations that resets each day. Live AereOnboardingPaymaster at 0x4058E406475Dbed7056Aee0c808f293F05fEa879 is the first touch. It sponsors a small, hard-capped number of operations per address under a sitewide daily ceiling for Sybil resistance, letting a fixed and modest Foundation budget carry a large number of first-time users through their opening interactions before they hold anything at all. AereAppPaymasterFactory at 0xEC22603E8712cBc5c31E53370D10f1a80CcB4DF0 lets any dapp permissionlessly deploy and fund its own paymaster from its own treasury, the standard pattern for a game or marketplace that wants to pay its users' fees. AereTokenPaymasterV2 at 0x217f56a5b0C7f35abe4D2fff924A6c13B85d7243 lets a user settle fees in a whitelisted token instead of native AERE, converting at an oracle price with a bounded markup. AereStakeQuotaPaymasterV2 at 0xE50464ca7E8E7F542D1816B3172a2330cFE384E8 offers a stake-for-transactions model: a user's effective AERE stake, read live from AereStakingV2 at 0x1D95eF6D17aeAB732dF914Ba2d018c270BC155FC and AereLockedStaking at 0x21108c28A849b05aE6b7a3a5bc435C9Bc897E7Ad , buys a daily quota of sponsored operations that resets each day. Both V2 token and stake-quota paymasters are hardened redeploys that fixed confirmed bugs in their V1 predecessors, and both V1 contracts, along with the legacy passkey factory, remain on chain but deprecated. Integrators must point at the V2 addresses above. The companion spec documents each fix; the shape of the honesty is that these contracts were reviewed, found wanting, and replaced in the open rather than quietly. Upgrading a wallet in place (EIP-7702, live) Live Not everyone wants a new address. A user who already holds an ordinary key-based wallet can keep it and gain smart-account behavior by delegating to AereDelegate7702V2 at 0xC6d18e0Ce1B6467d952e31315505E0190a4A3310 , the corrected replacement for the earlier V1 at 0x5673D92080efbd0987402E9335c14200d0a5EaeF . The V1 is deprecated and should not be delegated to, because a session key on it could escape its intended scope; V2 closes that gap. Because EIP-7702 transmits only code and not storage, every account delegating to this one shared implementation gets independent storage at its own address and can re-point or revoke its delegation at any time with no migration. The delegate gives that wallet atomic batching (many actions in one confirmation), an optional registered passkey for relayer-paid calls, and scoped session keys with an expiry, a target and selector allowlist, a per-key spend cap, and a kill switch. A companion index, AereDelegationRegistry at 0x6c25c07D134713b6C2F8E19D807423f022903D63 , is a purely informational, permissionless directory that dapps read to show a "smart-wallet enabled" badge; it holds no funds and has authority over nothing. Modular accounts, session keys, and social recovery (in development) In development The next-generation account line is source-complete but not yet on mainnet, and this document will not print an address for a contract that does not exist on chain 2800. It comprises an ERC-7579 modular account with pluggable validator and executor modules, two generations of a session-key validator, and a social-recovery module. The session-key validators grant a scoped key a time window, a spend cap, and an allowlist of permitted calls, and the V2 iteration closes a confirmed cap-bypass and forbids a session key from ever calling account-admin functions back into its own account. The social-recovery module is the guardian-based flow the live passkey account deliberately lacks: an M-of-N guardian set can, after a timelock and a threshold of approvals, rotate the account's owner, with the current owner able to cancel at any time before execution. When this line is audited and deployed, its addresses will enter the canonical registry and this chapter will be updated to describe it as live. Until then it is honestly labeled in development. Token-bound accounts (ERC-6551, live) Live ERC-6551 gives every non-fungible token its own wallet. These are account primitives, not tokens; they mint nothing and have no supply. The ERC6551Registry at 0x7fFdA0AcDeB919938dB91dbEa779D841c833EF68 is the verbatim reference registry, a stateless, owner-less factory that deploys a deterministic account bound to a specific token. The implementation those accounts point at is AereTokenBoundAccount at 0xBc5e24180f3F75DC6b1965E4aaD3D4F184b6F9E2 , whose sole source of authority is whoever currently holds the bound token, read live. The holder can execute calls and produce EIP-1271 signatures on the account's behalf, and because the account also supports the ERC-4337 path, a paymaster can sponsor the token wallet's fees too. A live demonstration binds token number one of AereNFT at 0x3f9A9D9CAB005327869396C69bE226ef98039f1c to the account at 0x82D24cC4E09CaBfD9B00233438B8B6321CBC13Dd . The practical effect is that a character, a membership, or a real-world-asset token can own and move its own portfolio, and transferring the token transfers the whole wallet with it. A post-quantum wallet (live, honest scope) Live At the far edge of the account roadmap sits the most experimental primitive in the stack and the one whose scope must be stated most carefully. AerePQCAccountFactory at 0xd5315Ea7caa60d320c4f34b1bEd70dd9cc02CE58 creates a working ERC-4337 smart account whose sole owner is a NIST Falcon-512 lattice public key, with no classical fallback. Every authorization, whether a bundled operation, a contract-signature check, or a direct call, is decided by the live on-chain AereFalcon512Verifier at 0x4E8e9682329e646784fB3bd01430aA4bA54D8fFC , which runs real lattice cryptography rather than a stub. A sample account owned by a genuine Falcon-512 key lives at 0xa42a5e7F72E46BadC11367650Ec34D676194326f , and both a contract-signature acceptance and a full operation through the account-facing EntryPoint were demonstrated end to end. The honest scope is exactly this. The key is Falcon-512, NIST security level 1, not Falcon-1024. A single post-quantum authorization is genuinely heavy: it consumes on the order of ten million units of on-chain execution work, well under the network's per-transaction ceiling of 16,777,216 units, but far above an ordinary transfer. That cost is why the two largest verifiers in AERE's broader suite, Falcon-1024 and ML-DSA-44, were read-only views on mainnet, rather than usable account owners, until the native precompiles arrived. A native precompile that makes lattice verification cheap was validated against every NIST known-answer test on an isolated Besu scratch fork (chain 28099), where a full Falcon-512 verify-and-record costs only tens of thousands of units, and it is now live on AERE mainnet: the AerePQC client fork activated the five native PQC precompiles at block 9,189,161 (2026-07-12), so a Falcon-512 verify-and-record costs a fixed precompile fee on chain 2800 today, and the two heaviest schemes, Falcon-1024 and ML-DSA-44, moved from read-only views to on-chain records. Crucially, this post-quantum property lives at the account and application layer. It secures how this wallet authorizes operations. It does not touch consensus, which is hybrid post-quantum in the anchor-certificate sense by a separate mechanism. On the breadth of the verifier suite this account draws on, we are not aware of any other public chain that verifies all of these on-chain, and that is the claim, stated with exactly that hedge and nothing stronger. The research paper pqc-onchain-verification carries the full analysis. Honest limitations This layer is real and on chain, and a serious reader should weigh it against what is equally true today. AERE runs ten QBFT validators under a single operator (f=3, quorum 7-of-10), on two clients (nine Besu, one Nethermind since 2026-09-11), with no external security audit of these contracts and thin real-world usage; the wallet layer inherits that trust profile, and sponsorship and relaying currently depend on a Foundation-hosted relayer. The two-EntryPoint split described above is a genuine seam, and its unification is future work. The account-facing EntryPoint implements a compatible subset of the canonical fee economics, sufficient for the hosted relayer rather than a drop-in reimplementation. The live passkey account's recovery is "keep or add a backup owner"; guardian-based social recovery is written but not yet deployed. The modular ERC-7579 line carries no mainnet address and must not be presented as if it did. The post-quantum account is quantum-resistant at the account layer, level 1, and the native precompile that makes it efficient is now live on mainnet via the AerePQC fork (block 9,189,161), so a Falcon-512 authentication costs a fixed precompile fee rather than roughly ten million units of Solidity work. And several deprecated V1 contracts remain on chain at their old addresses; integrators must use the canonical V2 addresses named here. None of this is fatal, and all of it is the point: the account layer is built to be honest about the math it depends on, and safe to change as that math changes. 06 Fair Ordering Fair Ordering and Interoperability Two opt-in anti-MEV subsystems and two interop stacks, all at the application and account layer, with the exact line drawn between what is verified on-chain and where the trust is still human. Chain 2800 · companion deep-dive: spec-antimev-mempool Two questions decide whether a settlement layer is fair to the people who use it. Who controls the order in which transactions execute, and what happens when value has to cross a boundary between chains. Both are ordering problems. Maximal Extractable Value (MEV) is the profit a party earns from controlling ordering inside one chain. Interoperability is the problem of preserving a user's intent as it moves across chains, where a second ordering authority on the far side can extract the same way. AERE addresses both, and this chapter describes what is built, what is demonstrated, and what is still a trust assumption, without rounding any of it up. An honest banner, first Application layer, not base-consensus MEV resistance Everything in this chapter lives at the application and account layer. None of it changes AERE's base consensus. AERE runs QBFT with ten validators under one operator and two clients (Besu and, since 2026-09-11, Nethermind), and validators sign QBFT messages with classical secp256k1 keys and, since 2026-09-01, with post-quantum seals of their own (refused without them from blocks 17,250,000 to 17,700,000, armed on 2026-09-05) to order the underlying transactions. A QBFT chain cannot acquire a protocol-level encrypted mempool or an enshrined proposer-builder separation without a client fork, and AERE has not forked its client for this. So what follows is not base-consensus MEV resistance and not enshrined PBS. It is a set of opt-in smart-contract and off-chain subsystems that a user or an application can choose to route through, and that protect what they can protect precisely. Everything in this chapter lives at the application and account layer. None of it changes AERE's base consensus. AERE runs QBFT with ten validators under one operator and two clients (Besu and, since 2026-09-11, Nethermind), and validators sign QBFT messages with classical secp256k1 keys and, since 2026-09-01, with post-quantum seals of their own (refused without them from blocks 17,250,000 to 17,700,000, armed on 2026-09-05) to order the underlying transactions. A QBFT chain cannot acquire a protocol-level encrypted mempool or an enshrined proposer-builder separation without a client fork, and AERE has not forked its client for this. So what follows is not base-consensus MEV resistance and not enshrined PBS. It is a set of opt-in smart-contract and off-chain subsystems that a user or an application can choose to route through, and that protect what they can protect precisely. Stating that boundary plainly is the point. For a young chain with a small validator set, credibility comes from scoping the claim correctly, not from dressing app-layer tooling as a consensus property. The deep mechanics of the anti-MEV design, including the on-chain pairing algebra, the epoch state machine, and the audit-fix history, live in the companion specification spec-antimev-mempool . This chapter summarizes and surfaces; the spec is the reference. Where MEV lives on AERE MEV is extracted in the gap between when a transaction is broadcast and when it is finally included and ordered. A party that can see pending transaction contents and influence their order can front-run, back-run, and sandwich a user's trade. On AERE the ordering authority inside that gap is the QBFT block proposer for ordinary transactions and, for the batch-settlement path, the solver that assembles a batch. AERE attacks the gap from two directions at once. Hide the contents, so whoever fixes the order cannot see what they are ordering. Remove the intra-batch ordering surface, so a set of trades clears together in one atomic transaction with no slot to insert a sandwich into. The two subsystems are conceptually a pipeline and are independent contracts today. They are described in turn. Direction one: a threshold-encrypted mempool The first subsystem is a Shutter-style encrypted mempool. The idea is simple to state and hard to make trustworthy. Users submit their transactions encrypted, under a threshold key that no single party holds. The sequencer commits an ordering while the contents are still ciphertext, so the order cannot depend on plaintext it never saw. Only after ordering is fixed does a committee of keypers release enough shares to reconstruct the epoch decryption key, at which point the transactions are revealed and executed strictly in the committed order. Reordering after the fact is impossible, because the ordering root is already on-chain and reveals must follow it. Fig 6.1 Threshold-encrypted mempool: order is fixed on ciphertext before any key is released 1 · submit encrypted txs threshold key, no single holder 2 · commit order ordering root order fixed on-chain sequencer never sees plaintext no early decrypt 3 · release key 3-of-5 keypers reconstruct epoch key pairing-verified @ 0x0f 4 · reveal + execute in committed order V3 skip after reveal deadline What it shows. The ordering is committed on-chain while the transactions are still ciphertext, so the order cannot depend on plaintext the sequencer never saw. Submitting a decryption share reverts until that commit exists, which is the structural no-early-decrypt guarantee. On-chain, the epoch key is pairing-verified through the EIP-2537 precompile at 0x0f ; the final byte-mask XOR is an off-chain step. This is a trusted-dealer, single-coordinator proof-of-concept, outside the canonical registry. AERE built this in three stages. The V0 contract, AereShutterMempool , is a code-only reference that establishes the commit and reveal skeleton with a placeholder decryption key. It is orchestration plumbing, not cryptography, and it exists in the repository only to be superseded. It carries no deployment record. The real cryptography arrives in V2 and V3, AereShutterMempoolV2 and AereShutterMempoolV3 . These implement Boldyreva threshold BLS over the BLS12-381 curve and verify it on-chain using the EIP-2537 pairing-check precompile at address 0x0f , which is live on chain 2800 under the Pectra ruleset. The contract checks two pairing equalities through that single precompile: that each keyper's share is consistent with its published verifiable-secret-sharing commitment, and that the reconstructed epoch decryption key is the genuine threshold signature over the epoch tag. A malformed share or a forged key fails its pairing and reverts, so a keyper cannot post an inconsistent share and no decryption key can be accepted early or by a minority. The no-early-decrypt guarantee is enforced structurally: submitting a decryption share reverts until the sequencer has already committed the ordering. V3 adds one thing V2 lacked, a liveness escape hatch. In V2 a single committed position whose opening was never revealed would stall every later position in the epoch forever. V3 stamps a reveal deadline at finalization (sixty seconds in the proof-of-concept) and lets anyone skip a genuinely stuck head position once that window closes, while keeping reveal itself permissionless and never deadline-gated, so a late-but-honest opener can still land. Because a well-formed ciphertext embeds its own opening, any holder of the reconstructed key can reveal any position, which is what makes skip safe: it can only ever fire on a position nobody could reveal, never to censor a revealable one. Both V2 and V3 were deployed to chain 2800 and exercised end-to-end, with a three-of-five keyper committee, a finalized epoch, an ordering root over committed envelopes, and reveal-execute transactions walking the order in sequence. The companion spec transcribes the epoch identifiers, decryption-key hashes, and transaction hashes verbatim from the deployment artifacts for anyone who wants to re-verify. A proof-of-concept, with the caveats it carries The V2 and V3 contracts are a proof-of-concept. They are not registered in the canonical SDK address registry, and they carry no production-traffic claim. The proof-of-concept relies on a trusted-dealer Shamir setup, meaning one party transiently holds the master secret while sharing it, which is the single most important cryptographic caveat and a thing a live product must not ship on. The symmetric unmasking step happens off-chain. The coordinator and sequencer default to a single address in the proof-of-concept. Keyper misbehavior can be flagged on-chain through an accountability primitive that reverts on false accusations, but it is detection only, with no economic slashing yet. Now the honesty that has to travel with all of that. The V2 and V3 contracts are a proof-of-concept. They are not registered in the canonical SDK address registry, and they carry no production-traffic claim. Their addresses come only from repository deployment artifacts and are labeled as such; this document refers to them by name rather than promoting their hex to canonical status. The proof-of-concept relies on a trusted-dealer Shamir setup, meaning one party transiently holds the master secret while sharing it, which is the single most important cryptographic caveat and a thing a live product must not ship on. The symmetric unmasking step happens off-chain, because the pairing precompile returns only a boolean; on-chain, decryption-key correctness is fully pairing-verified, so decryption is deterministic and cannot be produced before the threshold acts, but the final byte-mask XOR is an off-chain step. The coordinator and sequencer default to a single address in the proof-of-concept. Keyper misbehavior can be flagged on-chain through an accountability primitive that reverts on false accusations, but it is detection only, with no economic slashing yet. In short, the encrypted mempool demonstrates that the pairing-verified threshold path works on AERE. It does not yet demonstrate a decentralized, dealer-free, slashing-backed production system, and the roadmap names each of those gaps as an item to close before promotion. Direction two: batch-atomic settlement Live The second subsystem is a batch-auction settlement layer, and unlike the mempool it is in the canonical registry and live. It settles trades through a sealed batch with a single uniform clearing price, and it is three contracts: AereSettlement at 0x9C2957b1622567B4802E4AFd4c42FB2ec70dE875 AereSolverRegistry at 0xDBD29332a9993d2816EF0bD240288E03a8103f3B AereVaultRelayer at 0x9FCA122e87E36D7cba20DbEA7b9b7354A4Cece91 The flow is that users sign EIP-712 order structs off-chain, gasless, each carrying the tokens to sell and buy, the exact sell amount, the user's own minimum buy amount, a deadline, and a replay nonce. An authorized solver collects open orders and submits the whole batch atomically through a single settle call. For each order the contract checks the deadline, requires that the solver's promised delivery meets or exceeds the user's own minimum, recovers and verifies the EIP-712 signature against the stated user, marks the order filled so it cannot replay, pulls the sell amount through the vault relayer, and pushes the bought amount to the user. If any order in the loop reverts, the entire batch reverts. Allowances live on the relayer rather than the settlement contract, a two-contract split that lets the settlement logic be upgraded without users re-approving their tokens. Solver access is an owner-curated allowlist in the registry, with a single bootstrap solver today. The MEV protection here is atomicity. Because every order in a batch shares one transaction, no actor can wedge a sandwich between two of them, and every filled order is guaranteed to deliver at least the floor its signer chose or the batch does not go through. Signature and replay safety are enforced per order. Those three guarantees, atomic execution, per-order limit protection, and replay safety, are real on-chain invariants that hold today. The critical honesty is about what the contract does not enforce, because its own docstring is more generous than its code. It does not verify a uniform clearing price on-chain. It checks each order against that order's own floor only, so a solver could in principle fill different users of the same pair at different effective prices as long as each clears its own limit; uniform-price fairness is a solver behavior, not a contract invariant. There is no surplus capture and no protocol fee: any price improvement above a user's floor accrues wherever the solver directs it, and there is no on-chain wiring from this contract to the AereSink flywheel router at 0x69581B86A48161b067Ff4E01544780625B231676 for surplus or MEV redistribution today. Partial fills, contract-signature (ERC-1271) orders, and dynamic fees are explicitly omitted and deferred. And the operational layer that would make this a live product, a dedicated solver service, an order-book API, and an intent toggle in the swap interface, is roadmap rather than deployed; the contracts are live, the surrounding service is in development. So the honest security posture is this: atomicity plus your own signed limit protect you from the worst MEV, and above that floor you are trusting a permissioned solver, one bootstrapped solver at that, for fair uniform pricing and surplus handling. That is a meaningful and deliberate distinction from a fully trust-minimized, permissionless batch-auction settlement, and it is stated rather than glossed. How the two relate today The intended composition is a pipeline: the encrypted mempool blinds the ordering party to order flow, and batch settlement removes the intra-batch ordering surface, so decrypted orders from an epoch would be handed to a settlement executor and cleared as one batch. That integration does not exist on-chain today. The mempool contracts expose an optional executor hook on reveal, but the settlement contract does not implement that interface and no adapter connects them, so a user currently uses one subsystem or the other, not a wired flow. Building that mempool-to-settlement adapter is a named roadmap item, not a shipped feature, and it is described as such. Interoperability: messages and intents Fair ordering does not stop at the chain boundary. When value crosses chains, a second ordering authority on the destination can extract exactly as a local proposer would, so AERE's interop layer is built on the same intent-centric philosophy: let the user express what they want, and let a competitive filler deliver it, rather than exposing a raw sequence of steps for someone to reorder. AERE deploys two complementary, interface-faithful interop stacks. Fig 6.2 Interop stacks: Hyperlane-compatible messaging and an ERC-7683 intent layer, awaiting a live relayer network AERE mainnet 2800 messaging AereMessenger Mailbox AereIGP gas paymaster intents (ERC-7683) AereERC7683 origin settler AereSpokePool Across v3 bridge layer Relayers + ISM single Foundation signer relayer still pending USDC.e Warp Route Phase 3 bootstrap Counterparty chain awaiting deployment counterparty Mailbox counterparty spoke Endpoints are deployed and interface-faithful. What moves value, the relayers, the interchain security modules, and the counterparty deployments, is not yet a live decentralized network. What it shows. The AERE-side endpoints (messaging and the ERC-7683 intent layer) are deployed and faithful to their interfaces. The bridge layer that actually moves value is drawn dashed and amber because it is not yet a live, decentralized network: the existing path runs through a single Foundation signer with a relayer still pending. The first real cross-chain use is the modest USDC.e Warp Route bootstrap that unlocks the home order book and the RWA lending markets in Phase 3. The messaging layer is Hyperlane-compatible. AereMessenger at 0xe54c2329f0786CFE3420c566B646148D25477325 is a Mailbox-compatible cross-chain message bus, and AereIGP at 0x61B48615F490A23945988c92835eF35fdD86E837 is the Interchain Gas Paymaster that receives AERE to fund outbound message gas. On top of that sits an intent layer aligned with the emerging ERC-7683 standard: AereERC7683 at 0x67Fb9830e3a2BC06cEb641cfF3beD87b273ccb29 is an IOriginSettler for gasless cross-chain intents, and AereSpokePool at 0xCAB1DBA5f6F06198000C20a974d675f1B3181AbD is an Across-v3-compatible spoke handling deposit, fill, and settlement. Both of those first versions are marked deprecated in our own canonical registry after an internal audit found a settlement-accounting defect, and neither should be integrated against. The corrected replacements are deployed and carry live code: AereSpokePoolV2Corrected 0xbEF9BF0D22dd00DBEdA262C3Cd3178f08C623d8d (6,317 bytes) and AereERC7683V2Corrected 0x8eC4e7F01790C04D450b45d399E71DFd381560e3 (7,931 bytes). They are fresh and inert: no remote spoke is enrolled and no value has been migrated onto them, so the honest status of the intent lane today is built and corrected but not carrying traffic. Together these let a user sign an intent on one side and have a filler satisfy it on the other, with the origin settler and spoke enforcing the settlement conditions rather than trusting the filler's ordering. The honesty here mirrors the MEV subsystems. These endpoints are deployed and faithful to their respective interfaces, but an interop stack is only as live as its off-chain security. The relayers, the interchain security modules that validate inbound messages, and the counterparty-chain deployments are what actually move value, and those are not yet stood up as a live, decentralized network; the existing bridge path runs through a single Foundation signer with a relayer still pending. The first real cross-chain use is concrete and modest: bridging USDC.e onto chain 2800 through a Hyperlane Warp Route is the Phase 3 bootstrap that unlocks the home order book and the real-world-asset lending markets. Until that bridge is run, the interop contracts are correct endpoints waiting for their network, not a live cross-chain product, and they are presented that way. Native interop: an on-chain zk Ethereum light client Live The stronger interop primitive does not wait for a trusted relayer at all: it verifies Ethereum's own consensus from inside a contract on chain 2800. AereZkEthLightClientV2 at 0x6f01ac96a28D0d670f94A41F323f198be14a17a8 (1,452 bytes of live code) checks live Ethereum Electra sync-committee finality on-chain by verifying a succinct SP1 Groth16 proof rather than trusting a relayer's assertion. It supersedes the first client at 0x2a2b6D936002A62adb4bb1d131007ec564429E9d , which our own canonical registry marks deprecated because its public verify view ran the proof without binding the committed committee to the client's own trusted state, so it was sound as a state machine but unsafe if read as a finality oracle. V2 routes both paths through one binding check. The history below was made on the first client and is real; measured 2026-08-01 that client reports one update and finalized slot 14,753,792, while V2 reports zero updates, so the lineage was carried over at deployment and no new proof has been submitted since. Finality advanced end-to-end through the contract, from slot 14745696 to slot 14753792, in about 297k gas, comfortably under AERE's per-transaction gas cap. Inside the SP1 zkVM the guest proves the full update: 512 sync-committee pubkey decompressions, at least 342 of 512 participation, the BLS12-381 aggregate signature over the Electra signing root, and the finalized-header and next-committee SSZ branches; the on-chain contract does only the cheap Groth16 verify through the live SP1 gateway at 0x9ca479C8c52C0EbB4599319a36a5a017BCC70628 , binds the public values to stored state, then advances finality and rotates the trusted committee. The first real proof, of the period 1800 to 1801 update, was generated on a dedicated non-infra prover in roughly 24 minutes and submitted at block 9,337,697 in 296,898 gas, taking the update count from zero to one; both tampered proofs and tampered public values revert. Around it sit the outbound primitives AereOutboundOutbox at 0xd43FeacbbdDc5ff7cE4A72C726f3FBD204ef7936 and AereOutboundVerifierV2 at 0x08b68bd553116Dffb99E648cb764AA93930da96F , which admits those messages on a zk proof. The original verifier at 0x8E893686b6B2509C5f7Fe477CE530Bc868B0074e was deliberately left inert and is now deprecated: its programVKey reads 0x0 on-chain, which is fail-closed, so every proof submitted to it reverts, and that value is immutable, so it can never be switched on. It was forgeable by design . Its guest took the validator set as a private, prover-supplied input and committed no validator-set root, so an attacker could list their own keys, self-seal a quorum and produce a valid proof for an arbitrary message. The rebuilt guest commits that root and pins the chain id to a constant, and V2 binds the committed root to an immutable anchor over AERE's real validator set, rejecting anything else, exactly as AereZkQbftLightClient does. Both directions are proven on mainnet: a genuine Outbox message was delivered, and a forged one, self-sealed by an attacker's own keys over a fabricated header, was rejected even though the live SP1 verifier confirms that proof is cryptographically valid. The flaw was found by code review, was never exploited and was never exploitable, since the contract was fail-closed throughout. The earlier header-relay AereEthLightClient at 0x9A9147236a47aE05eeEF692Bac985706f49E177b is superseded by the zk client above. The outbound direction now also has its own succinct primitive: AereZkQbftLightClientV2 at 0xc35A4D3828Af3fBD36c791EB1ca4B72C6Eb20384 , the canonical deployment since 2026-09-02 (anchored to the live nine-validator set; one proof processed at block 13,124,151; the earlier AereZkQbftLightClient at 0xCaDA54FAb6E7AE311d240Cf0C2Df45e974156488 is anchored to the July seven-validator set and cannot verify the live set), bound on-chain to the real SP1 program vkey and to AERE's seven-validator anchor as it stood at bootstrap (bootstrapped at block 9,312,565, the first block sealed by that set; the live validator set has been nine since 2026-08-09), so an external verifier could advance a trust-minimized view of AERE's OWN QBFT finality for blocks sealed by that seven-validator set by verifying a single Groth16 proof that a chain-2800 block carries a 2f+1 committed-seal quorum; since the set grew to nine on 2026-08-09 and to ten on 2026-09-11 this deployment cannot verify current blocks until it is redeployed against the current validator anchor. This is proven live end to end: a real Groth16 proof that chain-2800 block 9,989,005 carries a 5-of-7 committed-seal quorum under the validator set live at that height was verified on-chain in 313,462 gas , advancing the client's tracked finalized head to that block; the proof was generated on a dedicated non-infra prover. Tampered proofs, tampered public values, stale-anchor values and replays all revert. The earlier client at 0xc9A2DCaeD0Ceb2B400Dd705a75cbabEBf5aBB1c2 is deprecated and must not be used : it anchored the historical three-validator set, so it is frozen at block 9,241,622 and can never verify current finality; its own single advance was genuine at the time, so it is stale rather than fake. Honest boundary: this is an interop-layer contract that does not change AERE consensus, and it is trust-minimized not trustless, with classical ECDSA seals and a BN254 Groth16 wrap, so not quantum-safe; all ten validators are Foundation-operated, so the honest-majority premise is an operator assumption rather than an economic one. The validator-set anchor is immutable and does not track rotation, so a validator-set change requires a fresh deployment, which is exactly why the older client was replaced rather than updated. The honest boundary on the zk light client This is trust-minimised, not trustless. It inherits the security of at least two-thirds of Ethereum's 512-member sync committee, the same honest-majority assumption Ethereum light clients rely on, rather than a single relayer's word. It is also not quantum-safe, because the BLS12-381 sync-committee signatures and the Groth16 proof system over BN254 are classical. It advances real Ethereum finality on-chain today; it has not had an external audit, which is still pending. Threshold authorization: classical and post-quantum committees Live AERE ships on-chain t-of-n committee authorization in two registries. AereThresholdRegistry at 0x875BA0dbA1806Ad9aE57627d705ecA12139D1EF4 governs threshold-ECDSA committees, and AereThresholdPQCRegistry at 0x8Fbfe1C72E8c83ca2a0c475ce3648D47bCC8643c is post-quantum: it verifies that at least t distinct committee members each supplied a valid PQC signature, checked on-chain through the live AerePQC precompiles. Concretely, registerCommittee publishes a committee over one of those precompiles (0x0AE1 Falcon-512, 0x0AE2 Falcon-1024, 0x0AE3 ML-DSA-44, 0x0AE4 SLH-DSA-128s), and authorize clears only when at least t distinct members each supply a valid signature over a domain-separated, strictly-increasing-nonce challenge, so duplicate or out-of-range indices revert and replay is impossible. Because each leg is an independent single-signer verify, the cost is t verifications, and under AERE's 16,777,216-gas per-transaction cap any realistic custody quorum such as 3-of-5, 5-of-9, or 11-of-21 fits with wide margin. The contract holds no funds and has no admin; it is deployed and currently inert, with no committees registered yet, 18 of 18 local tests passing (including a check that duplicate committee keys are rejected at registration, so distinctness is enforced by key and not merely by index), and an external audit pending. The honest boundary is that the post-quantum registry is a threshold multisig of independent PQC signatures, not a single-aggregate threshold-PQC signature, and it authorizes at the application layer; consensus itself is hybrid post-quantum in the anchor-certificate sense, as described in chapter 3, and this registry is not what does that. Building directly on that registry, a non-custodial smart account, AereThresholdAccount , has been implemented and formally verified. It is an ERC-4337 account whose owner is a t-of-n post-quantum committee, so no single key can move its funds and there is no admin path, intended for custody where a bank or an agent should never be able to act alone. It routes every signature through the same audited precompile-verification code as the registry above, and an automated prover confirms its core invariants: below the threshold it never authorizes, a rejected or duplicated signature is never counted, its two authorization paths are domain-separated, and its replay barrier holds. It is built, unit-tested, property-fuzzed, and machine-checked, with matching TypeScript and Python client libraries, and its CREATE2 factory is now live on AERE mainnet at 0x69734E4044B1C5943B9256A73De41B101BFA2633 (chain 2800), deployed after the full self-audit above. It is the natural bridge from threshold verification to threshold custody. What this chapter claims, and what it does not The claim is precise. AERE has built, and in the encrypted-mempool case demonstrated end-to-end on chain 2800, two opt-in anti-MEV subsystems and two interop stacks, all at the application and account layer. The batch-settlement contracts are live and canonical and give real atomicity, per-order limit, and replay guarantees. The encrypted mempool proves a pairing-verified threshold path on-chain but remains a trusted-dealer, single-coordinator proof-of-concept outside the canonical registry. The interop endpoints are interface-faithful and deployed but await a live relayer network and the USDC.e bootstrap. None of it is base-consensus MEV resistance, and none of it is decentralized yet. The roadmap that closes these gaps, a distributed key generation to remove the dealer, keyper slashing, permissionless bonded solvers, on-chain uniform-price verification with surplus routed to AereSink, the mempool-to-settlement adapter, and a live interop relayer set, is laid out in the companion spec and the phase roadmap. This is the AERE thesis applied to ordering and interop: final as math where the math is already verified on-chain, and honest about every place the trust is still human. Final as math, safe when the math changes. 07 Provable Compliance Identity, Compliance, and Privacy A compliance stack built to be provable rather than promised, with a clear map of what is cryptographically trustless, what is optimistic, and what rests on a named issuer. Chain 2800 · companion deep-dive: spec-identity-compliance AERE treats compliance the way it treats settlement: as something that should be provable rather than promised. The chain's thesis, final as math and safe when the math changes, has a quieter corollary at the regulatory layer. A compliance claim is only worth as much as the proof behind it, and a proof is only honest if it states plainly what it does and does not establish. This chapter describes AERE's identity and compliance stack in that spirit. The companion deep dive, the identity and compliance specification ( spec-identity-compliance ), carries the contract-by-contract mechanics; here we summarize the design and, more importantly, we are candid about where the trust actually sits. Three facts frame everything below, and we state them before the design rather than after it. First, every piece of this stack lives at the application and account layer. None of it touches consensus. Validators sign ordinary QBFT messages over secp256k1. The identity and compliance contracts are plain EVM contracts that applications opt into, so nothing here changes the base protocol's security or its guarantees. Second, AERE today is a Foundation-operated network with a small validator set, one client implementation, and a single operator. The stack has not had an external security audit. Several of these contracts have little or no live usage, and the compliance privacy pool holds zero deposits at the time of writing. We treat those as facts to disclose, not as things to bury. Third, a single distinction runs through the entire stack and deserves to be named at the top: the difference between an inclusion proof and an absence proof. Most of the cryptography here proves that something is in a set. An address is on a sanctions list. A credential is in an issuer's tree. A note belongs to an attested clean set. Proving that something is not in a set is a fundamentally harder primitive, and wherever we lack it we say so rather than implying otherwise. Inclusion proof, not absence proof Most of the cryptography here proves that something is in a set: an address is on a sanctions list, a credential is in an issuer's tree, a note belongs to an attested clean set. Proving that something is not in a set is a fundamentally harder primitive, and wherever AERE lacks it, this chapter says so rather than implying otherwise. Presenting the sanctions registry alone as clean-gating would overstate it, and we do not. On-chain identity The base identity layer is AereIdentity at 0x658dD2CD1F798AAb19fEc8FF69A270B2d192CaD1 , a lightweight on-chain registry compatible in spirit with W3C DID and ERC-1056. It exposes three primitives. Any address can publish a pointer to a content-addressed profile document, so only the pointer and a timestamp live on-chain. The Foundation maintains an allowlist of trusted attestors, meaning KYC providers, employers, or communities that are permitted to issue credentials. An attestor then issues claims keyed by a claim-type tag such as an age-over-18 tag or a KYC-tier tag, with an optional hash of an off-chain evidence document, an expiry, and issuer-only revocation. A reader checks whether a subject holds a given claim, from a given attestor, that is unexpired and unrevoked. The honest scope of this contract matters. Claims are plaintext booleans on-chain. The registry reveals that a particular address holds a particular claim type from a particular attestor. That is a transparency-positive and privacy-negative design. It is appropriate for public credentials such as DAO membership or a verified-email flag, and it is the wrong tool for anything a user would reasonably want kept private, like residency or an exact KYC tier. Sensitive attributes belong on the zero-knowledge path described next, not here. For structured, schema-versioned regulator judgments, the newer successor is AereAttestationGateway at 0x9bdacA8dfF39Fc688e8D3c4bbA13bCFC0580c325 , which records append-only schemas and issuer-authorized attestations, supports validity windows and bounded inheritance so a revoked parent invalidates its children, and again stores only hashes rather than personal data. AereIdentity remains the simple key-value layer beneath it. AI-native identity: post-quantum keys and agent DIDs Live The identity layer is built for machine actors as well as people, because an autonomous agent that settles value needs an identity that outlives any single signing key and survives a cryptographic break. Two deployed contracts give it that. AerePQCKeyRegistry at 0x1eCa3c5ADcBD0b22636D8672b00faC6D89363691 is a post-quantum key registry: an account binds a PQC public key to itself and proves possession on-chain, so a counterparty can check that a given address genuinely controls the post-quantum key it claims. AereAgentDID at 0xce641d7d7C10553D82b06B7C21d423550e7522C5 builds an agent identity on top of that. The durable root of the identity is a Falcon post-quantum key, while the agent authorizes day-to-day actions with revocable secp256k1 session keys that it can rotate quickly. The split is deliberate: a slow, quantum-resistant root that rarely moves, and fast, disposable session keys for operational signing, so a leaked session key never puts the identity itself at risk. This is what makes the identity AI-native. An autonomous agent registers a Falcon-rooted DID, mints short-lived session keys for a task, and settles through AERE's machine-account rail, the AERE402 payment facilitator and the AereAgent registry, with each payment authorized by a session key that can be revoked the moment the task ends. The honest scope is the same as the rest of this chapter. These are deployed application-layer contracts with thin usage, not an audited or high-load system, and none of them changes consensus, which still signs classical secp256k1 QBFT. Zero-knowledge KYC attribute proofs When a user needs to prove a fact about themselves without revealing the underlying data, the anchor is AereZKScreen at 0x3A097A459FD26aC79573aCB5adB51430e473C2f1 , the version 3 deployment. This is a compliance-preserving anchor. It records that a user passed an off-chain screen without any of the source data touching the chain. The Foundation registers programs, where each program is one compliance statement identified by the verification key of a specific zero-knowledge circuit. A user runs the corresponding SP1 zkVM program off-chain, produces a Groth16 proof, and submits it. The proof is checked on-chain through the shared SP1 verifier gateway at 0x9ca479C8c52C0EbB4599319a36a5a017BCC70628 , and on success the contract stamps a clearance timestamp that applications can gate against with a freshness window. The flagship program is an over-18 proof, and it is worth describing precisely because precision is where honesty lives. A Foundation-approved KYC issuer publishes a Merkle root of birth-year credentials for the people it has verified. The circuit proves, in zero knowledge, that the prover holds a credential in that issuer's tree and that the birth year implies adulthood, without revealing the birth year. The adulthood threshold is a compile-time constant baked into the verification key, which makes the program a dated attribute that must be recompiled to advance the year. That is a deliberate tradeoff, chosen so a stale program cannot silently drift rather than to hide a limitation. The circuit and its proof pipeline are real and have been run end-to-end. An earlier edition of this chapter said the on-chain registration of that program was still pending a Foundation signature and that submitting a proof would revert as an unknown program. That is out of date and the correction runs in our favour, so it is stated as plainly as the caveat was: measured on 2026-08-01 on the live AereZKScreen 0x3A097A459FD26aC79573aCB5adB51430e473C2f1 , the over-18 program reads back registered, with its verification key matching the queried key and a non-zero authorized root set, so the program is registered and bound rather than unknown. What remains honest to say is that on-chain usage is thin: this is a live capability with almost no traffic, not a widely used one. Two further points keep this honest. The contract is program-agnostic, so an EU-jurisdiction or MiCA-eligibility proof, an accredited-investor proof, and an OFAC-screen proof all follow the identical pattern. Only the over-18 circuit exists in the repository today, though. The others are archetypes on the same rail and should be read as roadmap, not as live capabilities. And the version 3 anchor exists because the first two deployments got a soundness detail wrong: an earlier version let a prover supply the very Merkle root the screen was checked against, so anyone could prove membership in a set of their own construction. Version 3 closes that by binding each program to a Foundation-set authorized root and rejecting any proof that does not match it. We surface that history rather than quietly retiring the dead versions, because a compliance layer that hides its own bug fixes has not earned trust. The specification also instructs every consumer to treat a clearance as necessary but not sufficient, combining it with a live sanctions check for sanctions-sensitive flows. Fig 7.1 The over-18 attribute proof: prove adulthood without revealing the birth year KYC issuer · off-chain publishes a Merkle root of birth-year credentials root Foundation-approved issuer User · SP1 zkVM · off-chain proves in zero knowledge: • holds a credential in the tree • birth year implies adulthood birth year and identity stay hidden → Groth16 proof On-chain AereZKScreen v3 verify via SP1 gateway bind Foundation authorized root clearance stamped reveals only: adult = true hidden: birth year, identity Registered and bound on the canonical anchor, measured 2026-08-01 (an earlier edition said it was pending). Until it lands, a live submission reverts as an unknown program. The pattern is program-agnostic, but only the over-18 circuit exists today, and its adulthood threshold is a compile-time constant. What it shows. The flagship zero-knowledge attribute proof. A Foundation-approved issuer publishes a Merkle root of birth-year credentials; the user proves off-chain that they hold a credential in that tree and that their birth year implies adulthood, revealing neither the birth year nor their identity; the on-chain anchor verifies the proof against a Foundation-set authorized root and stamps a clearance. The pattern is program-agnostic, but only the over-18 circuit exists today and its on-chain registration is pending one Foundation signature. The OFAC sanctions registry AereSanctionsRegistry at 0xb7d235718D99560F6EA4Fc5eAea2F8a306A3Cacf is a read-only, public-good sanctions registry. There is no fee, no discretionary interception, and no custody. The design is a daily cycle: an off-chain ingester reads the official OFAC Specially Designated Nationals list, extracts crypto addresses where present, builds a Merkle tree, and the Foundation publishes the root. The live state is smaller than the design and is published here rather than left implicit. Measured on 2026-08-01, the contract holds exactly one snapshot, epoch 20641, proposed on 2026-07-07 and still in the proposed state with no attestation recorded and the neighbouring epochs empty. No daily cycle is running today. Because the epoch was never attested, a consumer must not read a negative answer from this registry as evidence that an address is not sanctioned; until an epoch is attested, treat the registry as not yet carrying a usable list. The lifecycle per epoch is optimistic and mirrors the network's oracle pattern. A snapshot is proposed with a link to the canonical OFAC source and an optional pinned copy of the full list, anyone may challenge it within a 24-hour window, the Foundation may dismiss a baseless challenge, and after the window elapses without an open challenge anyone may attest the epoch, which freezes the root. History is append-only. There is deliberately no path to remove an address, because removing one would imply the Foundation is making a sanctions decision, when in fact it only mirrors the canonical list. Additional list sources such as EU, UK, and UN consolidated lists have reserved identifiers, but Phase 1 ships OFAC SDN only. Here the inclusion-versus-absence distinction becomes the whole story. The registry answers whether an address is on the list, and it answers that with a real Merkle inclusion proof. It cannot prove that an address is clean. A standard Merkle root supports membership proofs only, and proving non-membership would require a sorted or sparse tree, which this is not. So "this address is sanctioned" can be shown trustlessly given the proof, while "this address is clean" reduces to the far weaker statement that no valid inclusion proof was supplied, which depends on the caller actually performing the lookup instead of skipping it. For flows that genuinely need a positive clean assertion, the correct composition is with a positive-allowlist primitive, either the compliance pool's clean-set proof or a future OFAC-screen zero-knowledge program. Presenting the sanctions registry alone as clean-gating would overstate it, and we do not. One adjacent contract deserves an honesty note. ChainalysisOracleWrapper at 0x1B7Be82C80f368f75Cb3807B1bc05E86A498f85c gives applications a stable interface that forwards to a Chainalysis-style upstream oracle. No such oracle is natively deployed on AERE, so until the Foundation configures an upstream the wrapper returns false for every address and must not be relied on as a sanctions source. It is scaffolding for a future integration, and we label it as such. The real on-chain sanctions signal today is the Merkle registry above. A related signaling surface, AereForensicEventRegistry at 0x4a7526A068e5DDE9788f6571E4A99095b14C6fff , lets detection bots post structured alerts about suspicious activity. It has no custody and no ability to intercept transactions, and in Phase 1 the reads that consumers gate on count only Foundation-confirmed alerts, so the trust anchor there is again the Foundation. Travel-rule primitives The FATF Travel Rule requires regulated institutions to exchange identity payloads for transfers above a jurisdictional threshold. Those payloads are confidential and are exchanged off-chain over a message bus. AERE's role is narrow and deliberately so. AereTravelRuleHashRegistry at 0xcF0E2e010E6e4506672019b1e570874AEeBC4c84 anchors only a commitment. The originating institution commits a hash of the standardized identity payload along with the counterparty address and the threshold, and the beneficiary later acknowledges receipt or disputes a mismatch. No payload data and no identity is ever stored on-chain. The anchor proves that a specific payload existed at a specific block, that the log is append-only, and that a regulator can audit the exchange without the chain ever revealing its contents. This contract has no admin, no interception, and no custody, which makes it genuinely trust-minimized in the narrow sense that it is just an append-only commitment log. The counterparties self-identify by their sending address, and the registry does not itself vouch that a committing address is a licensed institution. That verification is off-chain and can be layered through the attestation gateway. It is a minimal viable Travel Rule anchor, honestly scoped as Phase 1. The compliant privacy pool The stack's most ambitious primitive is AereCompliancePoolV2 at 0xB144c923572E5Ac1B6B961C4ccfec36917173465 , a compliant privacy pool denominated in WAERE ( 0x7e84d7d66d5da4cfE46Da67CDEeB05B323e1f5e8 ) with proofs verified through its dedicated adapter at 0xE2D3fa91b680E835c971761ba75Fde0204AEF95E . It is a Privacy-Pools construction in the Soleimani and Buterin lineage, hybridized with a Travel Rule hook. At its core is an append-only Merkle tree of deposit commitments with a rolling recent-root history, so a withdrawal can prove against any recent deposit root. A deposit binds the note to its depositor and records an off-chain Travel Rule commitment, tying the pool back to the anchor described above. A withdrawal submits a zero-knowledge proof that the note exists, that its nullifier is unspent, and that the recipient and fee parameters are bound so a front-runner cannot substitute them. What makes it compliant, and what makes it honest, is the same mechanism. To withdraw, a user proves that their note is a member of an association root, a Foundation-published Merkle root over the subset of deposits judged clean. This is the correct way to build compliant privacy: the user demonstrates that they are in the good set, rather than making the impossible-to-verify claim that they are not in some bad set. The tradeoff is explicit and we state it. The clean set is Foundation-curated, so a user whose legitimate deposit is not yet included cannot withdraw with privacy until it is. That is a real centralization point. To bound it, association roots go through an optimistic, bonded lifecycle: the Foundation proposes a root, anyone may challenge it with a bond, and the resolution fails safe. One comparison in the earlier edition of this text was wrong and is withdrawn: the sanctions registry runs the same optimistic shape but takes no bond at all, since its challenge entry point is non-payable and holds no balance, so only the compliance pool lifecycle is bonded. If the Foundation dismisses a baseless challenge within the window the bond is burned to preserve the anti-grief property, and if the Foundation fails to act, anyone can finalize the challenge as upheld, which refunds the honest challenger and permanently rejects the questioned root. That upheld-reclaim path exists because the first pool version could trap an honest challenger's bond forever, a bug we fixed rather than concealed. Two properties are worth stating plainly. The pool has no admin withdrawal. There is no function by which the Foundation or anyone else can pull user funds, and the compliance surface is limited to curating the clean set and, through the optimistic lifecycle, to a liveness assumption that the Foundation dismisses baseless challenges in time. And the pool is fresh. It holds zero deposits today. We present it as a working, tested primitive with no real usage yet, because that is exactly what it is. Fig 7.2 The compliant privacy pool: prove membership in a clean set, not the absence of guilt Deposit a note commitment is appended to an append-only Merkle tree + Travel Rule commitment Clean-set (association) root the Foundation publishes a root over the subset judged clean optimistic, bonded lifecycle propose → challenge → finalize fails safe on an upheld challenge Withdraw a zk proof shows: • note in a recent deposit root • member of the clean-set root • nullifier unspent • recipient and fee bound → private withdrawal The clean set is Foundation-curated: a real centralization point, bounded by a bonded challenge window. There is no admin withdrawal path. Membership is a positive clean-set proof, not an absence proof. Denominated in WAERE; the pool is tested but holds zero deposits today. What it shows. The compliant privacy pool. Deposits enter an append-only commitment tree; a withdrawal proves membership in a Foundation-published clean-set (association) root rather than the impossible claim of not being in some bad set. The clean set is curated, which is a named centralization point bounded by a bonded challenge window; there is no admin withdrawal, and the pool holds zero deposits today. What is trustless, what is optimistic, and what is attested The single most useful thing a reader can take from this chapter is a clear map of where trust lives, so we gather it in one place. Fig 7.3 Where the trust sits: three tiers from cryptographically trustless to a named issuer's word trust decreases Trustless cryptographic, given a proof Travel Rule anchor proves a payload hash existed at a specific block, append-only AereTravelRuleHashRegistry Sanctions inclusion given a proof, an address is on the list (membership only, cannot prove clean) AereSanctionsRegistry Optimistic Foundation root + challenge window Sanctions root proposed, challengeable, frozen on attest Clean-set membership compliance pool association root, bonded lifecycle Authorized roots zk-screen per-program roots bound in v3 each carries a Foundation liveness assumption Attested rests on a named issuer Attestation gateway records what a body asserted, hashes only Forensic registry counts Foundation-confirmed alerts, no interception AereIdentity claim the word of its attestor, no privacy Foundation-dependent surfaces, collected: the sanctions root, the clean-set root, the per-program authorized roots, the attestation schemas and authorized attestors, the pool's compliance-provider allowlist, and the forensic alert confirmations. Optimistic windows reduce this trust, they do not eliminate it. What it shows. The stack sorted by where trust sits. Only two statements are cryptographically trustless. The optimistic tier rests on a Foundation-published root plus a challenge window and a liveness assumption. The attested tier is exactly the word of a named issuer. Naming this honestly is treated as an asset: as the validator set widens and an audit lands, these are the surfaces that will decentralize. Cryptographically trustless statements are few and precise: the Travel Rule anchor proves a payload hash existed at a block, and the sanctions registry proves, given a proof, that an address is on the list. Optimistic statements rest on a Foundation-published root plus a challenge window: the sanctions root itself, the compliance pool's clean-set membership, and the zero-knowledge screen's per-program authorized roots all fall here, and each carries a Foundation liveness assumption. Plain attestations rest on a named issuer: the attestation gateway records what a body asserted, the forensic registry counts what the Foundation confirmed, and an AereIdentity claim is exactly the word of its attestor with no privacy. The pieces that ultimately depend on the Foundation, collected so none is buried, are the sanctions root, the clean-set association root, the per-program authorized roots, the attestation schemas and their authorized attestors, the pool's compliance-provider allowlist, and the forensic alert confirmations. The optimistic challenge windows reduce this trust but do not eliminate it, and they assume the Foundation stays live. We consider naming this an asset rather than a weakness. A compliance stack that pretends to be trustless when it is optimistic is worse than one that is honest about where the trust sits, and as the validator set widens and an external audit lands, these are precisely the surfaces that will decentralize. Final as math where the math is real, and honest about the human roots where it is not yet. For the full contract mechanics, audit history, and the trust table in tabular form, see the companion identity and compliance specification. 08 The Economy Token Economics and the Flywheel A supply that is fixed and unmintable, an immutable three-bucket revenue router that no admin can change, real yield instead of issuance, and a candid account of what is still reserve-funded. Companion: research/specs/spec-flywheel-economics.md · addresses from sdk-js/src/addresses.ts Companion deep-dive: research/specs/spec-flywheel-economics.md . Source of truth for addresses: sdk-js/src/addresses.ts . This chapter summarizes the design and surfaces the honest caveats; the spec holds the parameter-by-parameter detail. AERE's economic design rests on a single, unfashionable commitment: the money supply is fixed and no contract in the system can mint. Everything else, the burn, the flywheel, the staking yields, is built on top of that constraint rather than around it. This is the economic expression of the network thesis, final as math, safe when the math changes. A fixed cap is a promise that can be verified in one on-chain read, and it is a promise that never needs to be renegotiated. A fixed supply, verifiable and capped Total supply is 2,800,000,000 AERE, capped at genesis-v2 on 2026-05-07 and allocated at genesis across six wallets: 100M to the Strategic Investor (sold off-chain), 180M to the Foundation as chain admin and contract owner, 1.4B to the Reserve (scheduled), 560M to the Ecosystem Reserve, 420M to the Team Reserve, and 140M to the Airdrop Reserve. Those are the genesis allocations, and a reader who checks the balances today will not find that split intact, so the measured position is published here rather than left to be discovered. Measured at the head on 2026-08-01, the six genesis addresses hold 2,239,999,990.70 AERE between them: Strategic Investor 100,000,000, Foundation 179,999,989.999, Reserve 1,400,000,000, Ecosystem Reserve 0.699996, Team Reserve 420,000,000, Airdrop Reserve 140,000,000. The Ecosystem allocation no longer sits at its genesis address; 559,999,999 AERE of it are held at a single separate account on chain. The remaining 10.30 AERE of the difference reconciles as the fee spend of these six wallets since genesis, which is a reconciliation of the two columns rather than a traced sum of transactions, so it is marked NOT MEASURED as an independent figure. That account is not published here, and establishing and documenting its custody is an open item listed in the risks and limitations section of Chapter 9. Nothing was minted and nothing was destroyed by that move: the cap is unchanged and none of the mechanisms described below mint tokens. Native AERE is the gas and value token; WAERE ( 0x7e84d7d66d5da4cfE46Da67CDEeB05B323e1f5e8 ) is its 1:1 ERC-20 wrapper on the WETH9 pattern, and every ERC-20-facing mechanism in the economy (the sink, the staking receipt) operates on WAERE. The economic thesis is monotone: the burn path only ever removes AERE against this fixed cap, and no path re-mints. Every Ownable contract in the economy chapter that answers owner() returns the Foundation-controlled account ( 0x0243A4f47D44b40b65D33f20329dE20D00c6f3C3 , a single-key EOA, not a threshold multisig; a Safe multisig is roadmap), which was re-measured on 2026-08-01 and holds; across the whole canonical registry the picture is mixed, and the count is published in the governance chapter. The load-bearing flywheel contracts, by contrast, have no owner at all. Fig 8.1 Fixed supply: 2,800,000,000 AERE across six genesis wallets, capped at genesis-v2, never inflated 2,800,000,000 AERE · fixed, no inflation 100% capped at genesis-v2 Reserve (scheduled) 1.4B · 50% Ecosystem 560M · 20% Team 420M · 15% Reserve (scheduled) 1,400,000,000 · 50% Ecosystem Reserve 560,000,000 · 20% Team Reserve 420,000,000 · 15% Airdrop Reserve 140,000,000 · 5% Foundation 180,000,000 · 6.43% Strategic Investor 100,000,000 · 3.57% · sold off-chain What it shows. The whole 2.8B supply, set at genesis-v2 (2026-05-07) and never increased. No mechanism in the system mints tokens; the burn path only ever removes AERE against this cap. The Foundation holds 180M as chain admin and contract owner, but the load-bearing flywheel contracts have no owner at all. The burn: 37.5% of the validator reward AERE's QBFT chain does not run EIP-1559 protocol-level base-fee burning. Being precise about this matters for credibility. The widely quoted "37.5% burn" is not a consensus rule; it is applied to validator coinbase rewards by a splitter contract that validators (or their forwarder daemons) call each block, operationalizing the whitepaper's fee-burn intent at the coinbase layer rather than inside consensus. The original AereCoinbaseSplitter ( 0xb4b0eCe9011613A5b84248a9B42a0f309E6F01Ec ) performs a two-way split: it forwards burnBps / 10000 of the coinbase to the burn vault and rebates the remainder to the validator, atomically, with cumulative counters that let any explorer verify the burned total in a single read. Its successor AereCoinbaseSplitterV2 ( 0x8C1A48eFA57b66fEE743A00E3899c29ad3Fd27b4 ) adds a third slice: 37.5% burn, 15% routed to the flywheel sink, and the derived 47.5% rebated to the validator, so a fraction of every block reward begins compounding for stakers instead of returning entirely to the block producer. A word on the word "sealed," because honesty here is worth more than a stronger-sounding claim. The 37.5% burn rate is not immutable. It is an owner-adjustable parameter, bounded inside [0, 5000] basis points (a hard 50% cap that gives headroom while bounding abuse). What is truly sealed in AERE's economy is not the burn rate but the router it feeds, AereSink , which has no owner and no setters at all. The burn rate is a Foundation-tunable dial with a fixed ceiling; the flywheel split beneath it is set in stone. The burn endpoint itself is AereFeeBurnVault ( 0x696afDF4f814e6Fd6aa45CE14C498ed9375fB2c6 ), a stateless contract with no owner, no admin, no withdraw function, and no escape hatch. AERE that arrives there is permanently removed from circulation because nothing can move it out. There are two honest ways to describe that state: value on a no-withdraw contract is out of circulation the instant it arrives, and value becomes literally unrecoverable at the zero address once anyone calls the permissionless sweepToZero() . Both counters are exposed on-chain, so the reader can pick the definition they mean and verify either. The immutable flywheel: AereSink AereSink ( 0x69581B86A48161b067Ff4E01544780625B231676 ) is the credibility anchor of the whole economy. It is the single entry point for any protocol fee stream that should accrue to AERE holders, and it has no owner, no admin, no setters, no pause, and no upgrade proxy. It splits every inflow across three buckets whose recipients and basis points are fixed as immutable at deploy; the constructor reverts unless the three shares sum to exactly 10000. The deployed configuration is 15 / 40 / 45: Fig 8.2 The AereSink flywheel: one immutable, ownerless router splits every fee inflow 15 / 40 / 45 Protocol fee inflow coinbase splitter, RaaS fees, future streams AereSink no owner · no setters · no pause · immutable constructor reverts unless shares sum to 10000 15% 40% 45% Burn AereFeeBurnVault no withdraw, out of circulation on top of the splitter's 37.5% Buyback and burn swap to AERE, burn via AereSwapRouter, oracle floor merges with burn when inflow is AERE Staker yield into the sAERE vault raw transfer lifts total assets, exchange rate appreciates the flywheel: real fees compound into burn and staker yield, with no admin action and no new issuance What it shows. Every inflow is split on a fixed 15 / 40 / 45 basis that is set as immutable at deploy. There is no setBucket , no setRecipient , no setRouter . BURN and BUYBACK both destroy AERE; STAKER-YIELD lifts the sAERE exchange rate. The absence of an admin key is what makes the 15 / 40 / 45 promise worth believing. BURN (15%) goes to AereFeeBurnVault , on top of the splitter's 37.5%. BUYBACK-and-burn (40%) is designed to swap non-AERE inflows to AERE through a DEX router and burn the proceeds. Measured on the live sink on 2026-08-01, this bucket is not wired: DEX_ROUTER() reads 0x0000000000000000000000000000000000000001 and ORACLE() reads the zero address, both immutable, so the deployed sink is not connected to AereSwapRouter 0x7526B2E5526EfA84018378b60F2844Dad77523D8 or to any price oracle, and the buyback path cannot run for a non-AERE token on this instance. The 15/40/45 split itself is real and reads back from the contract as 1500, 4000 and 4500 basis points. When the inflow is already AERE or WAERE, which is the normal case since the splitter wraps before flushing, BURN and BUYBACK merge into one transfer to the burn vault, because buying AERE with AERE is a no-op. STAKER-YIELD (45%) is transferred into the sAERE vault. A raw transfer into an ERC-4626 vault lifts total assets without minting shares, so the exchange rate appreciates for every existing holder. This is the wire that connects protocol fees to stakers. The sink is engineered to be un-gameable at the edges as well as the center. Its swap design computes the minimum-output floor from an external oracle price rather than from pool reserves, because pool reserves can be manipulated by the same actor in the same transaction, and the interface is compatible with AereLendingOracle at 0xc0f18A567067F1B84BDf75eDEbFaDdCBb70A4C49 . That protection is a property of the design and not of the live instance: as measured above, the deployed sink holds the zero address as its oracle and address one as its router, both immutable, so no swap path is active on it and the floor described here is not doing any work today. Rewiring means a fresh sink deployment, and it is a roadmap item rather than an owner call. A failed swap does not revert the whole flush; the tokens rest as dust and anyone can re-flush them later through the permissionless sweepDust . And crediting the staker bucket triggers a best-effort sync() on the vault so the arrival begins dripping immediately rather than jumping the price for a sandwicher to race. The load-bearing claim: an ownerless split Immutability is the entire point. There is no setBucket , no setRecipient , no setRouter . If the router ever needs replacing, the sink is redeployed and fee sources are rewired in the open; the split itself can never be changed under holders. That absence of an admin key is what makes the 15 / 40 / 45 promise worth believing. Immutability is the entire point. There is no setBucket , no setRecipient , no setRouter . If the router ever needs replacing, the sink is redeployed and fee sources are rewired in the open; the split itself can never be changed under holders. That absence of an admin key is what makes the 15 / 40 / 45 promise worth believing. See the companion spec for the sandwich-resistance and dust-recovery detail. sAERE: real yield, not issuance sAERE ( 0xA2125bE9C6fd4196D9F94757Df18B3a2A5e650b0 ) is the liquid-staking receipt, an OpenZeppelin ERC-4626 vault over WAERE with no owner, no admin, no pause, and no parameter setters. Depositors lock WAERE and receive sAERE; the WAERE-per-sAERE rate drifts up as the sink's STAKER-YIELD bucket routes fees in. This is real yield in the strict sense. It comes from protocol fee inflows, not from token issuance, and no one chooses whether, when, or how much; once funds arrive they vest mechanically. There is no fixed APR on sAERE. The rate is whatever the fee flow produces. Two safety properties matter economically. Yield is not recognized as a step function the instant the sink transfers AERE in; arrivals vest linearly over a seven-day drip, so share price grows continuously rather than in block-sized jumps. That linear drip is precisely what defeats the flash-loan sandwich of deposit, flush the sink, and redeem in one block, since the price cannot jump within a block. And the classic ERC-4626 first-depositor inflation attack is neutralized by a virtual-share decimals offset, backed by a dead-shares seed at deploy. The honest caveat is that sAERE only appreciates if fees actually flow; with thin current usage, realized yield to date is minimal and should be read live from the exchange rate, not assumed. The mechanism is real and admin-free; the volume is early. Staking products: an honest subsidy with a runway AERE offers three staking surfaces, and they are frequently and wrongly conflated. Only sAERE is admin-free real yield. The other two pay a stated rate, and that rate is a reserve-funded subsidy, not perpetual issuance. Delegated validator staking , AereStakingV2 ( 0x1D95eF6D17aeAB732dF914Ba2d018c270BC155FC ), lets holders delegate native AERE to validators and earn an APR while validators post a self-stake bond and take a commission. The default reward rate is 8% (800 bps), owner-settable within [1, 10000] bps; accrual is timestamp-based and so immune to block-time changes, with a 7-day unbonding queue and a 5% slash rate on validator self-stake. One limit of the deployed code is stated here rather than left for a reader to find: the self-stake is only reachable by the slash path while the validator is registered as active, because deregistration moves the whole self-stake into the unbonding queue and the slash path does not reach that queue. The penalty is therefore weaker than the phrase slashable bond suggests, and making it unconditional needs a redeploy, which is a roadmap item. In context, measured 2026-08-01, the contract reports zero total staked and holds a zero balance, so nothing is delegated or bonded on it today. This is a bug-fix redeploy of a deprecated V1; use only V2. Fixed-term locked staking , AereLockedStaking ( 0x21108c28A849b05aE6b7a3a5bc435C9Bc897E7Ad ), pays a fixed APY in AERE at maturity across four tiers: 30 days at 10%, 90 days at 15%, 180 days at 22%, and 365 days at 30%. Principal is protected by construction; a withdrawal reverts unless the contract balance covers all locked principal plus the maturity, so one staker's payout can never drain another's principal. Early exit forfeits reward and returns principal only. Locked 30 days 10% APY Locked 90 days 15% APY Locked 180 days 22% APY Locked 365 days 30% APY Staking APRs are a reserve-funded subsidy, not issuance Because supply is capped at 2.8B and there is no consensus-level reward minting, both staking pools are paid from Foundation-seeded balances drawn out of the genesis reserves. So the 8% APR and the 10-to-30% locked APYs are subsidies with a runway, not native issuance and not perpetual rates. They are safe (principal is protected and the contracts cannot pay what they do not hold) but they are finite. The intended end-state is that the fee flywheel, not the reserve, becomes the funding source. The honesty that must accompany those numbers is the crux of a fixed-supply chain. Because supply is capped at 2.8B and there is no consensus-level reward minting, both staking pools are paid from Foundation-seeded balances drawn out of the genesis reserves. AereStakingV2 reverts a claim with "pool insufficient (needs foundation top-up)" if its balance cannot cover the reward, and AereLockedStaking simply cannot pay a maturity the reserve does not cover until it is topped up. So the 8% APR and the 10-to-30% locked APYs are subsidies with a runway, not native issuance and not perpetual rates. They are safe (principal is protected and the contracts cannot pay what they do not hold) but they are finite. The intended end-state is that the fee flywheel, not the reserve, becomes the funding source, at which point yield and burn grow together as real usage grows, without any parameter change and without any admin action, because the sink has no admin. A fourth surface, AereGovernanceStaked ( 0x8D77C888e439C4fADb2e23F1567a0A1965F80bCb ), is not a yield product; it reads staking state to give delegated stake voting power, with a 7-day unbonding period that makes vote-borrowing impractical. No adaptive issuance, by design This is the deliberate line in AERE's economics, and it is worth stating without hedging: there is no adaptive, algorithmic, or discretionary issuance, and there never will be under this design. Supply is fixed at 2.8B. The chain does not inflate to pay stakers, does not mint to hit a staking-ratio target, and does not run a monetary-policy dial that a committee can turn. Adaptive issuance is explicitly off-strategy and out of scope. That choice has a real cost, which the design accepts openly: it makes staking APR a bounded subsidy rather than a self-refilling faucet, and it puts the burden of long-run sustainability on genuine fee revenue routed through the sink. AERE takes that trade on purpose. A holder can verify the cap once and never worry that it moves; an inflating chain asks its holders to trust a policy that can change. Fixed supply is the money-side meaning of the thesis, safe when the math changes, because the one number that governs dilution simply does not change. What the flywheel does per block, worked Putting the pieces together, take a validator coinbase reward R under the V2 defaults and the sink's 15 / 40 / 45 split. The splitter burns 0.375 R directly, routes 0.15 R into the sink, and rebates 0.475 R to the validator. Inside the sink, BURN (15%) and BUYBACK (40%) are both AERE-destroying, so 0.55 of the 0.15 R slice, which is 0.0825 R, is burned, while STAKER-YIELD (45%) sends 0.0675 R to sAERE holders. Aggregating, 0.4575 R is burned, 0.0675 R accrues to stakers, and 0.475 R is rebated to the validator. The V2 source comment cites roughly 52.5% as "protocol-directed" (the full non-rebated share); the stricter and more honest figure for actual token destruction is 45.75%, since 6.75% becomes staker yield rather than being burned. Both are stated so a reader can choose the definition they mean. The same AereSink is the intended router for other fee streams beyond the coinbase, so broadening the set of contracts that flush into it is the primary lever that makes sAERE yield and the burn self-sustaining, and it requires no change to the immutable sink. What R actually is today: zero Every formula above is stated in terms of the validator coinbase reward R. The honest and load-bearing fact is that R is currently zero on mainnet 2800 , so 0.4575 R is also zero, and the burn destroys effectively nothing. A reader who takes only one number from this chapter should take that one. There are two independent causes, and either alone would be sufficient. First, the genesis QBFT configuration declares no blockreward key, and Besu therefore issues no block subsidy to the proposer. Second, londonBlock is 0, so EIP-1559 is active from genesis and the 1 Gwei base fee is destroyed by the protocol rather than credited to the coinbase account. What reaches a proposer is only the priority tip, and at present transaction volume that rounds to nothing. Because the two causes are independent, fixing one would not by itself start the flywheel. This is measurable by anyone in two RPC calls against the public endpoint, with no privileged access. Sampling the validator accounts (nine at that time) at the chain head, then re-sampling after the head advanced 17 blocks, returns byte-identical balances for all nine. Lifetime burned, read as the balance of AereFeeBurnVault 0x696afDF4f814e6Fd6aa45CE14C498ed9375fB2c6 , is 137,352,594,046,167,719 wei, which is 0.13735259 AERE against a fixed supply of 2,800,000,000 AERE, or roughly one part in twenty billion. We state this plainly because the alternative is worse. A burn mechanism that is live, immutable, ownerless and internally reviewed (not externally audited), but currently burning nil, is a true and defensible thing to have built. A project that publishes its own zero is more credible than one that lets a percentage imply a quantity. The mechanism is correct and it is already deployed; what is missing is fee volume, and fee volume is a demand problem, not a contract problem. The number rises when real usage arrives, and until it does this document will keep quoting it as it is. Any figure in this section can be re-derived at any time. Today the re-derivation runs through Foundation-operated endpoints; run your own node against the public genesis if you do not want to trust ours. Burned per reward R 0.4575 R To stakers 0.0675 R Rebated to validator 0.475 R Token destruction 45.75% the honest figure Honest limitations The mechanisms above are admin-minimized, reentrancy-guarded, and verifiable from source, but the economy is early and the reader deserves the caveats plainly: Realized volume is thin. The chain runs with ten validators under one operator, and two clients (Besu and, since 2026-09-11, Nethermind). Burn and yield to date depend on validators actually running the coinbase-forwarder daemon and on real fee flow. This chapter quotes parameters and formulas, not lifetime-burned or TVL or yield figures; those are to be read live from the contracts' on-chain counters. The V2 three-way split is an operational state, not a code invariant. The sink slice only routes once the Foundation has wired AereCoinbaseSplitterV2 to AereSink through the contract's seven-day sink-rotation timelock. Until then V2 behaves like the two-way V1. Confirm on-chain before quoting the 45.75% figure as live. Staking APRs are reserve-funded. No consensus-level minting exists; the delegated and locked pools pay from Foundation-seeded balances out of the fixed 2.8B. This is on-strategy (no adaptive issuance) but it means the APR is bounded by the reserve until fee flow replaces it. No external audit. Every fix in the economy so far comes from internal audit rounds. The contracts are admin-minimized and guarded, but they have not had a third-party audit. The design goal is not to hide any of this. It is to make the parts that must be trusted as small as possible, an immutable sink and a no-withdraw burn vault, and to make everything else verifiable in a single on-chain read. Fixed supply, a sealed flywheel split, real yield instead of issuance: final as math, safe when the math changes. 09 Governance and Path Governance, Roadmap, and Limitations How AERE is governed today and where that is not yet binding, the ordered and gated path from a single-operator network to a credibly neutral one, and a consolidated account of what is still weak. Chain 2800 · companion deep-dives: docs/ROADMAP-PHASES.md , spec-flywheel-economics.md , research/pqc-onchain-verification.md This chapter states three things plainly: how AERE is governed today and where that governance is not yet binding, the ordered path from what runs on mainnet now to a credibly neutral settlement layer, and a consolidated honest account of what is still weak. For a young chain, candour is a credibility asset, so nothing here is softened. The companion deep-dives are docs/ROADMAP-PHASES.md (the phase-by-phase gate list), research/specs/spec-flywheel-economics.md (the economic mechanisms cited below), and research/pqc-onchain-verification.md (the post-quantum verifier suite). Every address in this chapter is copied verbatim from the canonical registry sdk-js/src/addresses.ts . Contracts that are planned but not yet deployed are named by artifact only and are never given a fake address; the Governor and the Timelock, once in that category, are now deployed and addressed in the governance section, but own nothing yet. 9.1 Governance today, and the binding gap AERE has an on-chain governance surface and a candid gap between it and real control. Both matter, so both are stated. The parameters that exist The stake-weighted governance contract AereGovernanceStaked 0x8D77C888e439C4fADb2e23F1567a0A1965F80bCb reads voting power directly from the staking system: a holder's weight equals the total native AERE it has delegated across validators in AereStakingV2 0x1D95eF6D17aeAB732dF914Ba2d018c270BC155FC , a stake-to-vote model. Its live parameters, verifiable in source, are a proposal threshold of 100,000 AERE, a quorum of 20 percent of total staked AERE, a voting period of 7 days, and an execution delay of 2 days. The 7-day unbonding period on the staking contract is what makes vote-borrowing impractical: stake cannot be flash-loaned in to swing a vote and withdrawn the same block. These figures are documented in the flywheel-economics spec and are read straight from the deployed bytecode, not projected. Proposal threshold 100,000 AERE Quorum 20% of staked Voting period 7 days Execution delay 2 days Why that surface is advisory, not binding Here is the honest part. Those parameters describe a vote, but a passed vote does not today move the protocol by itself. The legacy AereGovernance contract executes proposals only against itself and is owned by the Foundation. AereGovernanceStaked tallies stake weight but does not own any protocol contract, so it cannot, on its own, change a parameter or perform an upgrade. Almost every Ownable protocol contract on chain 2800 is controlled by the Foundation-controlled account 0x0243A4f47D44b40b65D33f20329dE20D00c6f3C3 (a single-key EOA, not a threshold multisig; a Safe multisig is roadmap). The word every was too strong and is corrected here with the measurement behind it, dated 2026-08-11: of the canonical registry contracts, 79 answer owner() ; 61 return the Foundation account and 18 return other single-key operational accounts. Those 18 include contracts this document treats as load bearing, among them the proof router, the proof registry and the cryptographic-agility registry. They are scheduled to move to governance together with the rest, and the transfer is tracked in the roadmap below. In practice this means governance is advisory: the community can signal, but a Foundation signature, or in those 18 cases an operational one, is what actually executes. Describing this as decentralized governance would be false, so we do not. Governance is advisory until ownership moves to a Timelock Almost every Ownable protocol contract on chain 2800 is controlled by the Foundation-controlled account, and the measured exceptions are named in the section above: 73 of the 80 registry contracts that answer owner() return the Foundation account, and 7 sit under other single-key accounts pending transfer to governance (measured at the block named in the version section). The stake-weighted vote can signal, but an owner signature is what actually executes. Describing this as decentralized governance would be false, so we do not. The counterweight is real: the money flywheel and the verifiers already have no admin key at all. Where control is already relinquished The counterweight, and it is a real one, is that the pieces of the system where an admin key would be most dangerous have no admin key at all. The revenue router AereSink 0x69581B86A48161b067Ff4E01544780625B231676 has no owner, no setters, no pause, and no upgrade proxy; its 15 / 40 / 45 split across burn, buyback-and-burn, and staker-yield is constructor-set and immutable, so no vote and no Foundation signature can ever change how fees are divided. The liquid-staking receipt sAERE 0xA2125bE9C6fd4196D9F94757Df18B3a2A5e650b0 and the burn endpoint AereFeeBurnVault 0x696afDF4f814e6Fd6aa45CE14C498ed9375fB2c6 are likewise admin-free, as are the post-quantum verifiers. So the correct statement is precise: AERE's money flywheel is already ungovernable by anyone, while its parameter and upgrade authority still rests with the Foundation. The roadmap closes that second gap deliberately, and only after the network is hardened enough for it to be safe. Already ownerless AereSink revenue router, 15 / 40 / 45 constructor-set and immutable sAERE liquid-staking receipt, no admin, no setters AereFeeBurnVault burn endpoint, no withdraw The post-quantum verifiers, pure immutable logic Still Foundation-controlled Most Ownable protocol contracts, owned by the Foundation-controlled account (a single-key EOA today; a Safe multisig is roadmap), with 18 measured exceptions still under other single-key operational accounts and scheduled to move with the rest Parameter and upgrade authority rests with the Foundation The stake-weighted vote is advisory, not binding Governor and Timelock deployed (addresses in the governance section) but owning nothing yet, so governance is advisory until the ownership transfer The path to bind Binding governance means two concrete steps, both listed as roadmap in docs/ROADMAP-PHASES.md and neither yet performed. First, a Governor plus a Timelock. Both now exist on chain 2800 (AereGovernorV2 and its timelock, addressed in the governance section below) but they own nothing yet, so they bind nothing. Second, transfer ownership of the protocol contracts from the Foundation-controlled account to that Timelock, so that a parameter change or upgrade requires a passed on-chain vote followed by a timelock delay rather than a Foundation signature. That ownership transfer is the exact moment the Foundation's unilateral control ends. It is the single largest and most irreversible founder signature in the entire plan, and by design it comes late: after the validator set has grown and after the first external audit, never before. 9.2 The roadmap, phase by phase The roadmap is written to be verifiable rather than aspirational. Every live capability names the contract that backs it; every capability that is not yet live is labelled in development or roadmap and states the one honest dependency that unlocks it. The dependency vocabulary is deliberately blunt: code, money, people, or a founder signature. Fig 9.1 The path, phase by phase, with state badges and the one honest dependency that unlocks each 1 The live foundation Live The network that is running: 0.5s single-slot finality, Ethereum-parity EVM, fixed 2.8B supply, the full deployed stack, and the on-chain post-quantum verifier suite. dependency: none, it exists 2 PQC to the protocol layer, first decentralization, first audit In development Native PQC precompiles and EIP-2935 lookback are now live on mainnet via the AerePQC fork (block 9,189,161), and the validator set has grown from six to nine and, on 2026-09-11, to ten (f=3 with a quorum of seven of ten); still ahead, the first external audit. code people money founder signature 3 Ecosystem, liquidity, real usage, and a listing Roadmap Bridge USDC.e, open the home CLOB with a seeded liquidity ladder, and light up the RWA lending and intent rails; a centralized-exchange listing follows later. real usage organic makers and users 4 21 validators, client-diversity posture, and binding governance Roadmap Grow the set from 9 to 21 under a Validator Charter, hold an honest single-client posture until a shadow-net interop run proves otherwise, deploy the Governor and Timelock, and transfer ownership to it. people code the ownership-transfer signature 5 Credibly neutral, quantum-durable settlement End-state Not a new build: the condition in which the earlier phases are all true at once, precompiles audited and live, an independent 21-node set, binding governance, and real fees flowing continuously into the immutable sink. culmination of all above What it shows. Each phase is coloured by state (green live, amber in development, grey roadmap) and carries the blunt dependency vocabulary that unlocks it: code, money, people, or a founder signature. None of these milestones is reached by announcement. The detailed, verbatim account of each phase follows. Phase 1: the live foundation (shipped, dependency: none, it exists) Live Phase 1 is the network that is running, not a promise. Consensus is Hyperledger Besu QBFT with 0.5-second blocks, halved from one second mid-chain at block 2,137,652, and single-slot BFT finality, so a transaction is final in well under a second. The EVM tracks Ethereum's ruleset with Pectra activated at block 2,075,341 and Fusaka at block 2,106,597, giving functional parity with Ethereum mainnet, including the RIP-7951 P-256 precompile at 0x100 , the EIP-2537 BLS precompiles, EIP-7702 delegation, and the EIP-7825 per-transaction gas cap of 16,777,216, which AERE keeps deliberately. Supply is fixed at 2,800,000,000 AERE, capped at genesis-v2 on 2026-05-07 across six genesis wallets, with no new issuance in any mechanism. The deployed, Foundation-owned stack includes the wrapped token WAERE 0x7e84d7d66d5da4cfE46Da67CDEeB05B323e1f5e8 , the staking pool AereStakingV2 , the immutable flywheel sAERE feeding from AereSink , the lending engine proven end to end on its AereLendingMarket proof market 0x2C2d39dB711C0A33De04Dc74b1E22f4760FD4bb0 , a multi-prover zk-verifier stack routing through the SP1 gateway 0x9ca479C8c52C0EbB4599319a36a5a017BCC70628 , and the rollup validity anchors, from the bounded-VM AereRollupValidity 0x38772063572DF94E90351e44ccbBEefD5F497fbd , whose epoch 0 was recorded from a real SP1 Groth16 proof, up to the full-EVM AereEVMValidityBatch 0x49D30a5999eA5b7f6eFf12196AB006316683Ff3C , which proved and verified a 16-block batch of real chain-2800 blocks in a single Groth16 proof through the SP1 gateway, a proof-of-approach on real blocks not yet at production rollup cadence. That contract is superseded in the canonical registry by the canonical-bound AereEVMValidityBatchV2 0xe154B8993FB54dB4418e03ef4a04894f29E690aE , which is deployed and has not yet recorded a proof, so the batch above is still the strongest recorded result. The genuinely differentiated piece is the post-quantum verifier suite running on-chain at the application layer: WOTS+, XMSS, Falcon-512, and SLH-DSA-SHA2-128s all record on-chain, while Falcon-1024 0xF0aFA59BaB2058e4B6e6B424b7f76750F1F66e36 and ML-DSA-44 0xf1F7A6Acd82D5DAf9AF3166a2F736EE52C5F85AE now record on-chain through the native precompiles that went live with the AerePQC fork (block 9,189,161, 2026-07-12), since a full record transaction for each exceeds the 2 24 cap in pure Solidity. We are not aware of any other public chain that verifies all of these on-chain. The honest scope limit is stated at the front: this is application and account layer post-quantum security. Nothing in Phase 1 made consensus post-quantum; consensus became hybrid post-quantum in the anchor-certificate sense later, at block 13,014,000 and on 2026-08-14, by a separate activation, and any claim that Phase 1 did it would be false. Phase 2: PQC to the protocol layer, first decentralization, first audit In development State: partly shipped. The AerePQC client fork is live on mainnet (native PQC precompiles plus EIP-2935, block 9,189,161), so the post-quantum precompiles and the extended block-hash lookback are done; what remains is decentralization and the first external audit. Dependency for the rest: people (independent operators), plus money (an audit), plus a founder signature (validator votes). Phase 2 raises the credibility floor in three ways. The first is native PQC precompiles, now live. The pure-Solidity verifiers are already heavily optimized, but the residual cost is intrinsic, thousands of SHAKE256 permutations per verify, so the fix is native code. The AerePQC fork adds five native precompiles at the reserved band 0x...0AE1 to 0x...0AE5, one each for SHAKE256, Falcon-512, Falcon-1024, ML-DSA-44, and SLH-DSA-SHA2-128s, wrapping a maintained native library (Bouncy Castle 1.83) inside the client and validated bit-for-bit against the same NIST KAT and ACVP vectors the on-chain Solidity verifiers already pass (41 of 41 accept and reject cases). Proven first on an isolated Besu 26.4.0 scratch fork (chain 28099), they were activated on mainnet 2800 by the AerePQC fork at block 9,189,161 (2026-07-12): all KATs pass and measured verify-and-record gas is 86,336 for Falcon-512, 145,496 for Falcon-1024, 351,050 for ML-DSA-44, 558,276 for SLH-DSA-128s, and 21,470 for SHAKE256, all comfortably under the 16,777,216 cap. Activation was a coordinated flag-day hard fork with no re-genesis and no state migration, adding behavior only at otherwise-empty addresses, and the same fork also activated the extended EIP-2935 block-hash lookback (an 8191-block window). The fork added the precompiles and EIP-2935 only; it did not change consensus, and Block-STM parallel execution was not part of it and remains a testnet demonstration. Beyond this application and execution layer capability, consensus itself carries a post-quantum checkpoint: since 2026-08-14 no anchor block (every 32nd) finalizes without at least three valid Falcon-512 validator seals (f+1 of the nine validators of that time) (raised at block 14,961,456, August 21, 2026, to six seals, then a full 2f+1 quorum of nine; since the set grew to ten on 2026-09-11 the enforced minimum is still six, above f+1 but below the ten-validator quorum of seven) under its hash, with classical ECDSA finalizing every block. Separately, a validator finality-attestation layer has been demonstrated on an isolated 4-validator testnet as a gossiped, verified 2f+1 Falcon-512 quorum certificate, every validator co-signing each block and every node re-verifying it on import, blocking after a fork; across two healthy runs (229 and 215 blocks) every post-fork block carried a valid 3-of-4 certificate alongside the decisive ECDSA seal with zero rejects and no halt; that demonstration was later carried to mainnet in the anchor-certificate form described in chapter 3, not as a per-block quorum. The measured numbers and the KAT methodology are detailed in research/pqc-onchain-verification.md . The second was decentralization to seven validators, reached on 2026-07-12, and to nine on 2026-08-09 and ten on 2026-09-11 (the first Nethermind validator), through one-at-a-time header-voting admission with zero downtime. At n=10 (since 2026-09-11) the tolerated Byzantine faults f = floor((10-1)/3) = 3, so the chain survives up to three simultaneous validator failures. The set is still Foundation-operated. Each new operator must be an independent legal entity on independent infrastructure, in a different jurisdiction; only such admissions, none of which has happened yet, would remove the single-operator-can-halt objection. It does not by itself make the network decentralized, and it will not be described that way until the Phase 4 targets are met and independently verifiable. The third is the first external audit. AERE has had no external audit of its contracts or client changes; the numbered findings already fixed in the registry are internal audit discipline, not an independent check. The native PQC precompiles are now live on mainnet through the AerePQC fork, but that activation was a founder decision rather than the product of an independent review, and Besu still produces every mainnet block, so no second producing client is there to catch a consensus bug at runtime, so Phase 2 commissions a real external audit of the now-live native PQC code path and the rest of the stack. Phase 3: ecosystem, liquidity, real usage, and a listing Roadmap State: roadmap, code largely ready. Dependency: real usage, organic makers and users, who cannot be manufactured. AERE trades first on its own native on-chain order book; a centralized-exchange listing follows later. The native CLOB code ( AereCoreBookV0 , named by artifact because nothing is listed and no market address exists) is written and internally tested, but the market map is empty and the trade UI stays in demo mode until it is populated. Going live means bridging USDC.e onto chain 2800 through a Hyperlane Warp Route, deploying the WAERE/USDC.e market with immutable tick, lot, and taker-fee parameters, and seeding a two-sided liquidity ladder for that market. From day one every taker fee routes into AereSink , so trading volume becomes fuel for the token's own burn-and-yield flywheel. The RWA lending markets and the intent and compliance rails are coded and waiting on the same USDC.e bootstrap. A centralized-exchange listing follows later, once the home order book has real, organic trading depth. The honest cost of that patience is the absence of a fiat on-ramp in 2026. The public answer is simple and true: the price of AERE forms on AERE. Phase 4: 21 validators, client-diversity posture, and binding governance Roadmap State: roadmap. Dependency: people (15 or more independent operators and a governance quorum), plus code (a Governor and Timelock; the second-client interop run is now proven on an isolated testnet, so what remains is the supervised live admission rather than the interop work itself), plus a founder signature (the ownership transfer, the single largest irreversible action in the plan). Phase 4 is where the Foundation stops being able to act unilaterally. Twelve further one-at-a-time admissions lift the set from 9 to 21 validators, raising f to 6 at n=21 with a quorum of 14 of 21. The published distribution targets are concrete: at least 15 distinct legal operators, no operator running more than two validators, infrastructure and network paths independent across operators, and at least five jurisdictions, gated by a published Validator Charter and a charter admissions vote so no single party, the Foundation included, can seat or unseat a validator. Client diversity is stated without exaggeration. For a QBFT chain it is genuinely limited, and the second client is no longer a research item: a patched Nethermind has validated and followed live chain 2800; as of 2026-08-10 it is stalled behind the head and the gap is published rather than hidden, and on an isolated testnet it reaches QBFT consensus with Besu as an equal validator, with both clients proposing and every committed block carrying a cross-client seal quorum (Chapter 2). What remains is the live step, and it is deliberately the slow one, because a bug in a producing client can halt or fork a live chain: extended soaking, review, and a founder-supervised admission of the first mixed-client mainnet validator. Until that happens, the honest statement is a single-producer mainnet on Besu, mitigated by independent operators, staggered patch windows, and never upgrading all validators at once, with a second validating client on mainnet and cross-client consensus proven on testnet. It is not client-diverse today. Binding governance, described in Section 9.1, is the third part: deploy the Governor and Timelock, then transfer ownership of the protocol contracts to the Timelock. That transfer follows, and does not precede, both the validator expansion and the external audit. Phase 5: credibly neutral, quantum-durable settlement End-state State: the end-state the earlier phases converge on. Dependency: the culmination of all of the above, mostly people and sustained real usage plus the founder relinquishing unilateral control. Phase 5 is not a new build. It is the condition in which the earlier phases are all true at once, defined concretely so it can be checked rather than asserted: the native PQC precompiles are audited and active on mainnet through a completed flag-day fork, with the permanent honest caveat that this is application and account layer quantum resistance and consensus still signs classical secp256k1; the validator set is 21 nodes across at least 15 operators, five jurisdictions, and eight networks, tolerating six simultaneous faults; the Governor and Timelock own the protocol contracts and the Foundation is one voice among many; and real fee streams flow continuously into AereSink , whose immutable split burns AERE and lifts the sAERE exchange rate, with extra burn accruing to AereFeeBurnVault . The mechanism is immutable and live today; what Phase 5 adds is the volume that makes it matter. This is the destination the brand thesis names: final as math, safe when the math changes. Cross-phase dependency summary Phase Primary unlock Honest dependency 1 Live 0.5s-finality chain, full stack, on-chain PQC verifier suite none, it exists 2 Native PQC precompiles (fork, live), ten validators (f=3, quorum 7-of-10), first external audit code + people + money + founder signature 3 Home CLOB liquidity, real RWA markets, native order-book trading real usage + organic makers and users 4 9 to 21 validators, client-diversity posture, Governor/Timelock ownership people + code + the ownership-transfer signature 5 Precompiles live on mainnet, independent set, binding governance, self-sustaining flywheel culmination of all above 9.3 Engineering direction: distinct before fast The roadmap above answers a question about state: what runs, what is gated, and on what. This section answers a different one, about ordering. AERE's architecture is settled. Consensus is settled, the post-quantum verification layer is settled, the EVM ruleset is settled. What is left is a long list of things that could be built next, and the only decision that matters is which of them deserve a year. That decision is made by a single published criterion, written here so it can be held against us. The criterion. Every candidate is sorted into one of two piles: work that makes AERE distinct , and work that makes AERE faster . Anything in the second pile can be built by anyone with money and engineers. Anything in the first pile cannot. When the two compete for the same engineering quarter, the first pile wins. Verkle tries, a QUIC transport, io_uring storage, NUMA-aware scheduling, SIMD hashing and predictive caches are each a genuine improvement, and not one of them changes the category the network competes in. A year spent there produces a faster client, not a different one. This section exists so that year is spent deliberately, and so a reader can check later whether it was. The three pieces of work ordered first 1. The post-quantum seal quorum becomes part of the header commitment. Chapter 2 describes the research demonstration in which every validator on an isolated test network post-quantum signs each block's commit hash and gossips that seal inside its consensus message, so each block embeds a quorum certificate that every node re-verifies on import. The first ordered piece of work makes that certificate part of what the block header itself commits to, through a fixed-size digest carried inside the header data that is already covered by the block hash, so the certificate is bound by the same hash that binds everything else in the header. That is the step which turns post-quantum evidence from something a block carries into something a block's identity depends on. It is an execution item rather than a research item: the design is fixed, the guards are implemented and compile and pass together in a real client, each guard is proven able to fail under a negative control with the guard removed, the second client accepts the header element at compile time and at run time on real headers, and the activation sequence has been rehearsed on a test network. In the roadmap's own blunt vocabulary: the header anchor went live at block 13,014,000 and its enforced minimum has been three seals (f+1 of the nine validators of that time) since 2026-08-14, raised to six, then a full 2f+1 quorum of nine, at block 14,961,456 (2026-08-21); since the set grew to ten on 2026-09-11 the minimum is still six, below the new quorum of seven, so an anchor block without that certificate does not finalize, with classical secp256k1 ECDSA finalizing every block. Correction published 2026-08-19: this document previously stated that from block 14,050,000 every block required a 2f+1 (six-of-nine) post-quantum quorum to finalize. The per-block Falcon quorum rule armed at that height is, in the shipped code, retired in favour of the anchor rules from block 13,014,000, and a re-reading of the code and of the chain (non-anchor blocks carry no Falcon seals) shows it changed no enforcement; that statement is withdrawn. What is enforced is the anchor certificate described here. 2. From an L1 EVM to an L1 execution kernel. Today the EVM is the execution layer. The target is an execution kernel that owns state access, scheduling, commitment and proving, with the EVM as its first virtual machine rather than its only one, so that adding a second machine, RISC-V being the obvious candidate, is an additive change rather than a rewrite. Two things are declared immovable in advance and by design: consensus does not change, and the state model does not change. This is the same additive discipline Chapter 3 applies to post-quantum cryptography, applied to execution. It is deliberately written as an architecture document before it is written as code, and the document is not permitted to pass without answering three questions. Where exactly is the boundary, and what interface crosses it. What is declared unchangeable, named explicitly rather than assumed. And which three measurements decide whether the work was worth doing, given as numbers with a stated method rather than as adjectives. A kernel is rewritten once. If the boundary is drawn in the wrong place, nobody finds out for a year, which is precisely why the document comes first. 3. A cryptographic abstraction layer. Today, algorithms are bound to the protocol. The target is protocol to interface to algorithm, so that a primitive or a parameter set can be replaced by registering a new verifier behind an unchanged interface instead of by editing the protocol. This is insurance, not polish. Cryptographic recommendations move: standards bodies revise parameter sets, and the industry has already leaned toward the larger Falcon parameters, which is why AERE's native precompile is Falcon-1024. On the day a primitive is superseded, the whole difference between a week of work and six months of work sits in this layer. It is inexpensive to build before it is needed and expensive to build after, which is why it is third rather than tenth. The queue, sorted by the same criterion The rest of the engineering programme is published below in the two piles, in order. Nothing here is a claim about what exists; Section 9.2 is the account of what exists. This is an ordering, and it deliberately carries no dates. Work that makes AERE distinct Why it is in this pile Post-quantum consensus, end to end Validator signatures, consensus messages, peer authentication, slashing evidence, checkpoint signatures, light-client proofs and bridge signatures, all post-quantum natively rather than merely prepared for. This is the direct continuation of the first ordered item above, and it is the one line of work that would make the network's security assumption different in kind from every other chain's. Native proof of execution Chapter 4 describes the validity anchors that already record real proofs of real chain-2800 execution. The distinct version of that work is a chain where every block produces a proof of its own execution by default rather than by opt-in. It changes what the chain guarantees, not how quickly it does it. The execution kernel See item 2 above. It is the only item on the whole list that changes what the network is rather than how fast it runs. The cryptographic abstraction layer See item 3 above. Agility under a change of primitive is a property no amount of later optimization can retrofit cheaply. Work that makes AERE faster Scope Parallel execution, second generation Conflict prediction, an explicit dependency graph, parallel scheduling and a proof obligation on top of the Block-STM work in Chapter 2. Trie engine, second generation Verkle commitments, SIMD hashing, cache locality, compressed witnesses, parallel hashing and incremental commitment. Fully parallel commit Execution, state update, trie update, hashing, witness generation and proof generation all overlapped rather than staged. Adaptive QBFT Adaptive timeouts, proposer selection, message batching, peer selection and retransmission. Post-quantum engine, second generation SIMD and AVX512 paths, GPU and FPGA offload, batching, a verification cache and speculative verification. Network stack QUIC, multipath, adaptive gossip, erasure coding, congestion-aware routing, prioritization and binary propagation. Scheduler NUMA-aware, CPU-topology-aware, SIMD-aware and cache-aware, on an allocation-free hot path. Native block builder Ordering by throughput, trie locality, cache locality, dependency structure and verification cost. State cache Multi-layer, predictive, trie-aware and witness-aware. RPC engine Asynchronous, zero-copy, binary and streaming. Validator runtime Lock-free and wait-free where the algorithm permits, allocation-free and copy-free on the critical path. Storage layer io_uring, direct I/O, huge pages, asynchronous writes and adaptive compaction. Signature aggregation Aggregation applied wherever the protocol allows it rather than only where it is conventional. Light client Fewer proofs, less data and fewer hashes for the same assurance. Conflict-aware mempool Ordering by conflict, dependency, priority and locality so the executor receives work it can parallelize. Economic verification Model checking, SMT solving, and invariance and simulation proofs for the fee and burn mechanisms described in Chapter 8. Two rules that govern the whole list Formal verification is aimed, not sprayed. The target is complete coverage of the invariants whose failure would halt the chain or lose user funds, not complete coverage of lines of code. Verifying everything sounds stronger and is weaker in practice, because it consumes exactly the engineers and months the distinct pile needs. Stating the target as invariant coverage makes it a decision that can be argued with rather than an omission that has to be discovered. One at a time, and proven. Twenty simultaneous work sites are not a programme, and a document reporting twenty things in progress says nothing reliable about any of them. Each item above is finished only when it carries a measurement and a negative control, meaning its own proof has been shown capable of turning red when the property it checks is removed. A check that has never failed cannot be trusted. That rule is the same one the verification section of this document applies to itself. 9.4 Risks and limitations This chapter consolidates the weaknesses named throughout the whitepaper into one place, in plain language, so a reader never has to reconstruct them from footnotes. Centralization and fault tolerance. AERE today is a permissioned, single-operator network: ten validators, all keys held and run by the Foundation. With n=10 (since 2026-09-11) the tolerated Byzantine fault count is three (quorum 7-of-10), so the chain survives three simultaneous validator outages, but all ten are one operator. Stated in the standard unit, the Nakamoto coefficient is 1 : one party can halt the chain, because that party is every party. Fault tolerance of two is a property of the algorithm, not of the operator set, and the two should not be confused. This is the most material limitation, and the completed Phase 2 step to nine, then ten, and Phase 4 (to 21) exist to remove it in order. One producing client. The network produces every block with a single client (Besu). A second, independent client (a patched Nethermind) has validated and followed live chain 2800, which is verification-layer diversity when it is caught up; as of 2026-08-10 it is stalled behind the head, and it reaches consensus with Besu on an isolated testnet, but it produces no mainnet blocks. The verification-layer result is real and worth its exact weight: the two clients agree on block hash and state root at five heights spanning the post-quantum activation block 9,189,161, which is where a divergence would be most likely and most damaging. That is genuine cross-implementation assurance on the live chain. It is not production diversity, and the difference is that a bug in the sole producing client still has nothing to stop it from being written into a block. For a QBFT chain the live step is genuinely hard and founder-supervised, so this is stated as a mitigated single-producer posture, never as full client diversity. No external audit. Neither the contracts nor the client changes have had a third-party audit. The numbered findings already fixed and redeployed in the registry are the product of internal audit rounds, which is groundwork, not an independent verdict. The native PQC precompiles are already live on mainnet via the AerePQC fork, so the first external audit that Phase 2 commissions is an independent review of code now in production rather than a gate before activation. Governance is not yet binding. Most Ownable protocol contracts are owned by the Foundation-controlled account 0x0243A4f47D44b40b65D33f20329dE20D00c6f3C3 (a single-key EOA, not a threshold multisig; a Safe multisig is roadmap); measured on 2026-08-11, 61 of the 79 registry contracts that answer owner() return that account and 18 return other single-key accounts, and not one is owned by a timelock or a governor contract. The Governor and the Timelock are no longer pending deployment: AereGovernorV2 0x03251BD9A115385B76220b17914f56eAC0773047 carries 16,616 bytes of live code, its vote source AereGovLockV2 0x547F58B087BEbB1746d6159070E755b868C27731 carries 10,240, and the timelock 0x9d618c5AB5f40c7187fc8D644d1aC9Bae0805f85 carries 7,427 and reports a minimum delay of 172,800 seconds, which is 48 hours. The stake-weighted vote stays advisory because ownership has not been transferred to that stack, not because the stack is unbuilt. The mitigating fact is that the money flywheel ( AereSink , sAERE , AereFeeBurnVault ) and the verifiers already have no admin key at all. Thin usage, and subsidy-funded yield. Realized throughput and fee flow are early. Because supply is fixed at 2.8B with no consensus-level minting, staking yields, the 8 percent default delegated APR on AereStakingV2 and the 10 to 30 percent locked APYs, are paid from Foundation-seeded genesis reserves, not from issuance. They are a subsidy with a runway, safe because principal is protected, but they are self-sustaining only once real fee revenue routed through AereSink replaces the reserve. Burn and yield figures should be read live from the on-chain counters, never assumed. AERE remains a fixed-supply chain: there is no adaptive issuance and no new token. No fiat on-ramp, no listing. There is no fiat gateway and no CEX listing in 2026. A retail user who does not already hold a wallet, AERE, and bridged USDC.e cannot yet reach the market. This sequencing is deliberate: the price of AERE forms on its own on-chain order book first, with a centralized-exchange listing to follow later. Post-quantum scope. The post-quantum property is at the application and execution layer, not consensus. On mainnet 2800, Falcon-1024 and ML-DSA-44 record on-chain through the native precompiles that went live with the AerePQC fork (block 9,189,161, 2026-07-12); their pure-Solidity verifiers stay read-only references because a full record transaction exceeds the 2 24 cap in pure Solidity. Since 2026-08-14 AERE mainnet consensus is hybrid in a precise and limited sense: every 128th block (every 32nd block until block 17,225,968, on 2026-09-05) (an anchor block) does not finalize without a certificate of at least three valid Falcon-512 validator seals (f+1 of the nine validators of that time) (raised at block 14,961,456, August 21, 2026, to six seals, then a full 2f+1 quorum of nine; since the set grew to ten on 2026-09-11 the enforced minimum is still six, above f+1 but below the ten-validator quorum of seven) under its block hash, with classical ECDSA (secp256k1) QBFT finalizing every block; the flip was a separate, explicitly approved decision, delivered through coordinated per-node activation heights rather than a re-genesis, exactly as this document said it would be. Validator economics are currently nil, and so is the burn. Validator coinbase revenue on mainnet 2800 is zero, for two independent reasons: genesis declares no blockreward , and the 1 Gwei base fee is destroyed by EIP-1559 rather than paid to the proposer. Because the 37.5% burn is a share of that reward, it currently burns effectively nothing: 0.13735259 AERE over the chain's lifetime, against 2,800,000,000 AERE of supply. Aere is not deflationary today. The mechanism is live, immutable and ownerless and will burn in proportion to real fee flow when there is real fee flow; that is a demand problem, not a contract problem. Today the network is secured by an operator who is paid nothing by the protocol, which is sustainable only while that operator is also the Foundation. Chapter 6 gives the measurement and the two RPC calls that reproduce it. A documented deviation from written EIP-2935. Anyone running an Aere node should know this before they debug it. Between blocks 9,182,380 and 9,189,160 chain 2800 deviates from the EIP-2935 specification as written, because Besu skips the history-window write on proof-of-authority chains that lack the three request-contract addresses. The behavior is Besu's, not a local patch, and it is deterministic and identical across the clients we have compared, so it does not threaten consensus. It does mean that a historical block-hash lookup into that window can return a result that the written specification would not predict. We publish the exact range rather than let an integrator discover it as a mystery. Key custody is a single point of failure. Signing authority for chain 2800 is concentrated: the same operator holds the validator signing keys and the Foundation account, and neither hardware custody nor a threshold scheme is in use for them yet. The consequence is the honest one to state, so it is stated: losing or compromising that custody is losing or compromising the network's authority, and hardening it is a Phase 2 item rather than a solved problem. Measured on 2026-08-01, the Foundation address is a single key rather than a multisig, holds 179,999,989.99 AERE, and, re-measured on 2026-08-11, is returned by owner() on 61 of the 79 canonical-registry contracts that answer it; no contract on chain is currently owned by a timelock. The specific arrangement of key storage is deliberately not described here, because that detail helps an attacker and helps a reader not at all. This is stated in the same document that describes the governance roadmap because the gap between the two is the point. Part of the genesis supply sits outside its genesis wallet. Measured on 2026-08-01, the six genesis addresses hold 2,239,999,990.70 AERE against a 2,800,000,000 cap. The Ecosystem Reserve allocation was moved off its genesis address, so 559,999,999 AERE of the difference is held at a single separate account and the rest is the fee spend of those wallets since genesis. The cap is unchanged, nothing was minted and nothing was destroyed. What is open is documentation: bringing that balance under the same governance handover as the rest of the protocol, and publishing an attestation for it, is an unfinished item and is listed here rather than left for a reader to find by adding up the table in Chapter 8. Test coverage is partial, and here is the number. Contract test coverage is 36.44% of statements, 28.86% of branches and 32.14% of functions, with 161 of 270 contract files at zero coverage. The full suite runs end to end for the first time at 2,055 passing, 8 failing and 23 pending across 175 files. The core economic contracts are the well-covered ones and the untested majority is largely peripheral, but 36% is 36% and it is published rather than rounded into a claim about rigor. Throughput framing. The 273,000 TPS figure that appeared in AERE's design materials as a design ceiling has been withdrawn (its stated derivation does not reach that number) and was never a measured mainnet result. It is never presented as observed throughput. Every one of these is a fact the roadmap is built to change, in a named order, behind a named gate. None of them is reached by announcement. They are reached by shipping the code, running the audit, recruiting the operators, and casting the votes, and each milestone is written so it reads as accurate only when it is independently verifiable on-chain. © 2026 AERE Network Whitepaper Chain ID 2800 · 0xAF0 Status 2026-09-14 This page and its Markdown master docs/WHITEPAPER-V2.md have drifted apart and the footer used to claim they had not. Measured on 2026-08-02: this page carries 103 distinct contract addresses, the Markdown master 93, the print copy 92, and ten addresses appear here that are absent from the master, so regenerating the master over this page would delete published sections. Merging the two is an open item. Every contract address here is copied verbatim from the canonical registry sdk-js/src/addresses.ts , and where the registry marks an address as superseded this document says so and names the replacement. Every claim in this document is meant to be checked on-chain rather than taken on faith. --- # AERE ZK Finality, a design for converting optimistic batches to validity-proof finality URL: https://aere.network/zk-finality.html Fetched: 2026-09-15 AERE ZK Finality, a design for converting optimistic batches to validity-proof finality ZK Finality Gates, a design, not a deployment Correction, 2026-08-01. This page used to say that all eight optimistic rollups already had a companion finality gate, and it listed sixteen contract addresses plus a shared verifier. That was not true, and the page contradicted itself: it carried a "coming soon, contracts not yet deployed" banner in the same screen. We re-read the chain instead of the page. Measured with eth_getCode at the chain head on 2026-08-01: the shared verifier address had zero bytes of code , ten of the sixteen table addresses had zero bytes of code , and the remaining six were entirely unrelated live contracts that happened to be pasted into the table, among them an NFT contract, an oracle and a compliance screening contract. No ZK finality gate is deployed on chain 2800. The addresses have been removed rather than corrected, because there is nothing correct to point them at. The design below is real and is kept; the claim that it was live is gone. The AereL2ZKFinalityGate design gives an optimistic rollup batch a second way to become final. Instead of waiting out the fraud window, anyone holding a valid Groth16 proof of the batch's state transition calls submitProof() , the gate reads the batch's old and new state roots from the rollup's own verifier, builds the public signals from them, and asks a Groth16 verifier to check the proof. A proof for one batch cannot be replayed onto another, because the roots it is bound to are the ones the chain already recorded for that batch. The optimistic path stays in place underneath, so a rollup can adopt this one sequencer at a time. What exists today, measured Finality gates deployed on chain 2800 0 Shared Groth16 verifier deployed no, zero bytes of code at the address this page used to print Optimistic rollups live on chain 2800 0, see the L2 page Batches ever marked ZK-final 0 The circuit side of this work is real: the gate is designed against a snarkjs Groth16 verifier generated from the transfer8.circom circuit, a depth-3 Poseidon Merkle tree with one transfer per batch, and all gates would share that one verifier so the trusted setup is shared rather than repeated. What has not happened is deployment. When a gate is deployed, its address will appear here with a code size and a link, and not before. How the conversion works Optimistic rollup (status quo) + ZK Finality Gate (this layer) ──────────────────────────── ─────────────────────────────── Sequencer posts batch: Anyone holding a valid Groth16 proof - blockRange, batchHash of the batch's state transition calls: - oldStateRoot, newStateRoot submitProof(batchId, sIdx, rIdx, amount, Fraud window: 7 days pA, pB, pC) (anyone can challenge with a fault proof) The gate fetches (oldRoot, newRoot) from the rollup verifier, builds the public signals, and asks AereZKRollup8Verifier to verify. On success: zkFinalAt[batchId] = block.timestamp. Result: Result: Batch is "soft-final" until day 7 Batch is HARD-final immediately, (some apps may delay withdrawals) instant settlement, no fraud window, verified entirely on-chain. One gate template would serve every rollup, and a sequencer can be upgraded on its own to start producing proofs alongside its batch posts, so the conversion is incremental and the optimistic path stays as the fallback. None of that has been deployed yet, so read this box as a design and not as a description of chain 2800 today. --- # AERE ZK Rollup, State-transition validity proofs URL: https://aere.network/zk-rollup.html Fetched: 2026-09-15 AERE ZK Rollup, State-transition validity proofs AERE ZK Rollup Home All dApps ZK Commitments ZK Rollup with validity proofs Correction, 2026-08-01, and it is worth reading before you trust an address on any page. This page printed two addresses, one labelled the rollup and one labelled its Groth16 verifier. We probed both by walking their live runtime bytecode and matching the function selectors it contains. Neither is what the label said. The first has no stateRoot , no batchCount , no submitBatch and no verifyProof ; it is a bridge contract with a mint entry point. The second is a plain ERC-20: name() returns "Aere-Bridged USDC", symbol() returns "aUSDC", decimals() returns 6 and the total supply is 50 aUSDC. There is no ZK rollup and no rollup verifier deployed on chain 2800 . The addresses are removed rather than corrected, because there is nothing to correct them to. The circuit and the browser prover below are real; the deployment is not. The design: state is a Poseidon commitment of two account balances, and each batch is a transfer carrying a Groth16 proof that the transfer was applied correctly. An L1 verifier would check the proof, so there is no fraud window and finality is immediate on inclusion. This is the validity-proof model, in two-account form to show the cryptographic core, and the same pattern extends to N accounts through a Merkle-tree state. Everything in this paragraph describes what the circuit does, not what chain 2800 runs today. Rollup status AereZKRollup not deployed on chain 2800 (measured 2026-08-01) Verifier not deployed on chain 2800 (measured 2026-08-01) Account 0 , Account 1 , State root , Batches submitted , Connect Wallet Refresh 1 · Track local state The chain only stores a Poseidon commitment of the two balances. To advance the rollup, you must know the pre-image. Anyone can post a batch as long as they know the current balances. The genesis is account 0 = 1000, account 1 = 0. Account 0 balance Account 1 balance Check this matches on-chain root , 2 · Build a transfer Direction Account 0 → Account 1 Account 1 → Account 0 Amount Generate proof in browser (Groth16, ~1-2s) , 3 · Submit batch on-chain The verifier will reject any proof that doesn't match the current on-chain state root or violates the transfer rules. Submitting advances the rollup; the verifier call pays the normal 1 gwei minimum base fee on AERE. Submit batch , Recent batches , How it works Off-chain (browser) On-chain (AERE L1) ───────────────── ────────────────── 1. Read on-chain stateRoot ┐ 2. Know (bal0, bal1) such that │ Poseidon(bal0,bal1) == stateRoot │ 3. Pick (direction, amount) ├── Verifier (Groth16) checks: 4. Compute newBal0, newBal1 │ • prover knew pre-image of stateRoot 5. Compute newState = Poseidon(...) │ • amount ≤ sender balance 6. Run circom witness + Groth16 prove │ • newState matches Poseidon of new balances 7. Submit (newState, dir, amount, proof)──┘ 8. State root advances to newState 9. BatchPosted event emitted --- # AERE ZK Rollup (8-account), Merkle-tree state with Groth16 transfers URL: https://aere.network/zk-rollup8.html Fetched: 2026-09-15 AERE ZK Rollup (8-account), Merkle-tree state with Groth16 transfers AERE ZK Rollup (8-account) Home All dApps 2-account demo ZK Rollup, 8-account Merkle state Not deployed, and the addresses this page used to print were empty. Measured with eth_getCode at the chain head on 2026-08-01, both the rollup address and the verifier address shown here previously returned zero bytes . There is no contract at either one. The circuits, the browser prover and the contract source below are real work; the deployment is not done. The addresses have been removed so that nobody sends a transaction to an empty account on the strength of this page. Everything below describes the design. Production-shape ZK rollup design. State would be a depth-3 Poseidon Merkle root over 8 account leaves. Each batch is a transfer (senderIdx → receiverIdx, amount); the L1 verifier checks a Groth16 proof of the full state transition: sender Merkle inclusion, sender deduction yields intermediate root, receiver Merkle inclusion against intermediate, receiver addition yields newRoot, plus solvency. No fraud window. Same pattern scales straightforwardly to depth-N. Rollup status AereZKRollup8 not deployed on chain 2800 (measured 2026-08-01) Verifier not deployed on chain 2800 (measured 2026-08-01) Tree depth 3 (8 leaves), by design State root no contract to read Batches submitted 0, no contract to read Connect Wallet Refresh 1 · Local balances (must match on-chain root) Genesis: account 0 = 1000, all others 0. Update if you've replayed batches locally. Check Merkle root matches on-chain , 2 · Build a transfer Sender index Receiver index Amount Generate Groth16 proof , 3 · Submit batch Submit on-chain , Recent batches , --- # AERE ZK Commitments, Real Groth16 Proofs On-Chain URL: https://aere.network/zk.html Fetched: 2026-09-15 AERE ZK Commitments, Real Groth16 Proofs On-Chain AERE ZK Commitments Home All dApps Explorer Zero-Knowledge Commit-Reveal Groth16 Coming soon. This feature is built and on the AERE roadmap, its on-chain contracts are not yet deployed. Actions are disabled until launch. Built and tested, not yet deployed on chain 2800: the verifier and registry addresses below carry no contract code today (measured 2026-08-19), so the panel shows no data. The circuit is preimage.circom (453 non-linear constraints). Trusted setup: BN254 + Powers of Tau (2^10) + Groth16 ceremony with 1 contribution. Solidity verifier at 0x94AF…c29F , registry contract at 0x34F7…A299 . The proof is generated in your browser using snarkjs.wasm. Use cases: anonymous DAO voting, mixer commitments, anonymous airdrop claims. Registry status Total commitments , Total claims (proofs verified on-chain) , Verifier contract 0x94AF0740ad4b149F0bb860b0Dda61027322Bc29F (no code on chain 2800 today) Commitments contract 0x34F7b38dDC6b9d4f2ADC165AcF2b22B2349AA299 (no code on chain 2800 today) Connect Wallet Refresh Commit + Reveal Flow Step 1 · Generate a (secret, nullifier) pair Your secret stays in this browser. The nullifier is revealed later (as a hash) so each commitment can only be claimed once. Generate fresh , Step 2 · Compute Poseidon commitment + nullifier hash Real Poseidon-2 hash from circomlibjs running in your browser. Compute , Step 3 · Submit commit() on-chain Payload (utf-8 string, optional, e.g. encrypted vote, blob ref) Commit on-chain , Step 4 · Generate Groth16 proof browser-side Loads preimage.wasm (~2 MB) + preimage_final.zkey (~250 KB) and produces a real proof. Takes 1-5 seconds. Generate proof , Step 5 · Submit claim(), verifier executes BN254 pairing on-chain Application messageHash (bytes32, optional) Claim on-chain , How this is real The circuit ( preimage.circom ) is a real circom 2 program with 453 non-linear constraints over the BN254 scalar field The trusted setup ran on Foundation infrastructure: powersoftau new bn128 10 , contribute, groth16 setup , contribute, export verificationkey , export soliditycalldata The verifier is the byte-for-byte snarkjs-emitted Groth16 contract, pairing check via the EIP-196/197 precompiles Verification runs entirely on AERE L1; the network charges a 1 gwei minimum base fee (consensus-enforced since block 10,141,734), so on-chain verification costs a small, predictable fee rather than nothing Proof generation runs in your browser via snarkjs.groth16.fullProve() , your secret never leaves this page