4a0b48588c
Aere Network public source. Everything here can be checked against the live chain (chain id 2800, https://rpc.aere.network). Scope note, stated up front rather than buried: consensus on chain 2800 is classical secp256k1 ECDSA QBFT. The post-quantum work in this repository is at the signature, precompile, account and transport layers. Nothing here makes the consensus post-quantum, and no document in it should be read as claiming so.
130 lines
5.9 KiB
Markdown
130 lines
5.9 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 |
|
|
| 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.
|
|
</content>
|