Research In Progress

Determining a Distribution Mechanism

• By Istora Mandiri

This article outlines the chain-of-thorught regarding to how an EIP-1559-like system could be adpated to Ethereum Classic. We explore the different possibilities for distributing the Basefee back to miners, and exlpain why we settled on the solution proposed in ECIP-1120.

At first glance, implementing 1559 may seem like a simple case of copy and pasting the code used in upstream projects. However, Ethereum Classic's unique situation prevents this, and exploration of alternative approaches was required to reach a suitable solution.

Burning

This is simple solution that is technically possible, but has two problems

  • We waste the resources needed to secure the chain
  • We are technically messing with

Treasury

Some had the bright idea of putting the funds in a treasury contract. We have a whole article dedicated to why this is a bad idea. To summarize:

  • A Treasury breaks
  • It adds additional bias
  • It removes the clean seaparation between protocol and application execution
  • Etc.

Accumulator

A simple approach would be to have a simple accumulator

But this introduces problems with re-orgs.

Try to explain, in detail, why.

Reservoir

Explore more, could this be done in a contract instead ?

L-Smoothing (Backward-Looking Distribution)

The solution we propose is a protocol-native "l-smoothing" mechanism, as described in Section 8.3.1 of Roughgarden's analysis of EIP-1559.

In EIP-1559, the basefee is burned to prevent off-chain agreements (OCAs) between miners and users. Roughgarden proves that if the basefee were simply paid to the block producer, miners could collude with users off-chain to bypass the mechanism entirely—users would pay the miner directly, the miner would include an empty-looking transaction, and both would benefit at the expense of the protocol's fee predictability.

However, burning fees is not viable for Ethereum Classic, where miner revenue is essential for chain security. Roughgarden's l-smoothing provides an alternative: instead of paying the basefee to the current block's miner, distribute it across the miners of the next L blocks.

This works because:

  1. Dilutes manipulation incentives: A miner manipulating the basefee only receives 1/L of the benefit, making attacks economically unfavorable.
  2. Preserves miner revenue: All fees eventually go to miners, maintaining the security budget.
  3. Stateless calculation: The distribution can be computed by looking backward at ancestor blocks, avoiding the need for persistent state.
# Backward-looking fee distribution (l-smoothing)
def calculate_distributed_fees(blockchain, parent_hash):
    total_fees = 0
    ancestor_hash = parent_hash

    for i in range(L):  # L = number of blocks to smooth over
        ancestor = blockchain.get_block_header(ancestor_hash)
        if ancestor is None:
            break
        # Each ancestor contributes 1/L of its collected basefee
        ancestor_fee = (ancestor.base_fee * ancestor.gas_used) // L
        total_fees += ancestor_fee
        ancestor_hash = ancestor.parent_hash

    return total_fees

The value of L requires careful selection. A larger L provides stronger manipulation resistance but delays when miners receive their fees. Research is ongoing to determine the optimal value for ETC's block time and network conditions.

TODO: What about empty blocks? How does the curve shape affect incentives?

← Back to Articles