Olympia Upgrade — ECIP-1111, ECIP-1112, ECIP-1121 Implementation & Mordor Testnet

[chris-mercer]

Olympia Upgrade — ECIP-1111, ECIP-1112, ECIP-1121 Implementation & Mordor Testnet

Last Updated: March 2026 — Client Implementation Complete, Mordor Testnet Phase

Olympia is a protocol upgrade initiative that introduces a protocol-native funding primitive to Ethereum Classic — designed to secure the long-term health of the network for miners, developers, and the broader ETC ecosystem.

The term Olympia refers to a family of ECIPs, not a single mandatory governance system. These ECIPs share common design goals but differ in scope, activation requirements, and consensus impact. No new issuance is introduced at any phase.

---

Why Olympia Matters for Miners

Ethereum Classic miners are the backbone of the network. Olympia is designed with miners in mind at every stage.

The basefee was going to be burned. Under the standard EIP-1559 specification, the basefee is destroyed — permanently removed from circulation. Olympia diverts this value instead of burning it, redirecting it into a transparent on-chain treasury to fund the core software and infrastructure that keeps the network miners are securing alive and competitive.

The math is straightforward. At current transaction volumes, the basefee represents less than 0.01% of total miner income. All miner tips and priority fees are fully preserved. This is not a tax on miners — it is a redirect of value that would otherwise be destroyed.

The long-term play is for miners. As ETC's block rewards decline on the emission curve, network security depends increasingly on transaction fee volume. Olympia builds the infrastructure — client software, public RPC endpoints, block explorers, bootnodes — that attracts the on-chain activity needed to grow that fee market. A robust fee market on ETC is the long-term security budget for proof-of-work mining. Olympia builds toward that directly.

Miners participate in the upside. Once core network needs are sustainably funded, ECIP-1115 provides a path for miners to receive a share of the basefee directly — with distribution parameters informed by real empirical data from a live fee market rather than theoretical models. This is not hardcoded at launch; it is designed to be dialed in correctly once the data exists to do so responsibly.

---

March 2026 Update

Client implementation of ECIP-1111, ECIP-1112, and ECIP-1121 is complete across three execution clients — Core-Geth, Besu, and Fukuii. Implementations have been validated against go-ethereum, erigon, and nethermind reference clients. The multi-client Hive test suite is in place with both pre and post-Olympia configurations. Mordor testnet deployment is the next phase. Block numbers will be set following testnet.

---

Consensus-Affecting ECIPs

The following ECIPs introduce consensus-layer changes and require explicit network upgrades if adopted:

ECIP	Scope	Status
1111	Introduces EIP-1559 / EIP-3198 transaction semantics on ETC. Basefee redirected to treasury rather than burned.	✅ Client implementation complete
1112	Introduces a consensus-recognized treasury address and custody rules.	✅ Client implementation complete
1121	Execution client specification alignment (Olympia Hardfork). Includes ECIP-1111.	✅ Client implementation complete

---

Application-Layer and Mixed-Scope ECIPs

The following ECIPs operate entirely above consensus or depend on prior consensus changes without introducing new consensus rules themselves:

ECIP	Notes
1113	Governance authorization and execution pipeline (no consensus changes).
1114	Funding proposal workflow and execution semantics (application-layer).
1115	Optional miner basefee distribution mechanism. Parameters informed by empirical fee market data.
1116	Basefee allocation modifier; composable with multiple governance or funding frameworks.
1117	Alternative governance framework operating above consensus.
1118	Alternative funding and disbursement framework; replaces ECIP-1114 where adopted.
1119	Treasury withdrawal execution constraint applicable across governance and funding paths.

---

Design Constraints

• No New Issuance — All funding mechanisms rely on existing fee flows or governance-authorized treasury usage.
• Miner Tips Fully Preserved — Only the basefee is redirected. All priority fees and tips remain with miners.
• Basefee Was Burned — Under standard EIP-1559, the basefee is destroyed. Olympia redirects this value rather than burning it.
• No Implicit Governance Mandate — Governance frameworks are optional, composable, and mutually exclusive where specified.
• Explicit Consensus Scope — Consensus changes are introduced only where stated and reviewed on a per-ECIP basis.
• Protocol Neutrality — Treasury custody, governance authorization, and execution logic are deliberately separated.
• Critical Infrastructure in Scope — Client software, consensus implementations, public RPC, block explorers, and bootnodes are eligible funding targets.
• Miner Distribution Path — ECIP-1115 provides an empirical, data-driven path for miners to receive basefee distribution once core needs are met.
• ECIP-1000 Compliance — Scope, dependencies, and upgrade requirements are explicitly declared per proposal.

---

Discussion Scope (March 2026)

This thread serves as a shared discussion venue for:

• Review of consensus-affecting ECIPs (1111, 1112, 1121)
• Evaluation of governance frameworks (1113, 1117)
• Evaluation of funding and execution frameworks (1114, 1118)
• Review of independent modifiers and constraints (1115, 1116, 1119)
• Client implementation considerations and Mordor testnet coordination
• Miner participation, fee market development, and long-term security budget planning

Note: ECIP-1116 and ECIP-1120 represent protocol-level hardcoding of distribution mechanisms. These are scoped for evaluation after observable empirical evidence from ECIP-1115 experimentation and are not tracked in this thread.

No proposal discussed here is implied to be final, canonical, bundled, or mutually dependent unless such dependency is explicitly stated in the ECIP itself.

Moderation Note: This discussion thread is actively moderated. Comments that are outdated, resolved, or spam are hidden to maintain clarity. Hidden comments remain accessible via the "Show comment" toggle for anyone wishing to review the full history.

[chris-mercer]

Moderator Note (March 2026)
Client implementation of ECIP-1111, ECIP-1112, and ECIP-1121 is complete across three execution clients. Entering Mordor testnet phase.

📚 Olympia Introduction Series — Finalized (Updated November 2025)

Introductory & Educational Articles

• What’s Olympia? Why Now?
  Overview of the upgrade and ETC’s need for sustainable, decentralized funding.

• Miners, Not Middlemen
  How Olympia aligns incentives while preserving Proof-of-Work security.

• How the Olympia DAO Works (and What It Doesn’t Do)
  Clear explanation of ECIP-1113’s governance architecture and limits.

• A Decade of Donor Dependence
  ETC’s funding history and why protocol-native funding is essential.

• Olympia: The First Decentralized Treasury Framework Designed for Proof-of-Work
  Technical overview of ECIPs 1111–1114 and comparison to legacy proposals.

• The Olympia Treasury Is Neutral
  Why BASEFEE redirection is non-inflationary and maintains ETC’s monetary policy.

• Freedom to Build
  Olympia is opt-in, backward compatible, and ECIP-1000 compliant.

• Decentralization Is What You Do — Not What You Say
  How ECIPs 1111–1114 encode neutrality, immutability, and permissionless governance.

• The DeFi Stack Is Rising
  Olympia positions ETC as the PoW settlement and financial layer.

• The Final Piece Toward Sovereignty
  How Olympia completes ETC’s architecture for sustainable funding.

---

Historical & Contextual Articles

• The Road to Olympia
  A comprehensive retrospective from the DAO Fork through ECIP-1115.

---

Additional 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
• Funding ETC Without Compromise: Olympia vs. Legacy Proposals

---

Implementation Series (2025–2026)

• Part 0 — Implementing Olympia: From Draft to Testnet
  https://coinmarketcap.com/community/articles/69135a2872417b07898025bc/
  Launch of the implementation and testnet deployment phase.

More installments will follow as Mordor testing proceeds.

[boundless-forest]

UX: A Missing Piece – Who maintains and funds this infrastructure?

Hi, Ethereum Classic community! I just found this discussion from https://ecips.ethereumclassic.org/ECIPs/ecip-1113. From this ECIP, I learned that your community seems to have chosen a custom governance contract based on the OpenZeppelin Governor contracts. I want to introduce our UI/UX solution, https://github.com/ringecosystem/degov, for your consideration. It is designed based on the standard OpenZeppelin Governor contract. To support Ethereum Classic governance, we may need to make some customizations, but it should be easy. Please let me know if you are interested.

[chris-mercer]

UX: A Missing Piece – Who maintains and funds this infrastructure?

Hi, Ethereum Classic community! I just found this discussion from https://ecips.ethereumclassic.org/ECIPs/ecip-1113. From this ECIP, I learned that your community seems to have chosen a custom governance contract based on the OpenZeppelin Governor contracts. I want to introduce our UI/UX solution, https://github.com/ringecosystem/degov, for your consideration. It is designed based on the standard OpenZeppelin Governor contract. To support Ethereum Classic governance, we may need to make some customizations, but it should be easy. Please let me know if you are interested.

Thanks for adding this contribution to the discussion — a great example of a UX built around the OpenZeppelin Governor contracts highlighted in the spec.

If you’re interested in integrating with Ethereum Classic, it would be extremely helpful to add support for Mordor testnet (for experimentation) and ETC mainnet (for production) into your project.

For testing on Mordor, here’s a faucet for some mETC:
https://faucet.etcmc-monitor.org/

The community would very much welcome open collaboration on this. As Olympia governance progresses, having a user-friendly interface will be an important piece of the ecosystem. Feel free to experiment, share progress — your contributions could have a real impact in making ETC governance more accessible.

[boundless-forest]

Glad to help! Will check the details next week and give it a try.

[chris-mercer]

March 2026 Update: Client implementation of ECIP-1111, ECIP-1112, and ECIP-1121 is complete across three execution clients — Core-Geth, Besu, and Fukuii. Validated against go-ethereum, erigon, and nethermind reference implementations. Mordor testnet deployment in progress.

---

Summary of Olympia Upgrade Resolution Matrix (Updated March 2026)

The Olympia Upgrade resolves all major community criticisms through four core ECIPs (1111–1114) and one optional governance-layer enhancement (ECIP-1115).
The upgrade emphasizes transparency, decentralization, immutability, modularity, and Proof-of-Work alignment.

Key architectural choices now finalized across the ECIP suite:

• No governance token at launch (tokenless; one-address-one-vote)
• Non-inflationary BASEFEE redirection instead of fee burn or new issuance
• Immutable Treasury contract with no admin keys, proxies, or upgrade paths (ECIP-1112)
• Strict governance isolation, with all disbursements routed through the
  Governor → Timelock → Executor pipeline (ECIP-1113 + ECIP-1114)
• Hash-bound, chain-ID-protected execution to prevent replay or manipulation
• Permissionless proposal submission with standardized templates and spam controls
• DAO LLC limited to administrative duties only, with zero custody, authority, or override capabilities

ECIP-1115 introduces optional smoothing as a governance-layer mechanism only.
It does not alter consensus, monetary policy, block rewards, or miner incentives.

Together, ECIPs 1111–1114 define the consensus-safe, non-inflationary, and fully transparent funding and governance framework for Ethereum Classic.
ECIP-1115 provides an optional mechanism for long-term miner alignment without affecting consensus guarantees.

---

✅ Olympia Upgrade: Criticism Resolution Matrix (Click to Expand)

Topic	Criticism Summary	ECIP(s)	Resolution	Notes
Plutocracy Risk	Token voting may allow whales to dominate	ECIP-1113, 1114	✅ Addressed	No token at launch; one-address-one-vote; upgrade paths (quadratic, identity, delegated) require OIP approval.
Legal Capture / DAO LLC Overreach	LLC might override DAO authority	ECIP-1113, 1114	✅ Addressed	DAO LLC is an administrative proxy only; no Treasury access, no veto, no keys.
Miner Incentive Dilution	Redirecting BASEFEE harms miners	ECIP-1111	✅ Addressed	Priority fees remain with miners; BASEFEE was specified to be burned under EIP-1559 — Olympia redirects it instead. Less than 0.01% of current miner income.
Loss of Fee Burn / Scarcity Narrative	Burning supports deflationary branding	ECIP-1111	✅ Addressed	ETC's fixed supply preserved; BASEFEE redirected to public goods instead of destroyed.
DAO Inactivity / Low Quorum	Governance may stall	ECIP-1113	✅ Addressed	Adjustable quorum; optional pause/guard modules — no multisigs.
Execution Safety (Replay Attacks)	Proposal replay across forks	ECIP-1112, 1114	✅ Addressed	Hash-bound execution using (ecfpId, recipient, amount, metadataCID, chainid).
Fund Misuse / Spam Proposals	DAO may be flooded with junk asks	ECIP-1114	✅ Addressed	Draft windows, cooldowns, optional identity modules, structured templates.
Donor Overreach / Influence	Donors may bypass DAO	ECIP-1114	✅ Addressed	Donor funds must follow the ECFP lifecycle.
Hard Fork Complexity	Risk of client bugs	ECIP-1111, 1112, 1121	✅ Addressed	ECIP-1111, 1112, and 1121 implemented across Core-Geth, Besu, and Fukuii. Validated against go-ethereum, erigon, and nethermind. Mordor testnet deployment in progress.
Developer Retention / UX	Opaque governance repels devs	ECIP-1113, 1114	✅ Addressed	Clear lifecycle, milestone-based payouts, templates.
Critical Infra Funding	Infra shouldn't compete with marketing	ECIP-1113, 1114	✅ Addressed	Child-DAOs for recurring, depoliticized infra.
Multisig Control Risk	Treasury captured by signers	ECIP-1112	✅ Addressed	No admin keys; immutable vault; no multisigs.
Token Premine Risk	Governance token premine	ECIP-1113	✅ Addressed	No token at launch; future models require OIP approval, zero premine.
Long-Term Miner Alignment	Reduced issuance may weaken PoW	ECIP-1115 (optional)	⚪ Optional	Smoothing redistributes Treasury-held BASEFEE; no inflation. Data-driven path for miner distribution once core needs are met.

---

📜 Historical Sources of Community Feedback (Click to Expand)

• ETCDEV (2017–2018) – Collapse of ETC's primary engineering team due to lack of funding, leaving no sustainable path for protocol development.
• ETC Labs (2018–2021) – Centralized funder exited; incubator, grants, and client support wound down, exposing ecosystem fragility.
• IOHK Grothendieck / Mantis (2016–2021) – Withdrawal following ECIP-1098 rejection highlighted the risks of reliance on external, centralized sponsors.
• Core-Geth Fragility (2020–2025) – Upstream divergence and several chain incidents demonstrated the systemic risk of underfunded client maintenance.
• Client Deprecation & Single-Client Risk (2021–2024) – Periods of uncertain maintenance commitments and reliance on a single client exposed ETC to governance pressure and consensus fragility.
• 51% Attacks (2020) – Multiple attacks prompted exchanges to raise confirmation requirements, underscoring the need for sustainable security funding.
• Failed Treasury Attempts (ECIP-1051, ECIP-1098) – Community rejection of inflationary or multisig-based models established strict constraints (no inflation, no premine, no centralized control).
• 17k ETC Community Fund (2016–present) – Donation-based multisig became inert without a governance mechanism, demonstrating the need for permissionless, on-chain funding.
• ETC Cooperative Funding Reliance (2017–2022) – Grayscale-based funding ended, leaving ETC without a guaranteed long-term funding source for critical infrastructure.
• ETC Cooperative Funding Contraction (2025–Present) – After Grayscale-derived inflows ended in 2022, the Cooperative exhausted its remaining reserves by late 2024 and shifted to maintenance-only operations in 2025. This highlighted the long-term unsustainability of relying on external donors for core protocol development and security. With no other funded client-maintenance team remaining, the Olympia ECIPs were drafted by independent ETC contributors to establish a durable, permissionless funding path — following community discussions active since 2016 and addressing a recurring source of structural instability at the foundation of Ethereum Classic.
• Bitmain Stopgap Offer (2025) – Upon learning of ETC's core development funding crisis and the absence of a funded client-maintenance team, Bitmain indicated willingness to temporarily support two core developer roles while Olympia advanced. The roles have not been filled, but the signal illustrated that external stakeholders were willing to provide short-term support while ETC worked toward a long-term, decentralized solution.

---

🧩 Olympia Community Feedback Incorporated (Click to Expand)

• $ETC_to_Jupiter – transparency, trust
• Cryptoleer – donor integration, accountability
• Donald McIntyre – protocol purity, ECIP-1098 precedent
• DontPanicBurns – client readiness, feasibility
• Dundidit – auditability, security, jurisdiction-capture concerns
• freebird – decentralization architecture
• hebezhang – legal wrapper skepticism, opt-in concerns
• ilGirasole – visibility, comms
• IstoraMandiri – modular governance, DAO isolation
• jiegodose – UX
• Justjin – client funding, moderation
• lal – voting models, quorum, Child-DAO design
• Slayn – governance fatigue
• Speche87 – miner perspective
• tornadocontrib – CVEs, decentralization
• Wedergarten – neutrality, treasury concerns
• "Let's Keep Ethereum Classic Classic" (2021) – historical objections
• ETC Community Calls #41–42 – BASEFEE handling and consensus/governance separation

---

The finalized November 2025 drafts of ECIP-1111 → ECIP-1114, with optional ECIP-1115, deliver a modular, permissionless, immutable, non-inflationary framework for long-term Ethereum Classic sustainability — while upholding:
immutability, Proof-of-Work security, decentralized neutrality, and fixed monetary policy.

[chris-mercer]

March 2026 Update: ECIP-1111 client implementation complete across Core-Geth, Besu, and Fukuii. Entering Mordor testnet phase.

---

Summary of ECIP-1111 Responses (Updated March 2026)

ECIP-1111 activates EIP-1559 and EIP-3198 on Ethereum Classic as part of the Olympia upgrade.
Unlike Ethereum mainnet, ETC does not burn the BASEFEE. Instead, the consensus layer redirects it to the immutable Olympia Treasury (ECIP-1112), where it is held passively until disbursements are authorized through:

• Olympia DAO governance (ECIP-1113)
• The Ethereum Classic Funding Proposal (ECFP) process (ECIP-1114)
• Optional governance-layer smoothing (ECIP-1115)

ECIP-1111 is minimal and consensus-only: it introduces no governance logic, no new tokens, and no changes to miner priority fees.
All legacy transaction types remain valid, and Type-2 transactions (1559) are strictly additive and optional.

ECIP-1111 preserves ETC's monetary policy under ECIP-1017 (fixed issuance, no inflation), maintains full miner incentives, and brings ETC into alignment with modern EVM standards for tooling, UX, and interoperability.
Treasury accumulation begins immediately upon activation; governance and funding processes activate later as independent modules.

---

✅ ECIP-1111: Criticism / Response Mapping (Click to Expand)

Criticism	Summary	Response Location in ECIP-1111	Notes
Miner Incentive Dilution	Redirecting BASEFEE harms miners	✅ Motivation, Specification, Security	Priority fees remain 100% to miners; BASEFEE is separate from miner rewards and redirected at consensus. Less than 0.01% of current miner income.
Loss of Fee Burn / Scarcity Narrative	Burning BASEFEE supports deflationary marketing	✅ Monetary Policy Consideration, Rationale	ETC's fixed supply under ECIP-1017 remains unchanged; BASEFEE funds public goods instead of being destroyed.
Hard Fork / Client Bug Risk	New fee logic could split chain	✅ Specification, Testing & Coordination	ECIP-1111 implemented across Core-Geth, Besu, and Fukuii. Validated against go-ethereum, erigon, and nethermind. Mordor testnet deployment in progress.
Exchange Fork / Delisting Risk	May confuse exchanges	✅ Backwards Compatibility, Modular Activation	Legacy tx types remain valid; Type-2 is additive; BASEFEE redirect isolated.
Too Similar to ETH	"Looks like Ethereum governance"	✅ Motivation, EVM Compatibility	ETC does not adopt PoS, staking, validators, or burns; only uses the fee mechanism.
Unnecessary Complexity	ETC should stay simple	✅ Scope, Rationale	Only 1559/3198 included; no additional Ethereum upgrades.
Precedent Concern	Fee redirection dangerous	✅ Monetary Policy, Rationale	Treasury is immutable; no emissions, no new token; redirection is transparent and deterministic.
Miners Should Receive All Fees	BASEFEE belongs to miners	❗ Clarified	Under EIP-1559 semantics, only priority fees belong to miners; BASEFEE is protocol-defined. Under standard EIP-1559 it would be burned — Olympia redirects it instead.
Doesn't Solve Immediate Funding	Treasury fills before DAO exists	✅ Modular Activation	Treasury accumulates now; governance activates later with no consensus changes.
Fee Redirection Unproven on PoW	Treasuries are PoS concepts	❗ Incorrect	Ronin, Celo, Mantle, and others redirect EIP-1559-style revenue at L1/L2 today.
DAO Token / Premine Concern	Treasury could back a governance token	❗ Clarified	ECIP-1111 introduces no token; ECIP-1113 launches tokenless; any future token requires OIP vote with zero premine.

---

This March 2026 revision reflects the final ECIP-1111 architecture and implementation status:

• Consensus: ECIP-1111 / 1112 — ✅ Client implementation complete
• Governance: ECIP-1113
• Funding Execution: ECIP-1114
• Optional Miner Incentives: ECIP-1115

[chris-mercer]

March 2026 Update: ECIP-1112 client implementation complete across Core-Geth, Besu, and Fukuii. Entering Mordor testnet phase.

---

Summary of ECIP-1112 Responses (Updated March 2026)

ECIP-1112 defines the Olympia Treasury, an immutable, consensus-enforced smart contract deployed at a deterministic address via CREATE2.
The Treasury contains no admin keys, no upgrade paths, no delegates, and no proxies, ensuring permanent separation from all off-chain actors, including the DAO LLC.

The Treasury's responsibilities are intentionally minimal:

• Receive all BASEFEE amounts redirected under ECIP-1111
• Expose full transparency via events and public view functions
• Release funds only when called by the on-chain Executor defined in ECIP-1113, and only for proposals that satisfy ECIP-1114's hash-bound execution semantics

The Treasury cannot be modified, overridden, paused, upgraded, or accessed directly by any EOA, multisig, DAO LLC, or contract other than the authorized executor.

Because ECIP-1112 contains no governance logic, all participation, voting, security parameters, and upgrade paths live entirely in ECIP-1113 (governance) and ECIP-1114 (funding process).
The Treasury simply provides a transparent, deterministic, immutable vault for protocol-level revenue — fully aligned with ETC's Proof-of-Work ethos, fixed monetary policy (ECIP-1017), and immutability principles.

---

✅ ECIP-1112: Olympia Treasury Contract — Criticism / Response Mapping (Click to Expand)

Criticism	Summary	Response Location in ECIP-1112	Notes
Multisig Control Risk	Treasury could be captured or redirected	✅ Contract Requirements; Security (1)	No admin keys, no multisig, no privileged roles; immutable bytecode.
Replay Attack / Double Spend Risk	DAO could unintentionally repeat a disbursement	✅ Specification; Security (4)	Hash-bound execution with (ecfpId, recipient, amount, metadataCID, chainid); payouts are single-use.
DAO Capture or Failure	What if governance becomes compromised or inactive?	✅ Security (2), Fail-Safe Design	Treasury cannot release funds without executor calls; without governance approval, funds remain locked.
Premature Governance Activation	Governance may activate before audits are complete	✅ Modular Deployment; Pre-Governance Activation	Treasury accumulates passively; governance activates later and independently.
Execution Safety & Auditability	How to ensure safe release of funds?	✅ Specification; Events; Security (5)	Only the authorized executor can call release(); all transfers logged; audits required pre-activation.
Spam Proposal Concerns	Malicious ECFPs might target the Treasury	🚫 Out of Scope → ECIP-1113/1114	Treasury is execution-only; proposal filtering and governance protections live in 1113/1114.
Token Premine / Treasury Draining	Treasury could fund insider token allocations	✅ Contract Requirements; Governance Integration	Treasury has no token logic; any token proposal must pass on-chain governance; no direct withdrawals.
Insufficient Transparency	Treasury balance or actions could be hidden	✅ Events; Public View Functions; Transparency Mandate	Full observability on-chain; no hidden state or off-chain bookkeeping.
Treasury Abuse via LLC	DAO LLC could override withdrawals	✅ Governance Isolation; Abstract; Security (2)	LLC cannot call the Treasury; no private keys; cannot bypass DAO or executor.
Deployment Consistency (Consensus Risk)	Treasury must be identical across all clients	✅ Specification: CREATE2; Implementation Requirements	Deterministic address generated from bytecode; address hardcoded for consensus safety. Validated across Core-Geth, Besu, and Fukuii.
Mismatch with ETC Philosophy	Treasuries conflict with PoW and immutability	✅ Motivation; Design Principles; Ecosystem Precedents	Treasury is non-inflationary, immutable, usage-based; similar patterns exist across EVM PoW/L1 networks.
Fund Misuse by Bad Actors	Treasury could be drained after activation	✅ Security (2), Immutable Vault Design	Only the executor can call release(); no arbitrary transfers or privileged escape hatches.
Not Useful at Launch	Treasury is empty or unused initially	✅ Modular Deployment; Pre-Governance Phase	Designed to begin passively accumulating long before governance activation.

---

This March 2026 revision fully aligns ECIP-1112 with the finalized Olympia architecture and implementation status:

• Consensus layer: ECIP-1111 & ECIP-1112 — ✅ Client implementation complete
• Governance layer: ECIP-1113
• Funding process: ECIP-1114
• Optional smoothing: ECIP-1115

The Treasury remains the immutable foundation of ETC's transparent, protocol-native funding system.

[chris-mercer]

March 2026 Update: ECIP-1113 governance contract layer entering development phase following completion of ECIP-1111, ECIP-1112, and ECIP-1121 client implementations. CoreDAO deployment is Phase 1 of the contract layer rollout.

---

Summary of ECIP-1113 Responses (Updated March 2026)

ECIP-1113 defines the Olympia DAO governance framework, the sole on-chain executor authorized to release funds from the immutable Olympia Treasury (ECIP-1112).
The DAO launches without a governance token, avoiding premine risks, plutocracy, and insider allocation. Voting uses a one-address-one-vote model through a modular Voting Module that supports future OIP upgrades (quadratic voting, delegated voting, reputation systems, identity layers), all without modifying consensus or the Treasury.

All Treasury disbursements must pass through the Governor → Timelock → Executor pipeline and use the hash-bound, chain-ID-protected execution model defined in ECIP-1114.
ECIP-1113 introduces no admin keys, no multisigs, no proxies, no privileged override paths — all authority comes from transparent, on-chain proposals.

Optional, strictly limited safety modules include:

• Emergency Pause Module — temporary pause of queued actions; no spending authority; activated only by DAO vote
• Execution Guard Module — deterministic validation of calldata prior to execution

Child-DAO modules (Client/Infra/Security) provide recurring, auditable pipelines for core infrastructure while remaining fully subordinate to the main DAO.

ECIP-1113 corrects the failures of ECIP-1098 by ensuring:

• no inflation
• no premine or insider allocations
• no centralized multisig
• immutable Treasury integration
• permissionless participation
• full transparency
• strict isolation from the DAO LLC and all off-chain actors

The result is a secure, capture-resistant, minimal, and modular governance system aligned with ETC's Proof-of-Work, immutability, and neutrality.

---

✅ ECIP-1113: Criticism / Response Mapping (Click to Expand)

Criticism	Summary	Response Location	Notes
Plutocracy Risk	Token voting lets whales dominate	Tokenless Governance; Voting Module	One-address-one-vote at launch; upgrades require OIP, no premine allowed.
Token Premine Concern	DAO could introduce a premine	Specification; Security	Any future token must be OIP-approved, non-inflationary, and cannot premine.
DAO Inactivity / Low Participation	Low turnout may stall governance	Governance Parameter Controls	Quorum/thresholds configurable by OIP; optional identity modules can strengthen participation.
Emergency Governance Abuse	Pause or safety tools could centralize power	Emergency Pause; Execution Guard	Modules cannot release funds; no multisig; all use must be DAO-approved.
Legal Capture by DAO LLC	LLC might override DAO	Governance Isolation	LLC holds no keys, cannot call Treasury, cannot override votes; strictly administrative.
DAO Centralizes ETC	Similar to ECIP-1098's multisig	Rationale	No closed signers; no multisigs; fully permissionless, on-chain governance replaces centralized control.
Dev Capture / Clique Risk	Child-DAOs might be dominated	Child-DAO Specification	Child-DAOs cannot spend; budgets approved by main DAO and revocable.
No Dedicated Dev Funding Path	Core infra may go unfunded	Child-DAO Modules	Dedicated recurring pipelines (Client/Infra/Security DAO).
DAO is Slow / Inefficient	Timelocks delay urgent execution	Timelock Specification	Timelocks are safety; parameters adjustable by OIP later.
Spam Proposals / Bad Actors	DAO may be flooded with junk	Mitigations (ECIP-1114)	Structured templates, draft windows, cooldowns, optional Sybil resistance.
Donor Capture Risk	Donors might dominate governance	Governance Protections	Donors cannot bypass ECFP or DAO vote; no privileged donor paths.
No Real Safeguards	DAO seems trust-based	Security Model	No admin keys; immutable Treasury; executor path strictly validated.
"Multisig Simpler Alternative"	Suggestion to use multisig	❌ Not applicable	ECIP-1113 removes multisigs entirely; on-chain governance only.
No Immediate Funding	Treasury locked until DAO online	Modular Deployment	Treasury accumulates during Mordor testnet phase; DAO activates after audits and testnet readiness.
Regulatory Risk	DAO may create SEC/LLC concerns	Legal Interface	LLC is strictly administrative; governance is fully on-chain and isolated.
Voting Model Unclear	Need clarity on vote computation	Voting Module	One-address-one-vote; OIP governs any upgrades.
Historical Distrust (ECIP-1098)	Fear of repeating past failures	Rationale	Olympia fixes all ECIP-1098 flaws: no inflation, no multisig, no central control.
Tied Too Closely to ECIP-1111	Some want 1559 without governance	Modular Architecture	Consensus (1111/1112) and governance (1113) are fully decoupled. ECIP-1111 and ECIP-1112 activate independently; ECIP-1113 deploys as a subsequent contract layer.
1113 Viability Gates 1111/1112	Claim that consensus depends on governance viability	❌ Incorrect	ECIP-1111 and ECIP-1112 are consensus-only. The Treasury accumulates independently. Governance is a subsequent deployment. The Ronin network demonstrates this staged rollout pattern in production.

---

This March 2026 revision reflects the finalized governance architecture and current implementation status:
tokenless → modular → no multisig → immutable Treasury → strict execution pipeline → optional safety modules → OIP-controlled evolution.

• Consensus layer: ECIP-1111 & ECIP-1112 — ✅ Client implementation complete
• Governance layer: ECIP-1113 — 🔧 Contract development phase, CoreDAO first
• Funding process: ECIP-1114
• Optional smoothing: ECIP-1115

[chris-mercer]

March 2026 Update: Treasury accumulation begins upon ECIP-1111/1112 activation following Mordor testnet deployment. ECFP process activates as a subsequent contract layer after audits and testnet readiness.

---

Summary of ECIP-1114 Responses (Updated March 2026)

ECIP-1114 defines the Ethereum Classic Funding Proposal (ECFP) process, the exclusive, standardized, and permissionless workflow for requesting and executing disbursements from the immutable Olympia Treasury (ECIP-1112).
Every withdrawal must follow the Governor → Timelock → Executor pipeline defined in ECIP-1113 and comply with ECIP-1114's hash-bound, chain-ID-protected execution model.

ECIP-1114 ensures that every funding decision is:

• Transparent — proposals, votes, disbursements recorded entirely on-chain
• Deterministic — execution strictly bound to (ecfpId, recipient, amount, metadataCID, chainid)
• Permissionless — any ETC address may submit an ECFP
• Accountable — milestone-based payouts, clawbacks, structured templates
• Governance-isolated — no off-chain actor (including the DAO LLC) can bypass execution

The ECIP is designed to be minimal and modular:
Treasury accumulation under 1111/1112 begins immediately upon mainnet activation, while governance and ECFPs activate only after audits, testnet validation, and community readiness.
Optional smoothing (ECIP-1115) integrates through ordinary ECFPs.

---

✅ ECIP-1114: Criticism / Response Mapping (Click to Expand)

Criticism	Summary	Response Location	Notes
Spam Proposals / Sybil Attacks	DAO flooded with junk or malicious proposals	Spam & Sybil Mitigations; Security (5)	Draft windows, cooldowns, templates, optional identity modules.
Lack of Transparency	Proposal lifecycle unclear	Transparency & Indexing; Dashboard	All events on-chain; dashboards only mirror contract state.
Proposal Manipulation / Ambiguity	Metadata could drift	Metadata CID; Security (1)	Content-addressed proposals; execution is hash-bound and immutable.
DAO Favors Insiders	Insiders gatekeep proposals	Submission Rules; Openness	Any address may submit; moderators cannot block proposals.
Disbursement Misuse	Recipients misuse funds	Milestones & Vesting; Security (4)	Milestone-based releases, clawbacks, DAO-controlled payout sequencing.
DAO Inactivity / Gridlock	Stalled quorum halts funding	Quorum & Statuses	Quorum enforced; expired proposals handled cleanly; parameters OIP-tunable.
Execution Replay Risk	Execution repeated or replayed on forks	Hash-Bound Execution; Security (1,4)	Bound to (ecfpId, recipient, amount, metadataCID, chainid); single-use only.
Private Donor Influence	Donors bypass or influence DAO	Donation Handling; Legal Interface	All donor funds must follow ECFP flow; no bypass pathways.
DAO LLC Control Risk	LLC overrides DAO	Legal Interface; Governance Isolation	LLC has no Treasury access; no keys; executes only post-DAO for fiat/KYC.
Proposal Bloat / Voter Fatigue	Too many ECFPs overwhelm governance	Child-DAO ECFPs; Spam Mitigation	Recurring infra handled via Child-DAOs; reduces main-DAO load.
Plutocracy via Token Voting	Token voting favors whales	Clarified	Launches one-address-one-vote; any upgrade requires OIP + invariants.
Complexity / Bureaucracy	Process deters new contributors	Minimal Design; Templates	Clear templates + IPFS metadata + predictable lifecycle.
Governance Capture by Delegates	Delegation centralizes power	Clarified	No delegation at launch; future models bounded by OIP constraints.
No Real-World Enforcement	Contractors default post-payout	Security (4); DAO LLC	Milestone vesting + DAO LLC for fiat-side paperwork.
Off-Chain Execution Risk	LLC mishandles conversions	Legal Interface; Reporting	LLC bound to DAO; periodic reporting required.
Infrastructure Funding Recurrence	Core infra competes for proposals	Child-DAO ECFPs	Client/Infra/Security DAOs solve recurring needs without bloat.
Too Similar to EF Grants	Appears like centralized grantmaking	Motivation; Related Work	Replaces opaque foundation grants with transparent on-chain process.
Doesn't Solve Immediate Funding	Network needs funds now	Modular Activation	Treasury accumulates immediately via 1111/1112 upon mainnet activation; ECFPs activate later.
Proposal Review Is Political	Cliques could bias outcomes	Deliberation; Community Processes	Review is public; DAO settlement is final.

---

This March 2026 revision aligns ECIP-1114 with the complete Olympia architecture and current implementation status:

• 1111–1112: Consensus + immutable Treasury — ✅ Client implementation complete
• 1113: Tokenless, modular governance — 🔧 Contract development phase, CoreDAO first
• 1114: Standardized, hash-bound funding process — 🔧 Activates after audits and testnet readiness
• 1115: Optional smoothing at the governance layer

The ECFP lifecycle provides Ethereum Classic with a transparent, decentralized, deterministic funding mechanism for the next decade.

[chris-mercer]

March 2026 Update: ECIP-1115 remains optional and governance-layer only. Activation parameters will be informed by empirical fee market data following Mordor testnet deployment and mainnet activation of ECIP-1111/1112. No consensus changes required.

---

Summary of ECIP-1115 Responses (Updated March 2026)

ECIP-1115 introduces an optional governance-layer smoothing mechanism that reshapes a configurable portion of Treasury-held BASEFEE revenue across a future window using a deterministic L-curve.
The mechanism operates strictly at the governance/application layer and does not modify:

• consensus rules (ECIP-1111),
• Treasury immutability (ECIP-1112), or
• the execution pipeline (ECIP-1113 / ECIP-1114).

ECIP-1115 defines only a framework.
Activation, parameters, curve shape, window length, allocation fraction, and payout cadence are all set through the Olympia Improvement Proposal (OIP) process.

The smoothing module cannot withdraw funds automatically — every payout requires a normal ECFP → DAO vote → timelock → executor call.

Its purpose is to create more predictable long-term miner-support schedules as fixed issuance (ECIP-1017) declines — without altering block rewards, EIP-1559 semantics, or supply.

ECIP-1115 is the data-driven path for miners to receive a share of the basefee directly — with distribution parameters set after real fee market evidence exists, not before. This is by design: getting the parameters right matters more than getting them first.

ECIP-1115 enables ETC to gradually explore long-term, non-inflationary miner-alignment tools while preserving strict immutability, neutrality, and DAO-controlled evolution.

---

✅ ECIP-1115: Criticism / Response Mapping (Click to Expand)

Criticism	Summary	Response Location	Notes
Consensus Layer Complexity	Might alter consensus or BASEFEE computation	Scope (1); Spec (2)	Pure governance-layer; no consensus changes.
Hidden Dev Tax / Miner Dilution	Smoothing takes from miners	❌ Incorrect	BASEFEE already goes to Treasury under 1111; smoothing only shapes Treasury funds. Miners receive 100% of priority fees regardless.
Automatic Payout Concerns	Creates auto-executing entitlements	Spec (3); Governance Integration	No automatic execution; requires ECFP + vote + timelock + executor.
Complexity & Attack Surface	Adds new risk surface	Security Considerations	Modules cannot call Treasury; they compute intended schedules only.
DAO Capture / Abuse	Captured DAO might misallocate funds	❗ Same as any governance action	Still requires 1114's hash-bound execution + timelock pipeline.
Centralization via Miner Lists	Pool lists could centralize power	Spec (4)	Miner Reward Modules must be deterministic, OIP-approved, non-privileged.
User/Dev Fragmentation	Adds complexity to funding flow	Spec (1); Rationale	Optional, modular; base ECFP process unchanged.
Treasury State Risk	Treasury must track smoothing state	❌ Out of Scope	Treasury stores no smoothing state; proposals compute parameters externally.
Economic Validity	Hard to choose window without usage data	Motivation; Governance Integration	Designed for iterative OIP tuning as fee markets mature. Parameters informed by live fee market data post-activation.
Perception of Inflation	Looks like new issuance	❌ Incorrect	Redistributes existing Treasury BASEFEE; zero new supply.
Miner Eligibility Unclear	Who receives payouts?	Spec (4)	Deterministic, transparent, on-chain-constrained eligibility systems.
Governance Fatigue	Too many smoothing ECFPs	❗ Managed	Can batch payouts or use Child-DAO pipelines.
Why Not Hardcode Miner Distribution Now	Skip governance, go direct to miners	❗ Premature	ECIP-1116/1120 represent protocol hardcoding of distribution. These require empirical data from a live fee market to set parameters responsibly. ECIP-1115 provides that evidence base.

---

This March 2026 revision reflects the final ECIP-1115 design and its role in the phased deployment sequence:

• No consensus changes
• No automatic entitlements
• No inflation or new tokens
• No miner penalties
• Deterministic, transparent L-curve logic
• All execution routed through ECFP + OIP governance
• Fully modular and optional
• Parameters set after live fee market data exists — by design

Deployment sequence: ECIP-1111/1112 activate → Treasury accumulates → CoreDAO deploys → fee market data collected → ECIP-1115 parameters informed by evidence → miner distribution path opens.

ECIP-1115 provides ETC a future-proof, non-inflationary way to smooth Treasury-based miner incentives as long-term security needs evolve.

[chris-mercer]

Moderator note (Nov 2025):
This comment reflects early-September discussion during the Olympia draft phase.
The ECIP suite (1111–1115) has since been significantly revised and clarified,
including governance isolation, BASEFEE semantics, smoothing design, and
updated stakeholder feedback.

Marked as Outdated to maintain historical transparency while keeping the
discussion aligned with the finalized November 2025 specifications.

Note on Opposition Tactics (September 2025)

It’s become clear that opposition to Olympia is coming from only a handful of Discord accounts, not from material stakeholders in the Ethereum Classic ecosystem. One account in particular — Wedergarten ( @Soteria-Smart-Contracts )— has now been tied on-chain to past scam activity and to a misinformation bot campaign. Others have leaned on conspiracies, chain-split scare stories, and vague threats of petitions or websites.

This is not constructive engagement with the ECIP process.

For nearly a decade, the community has recognized the need for a decentralized, transparent solution to sustain client development, infrastructure, and security as block rewards decline under ECIP-1017. Olympia (ECIPs 1111–1114) was written to address exactly this — in an opt-in, permissionless way that preserves Proof-of-Work and makes a contentious hard fork extremely unlikely. Targeted deployment: Mordor testnet deployment is Q2 2026. Mainnet activation is targeted for Q3 2026, giving ample time for testnet validation and stakeholder alignment.

The material stakeholders — client maintainers, infrastructure providers, miners, and ecosystem contributors — understand the dilemma and are already signaling intent to support Olympia, or any valid alternative solution presented transparently through the ECIP process. What is clear is that doing nothing is not an option for Ethereum Classic or its stakeholders.

If Olympia is not the right answer, the productive path is not misinformation or theatrics, but drafting an alternative ECIP that directly solves the same problem. To date, no such alternative has been put forward.

March 2026 Update: ECIP-1120 has been put forward as an alternative, and is tracked separately. The Olympia framework addresses the full scope of network security needs; ECIP-1120 addresses only miner distribution while adding complexity and unknown parameters into the ETC protocol.

Without a solution, the network faces only two outcomes:

• a deprecated Core-Geth and an unfunded ETC ecosystem, or
• a centralized takeover of development by an unknown party.

Olympia exists to prevent those outcomes. If you believe there’s a better way, please bring it forward transparently in the ECIP process — not through bots, threats, or off-chain campaigns.

[chris-mercer]

Moderator Note (March 2026)

The questions raised in this thread have been addressed through implementation. ECIP-1111 and ECIP-1112 do not depend on ECIP-1113 viability — the treasury contract receives funds independently of the governance layer, which is a subsequent deployment. The Ronin network demonstrates this staged rollout pattern in production. Client work implementing ECIP-1111, ECIP-1112, and ECIP-1121 is complete and entering Mordor testnet deployment. This thread is resolved. Marked as outdated.

---

Moderator Note (Nov 2025)

The Olympia ECIPs (1111–1115) are now finalized for the November 2025 review phase.
All earlier draft-phase comments have been marked as Outdated where appropriate to preserve the historical record.
Please reference the finalized ECIPs when reviewing or providing feedback:

• ECIP-1111 – Olympia EVM & Protocol Upgrades
  https://ecips.ethereumclassic.org/ECIPs/ecip-1111
• ECIP-1112 – Olympia Treasury Contract
  https://ecips.ethereumclassic.org/ECIPs/ecip-1112
• ECIP-1113 – Olympia DAO Governance Framework
  https://ecips.ethereumclassic.org/ECIPs/ecip-1113
• ECIP-1114 – Ethereum Classic Funding Proposal Process
  https://ecips.ethereumclassic.org/ECIPs/ecip-1114
• ECIP-1115 – Optional Governance-Layer L-Curve Smoothing
  https://ecips.ethereumclassic.org/ECIPs/ecip-1115

Further discussion is welcome but should be grounded in the current November 2025 specifications and aligned with the ECIP-1000 review process.

[chris-mercer]

Olympia Upgrade — March 2026 Checkpoint

Client implementation of ECIP-1111, ECIP-1112, and ECIP-1121 is complete across three execution clients — Core-Geth, Besu, and Fukuii. Implementations have been validated against go-ethereum, erigon, and nethermind reference clients. A multi-client Hive test suite is in place with both pre and post-Olympia configurations across all three clients.

Mordor testnet deployment is the next phase. Block numbers will be set following testnet.

ECIP	Description	Status
1111	EIP-1559 / EIP-3198 — BASEFEE redirect to Treasury	✅ Client implementation complete
1112	Immutable Treasury contract	✅ Client implementation complete
1121	Execution client specification alignment (Olympia Hardfork)	✅ Client implementation complete

The BASEFEE redirected under ECIP-1111 was specified to be burned under standard EIP-1559. Olympia redirects it instead of destroying it — representing less than 0.01% of current miner income, with all priority fees and tips fully preserved. ECIP-1115 provides a data-driven path for miners to receive basefee distribution directly once core network needs are sustainably funded.

[IstoraMandiri]

@chris-mercer Please can you provide links to the client implementation code?

[chris-mercer]

Branches will be shared at Mordor activation.

[IstoraMandiri]

Claiming client implementation is "complete" across three clients while declining to share the code is a red flag. The ECIP process is an open standard — reviewers need to be able to inspect the implementation to verify the claims being made, especially for consensus-level changes like BASEFEE redirection.

"Branches will be shared at Mordor activation" is backwards. The point of review is to catch problems before testnet deployment, not after. If the code exists and works across Core-Geth, Besu, and a new client (Fukuii), there's no technical reason to withhold it.

Reviewable code is how open processes work. Withholding it just asks the community to trust the claim.

[IstoraMandiri]

@chris-mercer I kindly request that you stop hiding my comments. They contain useful information for the public to see, especially your recent moderator note, which says:

The staged admin transfer with mandatory delay transitions control from deployer to on-chain governance transparently and on a documented timeline.

However, this means that ECIPs 1112 and 1113 have a circular dependency around how the Treasury contract gets linked to its governance executor.

ECIP-1112 says the Treasury is immutable — no upgrades, no proxy, no selfdestruct. During the accumulation phase the executor address is set to an invalid value so withdrawals are blocked. But 1112 doesn't define how that address later gets updated to point to the real executor. It says "see ECIP-1113."

ECIP-1113 says the executor address "SHALL be hardcoded into the Treasury according to ECIP-1112's deployment rules." It points back to 1112 for the mechanism.

Neither spec actually defines the concrete step where an immutable contract transitions from an invalid executor address to a valid one. For an immutable contract there are really only two options:

1. The governance executor address is pre-computed (CREATE2) and hardcoded into the Treasury at deploy time. But then the "invalid value during accumulation" design doesn't apply — the address is already set, the executor contract just doesn't exist yet. That's a different trust model than what's described.

2. A write-once setter function where the deployer sets the executor exactly once, then it locks. But both specs explicitly say there are no privileged deployer roles or admin keys.

The claim that "governance activates as a contract layer after the consensus fork with no second hard fork required" and uses a "staged admin transfer with mandatory delay" doesn't appear to be grounded in either specification as written. One of these two proposals needs to own this transition mechanism and specify it concretely, because right now they each defer to the other.