# 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.