This page reads the live QBFT validator set from chain 2800 in your browser with a read-only call, then states plainly where AERE stands on decentralization today. No wallet. No keys. No writes. The number the reader should care about is not how many validator addresses exist, but how many independent parties it takes to halt the chain. Today that number is one, and this page says so directly.
AERE is not decentralized today. The live QBFT set is nine validators, but all nine keys are held and operated by the AERE Foundation, on one production client (Hyperledger Besu) and concentrated hosting. So the network is crash-fault-tolerant (it survives up to two simultaneous validator outages without halting), but it is not Byzantine-decentralized: a single operator controls every validator key and can halt, censor, or reorganize the chain unilaterally.
The Nakamoto coefficient is about 1. One party (the Foundation) is enough to stop block production. Nine addresses is not nine operators. This page does not describe AERE as decentralized, and neither should anyone quoting it. The path to a Nakamoto coefficient above one is real, staged, and shown at the bottom of this page, but it is roadmap, not today.
The button below sends one read-only JSON-RPC call, qbft_getValidatorsByBlockNumber, to the public endpoint and lists every address the QBFT engine currently recognizes as a validator. This is the same call the live validator page uses. It also reads web3_clientVersion so you can see the client the public RPC node runs. The validator count and addresses are fully verifiable by anyone from any node. What a public RPC call cannot prove is who operates each validator and what client each one runs. Those are operator-attested facts, disclosed honestly in the tables below rather than dressed up as something a stranger can verify remotely.
Nothing here is fetched from a third party and nothing is signed or written. The result depends only on the public state of chain 2800 and is identical from any node.
Press the button above to read the set live.
| # | Validator address (in QBFT set) | Operator (attested) |
|---|---|---|
| Not read yet. | ||
curl -s https://rpc.aere.network -X POST \
-H 'content-type: application/json' \
--data '{"jsonrpc":"2.0","id":1,"method":"qbft_getValidatorsByBlockNumber","params":["latest"]}'QBFT finalizes a block when a quorum of ceil(2N/3) validators agree. At N=9 that quorum is 6 of 9, and the chain tolerates f=2 crash faults: any two validators can go offline and the chain keeps producing blocks. That is a genuine liveness property, and it is live on mainnet.
The Nakamoto coefficient asks a different question: how few independent parties must act together to stop or subvert the chain. Because all nine validator keys are held by one operator, that operator alone can withhold the quorum (halt), refuse transactions (censor), or, holding more than two-thirds of the keys, sign conflicting blocks (equivocate). One party is sufficient for every one of these. So the Nakamoto coefficient, measured by operator rather than by key, is 1. Growing the address count without growing the operator count does not move this number. Only independent operators, and eventually a permissionless membership rule the Foundation cannot override, move it above one.
This is why AERE states crash-fault-tolerance and decentralization as two separate facts. The first is true today. The second is not.
A second independent client is the only thing that catches a consensus bug the first client would also make. On a BFT chain a client disagreement is a chain split, not a soft error, so this is treated as a stage-gated project, not a switch to flip. Honest status, no exaggeration:
| Client | Role on live 2800 | Status |
|---|---|---|
| Hyperledger Besu (Java) | Produces and validates every live block. The reference client. | Live, sole validator client |
| Nethermind (C#) + AERE PQC | Second independent execution client. On an isolated testnet it re-executes chain 2800 byte for byte and produces QBFT blocks that stock Besu accepts as valid (byte-identical hashes, tampered blocks rejected). Staged as a non-validating follower for the live chain, which re-verifies blocks but casts no vote and produces none. | Testnet-complete Not a live validator |
The honest reading: consensus on live chain 2800 is single-client (Besu). The Nethermind client proves interoperability on testnet and can follow the live chain as an independent verifier, but it is not in the validator set and takes zero part in consensus. Adding it as a validator is a founder-gated, audit-gated step (see the path below), because a from-scratch consensus client sealing live blocks can affect finality. Until a mixed-client set has soaked cleanly under audit, the accurate phrase is "single-client, mitigated by staggered upgrades," not "client-diverse." A non-validating follower does not change the Nakamoto coefficient: it still takes one operator to halt.
Each step names its real gate. None of them is done by writing marketing copy; each is code, money, people, or an explicit founder signature. They are ordered so the riskiest and most irreversible ones come last.
Only when steps 1, 3, 4, and 5 are all live and independently verifiable will AERE describe itself as decentralized. Interested in operating a node? See run a validator.
qbft_getValidatorsByBlockNumber on chain 2800 and are reproducible from any node. The "operator" column is attested by the Foundation, not proven by the RPC call, and is disclosed as such: today every row is the same operator.web3_clientVersion), not the client of each validator. This page never implies otherwise. That the public endpoint reports Besu is shown as evidence about that node, not about the whole set.
Method: qbft_getValidatorsByBlockNumber · Quorum: ceil(2N/3)
· Live validator state · Run a validator · Network status · Verify quantum durability