Run an AERE validator

AERE is a public EVM Layer 1 secured by Hyperledger Besu QBFT with 0.5-second deterministic finality. Consensus runs on 3 Foundation-operated validators today, with a public path to 7 and then 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, no probabilistic waiting, no reorgs. Running one does two things.

• It decentralises consensus. AERE runs on 3 Foundation-operated validators today. At n = 3 the network tolerates 0 Byzantine faults (per f = ⌊(n−1)/3⌋). The public path is 3 → 7 (tolerance 2) → 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. 3 validators, all run by the Foundation. 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 (Q3 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 genesis file and bootnodes

   Chain 2800's genesis.json and the current bootnode enode list are provided by the Foundation on application (and to prospective operators on request). Do not hand-copy an enode from a third party; use the list the Foundation gives you. Place genesis.json where your node can read it.

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, if you are admitted, your validator address). Back it up and never delete it.

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

3. Run Besu against Chain 2800

   The flags below mirror the live network configuration. Replace BOOTNODE_ENODE with the enode(s) the Foundation provides.

   docker run -d --name aere-besu \
     -p 30303:30303/tcp -p 30303:30303/udp \
     -p 8545:8545 -p 9545:9545 \
     -v /opt/aere-besu/data:/var/lib/besu/data \
     -v /opt/aere-besu/genesis.json:/var/lib/besu/genesis.json \
     -e BESU_OPTS="-XX:+UseG1GC -XX:MaxGCPauseMillis=100 -Xmx4g" \
     hyperledger/besu:26.4.0 \
     --data-path=/var/lib/besu/data \
     --genesis-file=/var/lib/besu/genesis.json \
     --network-id=2800 \
     --p2p-host=0.0.0.0 --p2p-port=30303 --p2p-enabled=true \
     --bootnodes=$BOOTNODE_ENODE \
     --max-peers=50 \
     # see "the sync-min-peers trap" below before changing this
     --sync-min-peers=1 \
     --sync-mode=FULL \
     --data-storage-format=BONSAI \
     --min-gas-price=0 \
     --rpc-http-enabled=true --rpc-http-host=0.0.0.0 --rpc-http-port=8545 \
     --rpc-http-cors-origins="*" --host-allowlist="*" \
     --rpc-http-api=ETH,NET,WEB3,QBFT,DEBUG,TXPOOL \
     --metrics-enabled=true --metrics-host=0.0.0.0 --metrics-port=9545 \
     --logging=INFO

   Note on --min-gas-price=0: Chain 2800's base fee is a small constant, so a full node accepts the network's transactions with a zero local floor. Do not set a nonzero min-gas-price on a node meant to follow mainnet. Tighten --rpc-http-cors-origins and --host-allowlist for a production, internet-exposed RPC; the wildcards above are for local bring-up.

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 address. This is the Ethereum-style address derived from your node's Besu signing key (<data-path>/key). It is the address the existing validators would vote into the set.
• 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 (validator address, enode, uptime) and, if it proceeds, proposes your address to the set.
2. Each existing validator casts a vote using Besu's qbft_proposeValidatorVote(address, true) method.
3. When a majority of the current validators have voted to add the candidate, the address 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 3 → 7 → 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?

hyperledger/besu:26.4.0 against --network-id=2800 (Chain ID 2800), with the Chain 2800 genesis file the Foundation provides.

Every figure on this page is grounded in AERE's live configuration and on-chain contracts. Where a value depends on onboarding (genesis file, bootnode enodes, validator-grade hardware, specific uptime targets, the deployed splitter address), it is provided by the Foundation on application rather than guessed. Consensus: QBFT on Hyperledger Besu, Chain ID 2800, 0.5s finality since block 2,138,451. No on-chain slashing. 3 Foundation validators today; public path to 7 then 21.