AERE Network's security posture, consensus guarantees, on-chain safeguards, infrastructure hardening, and how to report a vulnerability.
AERE Network runs the QBFT (Quorum Byzantine Fault Tolerant) consensus algorithm on two independently built clients, a Hyperledger Besu fork on nine of the ten validators and a Nethermind fork on the tenth. QBFT provides:
Instant finality on the validators. For a validator a block is final the moment it is included: there are no probabilistic confirmations and no reorg risk. From block 25,080,000 (AIP-22 stage 5) a node that does not take part in consensus, such as the public RPC endpoints, admits a header between anchors on the Falcon-512 seal of its proposer alone, so until the next anchor the blocks above its finalized block, including blocks it has already shown, can be replaced by a branch that the key of a single validator builds (such a node keeps the total-difficulty fork choice of the upstream client; the rule that never leaves a decided block runs on the validators only); for settlement, read the finalized or safe block, which moves only on an anchor certificate that the key of one validator cannot produce (derived from the code; measured on the rehearsal network 28099 with a classical-only fork, AIP-22 record of 2026-09-27: such a node followed the fork up to the block before the next anchor and moved to the anchored chain once linked to an honest validator; not measured: the same with a post-quantum key from stage 5, and whether a node started from the published package, with its seal ceiling at 1, answers these tags the same way); that is the one wait before treating a transaction as settled, not a count of block confirmations.
Byzantine fault tolerance. The network tolerates up to ⌊(n−1)/3⌋ faulty or malicious validators without compromising the safety or liveness of consensus (a node that does not take part in consensus is covered in the next card), where n is the total validator count.
Unlike proof-of-work chains where the "longest chain" rule allows forks and reorgs, QBFT validators reach explicit agreement before a block is committed, so on a validator a transaction in a committed block cannot be reversed by a competing chain tip. From block 25,080,000 (AIP-22 stage 5) a node that does not take part in consensus, such as the public RPC endpoints, admits a header between anchors on the Falcon-512 seal of its proposer alone, so until the next anchor the blocks above its finalized block, including blocks it has already shown, can be replaced by a branch that the key of a single validator builds (such a node keeps the total-difficulty fork choice of the upstream client; the rule that never leaves a decided block runs on the validators only); for settlement, read the finalized or safe block, which moves only on an anchor certificate that the key of one validator cannot produce (derived from the code; measured on the rehearsal network 28099 with a classical-only fork, AIP-22 record of 2026-09-27: such a node followed the fork up to the block before the next anchor and moved to the anchored chain once linked to an honest validator; not measured: the same with a post-quantum key from stage 5, and whether a node started from the published package, with its seal ceiling at 1, answers these tags the same way).
This makes AERE Network suitable for applications that need strong settlement guarantees, payments, on-chain records, cross-chain bridges: what they wait for, from block 25,080,000, is the finalized block, at most one anchor interval (32 blocks, about 20 seconds) behind the head, not a confirmation depth.
The AereSecurity contract at 0xaD305e…daC44 exposes security records that other contracts and off-chain systems can read. Whether it is being updated is visible in its transactions on the explorer; this page does not claim that it carries live data.
All interactions with this contract are publicly visible on the AERE Explorer.
Yes, since block 25,080,000 (AIP-22 stage 5), in this sense: headers no longer carry ECDSA commit seals and, since block 24,300,000 (AIP-22 stage 4), every vote counts only with the verified post-quantum seal of its author, and a commit still carries the ECDSA commit seal of its validator as an additional check. It has three limits: the transport between nodes is still authenticated by secp256k1, the ten validators are run by one operator, and no third party has audited it yet. A node that does not take part in consensus admits a header between anchors on the Falcon-512 seal of its proposer alone, so the post-quantum key of one validator can serve such a node a branch up to the block before the next anchor (below block 25,080,000 that took the ECDSA keys of a quorum), and the next anchor ends it for a node that requires the seals of a quorum in its certificate (the published follower, with its seal ceiling at 1, is not such a node: for it one leaked or misused post-quantum key of a validator makes the rewrite depth unbounded, section 6.4 of the aere-node SPEC). The anchor certificate it builds on dates from 2026-08-14: every 32nd block (every 128th from block 17,225,968 to block 20,746,736, 2026-09-05 to 2026-09-29) (an anchor block) does not finalize without a certificate of at least three valid Falcon-512 validator seals (f+1 of the nine validators of that time) (raised at block 14,961,456, August 21, 2026, to six seals, then as many as the QBFT quorum of nine; from 2026-09-11 the set was ten and six sat above f+1 but below its quorum of seven, until block 20,715,632, on 2026-09-29, raised the enforced minimum to seven, as many as the quorum of the ten validators) under its hash, with QBFT, run on a Besu-derived client at nine validators and on a Nethermind-derived client at the tenth since 2026-09-11, finalizing every block (corrected 2026-08-19: not a per-block quorum; corrected 2026-10-27: this said Hyperledger Besu QBFT), its votes attributed by every validator, since block 24,300,000 (AIP-22 stage 4), only through their verified post-quantum seals (since block 25,080,000, AIP-22 stage 5, headers no longer carry ECDSA commit seals and are admitted on the Falcon-512 seal of their proposer alone; a commit still carries the ECDSA commit seal of its validator as an additional check). 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 post-quantum message and anchor layers of consensus is still ahead.
No, and it has been withdrawn (2026-09-05): it was a design ceiling implied by the block parameters under ideal conditions, never a measurement of chain 2800, and its stated derivation does not reach that number. What the live network delivers today is sub-second deterministic finality on the validators (0.620 s blocks measured on 2026-10-15) and a 1 gwei base fee; measured throughput is published with its date and method on the benchmarks page at https://aere.network/benchmarks.html.
The validator set is Foundation-operated (10 nodes as read from the chain at 2026-11-01 19:45 UTC), tolerating 3 faulty nodes at a quorum of 7 of 10. The network is not yet decentralized. The published path admits independent operators and grows the set from ten toward twenty-one. Since 2026-09-11 the validator set runs two client implementations, nine Hyperledger Besu and one Nethermind, both sealing live blocks; a consensus fault in Besu would still stop the chain, so this is not client diversity in the fault-tolerance sense.
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.
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 on a Besu-derived node, such as the public RPC endpoints, and the node itself returns that activation time and the live precompile list; the eth_config of the second client does not list the Aere precompiles yet (measured 2026-10-27), so there call a precompile itself. 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.
There is no public way to obtain AERE right now. There is no public sale and no exchange listing, and the mainnet faucet was closed on 2026-10-15. A new address can add the network and make read-only calls, but it cannot yet send a transaction that needs gas.
Neither. It is trust-minimized: its security reduces to a QBFT quorum of Foundation-operated validators being honest (six of nine at its deployment; since the validator set grew to ten on 2026-09-11 it verifies only blocks sealed by that earlier set, and from block 20,836,228 (AIP-22 stage 3) headers name validators by post-quantum ids that its guest program cannot match, so re-anchoring alone does not restore it, and since block 25,080,000 (AIP-22 stage 5) headers no longer carry ECDSA commit seals either; a light client would have to verify the anchor certificates directly instead (AIP-22, Backwards Compatibility; rehearsed on testnet 28001 on 2026-09-26, not deployed on chain 2800); this sentence corrected on 2026-10-26), 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.
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:
Please allow reasonable time for triage and patching before any public disclosure. We commit to acknowledging reports within 5 business days.
Contact paths:
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.