ECIP 1116: Base Fee Miner Distribution

Simple Summary

This ECIP activates a consensus-layer miner distribution for the BASEFEE redirected under ECIP-1111, allocating ninety-five percent of each block’s BASEFEE to the block producer and five percent to the Olympia Treasury (ECIP-1112), replacing the one-hundred percent treasury accumulation defined in ECIP-1111.

Abstract

ECIP-1111 redirects one hundred percent of EIP-1559 BASEFEE to the Olympia Treasury rather than burning it. This ECIP modifies that split at the consensus layer so that miners receive ninety-five percent of each block’s BASEFEE directly to coinbase, while five percent continues to accumulate in the Treasury. Block rewards and priority fees defined in ECIP-1017 remain entirely unchanged. This modification is intended to accompany ECIP-1111 activation or follow it as a subsequent hard fork, strengthening miner incentive alignment with the Olympia upgrade before and during the transition to a fee-dominant security model.

Motivation

Miner Alignment with the Olympia Upgrade

ECIP-1111 replaces the standard EIP-1559 burn with full treasury redirection. While this preserves value that would otherwise be destroyed, it does so by routing one hundred percent of BASEFEE away from block producers entirely. Under standard EIP-1559 semantics miners already receive zero percent of BASEFEE — it is burned — so ECIP-1111 represents no regression relative to vanilla EIP-1559. However, Ethereum Classic miners have historically received the full gas fee under legacy transaction semantics, making any BASEFEE diversion a departure from prior expectations.

Directing ninety-five percent of BASEFEE to miners rather than the treasury addresses this concern directly. It gives block producers a material, ongoing stake in the success of the EIP-1559 fee market that ECIP-1111 establishes, creates a visible and immediate economic incentive to support the Olympia upgrade, and ensures that as the network transitions toward a fee-dominant security model under ECIP-1017’s declining block rewards, miners participate in that transition from the outset rather than waiting for the optional distribution path defined in ECIP-1115.

The five percent treasury allocation provides sustainable baseline funding for protocol development, client maintenance, and public infrastructure without requiring the full treasury accumulation model. If ECIP-1115 L-curve smoothing is subsequently activated, its miner distribution mechanism operates on top of this baseline rather than replacing it.

Why Five Percent to Treasury

At current transaction volumes, five percent of BASEFEE is less than 0.01 percent of total miner income. It scales proportionally with network activity, creating a sustainable development funding stream without imposing a meaningful economic burden on miners. As the fee market matures and base fees increase, the treasury receives a growing allocation that funds the infrastructure and client maintenance required to sustain the fee market itself — a direct alignment of incentives between treasury beneficiaries and the miners generating that revenue.

Relationship to ECIP-1111 and ECIP-1115

This ECIP modifies ECIP-1111 at the consensus layer. It does not alter the treasury contract defined in ECIP-1112, the governance framework of ECIP-1113, or the funding proposal process of ECIP-1114. Those components are unchanged; the treasury simply receives five percent rather than one hundred percent of BASEFEE from the consensus layer. ECIP-1115 L-curve smoothing operates on treasury-held funds after deposit and is fully compatible with this split — its miner distribution parameters would apply to the five percent treasury allocation independently of the ninety-five percent direct miner payment.

If the community prefers to activate ECIP-1111 first with full treasury accumulation and subsequently activate ECIP-1116 as a separate hard fork, both activation paths are valid. The intent of this ECIP is to give implementers and the community the option to include miner distribution from day one of Olympia activation rather than deferring it to a subsequent governance vote.

Specification

BASEFEE Allocation

Upon activation of this ECIP, the BASEFEE component of each block shall be allocated as follows, superseding the ECIP-1111 specification for BASEFEE handling:

Miner Allocation: Ninety-five percent of the BASEFEE shall be credited to the block coinbase address at the consensus layer during block finalization.

Treasury Allocation: Five percent of the BASEFEE shall be credited to the Olympia Treasury address defined in ECIP-1112 at the consensus layer during block finalization.

All other ECIP-1111 consensus rules remain in effect: the BASEFEE calculation and adjustment mechanism, the BASEFEE block header field, EIP-3198 opcode behavior, and the full priority fee payment to coinbase.

Formal Revenue Distribution

For each block, the complete revenue distribution is:

Miner_Revenue = Block_Reward(era) + (Base_Fee × 0.95) + Priority_Fees

Treasury_Revenue = Base_Fee × 0.05

Where:
  Block_Reward(era) follows ECIP-1017: 5.0 × 0.8^(era−1) ETC
  Base_Fee is the protocol-computed base fee for the block
  Priority_Fees is the sum of all maxPriorityFeePerGas contributions

Consensus-Layer Modification

Clients implementing ECIP-1111 MUST apply the following modification to block finalization logic:

Where ECIP-1111 specifies:

balance[OLYMPIA_TREASURY_ADDRESS] += basefee_revenue

This ECIP replaces that with:

miner_basefee     = basefee_revenue × 95 / 100
treasury_basefee  = basefee_revenue − miner_basefee

balance[block.coinbase]             += miner_basefee
balance[OLYMPIA_TREASURY_ADDRESS]   += treasury_basefee

Integer arithmetic MUST use the subtraction form (treasury = total − miner_portion) to ensure no wei is lost to rounding. The miner allocation is computed first; the treasury allocation is the remainder.

Activation

Activation block numbers are TBD pending Mordor testnet coordination. This ECIP MAY activate at the same block as ECIP-1111 or at a subsequent hard fork block.

• Mordor Testnet: TBD
• Ethereum Classic Mainnet: TBD

Integration with ECIP-1115

If ECIP-1115 L-curve smoothing is active, the smoothing function applies to treasury-held funds after the five percent deposit defined here. The ninety-five percent miner allocation is not subject to smoothing and is paid directly to coinbase each block regardless of ECIP-1115 activation state.

Rationale

Separating Miner Buy-In from Governance Uncertainty

ECIP-1111 presents miners with a choice between supporting an upgrade that redirects all BASEFEE away from them pending an unspecified future governance process, or opposing the upgrade on economic grounds. ECIP-1116 resolves this by removing the uncertainty: miners receive ninety-five percent of BASEFEE immediately and deterministically, with no dependency on governance activation timelines or DAO deployment readiness. This lowers the political threshold for miner acceptance of ECIP-1111 without requiring any changes to the treasury contract, governance architecture, or funding proposal process.

Why Not One Hundred Percent to Miners

A full one hundred percent miner allocation eliminates the treasury funding stream and defeats the primary motivation for ECIP-1111. The five percent treasury allocation at current fee levels generates meaningful long-term development funding while being economically negligible relative to block rewards and priority fees. It also preserves the treasury’s role as the funding source for future governance-approved initiatives, including the infrastructure that sustains the fee market miners depend on.

Consensus Enforcement

The split must be enforced at the consensus layer rather than through smart contract logic or social conventions. A miner ignoring the treasury allocation would produce an invalid block under this specification, ensuring consistent application across all participants without relying on voluntary compliance.

Backwards Compatibility

This ECIP introduces a hard fork modifying the block finalization rules established in ECIP-1111. Clients that implement ECIP-1111 without this modification will treat the treasury allocation as one hundred percent; clients implementing this ECIP will apply the ninety-five / five split. Both sets of clients remain valid on their respective chains until the activation block.

If activated simultaneously with ECIP-1111, no client implementing only ECIP-1111 semantics will be in consensus post-fork. If activated as a subsequent fork, clients implementing ECIP-1111 without ECIP-1116 will diverge at the ECIP-1116 activation block.

All existing transaction types (Type-0, Type-1, Type-2) remain valid. ECIP-1017 block rewards are unaffected. The BASEFEE opcode (EIP-3198) continues to return the block base fee regardless of distribution mechanics.

Security Considerations

Hashrate Impact

The miner allocation eliminates any economic argument against supporting ECIP-1111 based on BASEFEE diversion. In practice the treasury allocation represents a negligible fraction of total miner revenue in all near-term eras. The security analysis for ECIP-1111 applies without modification — if anything, miner economic alignment with the upgrade strengthens network security by reducing the incentive for disruptive opposition.

Rounding

Wei-level precision must be maintained. The subtraction form defined in the specification ensures no dust accumulates in the state due to integer rounding. Clients should include specific test vectors for odd basefee_revenue values to verify correct rounding behavior.

Treasury Minimum Viable Funding

At current ETC transaction volumes, five percent of BASEFEE provides materially less treasury accumulation than ECIP-1111’s full redirect. This is an acceptable trade-off: the treasury accumulates more slowly but miners are meaningfully invested in the fee market from activation. The development funding level is still sustainable for client maintenance and public infrastructure at current and projected near-term fee volumes. Treasury allocation grows proportionally with network adoption, self-funding the infrastructure improvements that drive that adoption.

Implementation

Clients MUST modify block finalization to implement the split as specified. Reference implementation will be documented in the olympiadao/olympia-treasury-contract repository and relevant client branches prior to Mordor testnet activation.

Test coverage MUST include:

• Correct miner and treasury balances across Type-0, Type-1, and Type-2 transactions
• Zero BASEFEE blocks (both allocations zero, no state change)
• Rounding behavior at odd basefee_revenue values in wei
• Cross-client state equivalence under the split
• Era transition blocks confirming block reward independence

Copyright

Copyright and related rights waived via CC0.