From a Layer 1 to cryptographic infrastructure.
Dated 2026-09-27Live, building, end stateChain 2800
AERE Network started as a public EVM Layer 1 with half-second finality. The chain is the vehicle, not the destination: what is being built on it is a set of cryptographic services, post-quantum by construction and checkable by anyone, that do not ask you to trust the operator. This page keeps what is live apart from what is being built and from where it ends, and dates each line.
Livemeasurable today on mainnet (chain 2800), on the public testnet (chain 28001) or in Aere Cloud; the line says which.
Buildingthe code exists and is proven in the lab or on the public testnet; it is not on mainnet.
End statewhere the component is going; not built, and not claimed.
01
Settlement
One public chain, final in half a second.
LiveChain 2800, a public EVM Layer 1 with deterministic 0.5-second finality and 2,800,000,000 AERE fixed at genesis-v2 (2026-05-07). Ten Foundation-operated validators since 2026-09-11 (f=3, quorum 7 of 10; nine until then).
BuildingThe independent-operator program: named organisations running validators on infrastructure the Foundation does not control, on the path to 21. Today one party can stop the chain, and this program is the only thing that changes that number.
End stateA settlement layer that no single organisation can stop or rewrite.
02
Consensus with post-quantum seals
Seals under the hash, on every message.
LiveEvery validator refuses a commit without a valid post-quantum seal of its author, and nine of the ten refuse any consensus message without one: the nine validators that run the primary, Besu-derived client since 2026-09-08 (commits since 2026-09-05), while the tenth, which runs the independent second, Nethermind-derived client, has refused unsealed commits since 2026-09-11 and applies the rule to proposal, prepare and round-change messages from AIP-22 stage 4, whose height is not yet set on chain 2800. Every 32nd block carries a certificate of at least seven Falcon-512 validator seals under its own hash, as many as the quorum of the ten validators (the seals prove those validators signed the block, not that it was decided, per the AIP-22 erratum of 2026-10-01), and every 128th block SLH-DSA-SHA2-128s seals as well (six per scheme at every 128th block until 2026-09-29); since 2026-09-30 the validators are named in consensus by post-quantum ids, and since 2026-09-27 the
finalized and safe tags point at the parent of the last certified anchor. Per-block finality rests on classical ECDSA. (Corrected 2026-10-09: until that date this line said that since 2026-09-05 no consensus message is accepted without such a seal; that date is the commit layer's alone, and the second client's exception was missing.)
BuildingAIP-22, the block header without ECDSA (post-quantum identity, finality and header): stages 1 to 6 proven on the public testnet, chain 28001, on 2026-09-23; on chain 2800 stages 1 to 3 are live (the quorum threshold and the 32-block Falcon-512 grid since 2026-09-29, post-quantum validator ids since 2026-09-30), and the heights of stages 4 and 5 (per-block post-quantum finality, the header without ECDSA) are a Foundation decision; the finality those stages define needs the post-quantum commit seal to bind the consensus round first (AIP-22 erratum, 2026-10-01). Compact post-quantum certificates, constant in size whatever the validator count, are the open research problem on this path.
End stateFinality decided by post-quantum signatures alone, with key rotation by epoch and no hard fork (rotation by epoch was proven on chain 28001 on 2026-09-23).
03
Post-quantum transactions and accounts
A transaction type that does not depend on ECDSA.
LiveNative post-quantum transactions (type 0x50, authorized by an ML-DSA signature of FIPS 204, AIP-20) accepted on mainnet since block 19,900,000 (2026-09-23). Post-quantum verifier precompiles live since block 9,189,161. An open-source signing library, sdk-pq-sign, in the repository.
BuildingAccount and wallet tooling that makes the post-quantum transaction the default path rather than the expert path.
End stateAccounts secured by post-quantum keys by default, with the classical path kept for compatibility only.
04
Verifiable execution
Do not trust the executor. Check the proof.
LiveSP1 proof verifiers on chain: a validity rollup proof of concept over a bounded VM, and a trust-minimized ZK light client anchored to the validator set it was deployed against on 2026-07-16.
BuildingA validity proof per block or batch. Chain 2800 has 2 recorded validity proofs over its first 13.3 million blocks, and the gap is printed in the daily security score. Falcon-512 verification inside a zkVM measured at 2.965 million cycles on 2026-09-26; a proving machine with 24 GB of memory is the next step.
End stateEvery block or batch carries a proof, and a phone can check that the chain executed correctly without re-executing it.
05
Proofs and notarization
Pin a fact to a certified block. Let anyone check it.
LiveProof of Software, a reproducible attestation of the exact bytes a node runs (1.1.0, 2026-09-18). The Proof API in Aere Cloud. AIP-23, published 2026-09-27: a proof that a record existed before a post-quantum-certified block, checked by
verify-proof.mjs against the anchor certificate; the notary contract is live on the public testnet.
BuildingThe notary on mainnet (one Foundation transaction), and the proof formats published as one named open standard.
End stateAny record, anywhere, pinned to a post-quantum-certified block and checkable by anyone, with no account at AERE.
06
Cryptographic infrastructure for organisations
The verification layer over any cloud.
LiveAere Cloud since 2026-08-23: managed RPC and chain data, post-quantum verification APIs, a post-quantum readiness scanner and domain perimeter, a security command center with six measured checks, and an audit log whose daily digest is notarized. Priced in USD. Aere Quantum, open source since 2026-09-29: self-hosted post-quantum key management, a private certificate authority for ML-DSA certificates, a TLS 1.3 gateway with hybrid key exchange, a cryptographic inventory and the control plane that ties them together; no third party has reviewed them.
BuildingHardware-backed key storage for the key service, and an external review of the Aere Quantum components. (Until 2026-09-29 this line listed the key service, the certificate authority and the gateway as built and not yet published.)
End stateA verification layer you run over your own cloud: keys, certificates, transport and audit that are post-quantum and provable, without moving your compute.
07
Identity and machine payments
Agents that pay, sign and prove.
LiveMachine payments over HTTP (x402) with a facilitator on the public testnet, chain 28001, since 2026-09-02. Post-quantum validator identity on the public testnet (AIP-22 stage 3, 2026-09-23).
BuildingOn-chain post-quantum identity for accounts and AI agents, and notarized provenance for what an agent did and when.
End stateAn agent that pays, signs and proves with post-quantum keys, and whose actions anyone can audit.
08
Verification for everyone
Check, do not trust.
LiveThe public verifier checks every Falcon-512 and SLH-DSA seal under the hash of the latest anchors. verifiable-claims.json ships with a checker that prints PASS or FAIL. A daily security score with published formulas, including what is not audited. A live benchmark every six hours, with its caveats printed next to the numbers.
BuildingLight clients for phones and browsers that verify the chain without a full node.
End stateVerification is the default on every device, and "trust us" never appears in the documentation.
Four verbs
Execute. Prove. Verify. Settle.
- Execute on a public chain that is final in half a second.
- Prove what ran and what happened, with post-quantum signatures under the block hash.
- Verify from anywhere, with published tools and no account.
- Settle under rules that do not change under you.
What this is not, yet
- Not decentralized: ten Foundation-operated validators since 2026-09-11; one party can stop the chain, and the Nakamoto coefficient is 1.
- Not audited externally: zero external security audits of the contracts and of the client modifications; the daily security score says so.
- Not client-diverse in the fault-tolerance sense: nine of the ten validators run Besu, so a consensus fault in Besu would still stop the chain.
- Not busy: usage is low, and every throughput figure on this site is measured, not designed (the 273,000 TPS figure was withdrawn on 2026-09-05).
- Not universal: that word belongs to the end state on this page, not to today.
Check the live lines
curl -O https://aere.network/tools/verify-anchor.mjs -O https://aere.network/tools/mpt.mjs -O https://aere.network/tools/falcon512.mjs -O https://aere.network/tools/registry-v3.mjs -O https://aere.network/tools/package.json && npm install node verify-anchor.mjs curl -s https://aere.network/verifiable-claims.json | head -c 600