aere-research/aips/AIP-2.md

AIP-2: Coinbase Fee-Burn Routing (37.5%)

Preamble

Field	Value
AIP	2
Title	Coinbase Fee-Burn Routing (37.5%)
Author	AERE Foundation
Type	Standards Track
Category	Core
Status	Final
Created	2026-07-11
Requires	None
Ratification	Foundation-ratified (pre-decentralization)

Abstract

This AIP documents the on-chain mechanism that makes AERE's fee-burn real and auditable: an atomic splitter that routes a validator's accumulated coinbase rewards so that a fixed fraction, 37.5% by default, is sent to a permanent burn vault and the remainder is returned to the validator. It is a retro-filed record of a change that is already live on chain 2800.

Motivation

The AERE whitepaper (Section 3.3) states that up to 37.5% of transaction fees are permanently removed from circulation. On a Hyperledger Besu QBFT chain there is no protocol-level base-fee burn of the EIP-1559 kind: QBFT credits fees to the block proposer's coinbase rather than burning any part of them at the consensus layer. So the whitepaper claim needed an explicit, on-chain mechanism, or it would be just a claim.

The goal was to make the burn (1) measurable in a single on-chain read, (2) impossible for the routing contract to steal or divert, and (3) verifiable by any third-party explorer or analyst against the whitepaper.

Specification

Contracts

• AereFeeBurnVault at 0x696afDF4f814e6Fd6aa45CE14C498ed9375fB2c6. A stateless sink. It accepts native AERE via receive() or burn(), and any ERC-20 via burnToken(). It has no withdraw function and no admin. Value that enters is removed from circulation. It exposes sweepToZero(), callable by anyone, which forwards its native balance to address(0) (QBFT Besu permits a send to the zero address, after which the value is unreachable). Counters totalBurnedAERE and totalSentToZero make the burn queryable in O(1). Source: contracts/contracts/AereFeeBurnVault.sol.

• AereCoinbaseSplitter at 0xb4b0eCe9011613A5b84248a9B42a0f309E6F01Ec. The routing contract. A validator or its forwarder daemon calls splitAndDistribute(validator) or splitToSelf() with the accumulated coinbase as msg.value. The contract computes burnAmount = msg.value * burnBps / 10000, forwards burnAmount to AereFeeBurnVault via its burn() entrypoint, and returns the remainder to the validator address. It maintains lifetime counters totalBurned and totalDistributed and per-caller attributions. Source: contracts/contracts/AereCoinbaseSplitter.sol.

• AereCoinbaseSplitterV2 at 0x8C1A48eFA57b66fEE743A00E3899c29ad3Fd27b4. The current canonical splitter. Source: contracts/contracts/AereCoinbaseSplitterV2.sol.

Parameters

• burnBps default is 3750, which is 37.5%, matching whitepaper Section 3.3.
• setBurnBps(uint256) is owner-only and MUST revert above 5000 (a hard cap of 50%). The whitepaper says "up to 37.5%", so the cap gives headroom while bounding abuse. Owner is the Foundation 0x0243A4f47D44b40b65D33f20329dE20D00c6f3C3.
• The splitter holds no custody across calls: every call fully dispatches msg.value into the burn portion and the validator rebate.

Extra burn on top

Beyond the coinbase split, the immutable revenue router AereSink at 0x69581B86A48161b067Ff4E01544780625B231676 directs an additional bucket to AereFeeBurnVault (see AIP-5). The 37.5% figure in this AIP refers specifically to the coinbase split, not to the total of all burn paths.

Rationale

The split is done in application code called by the validator rather than at the consensus layer because QBFT does not offer a base-fee-burn hook, and forking the client to add one would break EVM-equivalence with Ethereum tooling and add a consensus-critical code path to maintain. Routing the coinbase through an immutable, non-custodial splitter achieves the economic outcome (a fixed fraction provably burned, with public counters) without touching consensus.

The burn vault is deliberately separate from the splitter and has no admin, so even the splitter owner cannot pull burned funds back. The 50% hard cap on burnBps bounds the worst case if the owner key is misused.

Backwards Compatibility

None. This mechanism adds a routing path; it does not change transaction semantics, gas accounting, or the EVM ruleset.

Security Considerations

The honest limitation of this design is that the burn is cooperative, not protocol-enforced. Nothing at the consensus layer compels a validator to route its coinbase through the splitter. A validator that keeps its full coinbase simply does not burn. Today the network runs seven validators under a single operator (the Foundation), so in practice the burn depends on Foundation-operated infrastructure calling the splitter, not on a trustless rule. As the validator set decentralizes, making the burn a credible network-wide property will require either social/economic commitment from validators or a future Core AIP that moves the split into block production itself.

Within the contracts, the risks are limited: the splitter is non-custodial and reentrancy-guarded, and the burn vault has no withdraw path or admin. The burnBps setter is owner-gated and capped at 50%.

Reference Implementation and On-Chain Deployment

• contracts/contracts/AereCoinbaseSplitter.sol -> 0xb4b0eCe9011613A5b84248a9B42a0f309E6F01Ec
• contracts/contracts/AereCoinbaseSplitterV2.sol -> 0x8C1A48eFA57b66fEE743A00E3899c29ad3Fd27b4
• contracts/contracts/AereFeeBurnVault.sol -> 0x696afDF4f814e6Fd6aa45CE14C498ed9375fB2c6
• Related extra-burn bucket: AereSink 0x69581B86A48161b067Ff4E01544780625B231676 (AIP-5)

All addresses copied verbatim from sdk-js/src/addresses.ts. Live cumulative burn statistics are readable via AereCoinbaseSplitter.burnStats() and AereFeeBurnVault.totalBurnedAERE().

Copyright

Released to the public domain (CC0). No rights reserved.