Basefee Market with Miner Rewards

Abstract

This ECIP introduces a minimally complex implementation of EIP-1559 Ethereum Classic.

Thanks in part to more efficient transaction pricing and improved UX for end users, EIP-1559 has been adopted on many EVM chains. For Ethereum Classic to enjoy this benefit, and to maintain future compatibility with the wider ecosystem, including wallets and smart contracts, the adoption of this EVM standard is increasingly necessary.

As with EIP-1559, this ECIP proposes that users are given the option to price transactions using an algorithmic Basefee Market, via the opt-in "Type 2" transaction.

In Ethereum's implementation of EIP-1559, the Basefee is burned, but this is not practical for Ethereum Classic. Instead, this ECIP proposes that the Basefee is distributed in full to miners.

The contents of this ECIP represent an abridged summary of recommendations, excluding deeper explanations for brevity. In-depth research findings are linked in the Research Plan section.

Motivation

This ECIP exists partly in response to the ECIP-111X set of proposals.

In contrast, the goal of this ECIP is to find the least complex and most secure 1559-like implementation within real-world technical design constraints, rather than pursuing second-order ambitions. This means a math-only, protocol-native solution that distributes all fees to miners, without additional layers of complexity such as smart contracts or governance systems.

This proposal includes just enough self-contained, internally-consistent details to be implemented without creating new unanswered questions. The research conducted for this ECIP is published openly and may be useful for other ECIPs or chains exploring similar fee market mechanisms.

Specification

This ECIP consists of two key mechanisms that together enable the adoption of a 1559-like system for Ethereum Classic: a Basefee Market and a Basefee Distribution.

Basefee Market

The Basefee Market component is essentially a straightforward replication of relevant aspects of EIP-1559, with a Block Elasticity Multiplier optimized for ETC.

Type 2 Transactions

As defined in EIP-2718, Type 2 transactions are widely adopted across EVM chains. They allow users to specify a maximum fee and a priority fee (tip), with the protocol algorithmically determining the basefee based on network demand. Block elasticity allows blocks to temporarily exceed the target gas limit during demand spikes, with the basefee adjusting to bring utilization back to target. These mechanisms are detailed in the sections below.

As per EIP-1559, each transaction must satisfy:

assert transaction.max_fee_per_gas >= block.base_fee_per_gas
assert transaction.max_fee_per_gas >= transaction.max_priority_fee_per_gas
assert signer.balance >= transaction.gas_limit * transaction.max_fee_per_gas

priority_fee = min(transaction.max_priority_fee_per_gas, transaction.max_fee_per_gas - block.base_fee_per_gas)
effective_gas_price = priority_fee + block.base_fee_per_gas

Type 0 and 1 transactions will remain supported for legacy compatibility, with no schedule to deprecate.

Block Elasticity

EIP-1559 sets a block elasticity multiplier of 2x, and combined with Ethereum's current block gas limit of 60m, gives a maximum theoretical transaction size of 120m gas. This maximum transaction size, in theory, could be used to deploy large contracts or executions, and it may become important for future contract deployments or things like L2 state validation that consume large amounts of gas.

An opportunity arises for Ethereum Classic when designing this ECIP to achieve the goal of closer feature parity with Ethereum. By increasing the block elasticity multiplier from 2x, a higher value such as 4x, 16x, or 32x could be considered, enabling the same or greater maximum transaction size as Ethereum, and the contract operations this enables.

Research is ongoing to determine a suitable maximum elasticity value. The goal is to identify the highest safe multiplier given real-world hardware capabilities and network conditions on the Ethereum Classic network.

Basefee Calculation

The basefee adjusts dynamically based on network demand. When blocks are fuller than the target, the basefee increases; when blocks are emptier than the target, it decreases. This creates a self-correcting mechanism that targets 50% block utilization over time.

As per EIP-1559:

parent_gas_target = parent.gas_limit // ELASTICITY_MULTIPLIER

if parent.gas_used == parent_gas_target:
    expected_base_fee = parent.base_fee_per_gas
elif parent.gas_used > parent_gas_target:
    gas_used_delta = parent.gas_used - parent_gas_target
    base_fee_delta = max(parent.base_fee_per_gas * gas_used_delta // parent_gas_target // BASE_FEE_MAX_CHANGE_DENOMINATOR, 1)
    expected_base_fee = parent.base_fee_per_gas + base_fee_delta
else:
    gas_used_delta = parent_gas_target - parent.gas_used
    base_fee_delta = parent.base_fee_per_gas * gas_used_delta // parent_gas_target // BASE_FEE_MAX_CHANGE_DENOMINATOR
    expected_base_fee = parent.base_fee_per_gas - base_fee_delta

With BASE_FEE_MAX_CHANGE_DENOMINATOR = 8, the basefee can change by a maximum of ±12.5% per block.

BASEFEE Opcode

The 0x48 opcode will be introduced and will return current block's basefee, as specified in EIP-3198.

Basefee Market Parameters

Parameter selection requires client benchmarking (Core-Geth, Besu) and historical network analysis. Final values are subject to ongoing research.

Basefee Distribution

In EIP-1559, the basefee is burned to prevent miners from manipulating fees. However, burning is not practical for Ethereum Classic.

Under ECIP-1017, ETC has a fixed emission schedule with block subsidies decreasing 20% every 5 million blocks. Burning fees would interfere with this monetary policy, and as subsidies diminish during tail-end emissions, transaction fees are an increasingly important to miner revenue and chain security.

Various distribution mechanisms were considered. The proposed mechanism was the only solution identified that achieves all of the following requirements:

• Fees must go to miners to maximize security of the chain.
• Be protocol-native and maintain a clean separation of concerns between protocol and application layers.
• Disincentivize manipulation via empty block mining, spam transactions, or off-chain fee markets.
• Can be calculated statelessly, reducing attack surface and simplifying syncing after re-orgs.

The proposed approach is a backward-looking fee distribution, a form of "l-smoothing" as described in Roughgarden's analysis of EIP-1559 (Section 8.3.1). The miner of the current block receives a portion of the basefees collected from each of the previous N ancestor blocks. The specific parameters for this mechanism require further research.

A reference implementation is available in Besu. The following pseudocode illustrates the mechanism:

def calculate_distributed_fees(blockchain, parent_hash):
    total_fees = 0
    ancestor_hash = parent_hash

    for i in range(BACKWARD_FEES_BLOCK_COUNT):
        ancestor = blockchain.get_block_header(ancestor_hash)
        if ancestor is None:
            break

        # Each ancestor contributes a portion of its collected basefee
        ancestor_fee = (ancestor.base_fee * ancestor.gas_used) // BACKWARD_FEES_BLOCK_COUNT
        total_fees += ancestor_fee

        ancestor_hash = ancestor.parent_hash

    return total_fees

The miner's total reward becomes: block_subsidy + priority_fees + distributed_fees.

Smoothing fees across blocks also helps avoid a "death spiral" when the block subsidy approaches zero. Without smoothing, empty blocks offer no reward, removing incentive to mine them. This causes irregular block times, discouraging transactions, further reducing miner revenue and resulting a destructive feedback loop.

An alternative approach involving a subsidy accumulator or reservoir mechanism may also be explored. This would involve accumulating fees in a pool and distributing them over time, but introduces additional complexity around state management and re-org handling. Further research is needed to evaluate whether this approach offers benefits over the simpler backward-looking distribution.

Research Plan

Before moving from WIP to Draft, the following research will be completed. All findings will be published at https://ecip1120.dev.

Elasticity Multiplier Selection

Determine the optimal ELASTICITY_MULTIPLIER for ETC. Higher values (4x, 16x, 32x) enable larger maximum transaction sizes, achieving feature parity with Ethereum. This requires benchmarking client performance and network propagation to identify the highest safe value.

Client Benchmarking

Test Core-Geth and Besu performance at various elasticity multipliers and gas limits. Measure block processing time, propagation latency, and uncle rates to establish safe operating parameters.

Distribution Curve Design

Determine the optimal BACKWARD_FEES_BLOCK_COUNT and whether to use a uniform or decay curve. Analyze historical ETC block patterns to understand typical periods without transactions, and model how different curves affect miner incentives.

Economic Security Analysis

Model long-term miner revenue under various fee scenarios as block subsidies decline. Verify that the distribution mechanism maintains sufficient security budget through tail-end emissions.

Manipulation Resistance

Simulate attack vectors including spam transactions, empty block mining, and off-chain fee agreements. Verify the chosen parameters adequately disincentivize these behaviors.

Conclusion

This ECIP proposes a minimal implementation of EIP-1559 for Ethereum Classic, adapting the basefee market mechanism while distributing fees to miners rather than burning them. The backward-looking fee distribution preserves ETC's fixed monetary policy under ECIP-1017, maintains chain security as block subsidies decline, and resists manipulation through l-smoothing. Pending completion of the research plan, this proposal provides a path toward EIP-1559 compatibility while respecting Ethereum Classic's unique requirements.

References

• EIP-1559: Fee market change for ETH 1.0 chain
• EIP-2718: Typed Transaction Envelope
• EIP-3198: BASEFEE opcode
• ECIP-1017: Monetary Policy and Final Modification to the Ethereum Classic Emission Schedule
• Roughgarden, T. Transaction Fee Mechanism Design for the Ethereum Blockchain

License

This work is licensed under the Apache License, Version 2.0.