aere-research/aips/AIP-17.md

162 lines
7.4 KiB
Markdown

# AIP-17: One-Gwei EIP-1559 Base-Fee Floor
## Preamble
| Field | Value |
| --- | --- |
| AIP | 17 |
| Title | One-Gwei EIP-1559 Base-Fee Floor |
| Author | Aere Network Foundation |
| Type | Standards Track |
| Category | Core |
| Status | Final |
| Created | 2026-07-20 |
| Requires | 10 |
| Supersedes | None |
| Superseded-By | None |
| Ratification | Foundation-ratified (pre-decentralization) |
## Abstract
This AIP documents the client-flag-gated fork that clamps the EIP-1559 base fee
on chain 2800 to a minimum of 1 Gwei from block **10,141,734**. Before that block
the real minimum bottomed out at 7 wei. It is a retro-filed record of a change
already live on chain 2800: it backfills history and did not go through Draft,
Review or Last Call.
## Motivation
Aere's public RPC and its documentation reported a 1 Gwei base fee while the
chain's actual base fee had decayed to 7 wei. That gap was being closed by a
presentation-layer shim rather than by the chain, which meant a user who queried
the chain directly and a user who read our documentation got different answers,
and only one of them was true.
There were two honest ways to close it: change the documentation to say 7 wei, or
change the chain so that 1 Gwei is the real value. The second was chosen because
a base fee of 7 wei is not a meaningful price signal, and because a floor is a
value the chain can actually enforce and any observer can verify from block data.
The shim was then retired, which was the point of the exercise: the number
reported is now the number the chain produces.
## Specification
For every block `B`:
```
baseFee(B) = max( baseFee_1559(parent), 1000000000 ) if number(B) >= 10141734
baseFee(B) = baseFee_1559(parent) otherwise
```
where `baseFee_1559` is the unmodified parent-derived EIP-1559 base fee and
`1000000000` wei = 1 Gwei.
- The clamp is applied at the three exits of
`computeBaseFee(blockNumber, parentBaseFee, parentGasUsed, targetGasUsed)`,
identically on the produce path and the validate path, so a floored block both
produces and self-validates the floored value.
- The two driving values are Besu client **system properties**:
`AERE_BASEFEE_FLOOR_FORK_BLOCK = 10141734` and
`AERE_BASEFEE_FLOOR_VALUE = 1000000000`, exposed as
`aere.basefee.floor.forkBlock`.
- The defaults are **dormant** (`forkBlock = Long.MAX_VALUE`), so an unflagged
build never applies the floor and is byte-identical to stock in behavior.
- The change is deliberately **not** an EIP-2124 fork-id input and is not
registered as a scheduled fork.
**Measured activation boundary** (re-confirmed by direct measurement 2026-07-19):
block 10,141,733 has `baseFeePerGas = 7` wei; block 10,141,734 has
`baseFeePerGas = 0x3b9aca00 = 1,000,000,000` wei; the value holds at 1 Gwei at
every later block sampled through head, and `eth_feeHistory` at head reports
`0x3b9aca00`.
## Rationale
**Why a client flag rather than a chain-config fork.** Base-fee validation is
absent from the QBFT header ruleset, so a node with a different floor flag does
not reject a peer's blocks: two clients with different flags share one fork id
and peer normally. That property is what made the rollout carry no liveness risk,
because validators could be upgraded one at a time and a lagging node could not
halt or split the chain. The flag being dormant by default is what keeps every
historical block below 10,141,734 valid with its original sub-Gwei base fee.
**Why 1 Gwei.** It is the value the documentation already claimed, so the fork
made the documentation true rather than choosing a new number and creating a
second discrepancy.
**Alternatives rejected.** Keeping the presentation-layer shim: it makes the RPC
lie, and a hash-verifiable chain that needs a shim to look right has a
credibility problem worse than a low base fee. Enshrining the floor as a
consensus fork rule with a fork id: unnecessary given that base fee is not
header-validated here, and it would have introduced a genuine split risk in
exchange for nothing.
## Backwards Compatibility
Historical blocks are unaffected and still validate with their original base
fees. Integrators that hard-coded a sub-Gwei minimum gas price will underprice
transactions from block 10,141,734 onward and should read the base fee from the
chain. No contract interface changed.
## Security Considerations
This modification cannot halt or fork QBFT, because base-fee validation is not
part of the QBFT header ruleset (which is also why a non-upgraded node syncs
straight past the floor block with no rejection). The corresponding weakness is
the same fact stated from the other side: because the floor is not
consensus-enforced, a validator running without the flag would produce blocks
with a sub-Gwei base fee and no one would reject them. Consistency depends on
operational rollout to all validators, not on consensus. All seven validators are
Foundation-operated (AIP-9), so today that is an operational guarantee under one
operator.
**Open question, honestly flagged.** Where the EIP-1559 base fee ultimately goes
on chain 2800 is **not fully resolved**. Measurement on block 10,487,561 (one
transaction, `gasUsed` 22,474, `effectiveGasPrice` = `baseFeePerGas` = 1 Gwei, so
zero priority tip) showed a coinbase balance delta of **exactly 0 wei**, which
rules out the base fee being credited to the coinbase, since crediting would have
moved 22,474,000,000,000 wei. Because the tip was zero, that measurement cannot by
itself separate "protocol-burned" from "routed elsewhere". Completing the
distinction needs a block containing a transaction with a nonzero priority tip and
unpruned state.
**This floor is not a burn.** Aere's burn is a separate cut of the validator
coinbase reward (AIP-2). A base-fee floor sets a minimum price; it does not remove
supply. These two must not be conflated in any Aere document.
## Reference Implementation and On-Chain Deployment
- Diff: `aerenew/basefee-floor-dryrun/basefee-floor.diff`
- Runbook: `aerenew/docs/BASEFEE-FLOOR-FORK-RUNBOOK-2026-07-17.md`
- Specification detail: `aerenew/docs/AERE-PROTOCOL-SPECIFICATION.md` Section 5.1
- Chain ID 2800, activation block 10,141,734. No contract address: this is a
client change.
Verify it yourself: fetch `baseFeePerGas` for blocks 10,141,733 and 10,141,734
from `https://rpc.aere.network` and from the second public endpoint
`https://rpc2.aere.network`. Both return 7 wei and 1,000,000,000 wei
respectively, and the fork-block hash is identical across both endpoints.
## Errata
**Erratum 1 (2026-09-12).** The Security Considerations say "All seven validators
are Foundation-operated (AIP-9)" without a date, so read on its own it is a claim
about today. That was a measurement of 2026-07-19. Measured 2026-09-12: the set
is ten, still all Foundation-operated, so the conclusion of that sentence stands
and only its count moved. See the erratum on AIP-9. The original text is left
exactly as published, per AIP-1 section 5.
## Post-Acceptance Outcome Record
**2026-07-20.** Activation was clean and is **measured**: base fee 7 wei at block
10,141,733 became 1 Gwei at 10,141,734 and has stayed 1 Gwei; the fork-block hash
was identical across the public RPC and the second RPC, so there was no split;
N = 7 held with no halt. The presentation-layer shim was retired, and both public
endpoints now serve an honest, hash-verifiable 1 Gwei. Rollback remains available
by clearing the flag, which would return the chain to unmodified EIP-1559
behavior from the next block.
## Copyright
Released to the public domain (CC0). No rights reserved.