Public EVM Layer 1 · Chain ID 2800 · Live

AERE Network: a live post-quantum signature, on a public EVM Layer 1 (Chain ID 2800)

What it is. AERE is a public blockchain that runs ordinary Ethereum applications, and it is the first one where an account or a contract can require a NIST post-quantum signature, verified by the network itself. Five native PQC precompiles (Falcon-512, Falcon-1024, ML-DSA-44, SLH-DSA) have been active on chain 2800 since block 9,189,161, proven by a real Falcon-1024 signature recorded on-chain.

Why it matters. The signatures guarding almost every coin and contract in existence rest on mathematics that a large enough quantum computer undoes. Anything recorded today can be captured today and opened later. On AERE the defence is not a promise of a future upgrade, it is a signature the live network already verifies. What we do not claim: that every block is post-quantum final: per-block finality rests on classical ECDSA QBFT, with post-quantum validator seals required on every consensus message and anchor block, and every claim below points to a block, a contract, or a command you can run yourself. Loading the full interactive experience.

AERE runs Hyperledger Besu with QBFT consensus and 0.5-second deterministic finality, no re-orgs by construction. Its monetary policy is anchored in immutable code: 37.5% of the validator reward is burned (a Foundation-set rate, hard-capped at 50%) into a burn vault with no admin and no withdrawal path and the owner-less AereSink flywheel, and supply is fixed at 2,800,000,000 AERE with zero mint. Nobody holds a key that can print more, and nobody holds a key that can empty the vault, because no such key was ever written. The previously published 273,000 TPS design ceiling has been withdrawn; today the network delivers 0.5s finality and sub-cent fees. Settlement, fixed in code.

Live in production on chain 2800

Verify it yourself

# chain identity
curl -s https://rpc.aere.network -H 'content-type: application/json' \
  -d '{"jsonrpc":"2.0","id":1,"method":"eth_chainId","params":[]}'
Expect "0xaf0", which is 2800.
# the validator set, counted rather than described
curl -s https://rpc.aere.network -H 'content-type: application/json' \
  -d '{"jsonrpc":"2.0","id":1,"method":"qbft_getValidatorsByBlockNumber","params":["latest"]}'
Returns the validators at the current head: post-quantum validator ids since block 20,836,228, ECDSA addresses before it. On 2026-10-01 that array has 10 entries. Count them, and believe the chain rather than this sentence.
# the contracts named above carry code
curl -s https://rpc.aere.network -H 'content-type: application/json' \
  -d '{"jsonrpc":"2.0","id":1,"method":"eth_getCode","params":["0x696afDF4f814e6Fd6aa45CE14C498ed9375fB2c6","latest"]}'
Repeat with 0x79735c31F289F7A4d6Be3E02aaB70B544796D41d, 0x3A097A459FD26aC79573aCB5adB51430e473C2f1 and 0x69734E4044B1C5943B9256A73De41B101BFA2633. Each returns deployed bytecode, not 0x.

Method note. A precompile is not a contract and has no bytecode, so eth_getCode on a precompile address returns 0x either way. Absence of code is not absence of capability. The real test is a call with a known-good NIST vector and a second call with a corrupted one, so that a pass can be distinguished from a verifier that always says yes. Vectors, addresses and encodings are in the whitepaper and the documentation.

Where the network is going

Every item on the roadmap is asked one question: does it make the network singular, or only faster? Anyone with money and engineers can buy faster. Singular has to be built. When the two compete for the same people, singular wins. We publish no dates, we finish one thing before starting the next, and nothing counts as finished without a measurement whose test was shown able to fail.

Makes the network singular

Where the effort goes first.

  • Post-quantum protection carried deeper into the protocol. Today post-quantum seals are required on every consensus message and in a certificate under every anchor block's hash, and accounts and contracts can require them, which is where they are useful to you first; per-block finality still rests on classical ECDSA. The direction is to make every block's finality rest on post-quantum signatures, so the network's own agreement rests on them.
  • Post-quantum finality, end to end. Since 2026-08-14 the agreement between validators is hybrid in a limited sense: every anchor block, every 32nd block (every 128th from block 17,225,968 to block 20,746,736, 2026-09-05 to 2026-09-29), must carry under its hash a certificate of at least seven validator Falcon-512 seals, 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 at least seven SLH-DSA seals as well (the minimum was three until block 14,961,456, on 2026-08-21, and six until block 20,715,632, on 2026-09-29; SLH-DSA was required at every anchor from 2026-09-04 to 2026-09-29), and since 2026-09-05 every consensus message must carry a valid Falcon-512 seal of its author, while each block is still committed with classical ECDSA seals. We state exactly that rather than letting a reader assume more. The direction covers validator signatures, node-to-node authentication, checkpoints, light clients and bridges. Making that finality post-quantum needs the post-quantum commit seal to bind the consensus round first (AIP-22 erratum, 2026-10-01). Not quantum-ready. Quantum-native.
  • An execution kernel, not a single engine. The chain becomes a kernel able to host more than one virtual machine, the EVM first and room for others such as RISC-V, while consensus and the state model do not change. That last clause is the point of the design, not a footnote to it.
  • A cryptographic abstraction layer. A wall socket lets you change the appliance without rewiring the house. This does the same for signature algorithms: protocol, then interface, then algorithm, so that when the standards move the protocol does not have to be rebuilt to follow them.
  • A proof of correct execution at every block. Each block carries a compact proof that its transactions ran correctly, produced by default rather than on request. That changes what the chain guarantees, not only how fast it delivers.

Makes the network faster

Real value, none of it changes the category. It follows the column on the left.

  • Parallel execution and a fully parallel commit path, with conflicts predicted before they cost anything.
  • A faster state and storage engine, new multi-layer caching, and a rewritten RPC layer.
  • Consensus timing, block building and the transaction queue tuned to real traffic instead of averages.
  • A modern networking stack, hardware-aware scheduling, and hardware acceleration for post-quantum verification.
  • Lighter light clients, wider signature aggregation, and mathematical proof of the invariants that protect funds and liveness.

The road to full decentralization

The network runs on Foundation-operated validators today (10 as read from the chain at 2026-10-02 21:30 UTC). You can read that number straight off the chain with the second command above, and we would rather you did. Full decentralization of the validator set is the declared direction of this network, written here so it can be held against us.

One honest detail, of the kind usually left out. Seven is not a ceiling on ambition, it is a measured engineering choice for this stage: at seven, the fault margin protecting the network is the same margin a larger set would give. Choosing the simpler configuration at equal safety is not a retreat from decentralization, it is how the work that gets us there stays affordable.

We publish no date. A date we have not earned is not a commitment, it is a slogan. What we publish instead is each step, when it is proven, with the measurement attached, and the call above will show a change before any copy on this page does.

Read the whitepaper and key links

The whitepaper (2026 edition) is the full technical specification, published as a web document and as a downloadable PDF. The PDF is re-rendered from the same source as the web edition whenever that source changes, so the copy you download matches the edition on the site.

RPC endpoint: https://rpc.aere.network (Chain ID 2800).