ECIP 1111–1114 Discussion: Olympia Upgrade — Protocol Funding and Governance Suite

[chris-mercer]

ECIP 1111–1114 Discussion: Olympia Upgrade – Decentralized Protocol Funding & Governance

Olympia is the product of nearly a decade of Ethereum Classic community dialogue on sustainable funding.
It is the only realistic, open, and decentralized protocol funding framework proposed for Ethereum Classic since the Genesis Block on July 30, 2015.

Olympia consists of four coordinated ECIPs — 1111 through 1114 — that together create ETC’s first protocol-native, non-inflationary, DAO-governed treasury.
The system is fully ECIP-1000 compliant, designed for open review, and opt-in by nature: participation is voluntary, and all changes are implemented through transparent, modular upgrades that preserve consensus integrity.

The Four ECIPs

#	Title	Summary
1111	Olympia EVM & Protocol Upgrades	Activates EIP-1559 and EIP-3198 on ETC, redirecting BASEFEE to a public treasury instead of burning it.
1112	Olympia Treasury Contract	Immutable, consensus-recognized vault for redirected BASEFEE revenue.
1113	Olympia DAO Governance Framework	Modular, tokenless-at-launch DAO with on-chain voting and time-locked execution of treasury disbursements.
1114	Ethereum Classic Funding Proposal Process	Standardized, permissionless process for proposing, voting on, and executing funding requests.

These proposals embed transparency, neutrality, and sustainability into ETC’s base layer — funding clients, infrastructure, audits, and tooling without inflation, discretionary grants, or off-chain gatekeepers.

Key Properties

• ECIP-1000 Compliant – Authored, reviewed, and progressed through the established Ethereum Classic ECIP process.
• Opt-In by Nature – No participant is required to submit or vote on proposals; governance and funding are voluntary and at the application layer.
• Modular Activation – Each ECIP can be reviewed, tested, and activated independently, with no forced dependency on the full suite at once.
• Consensus Safety – Core protocol changes are limited to EIP-1559 and EIP-3198 activation and BASEFEE redirection logic; all governance is isolated from consensus.
• Unique in ETC History – First viable on-chain, decentralized funding mechanism in ETC’s ten years, addressing long-standing infrastructure sustainability challenges.

How to Participate

The final drafts incorporate all major community feedback from earlier review stages.
We now seek focused input on:

• Technical review — protocol, contract, and governance architecture
• Ecosystem readiness — tooling, client support, and integration
• Values alignment — consistency with ETC’s principles of immutability, neutrality, and decentralization

Read and comment on the ECIPs here: GitHub Discussion: ECIP-1111 to ECIP-1114

---

These proposals represent a historic opportunity to secure Ethereum Classic’s development future — and to set a precedent for decentralized funding across the Proof-of-Work ecosystem. Now is the time for the community to review, discuss, and help finalize them.

[chris-mercer]

The Olympia Introduction Series:

1. What’s Olympia? Why Now?
   Introduces the Olympia Upgrade and why Ethereum Classic needs it today.

2. Miners, Not Middlemen: How Olympia Protects Proof-of-Work on Ethereum Classic
   Explains how Olympia aligns incentives between miners, users, and developers without compromising PoW.

3. How the Olympia DAO Works (and What It Doesn’t Do)
   Unpacks ECIP-1113 and clarifies the limits and responsibilities of Olympia’s governance layer.

4. A Decade of Donor Dependence: Why Olympia Is ETC’s Path to Real Independence
   Reviews ETC’s funding history and why protocol-native funding is essential for sustainability.

5. Olympia: The First Decentralized Treasury Framework Designed for Proof-of-Work
   Technical breakdown of ECIPs 1111–1114 and how Olympia compares to ECIP-1098 and ECIP-1051.

6. The Olympia Treasury Is Neutral: How BASEFEE Redirection Respects ETC’s Monetary Policy
   Deep dive into ECIP-1111’s use of EIP-1559. Highlights how Olympia avoids inflation and central control over funds.

7. Freedom to Build: Why Olympia Is a Voluntary Upgrade to Ethereum Classic
   Clarifies that Olympia is fully opt-in, backward compatible, and aligned with ECIP-1000 — empowering users and builders without forcing participation or altering existing functionality.

8. Decentralization Is What You Do — Not What You Say
   Demonstrates how Olympia enforces Ethereum Classic’s founding values through ECIPs 1111–1114 by embedding decentralization into protocol design. Highlights permissionless funding, immutable contracts, and voluntary governance as mechanisms — not ideologies — that ensure no one controls ETC’s future, yet everyone can contribute.

9. The DeFi Stack Is Rising — How Olympia Positions Ethereum Classic as the Financial Layer for Proof-of-Work
   Demonstrates how Olympia secures ETC’s infrastructure, unlocks DeFi composability, and enables ETC to serve as a sovereign PoW settlement layer.

10. The Final Piece Toward Sovereignty
    Reflects on Ethereum Classic’s decade-long mission to resist centralization and achieve true independence. Shows how Olympia completes ETC’s foundational architecture, enabling sustainable, decentralized funding without compromise — and opens a new chapter for the PoW ecosystem built on neutrality, composability, and protocol-level coordination.

Other Olympia Articles:

• Olympia Upgrade: Protocol Funding and Governance for Ethereum Classic

• Ethereum Classic: The Olympia Upgrade. A Simplified Explainer

• Ethereum Classic’s Olympia Upgrade: Unlocking On-Chain Funding and Future Sustainability

• Funding ETC Without Compromise: Olympia vs. Legacy Proposals

[HebeBlock]

Some questions:

1.Inconsistent with ETC PoW Ethos

This EIP contradicts the Proof of Work (PoW) spirit of ETC.
Currently, PoW chains like BTC, LTC, and BCH have never established a similar mechanism to allocate transaction fees to a DAO organization.

Even ETH has adopted a burning mechanism instead of a similar allocation approach.

2.ETC No Need Official Team

The reference chains mentioned in the EIP, such as Ronin Network, Celo, Mantle, Polygon CDK, and OP Stack, are all supported by official teams, which provides justification for them to implement such mechanisms. However, ETC does not need such an official team.

3.Minimal Impact of DAO ImplementationAccording to Chris Mercer's description in his Medium article, before the Olympia upgrade, ETC miners earned only about $20 per day from transaction fees, indicating a very weak fee system. Implementing a DAO would not significantly change the ecosystem, as $20 per day equates to only $7,300 per year. If $7,300 per year is sufficient to develop the ETC ecosystem, then the funds Chris Mercer has received from etcgrantsdao over the years should have been more than enough.

4.Entity Issue Conflicts with Decentralization PrinciplesThe entity

mentioned in the EIP still seems to conflict with the decentralization principles of ETC PoW. The EIP states: "While the Olympia DAO governs proposal approval and treasury disbursement on-chain, all off-chain administrative and compliance functions — including fiat conversion, tax reporting, Bank Secrecy Act (BSA) and Know Your Customer (KYC) compliance, and contractor engagement — shall be facilitated by Ethereum Classic DAO LLC, a Wyoming-registered DAO entity.

[HebeBlock]

Oh, here is another question, does the implementation of this EIP require a hard fork, or does it only require core-geth support?

[chris-mercer]

Thanks for the thoughtful questions — I’ll do my best to clarify.

“As long as users use type-2, will the Fee enter Olympia DAO?”

Yes, but only the basefee portion — not the entire transaction fee. Type-2 transactions (introduced by EIP-1559) separate the total fee into a tip (which still goes to miners) and a basefee (which, in Olympia, is redirected to the treasury instead of being burned like on ETH).

So if users voluntarily opt into Type-2, miners still receive full block rewards and all tips. Olympia simply gives users a choice: they can stick with Type-0 (current ETC behavior), or use Type-2 if they want to support public goods through their activity.

“Isn’t this Olympia DAO tearing a hole in ETC’s fee structure?”

Not at all — because nothing is subtracted from existing rewards. Type-0 transactions are untouched. Olympia doesn’t “take” from miners or users. It adds an optional lane for users who wish to support the ecosystem. The analogy would be introducing a toll road next to a free highway — no one is forced to change lanes.

“ECIP-1098 vs Olympia: mandatory vs voluntary”

Exactly. This is the key distinction:

• ECIP-1098 imposed a mandatory 20% tax on all block rewards, cutting into miner income and giving control to Gitcoin and a few chosen teams.
• Olympia’s ECIPs (1111–1114) are 100% opt-in and only apply to a new transaction type that users/devs choose to use. Miners are never penalized. Participation is voluntary at every layer.

“ETC is more like BTC, not ETH — and few use dApps”

That’s fair — and that’s why Olympia is designed to start at $0. No funds are collected unless useful dApps are built and adopted. It creates incentives to build the kind of apps ETC currently lacks. If the ecosystem stays inactive, the treasury remains empty. That’s not a flaw — it’s the mechanism working as intended.

This way, the network avoids upfront taxation or forced redistribution and instead allows for bottom-up funding, based entirely on usage. If ETC remains a “hold-only” chain, Olympia won’t change much. But if builders want to engage, now they have a fair, transparent system to do so.

“Does this require a hard fork?”

Yes. ECIP-1111 introduces changes to gas handling (EIP-1559, EIP-3198) and adds the logic to redirect basefee to the Olympia Treasury (per ECIP-1112). This requires a coordinated hard fork with Core-Geth and other ETC client implementations if they exist.

---

Olympia respects ETC’s ethos by offering a voluntary, transparent, and decentralized funding path — with zero impact on those who choose not to participate. It doesn’t shake the consensus — it provides an opt-in mechanism for those who want to build something more. Thanks again for your comments and for helping push the conversation forward.

[HebeBlock]

So this is not a free choice for users, you took away the fee of type-2.

Although you claim that users can use type-0, you still took away the fee that belongs to miners.

And this requires a hard fork to achieve, which represents a more dangerous EIP.

[HebeBlock]

1. Enhanced User AutonomyBy allowing users and dApps to decide where the base fees from type2 transactions are sent—rather than mandating a single recipient like Olympia DAO—this approach gives the ETC community greater control.

This aligns seamlessly with ETC’s core ethos of decentralization, empowering individuals to support the causes or organizations they value most.

2. Flexibility and InnovationThis mechanism opens up a dynamic funding avenue for DAOs and projects within the ETC ecosystem. Developers can tailor type2 transaction settings to channel fees toward specific initiatives or DAOs, encouraging user participation and fostering innovation. This flexibility could inspire a wave of diverse projects, strengthening ETC’s appeal to creators and builders.

3. Decentralized GovernancePermitting users to choose the destination of their fees prevents the concentration of funds in a single DAO, mitigating the risk of centralized control. This “market-driven” governance model lets users vote with their transactions, supporting projects they believe in and ensuring a more equitable distribution of resources across the ecosystem.

4. Boosted Community EngagementWhen users can directly fund DAOs or projects they trust, it fosters a stronger sense of involvement and ownership within the ETC community. This bottom-up approach to resource allocation reflects the community’s true priorities and preferences, enhancing participation and loyalty.

5. Compatibility with ETHSetting the default fee recipient as the 0x000 address (akin to ETH’s fee-burning mechanism) maintains compatibility with Ethereum’s standards. At the same time, the option to customize fee destinations adds a layer of versatility unique to ETC, potentially attracting developers seeking more adaptable blockchain solutions.ConclusionThis design preserves ETC’s Proof-of-Work spirit and decentralized principles while granting users and developers unprecedented freedom.

By enabling the community to direct fees as they see fit, ETC can achieve a more adaptable and diverse funding model, driving the ecosystem’s growth and resilience.

[chris-mercer]

Thanks for your thoughtful input, Hebe — and for engaging meaningfully in the ECIP-1000 process. These Olympia ECIPs are in open draft precisely to invite this kind of constructive, community-driven thinking. We truly appreciate your contribution.

Your idea to give users or dApps more control over BASEFEE routing reflects a desire for flexibility and user empowerment — values that align closely with ETC’s ethos. That said, there are some practical risks and limitations to consider:

⚠️ Risks with User-Directed BASEFEE

• The BASEFEE (per EIP-1559) is protocol-defined and not user-configurable — it must follow deterministic logic to preserve network consensus.
• Introducing per-user or per-dApp fee routing would break compatibility with the EVM standard and create security risks such as DoS vectors and unpredictable miner behavior.
• It would also fragment funding flows, making it harder to sustainably support shared infrastructure.

✅ Why Olympia Offers a More Reliable Path

Olympia redirects the BASEFEE — which would otherwise be burned — into a single, auditable on-chain treasury. This creates a sustainable, non-inflationary funding stream for core protocol needs, such as:

• Maintaining Core-Geth and other consensus-critical software
• Funding security audits and client upgrades
• Supporting ecosystem tooling that benefits all stakeholders

This design keeps ETC fully compatible with Ethereum’s EVM (including Type-2 transactions) while empowering the community through transparent, on-chain governance.

🛠️ Governance Will Evolve With ETC

We recognize your concerns around governance, especially in ECIP-1113. The proposed DAO architecture is modular, upgradeable, and intentionally flexible — not locked in stone. The goal is to launch with safe defaults and evolve governance collaboratively over time.

Right now, the immediate need is simple but urgent: ensure critical infrastructure like Core-Geth doesn’t go unfunded. Olympia gives ETC a principled, practical way to meet that need — while laying the foundation for a broader ecosystem to grow on top.

Thanks again for your contribution — looking forward to more back-and-forth as we iterate together. 💚

[IstoraMandiri]

Thank you for your work on preparing this set of proposals.

First a note on the "Requires" field. While it is true that ECIPs 1111, 1112, and 1113 could be applied in a specific order, they are in fact interdependent. ECIPs 1111 and 1112 depend heavily on whether ECIP 1113 is viable. For this reason, perhaps they be grouped together, as is this discussion, into a single ECIP or processed as a collective proposal, or all be explicit that they "Require" each other (i.e. 1111 cites 1112, 3 and 4 as required)?

ECIP-1111 - Fee Market Change

This proposal introduces additional complexity by incorporating EIP-1559. Before proceeding, it is recommended that a separate ECIP be created to assess and debate the merits of implementing EIP-1559 on its own, prior to introducing other Olympia-related features or concepts such as the Ethereum Classic DAO LLC. This approach would keep the discussion focused and isolated from unrelated concerns.

Alternative options to consider include:

• Not implementing EIP-1559
• Implementing EIP-1559 with burned fees
• Implementing EIP-1559 and routing fees to an inactive "treasury" address
• Implementing ECIPs 1111, then 1112, etc. sequentially
• Implementing ECIPs 1111–1114 simultaneously

Clear, strong arguments are needed to justify any particular path forward, based strictly on the standalone merits of the fee market change, independent of treasury mechanisms, as 1559 is a core feature of the protocol.

Additionally, this ECIP introduces the concept of execution “off-chain by Ethereum Classic DAO LLC as a legal interface for compliance, payments, and treasury administration.” This raises serious centralization concerns that have not been adequately discussed. This aspect requires far more scrutiny.

ECIP 1112 + 1113 - Treasury Contract & DAO Governance

If the treasury contract is truly non-upgradable, is there a compelling reason to separate ECIPs 1112 and 1113? It may be worth combining them for simplicity.

Problem with Using Other EVM Networks as Precedent

Citing "other EVM networks" as precedent is problematic because many of those chains are already centrally owned or operated. Ethereum Classic does not have such central authorities, so implementing similar governance structures raises a core question: who controls or owns the LLC, how are voting tokens distributed, and ultimately, who or what entity is likely to control the DAO in practice?

Ambiguity in Contract Specifications

The proposal currently uses vague language such as "MAY" in sections that should be precise and normative. Governance specifications must be explicit — ideally identifying and recommending exact smart contract mechanisms and libraries. For instance, while the ECIP notes inspiration from frameworks like OpenZeppelin Governor and Compound Governor Bravo, it must go further by making concrete recommendations to guide discussion and implementation.

Inconsistencies in Governance Model

The ECIP currently describes multiple, conflicting governance models. It references a "stake-based or reputation-based system" but later points to token-based voting mechanisms (e.g., gETC, veOLY). It is unclear which model is intended. Additionally, the proposal does not describe how these tokens are distributed, which is critical to understanding who holds power and how voting influence is derived.

Explicit Definition of Governance Mechanisms

Key governance parameters and mechanisms must be clearly specified to avoid ambiguity and ensure system integrity. The ECIP should address:

• Quorum configuration: Who sets or modifies the quorum? Is a quorum needed to change the quorum itself?
• Emergency and veto mechanisms: What exact mechanisms exist, and how are they triggered or limited?
• Upgrade process: Who has authority to initiate and approve upgrades, and under what conditions?
• Timelock mechanics: Define how timelocks work (including quadratic variants if proposed), with examples showing configuration details and responsible parties.
• Configurable thresholds: Specify all relevant voting thresholds and who has the authority to adjust them.

These parameters must be implemented through transparent, deterministic mechanisms that minimize centralization risk and encourage robust community oversight.

Fallback Multisig Transparency and Risks

If a fallback multisig is to be included, its design must be fully transparent. Specifically, the ECIP must clearly specify:

• Who the initial signers are likely to be (by address or known public identity)
• How they are selected (e.g., community vote, reputation, appointment - if appointment, why)
• How to guarantee integrity of the selection process
• What their powers and limits are (e.g., veto, pause, or upgrade capabilities)
• What quorum is required to take action
• How signers can be added, removed, or rotated

Failure to define these aspects introduces a significant centralization risk. A poorly specified multisig could become a shadow governance mechanism, undermining the DAO’s autonomy. All governance fallbacks must be auditable, decentralized, and clearly bounded.

Role of the Ethereum Classic DAO LLC

The proposed Ethereum Classic DAO LLC would serve as a legal interface for the DAO, handling off-chain operations such as executing payments, signing legal documents, and managing treasury assets. Its relationship to the on-chain governance system and the fallback multisig must be clarified.

Critical questions include:

• Does the LLC act solely as an executor of DAO-approved decisions, or can it override them?
• Are the fallback multisig signers also LLC members, or are they independently chosen?
• What legal authority does the LLC have if DAO and LLC decisions conflict?
• In case of litigation or legal compromise, does the LLC maintain discretionary power?

Without precise boundaries, the LLC could effectively centralize control over decisions intended to be decentralized. The ECIP must define the LLC’s scope, responsibilities, and limitations to ensure alignment with Ethereum Classic’s decentralization ethos.

Recommendation: Phase DAO Development Before ECIPs 1111/1112

There is strong rationale for testing and refining DAO governance mechanisms independently before integrating them with ECIPs 1111 and 1112. A phased roadmap could involve deploying governance contracts, experimenting with quorum and participation thresholds, and stress-testing mechanisms under real-world conditions.

This approach would provide practical data to inform later decisions and help avoid premature coupling of untested governance models with critical fee market or treasury mechanisms.

In short, determining whether a DAO governance framework is viable — both technically and socially — should precede final decisions on ECIPs 1111 and 1112.

Additional Concerns (per ethereumclassicclassic.org):

These critical concerns must be addressed explicitly:

• UX: A Missing Piece – Who maintains and funds this infrastructure?
• Network Interaction Risk - Is it fair to add this burden to ETC holders?
• Coin Votes - Why do we assume that voting should be based on ETC ownership? Doesn't this put too much power into the hands of a few whales (or new whales), who do not have the same interests or philosophy as long time contributors who may not have a lot of ETC?
• The Impossible Quorum - Mentioned above, very difficult to find the balance of what voting threshold should be allowed (even more so for important contract updates)
• Disincentive Structure - Gas costs make it so that low-value ETC holders pay relatively more than big holders to interact.
• A Hacker’s Paradise - Network inherits risks based on added complexity.
• Denial of Service Vectors, Decentralized Autonomous Pwnage, Weaponized DeFi - These attacks should be considered and addressed specifically in the smart contract proposal.

Each of these risk categories should have corresponding mitigation strategies documented in the relevant ECIP(s).

---

I will not comments on 1114 for now, as it's implementation appears to rely heavily on answers to the above.

Once again, thank you for your proposal and I look forward to discussing further.

[chris-mercer]

Response: ECIP Structure, Dependencies, and Criticism Resolution Matrix

Thanks for your detailed review and suggestions. You are correct that ECIPs 1111–1114 are interdependent, and that this relationship should be made more explicit.

We split the proposals to align with the ECIP-1000 standard — keeping protocol change (1111), treasury (1112), governance (1113), and process (1114) modular and auditable — but they are intended to activate together as a single upgrade. None are viable in isolation.

Planned updates in the next draft:

Update the Requires: field on each ECIP to explicitly list 1111–1114 as dependencies.

Add a shared rollout summary and cross-link each ECIP at the top.

Include a unified activation section to make sequencing clear.

For the broader governance, legal interface, and technical design concerns you raised, we’ve mapped each one to the relevant ECIP in the Olympia Upgrade: Criticism Resolution Matrix here:
https://github.com/orgs/ethereumclassic/discussions/530#discussioncomment-13758474

That table documents how the current drafts address issues such as EIP-1559 evaluation, DAO LLC scope, governance model clarity, quorum and threshold configuration, fallback multisig transparency, and execution safety. It also incorporates feedback from multiple reviewers (including your earlier comments) into the redraft now under review.

This is exactly the kind of iterative refinement the open review phase is meant to produce. Appreciate your engagement — looking forward to your thoughts on the updated drafts once the dependency and rollout clarifications are in place.

[IstoraMandiri]

Thank you for the reply.

With regards to the implementation details, as you mention, I should wait for the next version to continue the discussion.

In the meantime, could you provide more information about the veOLY sytem you reference, so I can familiarize myself?

A google search returns this ECIP as the only reference with regards to Etheruem.

[chris-mercer]

You can start reviewing the next draft with valid criticism or feedback addressed here:
#535

[Soteria-Smart-Contracts]

@IstoraMandiri it is apparent that the goal here is to flood the github, socials and more with information that is generated by AI, often times not referable to any real documentation or concept. It is difficult to avoid questioning the intent of such proposed changes if transparency is what we see above, with your valid question of "In the meantime, could you provide more information about the veOLY sytem you reference, so I can familiarize myself?" being met with "You can start reviewing the next draft with valid criticism or feedback addressed here:
#535", a blatant insult to your expertise and time spent working on Ethereum Classic.

@chris-mercer Please follow up on the questions set out by @IstoraMandiri, Thank you

[chris-mercer]

Thank you for the question regarding the veOLY reference in ECIP-1113.

This was already discussed with @IstoraMandiri last month in a live chat. The record is public and clear — continued speculation — including recurring mischaracterizations from Wedergarten (@Soteria-Smart-Contracts), who previously launched the ClassicDAO (CLD) token sale — misrepresents the intent of the ECIP.

veOLY is a placeholder example of a potential modular governance extension — it is not active, not required, and not part of the initial launch.

It draws inspiration from the ve(3,3) model used in protocols like Curve and Solidly, where:

• ve = vote-escrowed (users lock tokens for voting power)
• (3,3) = game-theoretic alignment to reward long-term commitment

In Olympia’s case:

• No governance token is launched at genesis
• veOLY is mentioned only as a modular, opt-in extension that could be proposed via future ECFPs
• The DAO launches as tokenless, with a minimal, immutable contract suite designed to evolve safely over time

Olympia supports future voting logic (e.g., veOLY, quadratic voting, soulbound rep) — but none are required or preconfigured.

🧱 For reference:

• ECIP-1113: Olympia DAO Governance Framework
• ECIP-1114: ETC Funding Proposal Process

Appreciate the review and happy to clarify further if needed.
Please refrain from further misrepresentation within the ECIP-1000 process. Constructive feedback is welcome, but deliberate confusion undermines open governance.

[chris-mercer]

Summary of Olympia Upgrade Resolution Matrix (Updated August 2025)

The Olympia Upgrade addresses all major community criticisms through four modular ECIPs (1111–1114) that emphasize transparency, decentralization, and security.
Key design choices — such as no governance token at launch, non-inflationary BASEFEE redirection, immutable Treasury contracts, and fallback emergency governance — ensure alignment with Ethereum Classic’s Proof-of-Work ethos and monetary policy (ECIP-1017).

Treasury misuse is prevented by hash-bound, chain-ID-protected proposal execution (ECIP-1112/1114) and DAO-only authorization (ECIP-1113).
Spam and plutocracy concerns are mitigated by quorum rules, cooldowns, structured templates, and upgradeable voting models.
Developer and infrastructure concerns are addressed through predictable ECFP workflows, milestone-based disbursements, and recurring Child-DAO funding streams.
Legal risks are reduced by confining the DAO LLC to a narrow, auditable execution proxy role, strictly subordinate to on-chain governance.

Together, Olympia implements a principled, future-ready funding system for Ethereum Classic — modeled on proven EVM ecosystem practices, while preserving ETC’s immutability, Proof-of-Work identity, and fixed monetary schedule.

---

✅ Olympia Upgrade: Criticism Resolution Matrix

This table maps all major community criticisms to the relevant ECIP(s) and confirms whether the issue is addressed in the current drafts.

Topic	Criticism Summary	ECIP(s)	Resolution	Notes
Plutocracy Risk	Token voting may allow whales to dominate governance	ECIP-1113, ECIP-1114	✅ Addressed	No token at launch; upgrade paths include quadratic, delegated, or reputation-based voting.
Legal Capture / DAO LLC Overreach	LLC might override DAO authority	ECIP-1113, ECIP-1114	✅ Addressed	DAO LLC is execution proxy only; cannot hold keys, veto proposals, or bypass DAO instructions.
Miner Incentive Dilution	Redirecting BASEFEE harms miners	ECIP-1111	✅ Addressed	Miner tips remain untouched; BASEFEE redirected to Treasury in line with ECIP-1017 fixed supply.
Loss of Fee Burn / Supply Discipline	BASEFEE burn supports scarcity narrative	ECIP-1111	✅ Addressed	Scarcity preserved under ECIP-1017; redirection funds security/infra instead of permanent burn.
DAO Inactivity / Low Quorum	Governance could stall with low participation	ECIP-1113	✅ Addressed	Quorum enforced; fallback emergency multisig limited to pause/reset powers.
Execution Safety (Replay Attacks)	Proposal replay could double-spend across forks	ECIP-1112, ECIP-1114	✅ Addressed	Proposal hashes include (ecfpId, recipient, amount, metadataCID, chainid); one-time execution enforced.
Fund Misuse / Spam Proposals	DAO could be flooded with junk proposals or malicious asks	ECIP-1114	✅ Addressed	Draft gating, cooldowns, structured templates, optional Sybil-resistance modules.
Donor Overreach / Influence	Private or institutional donors may bypass DAO	ECIP-1114	✅ Addressed	Donor funds must pass through Donation ECFPs; reporting + separation rules enforced.
Hard Fork Complexity	Upgrade adds client risk (e.g., Core-Geth bugs)	ECIP-1111, ECIP-1112	✅ Addressed	Only EIP-1559/3198 added; Treasury is isolated; Mordor testnet deployment required.
Developer Retention / UX	Developers may avoid ETC if DAO is slow or opaque	ECIP-1113, ECIP-1114	✅ Addressed	Predictable ECFP process; milestone payouts; open templates; recurring proposals supported.
Critical Infra Needs Dedicated Streams	Core-Geth, RPC, explorers should not compete with all proposals	ECIP-1113, ECIP-1114	✅ Addressed	Child-DAO modules (Client DAO, Infra DAO, Security DAO) provide recurring, auditable funding.
Multisig Control of Treasury	Treasury might be captured by signers	ECIP-1112	✅ Addressed	Immutable Treasury vault; only DAO executor can release funds; no signer/admin access.
Token Premine / Insider Allocation Risk	Governance token could be premined or insider-distributed	ECIP-1113	✅ Addressed	No token at launch; any issuance requires DAO vote, with no premine permitted.

---

Sources of Community Feedback Incorporated

• $ETC_to_Jupiter – transparency, trust, and upgrade motives
• Cryptoleer – independence, donor integration, accountability balance
• DirtyRusski – miner alignment, legacy donor role, DAO vs. multisig debate
• Donald McIntyre – protocol purity, ECIP-1098 precedents, monetary policy
• DontPanicBurns – Core-Geth readiness, developer viability, phased rollout
• Dundidit – security-first emphasis, DAO accessibility, risk clarity
• freebird – treasury execution, decentralization safeguards
• hebezhang – legal wrapper skepticism, opt-in critiques, fee objections
• ilGirasole – ecosystem visibility, treasury comms, governance outreach
• IstoraMandiri – modular governance design, LLC scope, execution safety
• jiegodose – UX and discoverability concerns for contributors
• Justjin – client funding viability, fallback controls, moderation history
• lal – token voting criticism, quorum issues, Child-DAO advocacy
• Link – accountability, proposal transparency, voter education
• Slayn – governance fatigue, proposal incentive balance, efficiency
• Speche87 – miner perspective, PoW defense, infra sustainability
• tornadocontrib – Core-Geth CVE history, multisig risk, signer diversity
• Wedergarten – neutrality, legitimacy, historical context
• "Let’s Keep Ethereum Classic Classic" (2021) – historical anti-treasury objections

---

The August 2025 drafts of ECIP-1111 through ECIP-1114 resolve all major criticisms while preserving Ethereum Classic’s founding principles of immutability, Proof-of-Work security, and decentralized neutrality.

[chris-mercer]

Summary of ECIP-1111 Responses (Updated August 2025)

ECIP-1111 integrates EIP-1559 and EIP-3198 into Ethereum Classic under the Olympia upgrade. Unlike Ethereum mainnet, the BASEFEE is not burned — it is redirected to the immutable, governance-isolated Olympia Treasury (ECIP-1112), governed exclusively via Olympia DAO (ECIP-1113) and the ECFP process (ECIP-1114).

The design preserves miner incentives (priority tips remain untouched), maintains the fixed monetary policy of ECIP-1017 (no inflation), and provides a sustainable, non-inflationary funding stream tied directly to network usage.

ECIP-1111 is minimal in scope (only two EIPs included), battle-tested (EIP-1559/3198 deployed widely across EVM networks), and backward-compatible (legacy transaction types remain valid). Treasury activation follows a modular rollout: accumulation begins immediately, but governance disbursements are delayed until ECIP-1113 and ECIP-1114 are activated.

This approach modernizes ETC’s fee market, strengthens long-term sustainability, and avoids ETH-style validator governance or inflationary subsidies.

---

✅ ECIP-1111: Olympia EVM and Protocol Upgrades — Criticism / Response Mapping

Criticism	Summary	Response Location in ECIP-1111	Notes
Miner Incentive Dilution	Redirecting BASEFEE harms miners	✅ EIP-1559 summary, Motivation, Specification, Security Considerations	Priority fees remain fully with miners. BASEFEE goes to Treasury. Aligns with ECIP-1017’s fixed schedule.
Loss of Fee Burn / Scarcity Narrative	Burn strengthens ETC’s deflationary marketing	✅ Monetary Policy Consideration, Motivation, Rationale	ETC’s hard cap under ECIP-1017 is preserved; BASEFEE is transparently redirected rather than destroyed.
Hard Fork / Bug Risk	New fee logic could split chain or cause client errors	✅ Specification, Security Considerations, Testing & Coordination	EIP-1559 and 3198 are widely deployed. Core-Geth implementation validated for Mordor.
Exchange Fork/Delisting Risk	Fork could confuse exchanges	✅ Modular Activation, Backwards Compatibility, Rationale	Legacy transactions remain valid. Treasury redirection is consensus-enforced but isolated.
Too Similar to ETH / Governance Creep	Mirrors ETH’s governance or taxation model	✅ Motivation, Related Work, Rationale, EVM Compatibility	Key differences: no staking, no validator set, no inflation. BASEFEE redirected instead of burned.
Unnecessary Complexity	ETC should stay “simple classic”	✅ Rationale, Scope of This ECIP	Only two EIPs included; all others reviewed and excluded. Keeps upgrade minimal.
Precedent Concern	Redirecting fees sets dangerous precedent	✅ Monetary Policy, Modular Activation	Treasury is immutable and passive until DAO activation. No emissions or token added.
Miners Should Get Full Fees	BASEFEE should reward miners, not Treasury	✅ Motivation, Specification, Security Considerations	Priority fees remain to miners. BASEFEE redirected by consensus logic, consistent with ECIP-1017 economics.
Doesn’t Solve Short-Term Funding	Funds are locked until DAO/ECFP live	✅ Modular Activation, Motivation	Treasury accumulates safely until ECIP-1113 and 1114 governance is deployed.
Fee Redirection Unproven on PoW	DAOs and treasuries are PoS-centric	✅ Related Work, Motivation	Examples: Ronin, Celo, Mantle redirect BASEFEE to treasuries in production.
DAO Token or Premine Concern	Treasury funding could fuel governance token issuance	✅ Rationale, Scope, Related ECIPs	No governance token in ECIP-1111. ECIP-1113 explicitly states no token at launch; any future token must be on-chain approved with no premine.

[chris-mercer]

Summary of ECIP-1112 Responses (Updated August 2025)

ECIP-1112 establishes the Olympia Treasury as an immutable, consensus-enforced smart contract at a deterministic address.
It introduces no admin keys, proxies, or upgrade paths, ensuring separation from off-chain actors such as the DAO LLC.

Disbursements are strictly controlled by Olympia DAO (ECIP-1113) using hash-bound execution (with chainid replay protection), preventing double spending and unauthorized withdrawals.
The Treasury’s role is minimal: passive accumulation of BASEFEE redirected under ECIP-1111, and execution-only release of funds when instructed by DAO-approved proposals under ECIP-1114.

To mitigate risks:

• Governance capture or spam is handled externally by ECIP-1113/1114.
• Deployment is deterministic via CREATE2, with the address hardcoded into clients for consensus safety.
• Transparency is enforced by standardized event logs and public view functions.
• Security is reinforced by audits, testnet validation, and consensus-layer enforcement.

The design aligns with Ethereum Classic’s philosophy: no inflation, no premine, no privileged access, only transparent, verifiable stewardship of protocol-level revenue.

---

✅ ECIP-1112: Olympia Treasury Contract — Criticism / Response Mapping

Criticism	Summary	Response Location in ECIP-1112	Notes
Multisig Control Risk	Treasury could be captured or manipulated via a multisig	✅ Specification: Contract Requirements, Security (1), Modular Deployment	Treasury is immutable, has no admin keys, and cannot be upgraded or redirected.
Replay Attack / Double Spend Risk	DAO could unintentionally repeat a disbursement	✅ Reference Implementation, Proposal Hashing, Security (4)	Each proposal is hash-bound with metadata + chainid; re-execution is prevented.
DAO Capture or Failure	What if governance fails or is compromised?	✅ Security (2), Fail-Safe Treasury Design	Funds remain locked unless DAO executor triggers release.
Premature Governance Activation Risk	Governance might activate before audits or community readiness	✅ Modular Deployment, Pre-Governance Activation	Treasury accumulates funds passively; governance is a later step.
Execution Safety & Auditability	How do we ensure safe disbursements?	✅ Reference Implementation, Events, Security (5)	DAO executor only; all disbursements logged; external audits required.
Spam Proposal Concerns	Could malicious proposals flood the system?	✅ Execution Control, Security (2)	Treasury is execution-only; proposal filtering handled in ECIP-1113/1114.
Token Premine / Treasury Draining	Concern treasury funds could be siphoned by a token scheme	✅ Contract Requirements, Governance Integration	Treasury has no token logic; funds move only via DAO-approved proposals.
Insufficient Transparency	Opaque fund flows risk trust	✅ Events, Public View Functions, Transparency Objective	Treasury emits logs and exposes all balances/metadata on-chain.
Treasury Abuse via LLC	DAO LLC might interfere in disbursement	✅ Governance Separation, Abstract, Security (2)	LLC cannot call Treasury; it executes only if DAO on-chain vote instructs.
Deployment Consistency (Consensus Risk)	Treasury must be identical across clients	✅ Specification: CREATE2, Implementation	Deterministic address via CREATE2; hardcoded in consensus.
Mismatch with ETC Philosophy	Treasuries are foreign to PoW ethos	✅ Motivation, Design Objectives, Ecosystem Precedents	Non-inflationary, tied to usage, precedents exist (Ronin, Celo, Mantle).
Fund Misuse by Bad Actors	Treasury could be drained once unlocked	✅ Security (2), Immutable Vault Design	Only hash-verified DAO disbursements are possible; no direct withdrawals.
Not Useful at Launch	Doesn’t solve immediate funding	✅ Modular Deployment, Pre-Governance Phase	Explicitly phased: accumulates funds now, governance later.

[chris-mercer]

Summary of ECIP-1113 Responses (Updated August 2025)

ECIP-1113 specifies the Olympia DAO governance framework — the sole on-chain executor of the immutable Olympia Treasury (ECIP-1112).
It launches without a governance token, preventing premine, plutocracy, and capture risks. All proposals and disbursements follow the Ethereum Classic Funding Proposal (ECFP) process (ECIP-1114), enforced through hash-bound, replay-protected execution.

Safeguards include minimum quorum, approval thresholds, and timelock delays, as well as an optional time-limited fallback multisig strictly scoped to emergency pause/reset authority (no spending power).
Child-DAO modules support recurring, auditable infrastructure funding (e.g., Core-Geth, RPC endpoints), with all budgets subject to DAO oversight and revocation.

The DAO introduces no admin keys, no privileged allocations, and no inflation. All activity is transparent, permissionless, and auditable on-chain.
It corrects failures of ECIP-1098 (centralized multisig, inflationary treasury) by delivering a modular, decentralized, and capture-resistant governance model aligned with ETC’s Proof-of-Work and immutability ethos.

---

✅ ECIP-1113: Olympia DAO Governance Framework — Criticism / Response Mapping

Criticism	Summary	Response Location in ECIP-1113	Notes
Plutocracy Risk	Token voting could let whales dominate	✅ Rationale (Plutocracy Risk), Specification (Voting Mechanism), Governance Participation Protections	No token at launch; supports future upgrades (quadratic, reputation-based, soulbound, veOLY).
Token Premine Concern	Governance token might be premined	✅ Specification (Tokenless Governance at Launch), Rationale, Security	No token exists; any issuance must be DAO-approved with no premine.
DAO Inactivity / Low Participation	Low turnout may stall governance	✅ Governance Participation Protections, Specification (Fallback Multisig), Rationale (Emergency Governance)	Quorum enforced; fallback multisig only pauses/resets, cannot spend.
Emergency Governance Abuse	Multisig fallback could centralize power	✅ Specification (Emergency Governance), Rationale (DAO vs. Multisig Governance)	Multisig is time-limited, revocable, scoped to pausing — never treasury control.
Legal Capture by DAO LLC	LLC might override DAO	✅ Legal Interface section, Specification (No Admin Privileges)	LLC is fiat/KYC proxy only; cannot access Treasury; fully subordinate to DAO votes.
DAO Centralizes ETC	Looks like ECIP-1098’s central multisig	✅ Rationale (DAO vs. Multisig), Specification (Permissionless Access), Related Work	Replaces closed multisigs with permissionless, auditable on-chain governance.
Dev Capture / Clique Risk	Same actors may dominate Child-DAOs	✅ Child-DAO Modules, Rationale (Accountability), Governance Protections	Child-DAOs require main DAO approval; budgets scoped, auditable, revocable.
No Dedicated Dev Funding Path	Core infra might be underfunded	✅ Child-DAO Modules (Client DAO, Infra DAO), Specification	Provides recurring, transparent funding for clients, infra, and security.
DAO is Slow / Inefficient	Timelocks and quorums may slow action	✅ Rationale (Governance Upgradeability), Specification (Execution Logic)	Timelocks are safety features; rules can be upgraded by DAO vote.
Spam Proposals / Bad Actors	DAO could be flooded with junk ECFPs	✅ Specification (Proposal Submission), Security (Spam Mitigation)	Submission thresholds, cooldowns, hash-bound proposals mitigate spam.
Donor Capture Risk	Donors may dominate influence	✅ Governance Participation Protections, Legal Interface, Rationale	Donations cannot bypass DAO; all treasury access requires on-chain vote.
No Real Safeguards	DAO sounds idealistic, lacks enforcement	✅ Specification, Security, Rationale	No admin keys; immutable Treasury; DAO executor is the only release path.
Multisig Simpler Alternative	Why not multisig funding?	✅ Rationale (DAO vs. Multisig), Specification (Emergency Multisig)	DAO prevents centralization; emergency multisig is scoped, revocable.
No Immediate Funding	Treasury locked until DAO is live	✅ Modular Deployment, Rationale (Decoupled Governance)	Treasury accumulates passively under ECIP-1111/1112; DAO activates later.
Regulatory Risk	DAO may create SEC/LLC liability	✅ Legal Interface (DAO LLC), Governance Isolation	LLC handles fiat/KYC; DAO funds stay on-chain; no off-chain discretionary control.
Voting Model Unclear	How do votes work?	✅ Specification (Voting Mechanism), Implementation	One-address-one-vote at launch; modular upgrades supported.
Historical Distrust	Prior failures (ECIP-1098) make DAO suspect	✅ Rationale (ECIP-1098 Comparison), Related Work	Fixes past flaws: no inflation, no premine, immutable Treasury, transparent voting.
Tied Too Closely to ECIP-1111	Don’t want DAO, only EIP-1559	✅ Modular Deployment, Motivation, Specification	DAO is modular; ECIP-1111/1112 can run independently; DAO opt-in.

[chris-mercer]

Summary of ECIP-1114 Responses (Updated August 2025)

ECIP-1114 formalizes the Ethereum Classic Funding Proposal (ECFP) process, the exclusive mechanism for requesting and executing disbursements from the Olympia Treasury (ECIP-1112).
It ensures all funding decisions are transparent, standardized, and hash-bound to immutable metadata.

Safeguards include:

• Spam protection (proposal cooldowns, draft periods, structured templates, optional Sybil-resistance modules like BrightID or Gitcoin Passport).
• Replay protection (hash-bound execution with chainid domain separation).
• Accountability (milestone-based payments, clawbacks, and DAO-only executor path).
• Governance flexibility (one-address-one-vote at launch, with upgrade paths to quadratic, delegated, or tokenized voting).
• Child-DAO support for recurring, depoliticized infrastructure funding (Client DAO, Infra DAO, Security DAO).
• DAO LLC as a narrow, auditable legal proxy for fiat conversions and tax/KYC, with no discretionary control.

The system is minimal, modular, and phased: Treasury funds accumulate safely today (ECIP-1111/1112), while ECFP governance (ECIP-1113/1114) activates once audited and community-ready.

---

✅ ECIP-1114: Ethereum Classic Funding Proposal Process — Criticism / Response Mapping

Criticism	Summary	Response Location in ECIP-1114	Notes
Spam Proposals / Sybil Attacks	DAO could be overwhelmed with junk proposals	✅ Spam, Sybil, and Governance Capture Mitigations; Security (5)	Draft periods, cooldowns, optional Sybil modules, and structured templates mitigate spam.
Lack of Transparency	Proposal activity and disbursements may be opaque	✅ Specification (Transparency & Indexing), Dashboard, Rationale	All proposals, votes, and disbursements recorded immutably on-chain. Dashboard mirrors events.
Proposal Manipulation / Vague Terms	Ambiguous ECFPs could be abused	✅ Specification (Metadata & Templates), Security (1)	Required metadata CID, hash-bound execution, and immutability after activation ensure integrity.
DAO Favors Insiders	Process could enable gatekeeping	✅ Motivation, Rationale (Openness), Specification (Submission)	Any address may submit. No privileged access. Permissionless and standardized.
Disbursement Misuse	Recipients could misuse funds post-payout	✅ Specification (Milestones, Vesting), Security (4)	Supports milestone-based payouts and clawbacks. DAO controls release.
DAO Inactivity or Gridlock	Proposals may stall due to lack of quorum	✅ Specification (Quorum, Statuses), Governance Protections	Minimum quorum enforced. Expired proposals marked. Governance upgradable via DAO vote.
Execution Replay Risk	Proposals could be replayed or double-spent	✅ Proposal Hashing; Security (1,4)	Execution bound to (ecfpId, recipient, amount, metadataCID, chainid); one-time execution enforced.
Private Donor Influence	Donors may bypass governance	✅ Donation Handling, Strategic Donors, Legal Interface	All donor funds must flow through ECFP lifecycle. LLC cannot bypass DAO. Public reporting required.
DAO LLC Control Risk	Legal entity might override DAO	✅ Legal Interface (DAO LLC), Governance Isolation	LLC is an execution proxy only. Cannot access Treasury keys or override outcomes.
Proposal Bloat / Fatigue	Too many proposals may overwhelm voters	✅ Spam Mitigation, Child-DAO ECFPs	Child-DAO modules handle recurring infra to reduce governance fatigue.
Plutocracy via Token Voting	Token voting risks whale domination	✅ Voting Model Upgradeability; Security (3)	Launches with one-address-one-vote; upgrades to quadratic/reputation/token voting possible by DAO vote.
Complexity / Bureaucracy	Process may deter contributors	✅ Rationale (Minimal Design), Specification (Template & Lifecycle)	Standard templates + IPFS CID referencing keep process low-friction.
Governance Capture by Delegates	Delegation may concentrate power	✅ Voting Model Upgradeability, Governance Scope	Supports upgrades to cap delegate weight, hybrid systems, or councils.
No Real-World Enforcement	Contractors may default after payout	✅ Security (4), DAO LLC, Milestone Vesting	DAO LLC provides legal interface; milestone vesting reduces default risk.
Off-chain Execution Risk	LLC may mishandle fiat/KYC	✅ Legal Interface, Reporting Requirements	LLC bound by DAO instructions, publishes periodic reports, and rotates via DAO vote.
Infrastructure Needs Are Recurring	Critical devs should not compete with marketing	✅ Child-DAO ECFPs (Client DAO, Infra DAO, Security DAO), Rationale	Provides recurring, depoliticized funding streams for infra.
Not Needed / Too Similar to EF Grants	Looks like centralized grants	✅ Motivation, Related Work, Rationale	Transparent, on-chain process replaces opaque EF-style grantmaking.
Doesn’t Solve Funding Now	ETC needs immediate funding	✅ Modular Design, Activation Flow	Treasury accumulates now (ECIP-1111/1112). Governance activates later when ready.
Proposal Review Is Political	Reviews could devolve into cliques	✅ Specification (Review & Deliberation), Community Processes	Proposals reviewed publicly; moderators assist formatting but cannot gatekeep.