Run an AERE validator

This page is the HOW. The WHO is the Independent Validator Program: the entry bars for operators outside the Foundation, how seats are granted and lost, and the honest state of the program today.

Chain 2800, the network under Aere's four product lines (definition dated 2026-10-18), is a public EVM chain secured by QBFT on two independently built clients (Besu-derived and Nethermind-derived), with sub-second deterministic finality on the validators (0.5-second target). Consensus runs on 10 Foundation-operated validators (f=3, quorum 7-of-10, as read from the chain at 2026-11-01 19:45 UTC), with a public path to 21. This page is the honest operator guide: how to sync a full node on Chain 2800, and how to apply to join the validator set. This program exists specifically to admit the first independent operators.

01 · The caseWhy run an AERE validator

A validator on AERE is a verification node: it runs Hyperledger Besu, holds a signing key, and participates in QBFT block production. Every confirmed block is signed by the validator set and is final the instant it lands for the validator, with no probabilistic waiting and no reorganisation. Running one does two things.

• It decentralises consensus. AERE runs on 10 Foundation-operated validators (as read from the chain at 2026-11-01 19:45 UTC). At n = 10 the network tolerates 3 Byzantine faults (per f = ⌊(n−1)/3⌋, commit quorum 7-of-10). The public path is 10 → 21. Independent operators are how the network stops being Foundation-operated at the consensus level. This is stated plainly, not implied away.
• It earns the per-block fee remainder. AERE has no block subsidy and no inflation; QBFT validators are paid entirely from transaction fees. Each validator forwards its coinbase reward into an on-chain splitter that burns a fixed share and rebates the remainder to the validator. The exact split is set on-chain and is described in Validator economics below.

02 · No spinHonest current state

• Consensus is Foundation-operated. 10 validators, all run by the Foundation (9 until 2026-09-11). The network is on the decentralisation path; it is not yet decentralised.
• Admission is a Foundation governance vote. There is no stake-to-join, no permissionless validator registration. The Foundation proposes a candidate and the existing validators vote it in. See below.
• There is no on-chain slashing. QBFT on Besu is a permissioned BFT protocol with no bonded stake to slash. A misbehaving or offline validator is removed by a governance vote of the remaining set, not by an economic penalty. Do not expect stake-slashing mechanics from a proof-of-stake chain; AERE does not have them.
• A full/verification node is permissionless to run. Anyone can sync a full node against the public network and read state. Becoming a block-producing validator is the part that requires admission.
• Delegated validator staking is not live. The sAERE flywheel and EIP-7702 delegation primitives are roadmap items with no date set (until 2026-10-05 this page gave the third quarter of 2026). They are not a prerequisite for validator admission and do not exist as a self-stake mechanism today.

03 · SetupHardware + software requirements

Software

Hardware

AERE does not publish a fixed minimum hardware sheet; the appropriate spec depends on your role (full node versus block-producing validator) and expected load. The one configured value that is public: the Foundation validators run Besu with a 4 GB JVM heap (-Xmx4g). As practical guidance (not a documented spec), a full node on Chain 2800 is comfortable on a modern multi-core CPU, at least 8 GB RAM, and fast NVMe SSD storage with room to grow. Exact validator-grade hardware requirements are provided by the Foundation on application.

04 · Step by stepSync a full node on Chain 2800

Start here whether or not you plan to apply. A synced full node lets you verify the chain yourself, read state, and prove your operational readiness before applying. These are the real flags the network runs.

1. Get the node recipe, the genesis file and a bootnode

   All of it is public in the aere-node repository: genesis.json, the validator registries the post-quantum anchor rule needs, the patches, run-node.sh, and, in RUN-A-NODE.md, the bootnode enode that run-node.sh uses by default. Do not hand-copy an enode from a third party.

   git clone https://git.aere.network/aere-network/aere-node
   cd aere-node

2. Prepare a data directory

   Create a persistent data directory. Besu writes your node's signing identity to <data-path>/key on first start. This file is your node identity, and one of the three keys a validator needs (with a Falcon-512 key and an SLH-DSA-SHA2-128s key, see below). Back it up and never delete it.

   # one-time: create the data dir
   mkdir -p /opt/aere-besu/data

3. Build and run the node against Chain 2800

   One command verifies the genesis and the registries by SHA-256, fetches upstream Besu at the named commit, applies the mainnet patches in order, builds the node and starts it with the options of the activation heights the network runs. ./run-node.sh --help lists its options; RUN-A-NODE.md writes every step out by hand for anyone who wants to audit them rather than run them.

   ./run-node.sh --data-path /opt/aere-besu/data

   Until 2026-10-15 this step showed a docker run of the stock hyperledger/besu:26.4.0 image. A node started that way stops following chain 2800 at block 9,189,161. The command is no longer shown, so it cannot be copied.

4. Confirm the node is following the chain

   Point any Ethereum tool at your local RPC and confirm the chain ID and head. Compare your head against the public RPC to confirm you are in sync.

   # chain id should return 0xaf0 (2800)
   curl -s -X POST http://localhost:8545 \
     -H 'content-type: application/json' \
     -d '{"jsonrpc":"2.0","method":"eth_chainId","params":[],"id":1}'
   
   # your local head
   curl -s -X POST http://localhost:8545 \
     -H 'content-type: application/json' \
     -d '{"jsonrpc":"2.0","method":"eth_blockNumber","params":[],"id":1}'
   
   # the public head, to compare against
   curl -s -X POST https://rpc.aere.network \
     -H 'content-type: application/json' \
     -d '{"jsonrpc":"2.0","method":"eth_blockNumber","params":[],"id":1}'

5. Read the live validator set

   QBFT exposes the active set over RPC. This is what a candidate is voted into, and what the public dashboard reads.

   curl -s -X POST https://rpc.aere.network \
     -H 'content-type: application/json' \
     -d '{"jsonrpc":"2.0","method":"qbft_getValidatorsByBlockNumber","params":["latest"],"id":1}'

   The live state is also viewable at /validators.html (validator set, head, block age, and BFT fault tolerance, refreshed every 5 seconds).

Public endpoints

05 · GotchaThe sync-min-peers trap

find /opt/aere-besu/data -mindepth 1 ! -name key -exec rm -rf {} +

06 · RewardsValidator economics

AERE has no block subsidy and no inflation. Validators are compensated purely from transaction fees. Each validator forwards its coinbase reward into an on-chain contract, AereCoinbaseSplitterV2, which splits the reward into fixed on-chain buckets. Because the split is a contract, it is deterministic and publicly auditable, not a discretionary payout.

Bucket shares are set on-chain in basis points within hard caps (burn ≤ 5000 bps, sink ≤ 3000 bps) and the rebate is derived as 10000 − burn − sink. A change to the sink address is 7-day timelocked so validators get warning before any routing change. The deployed AereCoinbaseSplitterV2 address is published in the network's contract registry and documentation; confirm the current address there before wiring a forwarder.

07 · ApplyHow to apply to become a validator

Once you are running a healthy full node in sync with Chain 2800, you can apply to join the validator set. Applications go to the Foundation. Provide the following.

• Your validator identity. Since block 20,836,228 (2026-09-30) the validator set and the votes name each validator by a post-quantum id, not by the address of the Besu key. Admission needs three keys generated on your machine: the secp256k1 node key in <data-path>/key, a Falcon-512 key and an SLH-DSA-SHA2-128s key. Your public keys are published in the validator registry, and the existing validators vote your post-quantum id into the set (see the Independent Validator Program).
• Your node's enode / public P2P endpoint. So the set and each node's static-peer list can be updated to reach you (public IP and P2P port, Besu default 30303).
• Uptime and operational readiness. Evidence that your node is synced and stable (for example, a stable head matching the public RPC over time). QBFT block production depends on validators staying reachable; prolonged downtime is grounds for governance removal, so demonstrated reliability matters. Specific uptime targets and any additional operator requirements are provided by the Foundation on application.

There is no on-chain application form and no self-service registration. The application is reviewed by the Foundation, and admission is decided by the governance process described next.

08 · The honest partThe admission process

AERE runs QBFT on Hyperledger Besu, a permissioned BFT protocol. The validator set is governed by the validators themselves, not by a stake auction. Admission works like this.

1. The Foundation reviews your application (public keys, enode, uptime) and, if it proceeds, your public keys enter a new epoch of the validator registry and your post-quantum id is proposed to the set.
2. Each existing validator casts a vote for your post-quantum id with qbft_proposeValidatorVote(id, true).
3. When a majority of the current validators have voted to add the candidate, the id is admitted at the next epoch boundary and begins participating in block production.
4. Removal uses the same mechanism with false. A validator that double-signs, proposes invalid blocks, or suffers prolonged downtime is voted out by the remaining set.

09 · Straight answersHonest FAQ

Do I need to stake AERE to run a validator?

No. There is no self-stake and no bond. QBFT on Besu has no on-chain stake, and admission is by governance vote, not by locking tokens.

Can I get slashed?

No. There is no slashing on Chain 2800. The consequence for double-signing, invalid proposals, or prolonged downtime is being voted out of the validator set by the other validators.

Is joining permissionless?

Running a full node is permissionless. Becoming a block-producing validator is not, it requires a governance vote of the existing set. This program exists to onboard the first independent operators along the 10 → 21 path.

How much will I earn?

A share of transaction fees, specifically the validator-rebate bucket of the coinbase splitter (see Validator economics). There is no fixed APY and no block subsidy; income varies with network usage.

Which Besu version and chain ID?

The Aere fork of Hyperledger Besu, built from the public aere-node recipe, against Chain ID 2800, with the public genesis file. Stock hyperledger/besu stops following the chain at block 9,189,161.

Every figure on this page is grounded in AERE's live configuration and on-chain contracts. Where a value depends on onboarding (validator-grade hardware, specific uptime targets, the deployed splitter address; the genesis file and a bootnode are public in the aere-node repository), it is provided by the Foundation on application rather than guessed. Consensus: QBFT on two clients (Besu-derived and Nethermind-derived), Chain ID 2800, sub-second blocks since block 2,137,652 (0.5 s target). No on-chain slashing. 10 Foundation validators today (f=3, quorum 7-of-10); public path to 21.