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.
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.