AERE Network's security posture, consensus guarantees, on-chain safeguards, infrastructure hardening, and how to report a vulnerability.
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.
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.
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.
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.
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.
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.
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.
Yes, in a hybrid and limited form since 2026-08-14: every 128th block (every 32nd block until block 17,225,968, on 2026-09-05) (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 a full 2f+1 quorum of nine; since the set grew to ten on 2026-09-11 the enforced minimum is still six, above f+1 but below the ten-validator quorum of seven) under its hash, with classical secp256k1 ECDSA finalizing every block under Hyperledger Besu QBFT (corrected 2026-08-19: not a per-block quorum). 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.
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 0.5-second deterministic finality and sub-cent fees; measured throughput is published with its date and method on the benchmarks page at https://aere.network/benchmarks.html.
The validator set is ten Foundation-operated nodes (since 2026-09-11), tolerating three faulty nodes at a quorum of seven of ten. 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.
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 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.
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.
Neither. It is trust-minimized: its security reduces to a 2f+1 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 until it is re-anchored), 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.