171 lines
7.7 KiB
Markdown
171 lines
7.7 KiB
Markdown
# 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 |
|
|
| Supersedes | None |
|
|
| Superseded-By | 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()`.
|
|
|
|
## Errata
|
|
|
|
None.
|
|
|
|
## Post-Acceptance Outcome Record
|
|
|
|
*Appended 2026-07-20 under AIP-1 section 5. Nothing above this heading was
|
|
edited. This record exists because the mechanism works exactly as specified while
|
|
producing an economic outcome that a reader of the sections above would not
|
|
predict.*
|
|
|
|
**The burn is real and it is approximately zero.**
|
|
|
|
| Quantity | Value | Provenance |
|
|
| --- | --- | --- |
|
|
| Burn rate | 37.5% of the validator coinbase reward | spec (configured) |
|
|
| Hard cap on the rate | 50% (`setBurnBps` reverts above `5000`) | spec |
|
|
| Coinbase revenue to date | zero | measured |
|
|
| Lifetime burned | 0.1374 AERE | measured |
|
|
|
|
The splitter routes 37.5% of what it receives, and it has received almost
|
|
nothing, because the chain is quiet and coinbase revenue is effectively zero. A
|
|
percentage of zero is zero. The mechanism is live, immutable at its endpoints,
|
|
and verifiable; the supply effect is negligible.
|
|
|
|
**Therefore AERE is not deflationary today, and no Aere document may say that it
|
|
is.** A burn mechanism existing is not the same claim as supply decreasing, and
|
|
the difference between those two claims is 0.1374 AERE against a 2.8 billion
|
|
supply. This will change only if transaction volume changes; it is not a
|
|
parameter anyone can tune, because the rate is already set and the input is what
|
|
is missing.
|
|
|
|
**Two related confusions to keep out of Aere copy.** First, this burn is a cut of
|
|
the **validator coinbase reward**, not an EIP-1559 base-fee burn; QBFT credits
|
|
fees to the proposer's coinbase and burns nothing at the consensus layer, which is
|
|
why the mechanism is a contract above consensus. Second, chain 2800 does separately
|
|
run a 1 Gwei base-fee **floor** from block 10,141,734 (AIP-17); a floor sets a
|
|
minimum price and removes no supply. Conflating the floor with the burn produces a
|
|
statement that is wrong twice.
|
|
|
|
## Copyright
|
|
|
|
Released to the public domain (CC0). No rights reserved.
|