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.

7.4 KiB Raw Blame History