Network

The Post-Quantum Stack

Chain 2800Verifiable
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 1Live

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 2Live

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 3Live

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 4Live

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 5Armed

Consensus finality

A block-height switch after which no block finalizes without post-quantum signatures.

The blocking post-quantum quorum is armed fleet-wide behind a single coordinated activation height, aere.falcon.forkBlock. Before it, consensus signatures are classical ECDSA under QBFT, and this page says so. At and after it, the finality of every block depends on a certificate of validator Falcon signatures: a node presented with a block that lacks one will not accept it. Nine keyed validators give the layer a real fault margin (f=2), which is why the arming guard refuses a smaller set. This page will state the switch as live only once the chain itself shows it.

Armed · activates at block 14,050,000 · quorum 6 of 9

Layer 6Validating

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