6cb0140fae
The public history carried kat/__pycache__/mlkem768_reference.cpython-314.pyc, a compiled Python artifact embedding the operator's absolute local path. Text secret scanners do not read compiled binaries, which is exactly how it slipped through, and removing it from the tip would have left it reachable through the old root commits. So this repository is republished from a single clean root. This root also carries, from the previously unpublished line of work: - corrected LICENSE year, LICENSING.md, VERIFY-POLICY.md, and CITATIONS-UNRESOLVED.md remeasured 2026-08-11 (101 paths, README aligned) - O-018: run_consensus_verification.py ran 19 of 29 models and reported PASS; it now runs all 29, and computemarket_smt.py gains resolveByTimeout / reclaimUnsettled cases plus a negative control - O-006: the word 'audited' removed from next to Bouncy Castle, twice, after a concurrent edit resurrected it - O-014: prior art named and dated - Algorand's native falcon_verify shipped about ten months before AERE's precompiles; the primacy claim is withdrawn where it was implied - bench/ scripts parametrized so they actually run for an outsider (the earlier textual sanitization left $STAGING unexpanded inside Python strings) - AIP-2/AIP-3 errata with measured figures, spec remeasurements at 2026-08-01, and the spec-zk-stack retractions (owner is an operational key, not the Foundation; 'maximally sound' withdrawn; aggregator V1 deprecated) The redacted bench-host environment files from the sanitized line are kept exactly as published; the unredacted local variants are not carried.
144 lines
6.8 KiB
Markdown
144 lines
6.8 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 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.
|
|
|
|
**Realized burn to date, MEASURED.** The mechanism is live and the vault is
|
|
immutable, and it has burned essentially nothing. `eth_getBalance` on the burn
|
|
vault `0x696afDF4f814e6Fd6aa45CE14C498ed9375fB2c6` returned
|
|
`0x1e7f974e119aaa7` at block 10,571,949 on 2026-07-20, which is
|
|
137,352,594,046,167,719 wei, or 0.1373525940461677 AERE, against a fixed supply
|
|
of 2,800,000,000 AERE. The reason is arithmetic: the burn is a percentage of
|
|
validator coinbase revenue, that revenue is currently zero, and a percentage of
|
|
zero is zero. The 37.5% in this document is a conditional rate on future
|
|
revenue. AERE is not deflationary today. Verify with one RPC call.
|
|
|
|
## Motivation
|
|
|
|
The AERE whitepaper (Section 3.3) states that up to 37.5% of transaction fees are
|
|
permanently removed from circulation. That wording predates the implemented
|
|
mechanism and is superseded: what this AIP specifies, and what is live, is a cut
|
|
of the VALIDATOR COINBASE REWARD, not of transaction fees. The
|
|
validator-reward-cut description governs everywhere the two conflict. 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>
|