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 32nd block (an anchor block) does not finalize without a certificate of at least three valid Falcon-512 validator seals (f+1 of nine) (raised at block 14,961,456, August 21, 2026: the enforced minimum is now six of nine, a full 2f+1 quorum) 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. It is a design ceiling implied by the block parameters under ideal conditions, not a measurement of chain 2800, and realized live throughput is a small fraction of it. What the live network delivers today is 0.5-second deterministic finality and sub-cent fees. The full methodology, with a scope label on every figure, is published on the benchmarks page at https://aere.network/benchmarks.html.
The validator set is nine Foundation-operated nodes, tolerating two faulty nodes at a quorum of six of nine. 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 at least six of nine Foundation-operated validators being honest, 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.