# Aere Network - full site text for language models # Chain ID 2800. Public RPC: https://rpc.aere.network # Generated 2026-08-16 from 129 live pages. # Every technical claim on these pages is checkable against the chain itself. # Architecture, live versus planned · Aere Network URL: https://aere.network/architecture.html Fetched: 2026-08-16 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 is not delivered , and it is drawn separately so that it cannot be mistaken for running architecture. 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 is currently idle. Measured 2026-08-05 at head 12,469,045: 120 headers sampled across the most recent 3,000 blocks carried zero transactions in total , while txpool_status reported 200 pending transactions that are not draining into blocks. 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. The cause of the stalled backlog is not yet measured , and is recorded as an open item in 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 of the certificate anchor, live on mainnet and consensus-blocking since block 14,050,000, and three items that are NOT delivered on mainnet: Block-STM parallel execution, Adaptive QBFT, and the 273,000 TPS ceiling. 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, strictly sequential Standard Besu execution, one transaction after another. We say so plainly because the opposite claim is common and cheap to make. Parallel execution exists in the rollup sequencer only, drawn on the right. 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 9 validators, quorum 6, f=2, all operated by the Foundation. 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 Makes the block hash cover the Falcon certificate. Live on mainnet since block 13,889,296, minimum 3 seals enforced. Consensus-blocking since block 14,050,000. L2 ONLY, NOT ON L1 Block-STM parallel execution The executor is real and benchmarked, and it runs in the rollup sequencer. The Besu base layer stays sequential. See box 3, which says the same thing from the other side. 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 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-08-05. The left plane is measured; the right plane is not delivered. Nothing on the right has a deployed address, and 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 does exist and is benchmarked, but it runs in the rollup sequencer; the Besu base layer executes strictly sequentially, which is why box 3 states that in the 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 9 validators and 6 committed 65-byte seals, readable out of every signed header. That the 9 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 --- # AERE Network Whitepaper URL: https://aere.network/whitepaper.html Fetched: 2026-08-16 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.43 Status 2026-08-16 Foundation · Seychelles Print or save as PDF Version and verification Version 2.1.43 Content last changed 2026-08-16 Figures measured at block 14,216,402 Measured at 2026-08-16 19:04:54 UTC Content hash (SHA-256) eb0be4346de4c42c989bb2e7d6d16310dc9792c24a7404f8a7d84ff8ad36ef52 Document hash (SHA-256) 44cdbc5663e428962a7a8276588755e366c25e69aafbeb6b341fe444ce2ad4d0 Editorial hash (SHA-256) 5423ee20cec99275d2a1bc5a36517ea8d3e868fde4b2ce568bc69d0e64fe4ac2 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 14,216,402 , at 2026-08-16 19:04:54 UTC . If the node cannot be read, the build fails rather than republishing a stale number. Chain ID 2800 Measured Block interval 566.2 ms Measured Base fee 1 Gwei Measured Validators 9 Measured Fault tolerance f = 2 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 Design ceiling Consensus is classical. The 9 validators sign with secp256k1 ECDSA under QBFT. Post-quantum cryptography on this chain lives at the account and application layer, through the precompiles below, and not in consensus. All 9 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 14,216,402 : 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 566.2 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 is an architectural ceiling implied by the block parameters. It is not a measured mainnet rate and is never presented as one. 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 Hyperledger Besu QBFT, nine validators (f=2, quorum 6-of-9), 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; 61 of the 79 registry contracts that answer owner() return it, 18 return other single-key accounts, and none returns a timelock, measured 2026-08-11) 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 nine validators, all operated by the Foundation, on a single client, only two-fault Byzantine tolerance today (quorum six of nine), no external security audit, thin real usage, and no exchange listing. The post-quantum property is at the application and account layer, not consensus: validators still sign classical secp256k1 QBFT messages. Since block 13,014,000 the block hash itself covers a post-quantum certificate: every 32nd block carries, inside the hashed part of its header, a 32-byte digest that binds Falcon-512 seals from the validators. Measured across the fifty most recent anchor blocks on 2026-08-14, every certificate carried five seals, the configured cap. 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, and it is not a quorum, so no quorum is claimed. The blocking post-quantum mode went live at block 14,050,000: from that height a block does not finalize without a quorum of Falcon-512 validator signatures, with classical ECDSA seals retained alongside. 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 Nine validators, one operator (Foundation), two-fault Byzantine tolerance at n=9 (quorum 6-of-9) One producing client (Besu) on mainnet; the second client validates and follows there, and reaches consensus with Besu only on an isolated testnet 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. The block parameters admit a design ceiling on the order of 273,000 transactions per second; this is a theoretical maximum implied by the gas and block configuration, not 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 with native post-quantum signature verification precompiles live on mainnet , callable by anyone, from any contract or any eth_call , at a published public RPC endpoint. Not a testnet, not a demonstration contract, not an announcement of intent. 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 block 14,050,000 AERE mainnet consensus is hybrid: no block finalizes without a quorum of Falcon-512 validator signatures, with classical ECDSA (secp256k1) retained alongside; 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. Nine validators, one operator. All nine validators are held and run by the Foundation. With n=9 the tolerated Byzantine faults is two (quorum 6-of-9), so the chain now survives two simultaneous validator outages, but all nine are one operator. This is not a decentralized network today. One producing client. AERE produces every mainnet block with a single execution client, Besu. 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. Validators sign classical secp256k1 QBFT messages. Nothing in this whitepaper makes consensus post-quantum, and no wording should be read as claiming it does. Since block 13,014,000 the block hash itself covers a post-quantum certificate: every 32nd block carries, inside the hashed part of its header, a 32-byte digest that binds Falcon-512 seals from the validators. Measured across the fifty most recent anchor blocks on 2026-08-14, every certificate carried five seals, the configured cap. 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, and it is not a quorum, so no quorum is claimed. The blocking post-quantum mode went live at block 14,050,000: from that height a block does not finalize without a quorum of Falcon-512 validator signatures, with classical ECDSA seals retained alongside. 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 = 9, all Foundation-operated Honest counterweight: at n = 9, tolerated faults f = floor((n-1)/3) = 2. The chain now survives two simultaneous validator outages. Validators sign classical secp256k1 QBFT messages. 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 and consensus signatures are classical. 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 nine validators, and all nine 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 = 9 equals two, with a quorum of six of nine. 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 is already done; the remaining path from nine 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 are classical Consensus signatures themselves are classical. Validators sign QBFT consensus messages with secp256k1 keys. AERE's post-quantum work lives strictly above consensus at the application and account layer, and does not change what validators sign. 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 blocking post-quantum mode, nine keyed validators, is verified. 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, and since block 14,050,000 the Falcon quorum is consensus-blocking: mainnet QBFT does not finalize a block without it, with classical ECDSA (secp256k1) seals retained alongside. 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 design ceiling that appears in AERE's broader materials) is a design ceiling derived from block-space arithmetic under ideal conditions. 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 The base layer executes sequentially on mainnet today. Besu processes the transactions in a block one after another, in order, exactly as Ethereum mainnet does. Making the L1 base layer execute in parallel is real, proven work, but stated precisely it is three distinct proof-of-approach artifacts, not a shipped mainnet feature. None is part of the AerePQC mainnet fork (which activated only the post-quantum precompiles and the extended EIP-2935 block-hash lookback, described in Chapter 3) and none 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). Since block 14,050,000 consensus cryptography is hybrid in the producing client: no block finalizes without Falcon-512 validator signatures alongside classical secp256k1 ECDSA; the second client independently re-validates the chain. 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 nine Foundation-operated validators with f=2 fault tolerance (commit quorum 6-of-9), though on a single producing execution client (Besu, with a second independent client that validates chain 2800 and reaches consensus with Besu on an isolated testnet, but produces no mainnet blocks), 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; the base layer executes sequentially on mainnet today, but Block-STM is now implemented in the forked client with serial-equivalence correctness proven and demonstrated on testnet (not part of the AerePQC mainnet fork), and 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 the harvest step is free and is already happening. This is the harvest-now, decrypt-later posture, 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. AERE's validators still sign classical secp256k1 QBFT consensus messages, and nothing here changes that. As a separate research demonstration of what a future post-quantum consensus seal could look like, AERE has run 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 is a demonstration on an isolated testnet only. On mainnet 2800 consensus remains classical secp256k1 QBFT today; the seal registry is bound on-chain through an immutable anchor contract (nine entries, checkable with eth_getStorageAt), the enforced anchor minimum is three seals since 2026-08-14, and and since block 14,050,000 the blocking quorum is live: a block does not finalize without post-quantum validator signatures, with classical ECDSA retained alongside. The honest scope is stated at the front and repeated at the close: this is application-layer and account-layer quantum resistance, not post-quantum consensus. Honest boundary: application and account layer, not consensus Everything in this chapter sits above consensus. Validators still sign classical secp256k1 QBFT messages. Nothing here makes consensus post-quantum, and making consensus itself post-quantum is a separate, explicitly approved decision, delivered through coordinated per-node activation heights rather than a re-genesis, never a silent implication of the thesis. 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 audited Bouncy Castle 1.83 BCPQC verifiers 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 block 14,050,000 AERE mainnet consensus is hybrid: no block finalizes without a quorum of Falcon-512 validator signatures, with classical ECDSA (secp256k1) retained alongside; 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 post-quantum property is at the application and account layer, not consensus: AERE's validators still sign classical secp256k1 QBFT messages, and nothing in this chapter makes consensus post-quantum. Centralized network today. The network runs nine validators under a single operator, and one execution client (Besu), with only two-fault Byzantine tolerance at n=9 (quorum 6-of-9), 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; validators still sign classical secp256k1 QBFT. 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: nine validators under a single operator, one client (Besu), 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 pending 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 audited 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 audited 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, are read-only views on mainnet today rather than usable account owners. 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: AERE's validators still sign classical secp256k1 QBFT. 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 nine QBFT validators under a single operator (f=2, quorum 6-of-9), on one client (Besu), 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 Hyperledger Besu QBFT with nine validators under one operator and one client, and validators sign classical secp256k1 QBFT messages 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 Hyperledger Besu QBFT with nine validators under one operator and one client, and validators sign classical secp256k1 QBFT messages 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: AereZkQbftLightClient at 0xCaDA54FAb6E7AE311d240Cf0C2Df45e974156488 , the canonical deployment, 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 any external verifier can advance a trust-minimized view of AERE's OWN QBFT finality by verifying a single Groth16 proof that a chain-2800 block carries a 2f+1 committed-seal quorum. 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 nine 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, while since block 14,050,000 consensus itself is post-quantum-blocking as described in chapter 3; the registry authorizes at the application layer over classical secp256k1 QBFT. 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 In development, not shipped: registering the over-18 program on the canonical anchor needs one Foundation signature. 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 nine validator accounts 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 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 nine validators under one operator, and one client (Besu). 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, principally the Governor and the Timelock, are named by artifact only and are never given a fake address. 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: 61 of the 79 registry contracts that answer owner() return the Foundation account, and 18 sit under other single-key accounts pending transfer to governance. 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 14 measured exceptions still under an operational deployment account 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 not deployed yet, named by artifact only The path to bind Binding governance means two concrete steps, both listed as roadmap in docs/ROADMAP-PHASES.md and neither yet performed. First, deploy an OpenZeppelin Governor plus a TimelockController . Neither is deployed, so this chapter names them by artifact and gives no address. 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 (deeper fault tolerance, f=2 with a quorum of six of nine); 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. Validators still sign classical secp256k1 QBFT consensus messages, so nothing in Phase 1 makes consensus post-quantum, and any claim that it does 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 an audited 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, since block 14,050,000 consensus itself is post-quantum-blocking: no block finalizes without Falcon-512 validator signatures, with classical ECDSA retained alongside. 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 stays a testnet demonstration and mainnet consensus stays classical secp256k1 QBFT. 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, through one-at-a-time header-voting admission with zero downtime. At n=9 the tolerated Byzantine faults f = floor((9-1)/3) = 2, the credible minimum for a public BFT network, so the chain survives up to two 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), nine validators (f=2, quorum 6-of-9), 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, its enforced minimum was raised to three seals on 2026-08-14, and the blocking post-quantum quorum went live at the founder-approved activation height, block 14,050,000. That height, block 14,050,000, has passed, and the chain itself shows it: from that block, no block finalizes without post-quantum validator signatures, with classical secp256k1 ECDSA retained alongside. 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: nine validators, all keys held and run by the Foundation. With n=9 the tolerated Byzantine fault count is two (quorum 6-of-9), so the chain survives two simultaneous validator outages, but all nine 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 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 block 14,050,000 AERE mainnet consensus is hybrid: no block finalizes without a quorum of Falcon-512 validator signatures, with classical ECDSA (secp256k1) retained alongside; 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 appears in AERE's design materials is a design ceiling derived from the architecture, not 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-08-16 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. --- # The Post-Quantum Stack | Aere Network URL: https://aere.network/quantum.html Fetched: 2026-08-16 The Post-Quantum Stack | Aere Network 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 switch after which no block finalizes without post-quantum signatures. 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, and certificates in practice carry five, the configured cap. 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 Live: since block 14,050,000, no block finalizes without post-quantum signatures. The blocking post-quantum quorum went live at block 14,050,000 (aere.falcon.forkBlock), armed fleet-wide behind a single coordinated activation height. Before it, consensus signatures were classical-only 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. Nine keyed validators give the layer a real fault margin (f=2), 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. Live since block 14,050,000 · quorum 6 of 9 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 --- # Benchmarks and methodology, AERE Network URL: https://aere.network/benchmarks.html Fetched: 2026-08-16 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. 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 Design ceiling The 273,000 transactions-per-second figure that appears across AERE materials is a design ceiling derived from block-space arithmetic under ideal conditions . 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. That is precisely why 273,000 is a ceiling the multi-layer roadmap is 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 Design ceiling (for scale) not observed 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 9 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 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 is a design ceiling. It has never been measured on mainnet and no benchmark here reproduces it. The Block-STM speedups are single-machine microbenchmarks of a real executor. The L1 base layer still executes sequentially. 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 --- # Verified Contracts, AERE Network URL: https://aere.network/verified-contracts.html Fetched: 2026-08-16 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 Block 8873713 RPC https://rpc.aere.network Method: Sourcify-style bytecode and metadata match --- # 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-08-16 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 Monaco, 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 --- # 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-08-16 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 Monaco, 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 --- # 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-08-16 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 ZUR SOFORTIGEN VERÖFFENTLICHUNG Monaco, 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-08-16 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 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 --- # 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-08-16 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 PER DIFFUSIONE IMMEDIATA Monaco, 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 --- # 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-08-16 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 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、NIST標準ポスト量子署名のネイティブ検証をメインネットで稼働：公開EVMレイヤー1における先駆けの成果 URL: https://aere.network/press-release-post-quantum.ja.html Fetched: 2026-08-16 プレスリリース：Aere Network、NIST標準ポスト量子署名のネイティブ検証をメインネットで稼働：公開EVMレイヤー1における先駆けの成果 プレスリリース Aere Network、NIST標準ポスト量子署名のネイティブ検証をメインネットで稼働：公開EVMレイヤー1における先駆けの成果 即時リリース モナコ、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。ハイブリッドポスト量子コンセンサスは開発中で、監査を要件とします。 稼働中のシステムに対する第三者監査はまだ完了していません。 ご要望に応じて、取材にはスポークスパーソンが対応いたします。 以上 ← ニュースルームに戻る --- # Developer Hub, AERE Network URL: https://aere.network/developers.html Fetched: 2026-08-16 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 at ~3,500 gas. 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 . Note that there is currently no public way to obtain AERE: the faucet is deployed but unfunded, so a new address can read the chain but cannot send a transaction yet. 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, aere-sdk, aere-docs, aere-examples), 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. ⚡ 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 (not funded) The faucet contract is deployed but holds a zero balance, so it cannot pay out. There is currently no public way to obtain AERE. 💰 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-08-16 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. ⚠ There is currently no public way to obtain AERE. The AereFaucet contract is deployed but holds a zero balance, so claims revert. No public sale, no exchange listing, and no drip is available. A new address can connect to the network and make read-only calls, but it cannot send a transaction until it is funded. We will document a funding path here when one exists. # 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 GitHub: npm i github:aerenetwork/aere-sdk 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 ⚠ The faucet is not funded. It cannot pay out. AereFaucet is deployed at the address below and its dripAmount() is set to 0.05 AERE, but the contract balance is zero, so every claim() reverts. Claiming is disabled in the UI rather than letting you burn gas on a call that cannot succeed. There is no other public source of AERE at this time. 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: the L1 base runs Besu and executes sequentially; this parallelizes L2 rollup batches only. 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. Audited 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 Developer Docs, RPC, SDK, integration URL: https://aere.network/rpc-docs.html Fetched: 2026-08-16 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 557 ms block interval 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 GitHub: npm install github:aerenetwork/aere-sdk 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. --- # @aere/sdk, Official AERE Network SDK URL: https://aere.network/sdk.html Fetched: 2026-08-16 @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 one of four official AERE SDKs, TypeScript, Rust, Python, and Go, described below. 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 ships four client libraries. All four 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 . --- # Add AERE Network to MetaMask URL: https://aere.network/addnetwork.html Fetched: 2026-08-16 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 Need help? See the whitepaper or visit aere.network . --- # AERE Developer Grants URL: https://aere.network/grants.html Fetched: 2026-08-16 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 Faucet, Not Funded URL: https://aere.network/faucet.html Fetched: 2026-08-16 AERE Faucet, Not Funded AERE Faucet Home Add Network Explorer AERE Faucet This faucet is deployed on chain 2800 but is not funded, so it cannot send you AERE. ⚠ The faucet is not funded and cannot pay out. The AereFaucet contract holds a zero balance, so every claim() reverts. Claiming is disabled here rather than letting you spend gas on a call that cannot succeed. There is currently no public way to obtain AERE: no drip, no public sale, and no exchange listing. This page will be updated when a funding path exists. Configured drip (not payable) … Configured cooldown 24 hours Faucet balance 0 AERE Network AERE Network (2800) Status not funded, cannot pay out Your wallet address Use Connected Wallet Claim AERE (faucet not funded) --- # AERE Network, dApps Directory URL: https://aere.network/dapps.html Fetched: 2026-08-16 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 Governance proposals · 20% quorum of total staked · simple majority · 48-hour timelock. Superseded contract, vote is advisory. Live Governance Dashboard Live DAO proposals and on-chain voting state. New DeFi Swap V2-style AMM · 0.3% LP fee · WAERE-paired pools. Live Bridge Lock-and-release federated bridge to EVM chains. 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 Staking, fixed-term locks on AereLockedStaking URL: https://aere.network/stake.html Fetched: 2026-08-16 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. --- # AERE Locked Staking, Liquidity Lock Tiers URL: https://aere.network/stake-v2.html Fetched: 2026-08-16 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 DAO, Governance URL: https://aere.network/dao.html Fetched: 2026-08-16 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 NFT, Mint & Marketplace URL: https://aere.network/nft.html Fetched: 2026-08-16 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. --- # Staking & Validator Rewards, AERE URL: https://aere.network/staking-rewards.html Fetched: 2026-08-16 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 9 Foundation validators today (f=2, quorum 6-of-9) 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 insider unlocks. The chain no one can rug. 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. --- # AERE Oracle Network URL: https://aere.network/oracles.html Fetched: 2026-08-16 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 CEX listing yet, and the only on-chain pool today is a 105-AERE demo seed, that is not a market price. 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. --- # AERE Identity, DID Registry URL: https://aere.network/identity.html Fetched: 2026-08-16 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 --- # AERE Governance, On-chain DAO state URL: https://aere.network/governance.html Fetched: 2026-08-16 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 Mempool, Live pending transactions URL: https://aere.network/mempool.html Fetched: 2026-08-16 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 (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 Tokens & NFTs, Token tracker URL: https://aere.network/tokens.html Fetched: 2026-08-16 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 , --- # Token · AERE Block Explorer URL: https://aere.network/token.html Fetched: 2026-08-16 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 Validators, Live consensus state URL: https://aere.network/validators.html Fetched: 2026-08-16 AERE Validators, Live consensus state Live validator state All nine validators are operated by the Foundation today, 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. --- # AERE Network, System status URL: https://aere.network/network-status.html Fetched: 2026-08-16 AERE Network, System status AERE Network, system status Live health of every AERE Network service. 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. 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 Checking… 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 Economy, Token supply, treasury, locks, burns URL: https://aere.network/economy.html Fetched: 2026-08-16 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 . --- # Aere Network - Press and Media Center URL: https://aere.network/press.html Fetched: 2026-08-16 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 Activates Hybrid Post-Quantum Consensus on Its Public Mainnet Monaco, August 15, 2026. At block 14,050,000 the post-quantum quorum became consensus-blocking: no block finalizes without Falcon-512 validator signatures, with classical ECDSA retained alongside, and the chain did not stop for the transition. Verifiable from any machine, from public endpoints. Read the press release Visit the newsroom Previous release: Native NIST post-quantum signature verification live on mainnet (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), nine Foundation-operated validators, quorum six of nine, tolerating two 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 Block parameters imply a design ceiling on the order of 273,000 TPS; a ceiling, not a measured live rate 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 is a design ceiling implied by block parameters, not a measured figure; today's realized throughput is far below it. 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 contributors working in the open. View the team page 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. --- # About Aere Network URL: https://aere.network/about.html Fetched: 2026-08-16 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. Since block 14,050,000 mainnet consensus is hybrid: no block finalizes without a quorum of Falcon-512 validator signatures, with classical ECDSA retained alongside; an external audit of the post-quantum consensus layer is still ahead. Chain ID 2800 (public EVM Layer 1) Consensus QBFT, nine Foundation-operated validators, deterministic finality (quorum six of nine) 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. Leadership and contributors are listed on the team page . 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 --- # Contact Aere Network URL: https://aere.network/contact.html Fetched: 2026-08-16 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. --- # Editorial Standards & Ownership, Aere Network URL: https://aere.network/editorial-standards.html Fetched: 2026-08-16 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 . --- # Team & Leadership, AERE Network URL: https://aere.network/team.html Fetched: 2026-08-16 Team & Leadership, AERE Network Team & Leadership The people and contributors building AERE Network, a permissionless, EVM-compatible Layer 1 designed for performance at scale. Founder & CEO Liviu Hrenaru Founder & Chief Executive Officer Liviu Hrenaru founded AERE Network with a single conviction: that the next generation of decentralised applications deserves infrastructure that is genuinely fast, honest about its capabilities, and built to last. His vision is an EVM-compatible Layer 1 that gives developers the full Ethereum tooling experience, MetaMask, Hardhat, ethers.js, Solidity, without the congestion and unpredictable fees that have held the ecosystem back. Under his direction, AERE Network launched its mainnet on Hyperledger Besu with QBFT consensus, achieving sub-second finality and a throughput ceiling of up to 273,000 transactions per second (a design target implied by the block parameters, never measured on mainnet, methodology at /benchmarks ), while maintaining complete EVM compatibility at Chain ID 2800. Liviu drives the network's product direction, ecosystem strategy, and the long-term mission of making on-chain interaction accessible, transparent, and economically viable for builders and end users alike. Core contributors Beyond the founder, AERE Network is developed and maintained by a distributed team of blockchain engineers, infrastructure specialists, and open-source contributors. The team spans protocol engineering, smart-contract development, DevOps and validator operations, and ecosystem support. Contributors work across time zones, collaborating in the open on git.aere.network . Individual contributor profiles and commit histories are visible in the public repositories. Mission Make fast, honest, EVM-compatible infrastructure available to every builder. AERE Network exists to close the gap between what the Ethereum developer ecosystem expects and what production infrastructure can actually deliver. We build in public, document our real capabilities, and never inflate numbers we cannot demonstrate on-chain. The long-term goal is a self-sustaining ecosystem, governed by its participants via the AERE DAO, funded through the Foundation treasury, and open to anyone who wants to build something real. Core values Transparency All protocol decisions, grant disbursements, and governance votes are recorded on-chain or in public Gitea issues. Nothing happens behind closed doors. Performance We build for real-world throughput, not benchmark conditions. QBFT consensus gives instant finality with no risk of reorgs on any honest transaction. Builder-first Developer experience is a first-class concern. If a standard Ethereum tool does not work on AERE without modification, that is a bug we fix, not a trade-off we accept. Join the team We are always interested in engineers, researchers, and ecosystem builders who want to work on live blockchain infrastructure. Open a conversation on Gitea or reach out through the community channels. View open repositories → --- # AERE Foundation URL: https://aere.network/foundation.html Fetched: 2026-08-16 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 nine validators today 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 and vested on a schedule governed by the DAO. 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 can vote on protocol upgrades, treasury disbursements, and ecosystem decisions through the AERE DAO. Governance is stake-weighted and fully on-chain. 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 → --- # Security, AERE Network URL: https://aere.network/security.html Fetched: 2026-08-16 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 hybrid form since block 14,050,000: no block finalizes without a quorum of Falcon-512 validator signatures, with classical secp256k1 ECDSA retained alongside under Hyperledger Besu QBFT. 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. It is a design ceiling implied by the block parameters under ideal conditions, not a measurement of chain 2800, and realized live throughput is a small fraction of it. What the live network delivers today is 0.5-second deterministic finality and sub-cent fees. The full methodology, with a scope label on every figure, is published on the benchmarks page at https://aere.network/benchmarks.html. How decentralized is AERE today? The validator set is nine Foundation-operated nodes, tolerating two faulty nodes at a quorum of six of nine. 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 at least six of nine Foundation-operated validators being honest, 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-08-16 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 a live oracle contract (AereOracle) that exposes a median price feed across multiple reporters, a requirement for any lending or derivatives protocol. A block explorer, a public RPC endpoint, and an on-chain indexer API 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 ↗ --- # Payments & Enterprise, AERE Network URL: https://aere.network/solutions-payments.html Fetched: 2026-08-16 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 as the settlement layer for consumer payment applications, including non-custodial crypto card neobanks. Card settlements, stablecoin transfers, and on-chain receipts settle on AERE mainnet, with instant finality and predictable fees. The chain is production infrastructure, not a testnet. 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 ↗ --- # Gaming on AERE Network URL: https://aere.network/solutions-gaming.html Fetched: 2026-08-16 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 ↗ --- # Institutions & Real-World Assets, AERE Network URL: https://aere.network/solutions-rwa.html Fetched: 2026-08-16 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 ↗ --- # NFTs & Digital Culture, AERE Network URL: https://aere.network/solutions-nft.html Fetched: 2026-08-16 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 ↗ --- # Infrastructure & Tooling, AERE Network URL: https://aere.network/solutions-infrastructure.html Fetched: 2026-08-16 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 Indexer API https://api.aere.network 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 reference indexer at api.aere.network that indexes logs, transactions, and token transfers. 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 AERE indexer 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 ↗ --- # Aere Network, Blog & Newsroom URL: https://aere.network/blog.html Fetched: 2026-08-16 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 Aere is the first public EVM Layer-1 with native NIST post-quantum signature verification live on mainnet Official press release, Monaco, 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) deployed on chain 2800. Users sign one intent, a competitive solver network delivers in ~30 seconds. No multi-step bridge UX. Permissionless solver participation. 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 accept signatures from the global validator network. No more 1-of-1 federated bridge. 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 --- # What is AERE Network?, AERE Blog URL: https://aere.network/blog-what-is-aere.html Fetched: 2026-08-16 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 Genesis v2: Correcting the Supply to 2.8 Billion, AERE Blog URL: https://aere.network/blog-genesis-v2.html Fetched: 2026-08-16 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 --- # Add AERE Network to MetaMask in 60 Seconds, AERE Blog URL: https://aere.network/blog-add-to-metamask.html Fetched: 2026-08-16 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. For larger amounts, AERE is available through the exchange and bridge routes listed on the main site. ← Back to Blog --- # Deploy Your First Smart Contract on AERE, AERE Blog URL: https://aere.network/blog-first-contract.html Fetched: 2026-08-16 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 --- # How AERE Validators Work, AERE Blog URL: https://aere.network/blog-validators.html Fetched: 2026-08-16 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 9 Foundation validators today (f=2, quorum 6-of-9), 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 --- # The 2.8 Billion AERE Supply, Explained, AERE Blog URL: https://aere.network/blog-tokenomics.html Fetched: 2026-08-16 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 --- # Why EVM Compatibility Matters, AERE Blog URL: https://aere.network/blog-evm-compatibility.html Fetched: 2026-08-16 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 Developer Grants: Build and Get Funded, AERE Blog URL: https://aere.network/blog-grants.html Fetched: 2026-08-16 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 MEV-resistant, batch-auction DEX live, AERE Blog URL: https://aere.network/blog-batch-auction-dex.html Fetched: 2026-08-16 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 with MEV-protected mode toggled on, 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 Academy, Learn to Build on AERE Network URL: https://aere.network/academy.html Fetched: 2026-08-16 AERE Academy, Learn to Build on AERE Network AERE Academy 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, staking rewards at 8% APY, 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 . --- # AERE Network Fundamentals, AERE Academy URL: https://aere.network/course-fundamentals.html Fetched: 2026-08-16 AERE Network Fundamentals, AERE Academy ← Back to AERE Academy AERE Network Fundamentals 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 ~1 second 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 = ⌊(2n/3)⌋ + 1 where n is the validator count), 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 base rate is 8% APY. 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 (8% APY), 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 --- # Deploy Your First Smart Contract, AERE Academy URL: https://aere.network/course-first-contract.html Fetched: 2026-08-16 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 ~1 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 --- # Run an AERE Validator, AERE Academy URL: https://aere.network/course-validator.html Fetched: 2026-08-16 Run an AERE Validator, AERE Academy ← Back to AERE Academy Run an AERE Validator 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 9 Foundation validators today (f=2, quorum 6-of-9), 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 7 validators today 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. Hyperledger Besu is the required client; 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 Tokenomics & Governance, AERE Academy URL: https://aere.network/course-tokenomics.html Fetched: 2026-08-16 AERE Tokenomics & Governance, AERE Academy ← Back to AERE Academy AERE Tokenomics & Governance 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 --- # AERE Bridge, Cross-Chain Transfer URL: https://aere.network/bridge.html Fetched: 2026-08-16 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) --- # AereSwap, V2 AMM on AERE Network URL: https://aere.network/swap.html Fetched: 2026-08-16 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). --- # AERE Network, Lending URL: https://aere.network/lending.html Fetched: 2026-08-16 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, the native token of AERE Network URL: https://aere.network/aereusd.html Fetched: 2026-08-16 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 → --- # AERE Yield Farm, LP staking · native AERE rewards URL: https://aere.network/farm.html Fetched: 2026-08-16 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) . --- # AereVesting, Linear vesting with cliff URL: https://aere.network/vesting.html Fetched: 2026-08-16 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 (foundation multi-sig) 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 --- # AereSubscriptions, Recurring on-chain payments URL: https://aere.network/subscriptions.html Fetched: 2026-08-16 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. --- # AereLaunchpad, Token launches on AERE URL: https://aere.network/launchpad.html Fetched: 2026-08-16 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 --- # AereInsurance, smart-contract exploit cover URL: https://aere.network/insurance.html Fetched: 2026-08-16 AereInsurance, smart-contract exploit cover 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) --- # AereAirdrop, Merkle airdrop claims URL: https://aere.network/airdrop.html Fetched: 2026-08-16 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. --- # AERE HTLC, Hashed Timelock Contracts URL: https://aere.network/htlc.html Fetched: 2026-08-16 AERE HTLC, Hashed Timelock Contracts 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 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 Payment Channels, Bidirectional State Channels URL: https://aere.network/channels.html Fetched: 2026-08-16 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 Lightning, Multi-Hop Routed Payments (Coming Soon) URL: https://aere.network/lightning.html Fetched: 2026-08-16 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 Lightning Channels, Off-chain payment channels with HTLCs URL: https://aere.network/lightning-channels.html Fetched: 2026-08-16 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 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-08-16 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 L2, Optimistic Rollup Deposit URL: https://aere.network/l2.html Fetched: 2026-08-16 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 . --- # AERE ZK Commitments, Real Groth16 Proofs On-Chain URL: https://aere.network/zk.html Fetched: 2026-08-16 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. Real ZK system on AERE Network. 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 Commitments contract 0x34F7b38dDC6b9d4f2ADC165AcF2b22B2349AA299 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, and because the network charges no base fee, on-chain verification is essentially free for users Proof generation runs in your browser via snarkjs.groth16.fullProve() , your secret never leaves this page --- # AERE ZK Rollup, State-transition validity proofs URL: https://aere.network/zk-rollup.html Fetched: 2026-08-16 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 costs no fees 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-08-16 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 Finality, a design for converting optimistic batches to validity-proof finality URL: https://aere.network/zk-finality.html Fetched: 2026-08-16 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 Name Service, Human-readable addresses on AERE URL: https://aere.network/names.html Fetched: 2026-08-16 AERE Name Service, Human-readable addresses on AERE 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. Registry overview AereNameService 0x0763e281…ECa18b272 Treasury (receives fees) 0x658dD2CD…2d192CaD1 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 1 AERE alice, satoshi 4 chars 10 AERE aere, neo 3 chars 100 AERE btc, dao 2 chars 1,000 AERE l1, vc 1 char reserved governance only All fees go to the AereTreasury (DAO-controlled, 2-day timelock on outflows). --- # AereMultiSig, M-of-N foundation wallet URL: https://aere.network/multisig.html Fetched: 2026-08-16 AereMultiSig, M-of-N foundation wallet 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 MultiSig, Live signer activity URL: https://aere.network/multisig-live.html Fetched: 2026-08-16 AERE MultiSig, Live signer activity 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) . --- # AERE Vote Delegation, Governance V2 URL: https://aere.network/delegate.html Fetched: 2026-08-16 AERE Vote Delegation, Governance V2 AERE Vote Delegation Home DAO Explorer Delegate Voting Power Coming soon, contract not yet deployed. The delegation contract is not live on chain 2800. Buttons below are disabled. Per whitepaper §4: AereGovernanceStaked uses staked-token voting power. This page will be activated once the delegation contract is deployed. Governance V2 Not yet deployed 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. --- # Universal Login, multi-key wallets, recovery, gasless onboarding, AERE Blog URL: https://aere.network/blog-universal-login.html Fetched: 2026-08-16 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 --- # AERE verifies zk proofs, SP1 + RISC Zero live, AERE Blog URL: https://aere.network/blog-zkverify.html Fetched: 2026-08-16 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 wallets via Touch ID / Face ID, passkey accounts live, AERE Blog URL: https://aere.network/blog-passkey.html Fetched: 2026-08-16 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 sub-second, 0.5s block time live, AERE Blog URL: https://aere.network/blog-subsecond.html Fetched: 2026-08-16 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 --- # AERE upgrades to Fusaka, native passkey signatures now on-chain, AERE Blog URL: https://aere.network/blog-fusaka.html Fetched: 2026-08-16 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 runs 7 Foundation-operated validators (f=2, quorum 5 of 7), and the average block interval over the last 2,000 blocks measured 0.517 s 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 --- # Coinbase splitter live: 37.5% validator-coinbase burn sealed on chain 2800, AERE Blog URL: https://aere.network/blog-burn.html Fetched: 2026-08-16 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 7 validators today, 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 --- # AERE upgrades to Pectra, EIP-7702 + BLS precompiles now live, AERE Blog URL: https://aere.network/blog-pectra.html Fetched: 2026-08-16 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 is now 7, all Foundation-operated (f=2, quorum 5 of 7), and the average block interval over the last 2,000 blocks measured 0.557 s when this was re-checked on 2026-08-10 (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 gasless, multi-paymaster stack live, AERE Blog URL: https://aere.network/blog-paymasters.html Fetched: 2026-08-16 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, enough to sponsor first-timer transactions for ~100,000 users at chain-level gas costs, with no automatic refill. After that, users have to use one of the other paths. 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. No major EVM chain has shipped this UX. We just did. 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. Their stake still earns its normal staking yield (via AereLockedStaking or sAERE). Daily transactions cost zero. They never see "approve gas fee" on a Face ID prompt. 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 goes intent-based, Across SpokePool + ERC-7683 live, AERE Blog URL: https://aere.network/blog-intents.html Fetched: 2026-08-16 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 pays developers, Fee Monetization live, AERE Blog URL: https://aere.network/blog-fee-monetization.html Fetched: 2026-08-16 AERE pays developers, Fee Monetization live, AERE Blog Engineering · Tokenomics AERE pays developers, Fee Monetization live 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 live, all on chain, all permissionless. ← Back to all posts --- # AERE goes verifiably random, drand beacon live, AERE Blog URL: https://aere.network/blog-randomness.html Fetched: 2026-08-16 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 pull-oracle, industry-standard price feeds live, AERE Blog URL: https://aere.network/blog-pyth.html Fetched: 2026-08-16 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 cross-chain, Hyperlane-compatible messenger live, AERE Blog URL: https://aere.network/blog-bridge.html Fetched: 2026-08-16 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 --- # Research & Papers | Aere Network URL: https://aere.network/papers.html Fetched: 2026-08-16 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: 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 --- # For Regulated Finance | Aere Network URL: https://aere.network/for-regulated-finance.html Fetched: 2026-08-16 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 three per block. Five NIST post-quantum verifiers run as native precompiles. Since block 14,050,000, consensus does not finalize a block without post-quantum validator signatures. 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 block 14,050,000, consensus on chain 2800 does not finalize a block without post-quantum (Falcon-512) validator signatures; classical ECDSA seals remain alongside. All nine 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 npm install @noble/hashes curl -O https://aere.network/tools/verify-anchor.mjs 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 --- # The Post-Quantum Stack | Aere Network URL: https://aere.network/quantum-stack.html Fetched: 2026-08-16 The Post-Quantum Stack | Aere Network 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 switch after which no block finalizes without post-quantum signatures. 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, and certificates in practice carry five, the configured cap. 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 block-height switch after which no block finalizes without post-quantum signatures. The blocking post-quantum quorum went live fleet-wide at block 14,050,000, a single coordinated activation height, aere.falcon.forkBlock. Before it, consensus signatures were 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. Nine keyed validators give the layer a real fault margin (f=2), 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. Live · since block 14,050,000 · quorum 6 of 9 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 --- # Post-Quantum Notarization | Aere Network URL: https://aere.network/notarization.html Fetched: 2026-08-16 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, at an enforced minimum of three per block. 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 anchoring mechanism is real and running: this network's own whitepaper re-anchors its content hash on a fresh block several times a day, and that anchor is publicly verifiable right now. What a customer engagement builds on top of it is the productised path: a per-document API with authentication and billing, a verification page your counterparties can use, and a signed conformance report. We would rather tell you what is a working mechanism versus what is a delivery than dress a roadmap as a product. Verify an anchor yourself npm install @noble/hashes curl -O https://aere.network/tools/verify-anchor.mjs node verify-anchor.mjs # the same tool that checks a document anchor checks the # chain's own post-quantum certificate: 20/20 blocks bound. 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 --- # Quantum-Safe Settlement | Aere Network URL: https://aere.network/quantum-safe-settlement.html Fetched: 2026-08-16 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 32nd block 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. 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 block 14,050,000 consensus on chain 2800 does not finalize a block without post-quantum (Falcon-512) validator signatures, with classical ECDSA retained alongside; 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 npm install @noble/hashes curl -O https://aere.network/tools/verify-anchor.mjs 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. 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 --- # Base Fee Floor | Aere Network URL: https://aere.network/glossary/base-fee-floor.html Fetched: 2026-08-16 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 nine validators that run QBFT consensus, where a block needs a quorum of six 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, so it can never 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-08-16 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 nine validators with a quorum of six. 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 5, the configured cap. 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-08-16 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 nine validators running a fork of Hyperledger Besu under QBFT consensus, with a quorum of six 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-08-16 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 nine validators , with a quorum of six. 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-08-16 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 5, the configured cap. 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-08-16 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 six of nine 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 nine validators and a quorum of six: once six 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-08-16 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 5, the configured cap. 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-08-16 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-08-16 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: nine validators, a quorum of six, 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 nine validators and a quorum of six, 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 nine 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-08-16 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 5, the configured cap. 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-08-16 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 nine 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-08-16 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 nine validators and a block roughly every 500 ms. A block is committed only when six of the nine 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 chain 2800 post-quantum conformance evidence (sample report) URL: https://aere.network/tools/sample-conformance-report.html Fetched: 2026-08-16 AERE chain 2800 post-quantum conformance evidence (sample report) SAMPLE REPORT · REAL MEASUREMENTS AERE chain 2800: post-quantum conformance evidence generated 2026-08-15T10:02:54.806Z · endpoint https://rpc.aere.network · 611 read-only RPC calls in 28.5s · every number below was measured by the toolkit, none written by hand 35 PASS 0 FAIL 5 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 4 · 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.5 .. 0.55 s 0.5325 .. 0.5325 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.05000 s PASS interval.imprastiere the 4 windows disagree by 0.00000 s, so the rate is quoted as +/- 0.00050 s, dominated by timestamp quantisation; with that margin included the figure still fits inside the declared band, so one number honestly describes this sample 0.5 .. 0.55 s 0.53200 .. 0.53300 s PASS interval.viata-nu-este-acum the genesis-to-head lifetime average is a DIFFERENT number from the current rate, so the current rate must never be published as the chain's lifetime speed different different 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 9 9 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*9/3) = 6) >= 6 6..6 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 9 9 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,0xdf09b32c761620c5be77da398b97a64f03c3980c,0xe13aa491abbc1252dd714e7ca0e55717a2143eaf,0xf73bbbd26a82dbc769066550d8d4585eab2fc00d 0x1bd5514286f5602a6762b0075266379d29af1c9d,0x4bf6f91d84b37454544279cba152581ed6820044,0x5f50fc4e1b129bbd5e6e9f80c57680b0b4a86eb0,0x97473985d04723299559f49b856effb47d7abfad,0xb5e768cb3117ea25175f51aa956b48691025c2a8,0xc3314fd768bb68b986e80c0a14175f6f72630d7a,0xdf09b32c761620c5be77da398b97a64f03c3980c,0xe13aa491abbc1252dd714e7ca0e55717a2143eaf,0xf73bbbd26a82dbc769066550d8d4585eab2fc00d PASS validatori.cine-le-opereaza who operates these seven 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. 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 611 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". --- # Solutions | Aere Network URL: https://aere.network/solutions.html Fetched: 2026-08-16 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 block 14,050,000 no block finalizes without post-quantum validator signatures. 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 32nd header. 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 nine validators are operated by the Foundation today; 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 --- # Payments That Stay Settled | Aere Network URL: https://aere.network/payments.html Fetched: 2026-08-16 Payments That Stay Settled | Aere Network Solutions Payments That Stay Settled Payments Deterministic finality Chain 2800 Updated 2026-08-15 Hybrid consensus since block 14,050,000 3 min read A payment on chain 2800 is final in about half a second, there is no reorg to undo it, and since block 14,050,000 it settles 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 six of nine validators signs it, about half a second after your transaction enters it (block time measured at 0.53 s today), 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 six of nine 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 Since block 14,050,000, consensus on chain 2800 is hybrid: no block finalizes without a quorum of Falcon-512 post-quantum validator signatures, with classical ECDSA retained alongside. On top of that, every 32nd block header carries a certificate of validator Falcon seals bound under the block hash, live since block 13,014,000 and enforced at a minimum of three seals since 2026-08-14. 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 nine validators are operated by the Foundation today. 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 npm install @noble/hashes curl -O https://aere.network/tools/verify-anchor.mjs 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 --- # Real-World Asset Tokenization | Aere Network URL: https://aere.network/real-world-assets.html Fetched: 2026-08-16 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 Post-quantum quorum since block 14,050,000 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 six of nine validators signs it, and the QBFT consensus produces no reorganizations by design. Blocks arrive about every half second, 0.53 seconds as measured today. For an asset registry this means a transfer is settled when it is included, and it stays settled. Since block 14,050,000, consensus is hybrid: no block finalizes without a quorum of Falcon-512 post-quantum validator signatures, with classical ECDSA retained alongside. Before that, since block 13,014,000, every 32nd header has carried a certificate of validator Falcon seals bound under the block hash itself, with a minimum of three seals enforced since 2026-08-14. 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 nine validators are operated by the Foundation today. 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 npm install @noble/hashes curl -O https://aere.network/tools/verify-anchor.mjs 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 --- # Press Release: Aere Network Activates Hybrid Post-Quantum Consensus on Its Public Mainnet URL: https://aere.network/press-release-full-quantum.html Fetched: 2026-08-16 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 Monaco, August 15, 2026 Monaco, 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. Block 14,050,000 completed the arc: the post-quantum quorum became consensus-blocking, so a block without it does not finalize at all. 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 . --- # Pressemitteilung: Aere Network aktiviert hybriden Post-Quanten-Konsens auf seinem öffentlichen Mainnet URL: https://aere.network/press-release-full-quantum.de.html Fetched: 2026-08-16 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 Monaco, 15. August 2026 Monaco, 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-08-16 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 Monaco, 15 de agosto de 2026 Monaco, 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-08-16 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 Monaco, le 15 août 2026 Monaco, 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 . --- # 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-08-16 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 Monaco, 15 agosto 2026 Monaco, 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-08-16 プレスリリース:Aere Network、パブリックメインネットでハイブリッド耐量子コンセンサスを有効化 プレスリリース Aere Network、パブリックメインネットでハイブリッド耐量子コンセンサスを有効化 報道関係各位 Monaco、2026年8月15日 Monaco、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-08-16 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 Monaco, 15 de agosto de 2026 Monaco, 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 . --- # Independent Validator Program | Aere Network URL: https://aere.network/run-a-validator-program.html Fetched: 2026-08-16 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 nine 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 a block without Falcon-512 validator signatures, live since block 14,050,000; a certificate of those signatures bound under the block hash every 32 blocks; 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 --- # quantum-exposure-report.html URL: https://aere.network/quantum-exposure-report.html Fetched: 2026-08-16 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. 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.