UpdateOpinion

Why Not Olympia?

• By Istora Mandiri

The Ethereum Classic community has two paths forward for EIP-1559 adoption: Olympia (ECIP-1111) proposes a treasury-based system with on-chain governance, while ECIP-1120 takes a protocol-native approach with algorithmic fee redistribution. This article explains why ECIP-1120 better aligns with ETC's core principles.

The Fundamental Question

The difference between these proposals boils down to a single philosophical divide:

  • Olympia asks: "Who should decide how to spend accumulated fees?"
  • ECIP-1120 asks: "How do we stabilize mining revenue without anyone deciding?"

The first requires governance. The second requires math.

Complexity: One Variable vs. Five ECIPs

Olympia's Architecture

Olympia spans five separate ECIPs (1111-1115):

  • ECIP-1111: Core EIP-1559 implementation + treasury redirection
  • ECIP-1112: Olympia Treasury smart contract
  • ECIP-1113: DAO governance framework
  • ECIP-1114: Funding proposal process
  • ECIP-1115: Additional governance mechanics

Each layer introduces:

  • Smart contract execution overhead
  • Governance coordination requirements
  • Multiple potential failure points
  • Ongoing maintenance burden
  • Political attack surfaces

ECIP-1120's Architecture

ECIP-1120 is implemented entirely in consensus code with:

  • One state variable: reservoir_balance
  • Zero smart contracts: No execution overhead
  • Zero governance: Algorithmic distribution only
  • Zero discretionary spending: Pure math

Every additional component is a liability. ECIP-1120 minimizes components.

Performance: Consensus vs. Execution Layer

Where Olympia Puts Fee Handling

Olympia redirects base fees to a smart contract address during block finalization:

// Olympia approach (pseudocode from ECIP-1111)
baseFeeAmount = block.gasUsed * block.baseFee
state.addBalance(treasuryAddress, baseFeeAmount)

This treasury contract then:

  1. Accumulates ETH balance
  2. Executes governance logic (contract calls)
  3. Processes withdrawal requests (more contract calls)
  4. Interacts with DAO mechanics (even more contract calls)

Every interaction costs gas and requires EVM execution.

Where ECIP-1120 Puts Fee Handling

ECIP-1120 handles fees during block validation itself:

// ECIP-1120 approach (simplified)
base_fees_collected = Σ(gas_used × base_fee)
reservoir_balance += base_fees_collected

distribution_amount = calculate_flow_rate(reservoir_balance)
reservoir_balance -= distribution_amount
miner_reward += distribution_amount

Zero execution overhead. Zero gas costs. Zero external dependencies.

Fee redistribution happens at the same time block rewards are calculated—it's just consensus arithmetic.

Neutrality: Algorithmic vs. Discretionary

Olympia's Allocation Model

From ECIP-1114, the Olympia funding process requires:

  • Proposal submission (who gets to submit?)
  • Voting mechanisms (who gets to vote?)
  • Approval thresholds (who sets them?)
  • Disbursement execution (who triggers it?)
  • Ongoing governance (who maintains it?)

Every "who" question introduces a power center. Every power center introduces politics.

Even with the best intentions, discretionary allocation inevitably creates:

  • Rent-seeking behavior
  • Political capture risk
  • Favoritism concerns
  • Coordination overhead
  • Trust requirements

ECIP-1120's Allocation Model

ECIP-1120 has zero discretionary allocation:

  • Mine a block → receive subsidy + fees + reservoir distribution
  • Distribution is proportional to work performed
  • No voting, no proposals, no human decisions
  • Same rules for every miner, every block, forever

The protocol doesn't care who you are. It only cares that you solved the hash puzzle.

Attack Surface: Minimal State vs. Smart Contract Stack

Olympia's Attack Surface

Treasury smart contracts introduce:

  • Re-entrancy risks: Can governance calls be exploited?
  • Access control bugs: Are admin functions properly protected?
  • Upgrade vulnerabilities: Who can change contract logic?
  • Economic attacks: Can voting be manipulated?
  • Social engineering: Can governance be captured?

Even "immutable" contracts require:

  • Careful initial deployment
  • Extensive security audits
  • Ongoing monitoring
  • Governance to respond to exploits

The DAO hack demonstrated that smart contract treasuries can fail catastrophically.

ECIP-1120's Attack Surface

Protocol-level state introduces:

  • One integer variable: reservoir_balance
  • Basic arithmetic: Addition and division
  • Deterministic rules: No external calls
  • Consensus enforcement: Validated by every node

Attack vectors are limited to:

  • Consensus bugs (which affect all protocol rules equally)
  • Arithmetic overflow (prevented by standard safeguards)

There's nothing to hack because there's no contract to exploit.

The Philosophy Question

What Does "Protocol Neutrality" Mean?

Ethereum Classic claims to value protocol neutrality—the idea that the protocol itself shouldn't favor any particular party or use case.

Olympia's treasury requires asking:

  • Which projects deserve funding?
  • How much should each receive?
  • Who decides these questions?
  • What happens when we disagree?

These are political questions dressed up in technical clothing. No governance mechanism can avoid politics when allocating discretionary funds.

ECIP-1120 sidesteps politics entirely by asking:

  • Did you mine a block? ✓
  • Here's your proportion of the reservoir. ✓

No discretion. No politics. No governance. Just math.

Precedent Matters

ETC was born from rejecting The DAO bailout—a moment when Ethereum's community chose social consensus over code immutability.

Olympia's treasury model requires exactly the social consensus ETC was created to avoid. It asks the community to:

  • Trust governance mechanisms
  • Coordinate on spending decisions
  • Manage discretionary funds
  • Evolve governance over time

ECIP-1120 stays true to ETC's founding principle: Code is law. Not "code plus periodic governance decisions."

Real-World Parallel: Central Banks vs. Algorithms

This debate mirrors a broader philosophical question in cryptocurrency:

The Central Banking Model (Olympia)

  • Human discretion determines allocation
  • Committees decide who receives funding
  • Rules evolve through political process
  • "We're smart enough to manage this"

The Algorithmic Model (ECIP-1120)

  • Mathematical rules determine allocation
  • Code decides who receives funding
  • Rules are fixed unless consensus changes protocol
  • "We're not smart enough to avoid being corrupted"

Bitcoin chose algorithmic rules. Ethereum Classic chose immutability. ECIP-1120 continues this tradition.

The Simplicity Argument

From ECIP-1111's rationale:

"The Olympia upgrade introduces no additional consensus-layer complexity beyond the well-established specifications of EIP-1559 and EIP-3198"

This is technically true—the consensus layer just redirects fees to an address. But this statement ignores:

  • The smart contract complexity at that address
  • The governance complexity above that contract
  • The social complexity of maintaining governance
  • The political complexity of allocation decisions

Consensus complexity is only one type of complexity. System complexity matters more, and Olympia's system is vastly more complex than ECIP-1120's.

Lines of Code

Approximate implementation burden:

Olympia:

  • EIP-1559 implementation: ~1000 lines
  • Treasury contract: ~500 lines
  • Governance contract(s): ~2000 lines
  • Proposal logic: ~1000 lines
  • Frontend/tooling: ~5000 lines
  • Total: ~9500+ lines

ECIP-1120:

  • EIP-1559 implementation: ~1000 lines
  • Reservoir logic: ~100 lines
  • Total: ~1100 lines

Every line of code is a potential bug. Every governance interaction is a potential attack. Simplicity is a security feature.

What Olympia Gets Right

To be fair, Olympia correctly identifies several real problems:

  1. ETC needs EIP-1559 compatibility → ECIP-1120 agrees
  2. Burning fees is wrong for ETC → ECIP-1120 agrees
  3. Long-term security needs consideration → ECIP-1120 agrees
  4. Protocol funding could help the ecosystem → ECIP-1120 disagrees (but understands the appeal)

Olympia's diagnosis is largely correct. The disagreement is about the cure.

The Funding Argument

The main argument for Olympia is: "Things need to be funded."

Client development, infrastructure, research, community initiatives—all require resources. Olympia's treasury aims to create a sustainable funding source for ecosystem development.

Why This Argument Fails

First: Funds Already Exist

The ETC ecosystem isn't broke. Funds exist through:

  • ETC Cooperative: Established entity with funding mechanisms
  • Private development: Companies and individuals already building on ETC
  • Grants and sponsorships: Traditional funding channels that work
  • Community initiatives: Volunteer contributions and crowdfunding

The problem isn't lack of funds—it's coordination and allocation. Olympia's treasury doesn't solve coordination; it just moves it on-chain and adds governance overhead.

Second: DAO Redistribution Doesn't Solve Funding Problems

Olympia's governance model introduces:

  • Allocation disputes: Who deserves funding? How much?
  • Political capture: Voting power concentrates over time
  • Coordination costs: Proposals, voting, execution all require effort
  • Slow decision making: Governance takes time; urgent needs don't wait

Every treasury-based project in crypto faces these issues. Adding "DAO" doesn't make hard allocation decisions any easier.

Third: The Fees Are Too Small Anyway

Let's be realistic about the numbers:

Current ETC base fees would generate perhaps $10-50K per year at current activity levels. Even during high-activity periods, we're talking maybe $200-500K annually.

For comparison:

  • A single experienced protocol developer costs $150-300K/year
  • Client maintenance requires multiple developers
  • Infrastructure, security audits, research all need funding

The treasury would accumulate slowly and fund modestly. It's not a silver bullet for ecosystem development.

If you need significant funding now, you need traditional sources. If you're planning for decades-long accumulation, you're optimizing for a distant future while adding governance complexity today.

Fourth: Miner Revenue Matters More

Here's what actually threatens ETC's long-term viability: Mining becoming unprofitable.

If mining revenue drops too low:

  • Hashrate declines
  • 51% attacks become cheaper
  • Network security collapses
  • Nothing else matters

Olympia's treasury diverts fees to governance-controlled allocation. ECIP-1120's reservoir ensures miners receive stable, predictable revenue.

Which is more critical to ETC's survival?

The Real Question

It's not "Should ETC fund development?" Of course it should—through whatever means work.

The real question is: "Should protocol-level base fees be diverted to a governance-controlled treasury, or should they stabilize mining revenue?"

  • If you prioritize flexible ecosystem funding → Olympia
  • If you prioritize mining sustainability and protocol neutrality → ECIP-1120

One choice requires trusting governance. The other requires trusting miners to secure the chain—which is literally what PoW is designed for.

The Core Disagreement

The question isn't "Should ETC have protocol-level fee redistribution?" Both proposals say yes.

The question is "What should we do with accumulated fees?"

  • Olympia says: Let governance decide how to allocate them
  • ECIP-1120 says: Give them all to miners, automatically

One approach requires trust. The other requires math.

Conclusion: Math Over Governance

ECIP-1120 chooses:

  • Mathematical automation over human discretion
  • Minimal complexity over modular sophistication
  • Protocol neutrality over flexible allocation
  • Code determinism over governance evolution
  • Attack surface minimization over feature richness

These aren't just technical preferences. They're philosophical commitments about what Ethereum Classic should be.

Olympia offers more features and more flexibility at the cost of more complexity and more governance.

ECIP-1120 offers less flexibility and fewer features at the benefit of less complexity and zero governance.

For a chain born from rejecting discretionary protocol intervention, the choice should be clear.

Join the Discussion

This is a transparent, community-driven research process. We welcome your input:

Disagree with something here? Great! Submit a pull request or open an issue:

  • GitHub Repository
  • Propose edits, suggest improvements, challenge assumptions
  • All contributions and critiques are welcome

Have questions or counterarguments? Share them:

  • Comment on relevant ETC discussion threads
  • Write a response article (we'll link to it)
  • Engage constructively with the research

The best ideas emerge from rigorous debate. Help us make ECIP-1120 better—or convince us we're wrong.

Want to dive deeper? Read the full ECIP-1120 specification or explore Olympia's ECIPs to compare the technical details yourself.

← Back to Articles