ECIP 1120: Basefee Market with Miner Rewards

Abstract

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

EIP-1559 was introduced on Ethereum Mainnet in August 2021 during its London Hard Fork. Thanks in part to improved user experience and more efficient transaction pricing, EIP-1559 has achieved widespread adoption across many EVM chains. In turn, EVM-compatible wallets and smart contract systems are increasingly designed with the assumption that EIP-1559 is a baseline standard.

For users of Ethereum Classic to enjoy the benefits of 1559, and for the ETC protocol to maintain future-proof compatibility with the wider EVM ecosystem, the adoption of a 1559-compatible format is increasingly desirable. To this end, ECIP-1120 gives users 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, ECIP-1120 proposes that the Basefee is distributed in full to miners to maximize long-term security budget, which will become increasingly important during the tail-end of the emission curve in the coming decades.

This ECIP presents key recommendations, with assumed parameters summarized in the Key Parameters section.

Motivation

The goal of this ECIP is to identify the least complex and most secure 1559-like implementation within real-world technical design constraints.

ECIP-1120 presents a math-only, protocol-neutral, protocol-native solution that distributes all fees to miners without any smart contracts or a governance system. It is fully self-contained with no dependencies on other ECIPs; once provisional parameters are finalized, this specification provides everything needed for implementation.

Specification

ECIP-1120 consists of two key mechanisms - a Basefee Market and a Basefee Distribution - that together define a 1559-like protocol upgrade for Ethereum Classic.

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

Type 2 transactions, using the envelope format defined in EIP-2718, 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 Type 2 transaction satisfies the following validation rules:

// Pseudocode: Type 2 transaction validation and effective gas price calculation.
// Ensures the transaction can pay the Basefee and calculates the miner's priority fee.

// maxFeePerGas is at least the current Basefee
assert(transaction.maxFeePerGas >= block.baseFeePerGas);
// maxFeePerGas is at least the priority fee
assert(transaction.maxFeePerGas >= transaction.maxPriorityFeePerGas);
// Signer has sufficient balance for worst-case gas cost
assert(signer.balance >= transaction.gasLimit * transaction.maxFeePerGas);

// Priority fee is capped by either the user's specified max priority fee,
// or the remaining fee budget after paying Basefee (whichever is lower)
const priorityFee = min(
  transaction.maxPriorityFeePerGas,
  transaction.maxFeePerGas - block.baseFeePerGas
);
// Effective price paid per gas unit: Basefee goes to distribution, priority fee to miner
const effectiveGasPrice = priorityFee + block.baseFeePerGas;

BASEFEE Opcode

The 0x48 opcode returns the current block’s Basefee, as specified in EIP-3198.

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:

// Pseudocode: Basefee calculation for the next block.
// Adjusts Basefee up or down based on how full the parent block was relative to target.

// Calculate the target gas usage (equilibrium point where Basefee stays stable)
const parentGasTarget = parent.gasLimit / ELASTICITY_MULTIPLIER;

let expectedBaseFee: bigint;
if (parent.gasUsed === parentGasTarget) {
  // Block was exactly at target: Basefee remains unchanged
  expectedBaseFee = parent.baseFeePerGas;
} else if (parent.gasUsed > parentGasTarget) {
  // Block was above target: increase Basefee to reduce demand
  const gasUsedDelta = parent.gasUsed - parentGasTarget;
  // Calculate proportional increase, minimum of 1 wei to ensure upward pressure
  const baseFeeDelta = max(
    (parent.baseFeePerGas * gasUsedDelta) /
      parentGasTarget /
      // With a `BASE_FEE_MAX_CHANGE_DENOMINATOR` of `8`, 
      // the Basefee can change by a maximum of `±12.5%` per block.
      BASE_FEE_MAX_CHANGE_DENOMINATOR,
    1n
  );
  // New Basefee = previous Basefee + delta (fee increases)
  expectedBaseFee = parent.baseFeePerGas + baseFeeDelta;
} else {
  // Block was below target: decrease Basefee to encourage more transactions
  const gasUsedDelta = parentGasTarget - parent.gasUsed;
  // Calculate proportional decrease (can reach zero, no minimum)
  const baseFeeDelta =
    (parent.baseFeePerGas * gasUsedDelta) /
    parentGasTarget /
    BASE_FEE_MAX_CHANGE_DENOMINATOR;
  // New Basefee = previous Basefee - delta (fee decreases)
  expectedBaseFee = parent.baseFeePerGas - baseFeeDelta;
}

Basefee Distribution

In Ethereum’s implementation of EIP-1559, the Basefee is burned. Instead, ECIP-1120 proposes that Basefees are distributed to miners using a backward-looking mechanism, a form of “ℓ-smoothing” as described in Roughgarden’s analysis (Section 8.3.1).

In ECIP-1120, total miner rewards consist of:

• Block Subsidy - based on the ECIP-1017 emission curve, and
• Priority Fees - optional tips, as a fallback pricing mechanism when blocks are full, and
• Distributed Fees - a portion of the Basefees collected from each of the previous BACKWARD_FEES_BLOCK_COUNT ancestor blocks, calculated as follows:

// Pseudocode: Backward-looking fee distribution calculation.
// Sums a portion of Basefees from each of the previous BACKWARD_FEES_BLOCK_COUNT ancestor blocks.

function calculateDistributedFees(
  blockchain: Blockchain,
  parentHash: Hash
): bigint {
  let totalFees = 0n;
  // Start traversal from the parent block
  let ancestorHash = parentHash;

  // Iterate through the lookback window
  for (let i = 0; i < BACKWARD_FEES_BLOCK_COUNT; i++) {
    const ancestor = blockchain.getBlockHeader(ancestorHash);
    // Each ancestor contributes a portion of its collected Basefee.
    // Total Basefee collected = BaseFee * gasUsed (fee per gas × gas consumed).
    // Divide by block count to spread each block's fees across future blocks.
    // Distribute the remainder fairly to ensure sum(distributed_fees) == sum(collected_fees)
    const totalFee = ancestor.baseFeePerGas * ancestor.gasUsed;
    const baseShare = totalFee / BACKWARD_FEES_BLOCK_COUNT;
    const remainder = totalFee % BACKWARD_FEES_BLOCK_COUNT;
    // Distribute the extra 1 wei to the first 'remainder' blocks in the window
    const extra = i < remainder ? 1n : 0n;
    const ancestorFee = baseShare + extra;

    totalFees += ancestorFee;

    // Move to the next older block in the chain
    ancestorHash = ancestor.parentHash;
  }

  // Return the sum of fee portions from all ancestors in the lookback window
  return totalFees;
}

Key Parameters

The following parameters govern the behavior of ECIP-1120. See Parameter Selection for rationale.

*Assumed values cannot be finalized at this stage. Final values require client implementation and testing to determine optimal tradeoffs. See Research for details.

Rationale

Why Not Burn or Redirect?

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

Redirecting fees to a Treasury or DAO, in addition to reducing the security budget, introduces myriad governance complexities and smart contract dependencies.

Directing all transaction fees to miners, as is the case today:

• Keeps complexity and attack surface to a minimum
• Maintains protocol neutrality
• Sidesteps governance issues
• Leaves the social contract between miners and developers unchanged

Maximizing mining incentives prioritizes the security and long-term sustainability of the chain.

Why Smoothing?

An immediate payment to the block’s miner is vulnerable to manipulation via spam transactions and off-chain fee agreements. This ECIP instead distributes Basefees to miners using an algorithmic backward-looking smoothing mechanism.

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 in a destructive feedback loop.

Why Protocol-Native?

This ECIP keeps fee distribution logic at the protocol layer rather than delegating to smart contracts. Keeping this logic outside the EVM dramatically reduces complexity, making the mechanism simpler to implement, test, and audit across client implementations.

Crossing the protocol/application boundary introduces additional concerns:

• Attack surface - Smart contracts introduce reentrancy, overflow, and other vulnerability classes not present at the protocol layer.
• Governance capture - Governance systems are susceptible to capture, bribery, or manipulation by well-resourced actors.
• Code is Law - Embedding fee logic in contract state creates immutability expectations that may conflict with future necessary adjustments, potentially forcing contentious interventions that undermine ETC’s principles.
• Future adaptability - Protocol-layer logic can be optimized or modified in future hard forks, whereas contract-based solutions are constrained by EVM limitations and may miss opportunities for deeper integration or performance improvements.
• Resource overhead - Smart contract execution consumes gas and adds computational load to every block, whereas protocol-native logic executes outside the EVM with no gas cost.

A protocol-native approach maintains a clean separation of concerns. The protocol handles consensus-critical fee mechanics, while the application layer remains focused on user-facing functionality.

Why Stateless?

The backward-looking approach is deliberately stateless. The distributed fee amount is derived entirely from existing block header data, with no additional state variables required. This dramatically simplifies implementation, testing, and auditing.

A forward-looking accumulator would require stateful tracking that complicates re-org handling. When a reorg occurs, stateful data (such as an accumulator or reservoir balance) would require rolling back previous operations and tracking the history of changes to correctly restore state on the canonical chain. This adds implementation complexity, increases the attack surface, and imposes additional memory and disk costs during fork transitions.

Stateless calculation allows nodes to simply recompute the fee distribution from the new canonical chain’s block headers, requiring no rollback logic, no state corruption risk, and no additional storage beyond what is already required for block headers.

Block Elasticity Opportunity

In EIP-1559, the gas target is the equilibrium level where Basefee remains stable, while the gas limit is the maximum capacity per block. These are related by the formula gas_limit = gas_target × elasticity_multiplier. Blocks can vary between empty and fully utilized, with the Basefee algorithm incentivizing average utilization toward the target.

On Ethereum, EIP-1559 sets a block elasticity multiplier of 2x. With Ethereum’s current block gas limit of 60m, this means a gas target of 30m. Since individual transactions can consume up to the full block gas limit, this enables large contract deployments or executions such as L2 state validation that consume significant gas.

This ECIP presents an opportunity to bring Ethereum Classic closer to feature parity with Ethereum. Ethereum Classic’s current limit of 8 million is controlled by miners, but client defaults recommend this conservative value to minimize state bloat.

By increasing the block elasticity multiplier from 2x, a higher value such as 4x, 16x, or even 32x could be considered, enabling maximum transaction sizes equal to or greater than Ethereum, supporting large contract deployments and L2 settlement operations. Crucially, this can be achieved while still maintaining a much more conservative average block size and thus minimal state bloat over time, more in line with the Ethereum Classic ethos.

The goal is to identify a reasonable multiplier given real-world hardware capabilities and network conditions on the Ethereum Classic network, including how the Basefee adjustment rate interacts with higher elasticity values.

Determining Distribution Parameters

The backward fees block count balances client performance (fewer calculations per block) against sufficient smoothing to achieve the desired incentive properties. This ECIP currently specifies a uniform distribution curve; alternative curves such as exponential decay may be explored in future work. Final values require implementation and testing across ETC clients to determine optimal tradeoffs.

Backwards Compatibility

Legacy Transactions

Type 0 (legacy) and Type 1 (EIP-2930 access list) transactions remain fully supported. These transactions are treated as having maxFeePerGas = maxPriorityFeePerGas = gasPrice, ensuring backwards compatibility with existing transaction workflows.

Block Header Changes

This ECIP adds a BaseFeePerGas field to the block header, as specified in EIP-1559. This field is RLP-encoded as a 256-bit integer appended to the existing header structure. The block hash calculation includes this new field, making post-fork blocks incompatible with pre-fork clients.

Wallet and Tooling Compatibility

Wallets and tooling that support EIP-1559 on other EVM chains work with minimal changes. Gas estimation APIs account for the Basefee, and transaction signing supports the Type 2 envelope format per EIP-2718.

Client Requirements

A hard fork is required. ETC clients (Core-Geth, Besu) upgrade before the activation block. Non-upgraded nodes reject post-fork blocks and fork onto an incompatible chain.

Security Considerations

51% Attack Resistance

Since all fees are returned to miners, total miner compensation remains essentially unchanged compared to the current fee market, with no reduction in security budget other than a reduction in mispriced transactions. This contrasts with fee-redirection mechanisms that permanently remove value from the security budget. As block subsidies decline under ECIP-1017, maintaining full fee distribution to miners becomes increasingly important for sustaining the cost of 51% attacks.

Manipulation Resistance

The distribution mechanism is intended to satisfy key incentive compatibility properties as defined in Roughgarden’s analysis: MMIC (myopic miner incentive compatibility, Section 5), UIC (user incentive compatibility, Section 4), and OCA-proofness (off-chain agreement proofness, Section 6). Formal verification of these properties under ECIP-1120’s specific parameters is an area for future research; see Research.

Resource Exhaustion Attacks

Increased block elasticity expands the potential for denial-of-service attacks where adversaries submit computationally expensive transactions to slow block processing or network propagation. Client benchmarking establishes safe parameter values for specific hardware configurations. Elasticity and gas limit values are chosen to ensure that even worst-case blocks (maximum gas, adversarial transaction patterns) can be processed within acceptable time bounds on recommended node hardware.

MEV-related Attacks

Miner Extractable Value (MEV) refers to profit that miners can extract by reordering, inserting, or censoring transactions within blocks. High-value blocks create incentives for chain reorganizations to capture outsized rewards.

Fee smoothing via backward-looking distribution reduces block reward variance, decreasing the incentive to re-org for high-fee blocks. Since fees are distributed across multiple blocks, no single block presents an outsized MEV opportunity.

Research

Certain parameter values cannot be reasonably finalized until the mechanism is implemented and tested across ETC clients. The companion research site at ecip1120.dev tracks this work, covering economic security modeling, elasticity multiplier benchmarking, distribution curve design, client performance testing, and reference test vectors. This ECIP remains the authoritative specification; any consensus-critical changes will be made here via PR.

Implementation

ECIP-1120 is designed for deployment in a single hard fork. All components (Type 2 transactions, Basefee calculation, fee distribution, BASEFEE opcode) activate together at a designated block height, preventing partial implementations that could create unexpected behavior or security gaps.

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, maintains chain security as block subsidies decline, and resists manipulation through ℓ-smoothing. 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-2930: Optional access lists
• 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

Copyright and related rights waived via CC0.