AERE settles in half a second with mathematical finality. The consensus is sound. The operator set is not yet wide enough — and we are recruiting the independent organizations who will change that.
AERE runs on three verification nodes, and all three are operated by the AERE Foundation. That is centralized operation of a sound protocol, and we will not dress it up as anything else. With three nodes, QBFT consensus keeps every block consistent and final — but the failure of a single node pauses block production until it returns, and institutional reviewers correctly treat a one-operator set as a single point of trust.
This program exists for exactly one reason: to move the network from 3 Foundation-operated nodes to 7 independently operated nodes, with named, publicly identified organizations running infrastructure the Foundation does not control — and from there to 21.
qbft_getValidatorsByBlockNumber on rpc.aere.network · see the live consensus state →AERE is an EVM network running QBFT consensus — a Byzantine-fault-tolerant protocol in which a fixed set of identified nodes takes turns proposing blocks and collectively signs each one before it is accepted. There is no probabilistic settlement and no reorganization window: once a block carries a quorum of signatures, it is final. At AERE's cadence, that happens every 0.5 seconds.
As an operator, your node:
Protocol documentation calls these nodes validators. There is no token-stake bond and no stake-based selection in the current phase — membership is by identity and vote, which is why we select operators the way we do (below).
A verification node is a single Hyperledger Besu instance. The requirements are modest by design — the point of this program is operator diversity, not exotic hardware.
| Component | Minimum | Recommended |
|---|---|---|
| CPU | 4 vCPU (x86-64) | 8 vCPU, dedicated cores |
| Memory | 16 GB RAM | 32 GB RAM |
| Storage | 500 GB NVMe SSD | 1 TB NVMe SSD (headroom for growth) |
| Network | 100 Mbps, static public IP | 1 Gbps, static public IP |
| OS | Linux (Ubuntu 22.04/24.04 LTS or equivalent), Java 21 or the official Besu container image | |
| Operations | Your own infrastructure or your own cloud account — not Foundation-provisioned. Monitoring with alerting. A reachable on-call contact. | |
Sub-second blocks reward low, stable latency: prefer European or otherwise well-peered locations and avoid heavily oversubscribed instances. Full technical setup is covered in the onboarding runbook you receive when accepted.
Accepted operators receive an operator grant of 2,500 to 5,000 AERE, funded from the on-chain Ecosystem Reserve, structured around a 90-day shadow run:
The grant is the only committed compensation today. A protocol-level fee share for verification node operators is under design and will be announced when — and only when — it is live. We do not promise yield we have not shipped.
Because QBFT membership is identity-based, the value of the set comes from who is in it. We select for verifiable independence, not for volume of applications.
| Criterion | What it means in practice |
|---|---|
| Named entity | A registered organization — company, university lab, foundation, or cooperative — not an anonymous individual. The entity name is published on this site. |
| Public identity | You are willing to be publicly listed as an AERE node operator, with a named technical contact. |
| Independent infrastructure | Your own servers or your own cloud account, in a data center / provider that meaningfully differs from the existing set. We actively select for provider, network, and jurisdiction diversity. |
| Operational track record | Evidence you run production infrastructure today — other chains, RPC services, hosting, research clusters. We verify. |
| 99.5% uptime target | Measured monthly over the shadow run and as a standing expectation in the live set, with coordinated maintenance windows. |
Fault tolerance in QBFT is arithmetic, not marketing: a set of N nodes tolerates f = ⌊(N−1)/3⌋ faulty nodes. We publish the math because it is the honest measure of where the network stands.
Nodes are added one at a time by on-chain majority vote of the existing set, each addition recalculating the quorum. Every membership change is publicly verifiable on the live consensus page.
One email. No forms, no waitlist theater. Send the following to [email protected]:
We reply to every serious application within five business days. Accepted operators receive the full technical onboarding runbook, the canonical genesis bundle, and a direct channel to the Foundation engineering team.
No. QBFT has no protocol-level slashing — there is no bonded stake, and nothing is burned for downtime or misbehavior. What exists instead is removal: a majority of the operator set can vote a node out, on-chain, and the grounds for that are written down and shared with every operator before they join. We state this plainly because operators deserve to know exactly what mechanism governs them.
No. Membership in the verification set is by identity and vote, not by stake. The program pays you — the operator grant — rather than the other way around.
Not your node, not your keys, not your infrastructure. The Foundation operates its own nodes and holds the same one-vote-per-node membership rights you do. The explicit goal of this program is to make the Foundation a minority of the set.
Your node runs fully synced alongside the live set, with uptime and signing-readiness monitored, before it is voted into consensus. It is a rehearsal with real measurements — so that by the time your node helps finalize blocks, both sides know it belongs there.