Olympia · Node operators
Upgrade Your Node
Olympia is a hard fork. Before it activates, every Ethereum Classic node has to be running a release that knows about it, or it stops following the network at that block. This page is how you get there, and what changes once you do.
Activation blocks for ECIP-1111 and ECIP-1121 are settled through open coordination among the people who have to act on them: client implementers, node operators, miners, exchanges and infrastructure providers. Mordor activates first, and the mainnet block follows a clean Mordor run and a stakeholder readiness check. Every client publishes a compatible release well ahead of the block.
The recommended path
Run Fukuii
Fukuii is Ethereum Classic’s first native client, written for this network rather than adapted from an Ethereum one, and it is the primary client for the Olympia era. It carries the Olympia changes from ECIP-1111, ECIP-1112, ECIP-1121 and ECIP-1122. It is Apache 2.0, developed in public, and every release carries a build signature and a bill of materials.
Read about FukuiiWhat it needs
- Java
- Current JDK LTS, 25
- Any OpenJDK build of the current LTS. The container image bundles one, so a container node needs no JDK at all.
- Memory
- 8 GB minimum for the JVM heap
- Add headroom for each additional network run in the same process.
- Disk space
- Set by the network and the storage mode
- An Ethereum Classic node is substantially smaller than an Ethereum one. An archive node is a multiple of the pruned figure on either.
- Disk type
- SSD, and NVMe for a mining pool or a public RPC node
- State access during sync is random rather than sequential, which a spinning disk cannot keep up with.
- CPU
- Highest while syncing, lower at the chain tip
- Size for the sync, then scale down on observed usage rather than on the peak.
Install it
The container image is the shortest path from nothing to a running node, because it bundles a Java runtime and there is no JDK to install first.
docker pull ghcr.io/fukuii-project/fukuii-cli:latest
docker run ghcr.io/fukuii-project/fukuii-cli:latest --versionOr install the archive build. Fukuii runs on the JVM, so one archive covers every platform that has a JDK rather than there being a build per operating system, and the checksums file published beside it is what verifies the distribution.
# 1. Install the current JDK LTS (25)
sudo apt update && sudo apt install -y openjdk-25-jdk # Debian, Ubuntu
# sudo dnf install java-25-openjdk-devel # Fedora, RHEL
# 2. Download the distribution and verify it against the published checksums
curl -LO https://github.com/fukuii-project/fukuii-cli/releases/latest/download/fukuii-<ver>.tgz
curl -LO https://github.com/fukuii-project/fukuii-cli/releases/latest/download/SHA256SUMS.txt
sha256sum -c SHA256SUMS.txt --ignore-missing
# 3. Extract, put the launcher on PATH, then verify
tar -xzf fukuii-<ver>.tgz
export PATH="$PWD/fukuii-<ver>/bin:$PATH"
fukuii --versionRun it
A network is selected with one flag. The same binary runs Mordor, and can run both at once in a single process, so adding a network is configuration rather than a second client to install and audit.
# Ethereum Classic mainnet, chain 61
fukuii --network=etc
# Mordor, chain 63, which activates first
fukuii --network=mordor
# Or in a container, with a named volume so state survives a restart
docker run -v fukuii-data:/var/lib/fukuii \
ghcr.io/fukuii-project/fukuii-cli:latest --network=etcIf you mine
Fukuii implements ETChash and the ECIP-1099 epoch schedule, and it serves the work interface mining software connects to, so it can be the node behind a mining operation rather than only a node beside one. A pool talks to it over JSON-RPC, so that surface has to be reachable from the pool process and the payout address has to be set on the node that builds the blocks.
fukuii --network=etc \
--miner-enabled \
--miner-coinbase=0xYourPayoutAddress \
--rpc-http-enabled \
--rpc-http-port=8545 \
--rpc-http-api=ETH,NET,WEB3Upgrading a node you already run
- 1Take the release marked for Olympia from the releases page, which publishes builds for every supported platform well ahead of the activation block.
- 2Stop the node.
- 3Replace the binary, or pull the new container tag.
- 4Start it again and confirm the version.
There is no resync. A hard fork changes the rules a node applies from the activation block onward, not the chain behind it, so an upgraded node keeps the state it already has. Missing the block is the case that costs a resync, because the node follows the old rules past it and leaves the canonical chain.
A supported path
Already running Core-Geth
Core-Geth carries the Olympia parameters from ECIP-1111, ECIP-1112, ECIP-1121 and ECIP-1122. An operator already running it does not have to change client in order to take the upgrade, which is deliberate: an upgrade that forced every operator to migrate at the same time would be a harder upgrade to land safely.
What settles conformance is not a client’s own account of itself. Cross-client state-transition equivalence is demonstrated on Mordor before a mainnet activation block is scheduled, and ECIP-1122 asks for the minimum-tip check at both points a transaction can enter a block, at pool admission and again at block production.
It is in maintenance rather than active development, and that is a real status rather than a polite word for old. The upstream repository received no substantive code commit after June 2024, and the 21-month gap that followed is the longest in this network’s history. Six security vulnerabilities went unpatched during it, and in March 2026 mainnet bootnodes came under active attack. All six are fixed, and the maintained client lives in the ethereumclassic organization.
Run the ethereumclassic build. The original repository at etclabscore is the one that carried the unpatched releases, and an operator still on one of those is running a node with known remote-crash vulnerabilities in it. Rotating the node key afterward is a sensible precaution on any node that has been running a long time.
Upgrading a Core-Geth node
- 1. Take the Olympia release from the ethereumclassic repository, not from etclabscore.
- 2. Stop the node.
- 3. Replace the binary, or update through your package manager.
- 4. Start it again and confirm the version.
New deployments should use Fukuii. A single client that only one organization is positioned to maintain is a network-level risk, and Ethereum Classic has now watched that risk turn into an incident. More than one independent implementation is the structural answer to it.
What changes for an operator
Three client parameters change, and all three are chain configuration rather than consensus rules. A client that does not implement them still follows the chain; it gives weaker guarantees while doing so. Each one codifies something the network has been relying on informally, which is exactly the class of property that works until it does not.
A floor under the miner's tip
MIN_MINER_TIP = 1 gwei
Your node rejects a transaction whose effective tip falls below one gwei, and it checks twice: when the transaction arrives over RPC or peer-to-peer gossip, and again when it selects transactions for a block. This codifies what wallets already recommend rather than introducing a new cost. The transaction-pool price limit inherited from go-ethereum defaults to one wei, a billionth of the figure people actually pay, and any operator can override it.
A gas target the network sets
8,000,000 to 60,000,000
The gas target becomes a network-authoritative value that overrides an operator's own gas-limit flag: 8,000,000 through the Spiral era, and 60,000,000 from Olympia onward. Over three weeks in late 2023 the mainnet limit was dragged from 8,000,000 down toward 1,000,000, blocking deployment of any contract that needed more, and the block headers still show it. One operator's configuration moved the whole network's limit, and the network had no protocol-level defense against that. This parameter is that defense.
MESS comes back on
ECIP-1100 re-activated
Modified Exponential Subjective Scoring scores competing chains exponentially rather than linearly by total difficulty, which makes a low-cost chain reorganization expensive to attempt. It ran from block 11,380,000 and was switched off at block 19,250,000, which is Spiral's own activation block, so the deactivation was scheduled into that upgrade rather than a response to conditions. Olympia restores it, closing a window that runs precisely from Spiral to Olympia.
Two floors, on the two halves of the gas price
Olympia introduces two separate floors, set by two different ECIPs, and quoting one of them alone understates what a transaction costs. Ethereum Classic has no base fee at all today, because EIP-1559 is not active here, and its miner tip is floored at one wei by client default, so the one gwei people actually pay is a wallet convention rather than a rule the network enforces.
| Per unit of gas | Set by | Amount | Paid to |
|---|---|---|---|
| Base fee floorMIN_BASE_FEE | ECIP-1111, a consensus rule applied at every block | 1 gwei | The Treasury |
| Miner tip floorMIN_MINER_TIP | ECIP-1122, chain configuration | 1 gwei | The miner |
| Minimum gas priceMIN_GAS_PRICE | Derived from the two above, on a conformant network | 2 gwei | Split between them |
What it costs a sender
A standard transfer consumes 21,000 gas, so the two-gwei floor puts its minimum cost at 0.000042 ETC. What people actually pay today is around one gwei by convention, which puts the same transfer at 0.000021 ETC. The floor doubles a very small number. Against what clients permit it is a far larger multiple, and that gap is the point: it is friction at spam scale and nothing at all at ordinary human scale.
Not EIP-1559’s initial base fee
MIN_BASE_FEE is a permanent floor applied at every block. EIP-1559’s INITIAL_BASE_FEE applies once, to the fork block itself. The two happen to share the value of one gwei and they are distinct constants, so they must not be conflated in client configuration.
What a block producer can still do
Only MIN_BASE_FEE is a consensus rule. The tip floor is chain configuration, so a producer that declines to enforce it can still include cheaper transactions, and every other node has to accept and store them. Two gwei is therefore what a conformant network charges rather than a guarantee the protocol makes, and one gwei is the floor that holds regardless.
What Olympia means if you mine
The short answer is that block rewards do not change and tips still go to the miner in full. The longer answer is worth the paragraphs below, because the honest version has a nuance in it and the network figures are the reason the question matters at all.
Ethereum Classic today
Reference figuresBlock height
25,124,079
Ethereum Classic mainnet, chain 61
Block space used
0.12%
Almost every block has room to spare
Gas limit
8,000,000
Olympia raises the target to 60,000,000
Block reward
1.6384 ETC
Falls by a fifth at block 30,000,001, 4,875,922 away
Measured from Blockscout on 11 August 2026 and shown until the live read arrives. Block reward is derived from the height under ECIP-1017. Check it yourself
Block rewards do not change
ECIP-1017’s emission schedule is untouched. Olympia changes where a fee component goes, not ETC’s supply or its issuance.
Tips still go to the miner
In full, and paid directly to block producers as they are today. Olympia puts an enforceable floor under the tip for the first time.
The base fee does not exist yet
EIP-1559 is not active on Ethereum Classic, so nothing is being burned and nothing is being discarded. Olympia creates the component and sends it to the Treasury.
The nuance, stated rather than skipped. At the minimum gas price the miner’s floor rises rather than falls: the Treasury’s gwei is new cost borne by the sender, and the tip floor beneath the miner becomes enforceable where the client default today is one wei. Above the floor it runs the other way. At a fixed total gas price, one gwei per unit of gas moves from the tip to the Treasury. ECIP-1111 puts that at a low single-digit percentage of fee income measured against Ethereum Classic’s observed fee levels, and fee income is itself a fraction of a percent of total miner revenue while block subsidies dominate.
That last clause is the whole argument. The block subsidy falls by a fifth every 5,000,000 blocks under ECIP-1017, and it keeps falling. On any Proof-of-Work network, fee income has to grow into the gap the subsidy leaves behind. Ethereum Classic’s fee income cannot do that yet, and the figures above are why: block space is almost entirely unused, so there is very little fee income to grow.
Olympia does not close that gap on its own, and nothing here claims it does. What it does is put the parts in place. A fee market that exists at all, rather than one deferred at Mystique pending a decision on where the base fee should go. A floor under it, so it cannot decay to nothing while blocks stay empty. And a funding path for the development that would produce the usage that makes any of this matter at all.
The security budget question gets its own answer later in the roadmap, in two stages that are sequenced on purpose. ECIP-1115 runs a candidate curve at the contract layer, where the allocation fraction, window length and curve shape are adjustable through governance and a mistake costs a proposal rather than a fork. Only once a curve is demonstrated in production does ECIP-1116 spend a second hard fork embedding it into block finalization, after which the protocol pays it directly and the payment path leaves governance entirely.
What Olympia changes in the EVM
Two ECIPs touch the execution layer. ECIP-1111 activates the fee market. ECIP-1121 brings the rest of the execution layer into line with Ethereum, excluding everything that depends on Proof-of-Stake or on blob data availability.
ECIP-1111 activates two EIPs
A transaction pays a base fee the protocol sets and a tip the sender chooses, with the base fee adjusting block by block to demand. Ethereum burns that base fee. Ethereum Classic redirects it at the consensus layer to the Treasury, credited once per block as gas used multiplied by the base fee for that block.
Opcode 0x48, which gives a contract access to the current block’s base fee. It is what makes fee-aware contract logic possible, and it is half of why tooling that assumes EIP-1559 semantics works on Ethereum Classic without ETC-specific handling.
Both are fully additive: a new transaction type and a new opcode. Type-0 and Type-1 transactions, already-deployed contracts and historical state are all unaffected.
ECIP-1121 aligns the rest of the execution layer
Ethereum Classic implemented partial London EIPs at Mystique in 2022 and partial Shanghai EIPs at Spiral in 2024, deliberately deferring the fee market so its governance could be designed separately. ECIP-1121 fills the Shanghai gaps Spiral left and carries the execution layer forward through three delivered Ethereum upgrades and into a fourth that has not activated yet.
Two more arrive without a fork. eth/69 and eth/70 are peer-to-peer protocol versions rather than consensus changes, and they negotiate as devp2p capabilities, so they activate independently of the activation block.
Glamsterdam is the alignment target, not a finished one
Glamsterdam is still being assembled on Ethereum, so there is no settled set to align to yet. ECIP-1121 adopts the 2 pieces of it that are ready and stable: the deterministic factory contract (EIP-7997), which gives Ethereum Classic the same deployment addresses as every other EVM chain, and eth/70 (EIP-7975). A further 7 are listed for the Olympia Core Devs Call, adopted by nothing and rejected by nothing until that call classifies them. Three more, EIP-2780, EIP-8037 and EIP-8038, are a mutually dependent gas-repricing cluster that resolves to EIP-7928, which adds a field to the block header and so needs its own ECIP rather than fitting inside an execution-layer-only one. EIP-7708 waits on EIP-4788, which is itself excluded here as Proof-of-Stake. Fusaka is a delivered cycle, and its execution-layer work is in this set wherever it does not depend on blobs or on Proof-of-Stake.
Gas and state access
Account code for externally owned accounts, recalibrated calldata and MODEXP pricing, a bound of 8,192 bits on MODEXP inputs, a per-transaction cap of 16,777,216 gas, and the 60,000,000 gas target. Type-4 transactions use chain ID 61 on mainnet and 63 on Mordor for replay protection.
EVM safety
SELFDESTRUCT restricted to the transaction that created the contract, a block size limit of 8 MiB, the eth_config JSON-RPC method, and a deterministic factory contract. That 8 MiB is the same execution-layer limit Ethereum enforces rather than a smaller one: Ethereum reaches it by holding 2 MiB of a 10 MiB budget back for its beacon block, and the figure each chain applies to the block itself is identical.
Execution context
Transient storage through TSTORE and TLOAD, historical block hashes served from state, MCOPY for memory copies, and the CLZ opcode at 0x1e. Between them they unlock reentrancy guards and cross-contract patterns that do not have to touch persistent storage.
Blobs are excluded by design. 9 EIPs that depend on blob data availability are left out: EIP-4844, EIP-7516, EIP-7594, EIP-7691, EIP-7840, EIP-7892, EIP-7918, EIP-8070 and EIP-8136. Ethereum introduced blobs to carry Layer 2 data. Ethereum Classic is a Layer 1 execution chain and does not have that problem, so it takes the execution-layer work without inheriting the scaffolding underneath it. The Proof-of-Stake set, from beacon-chain dependencies through proposer-builder separation, is excluded on the same basis: not applicable rather than deferred.
Developer tooling: works without modification
Solidity 0.8.x and later
Recent compiler versions and optimization passes produce compatible bytecode for Ethereum Classic without modification.
Foundry and Hardhat
Standard EVM testing and deployment toolchains work without ETC-specific forks or patches.
wagmi, viem and ethers.js
Standard wallet libraries and RPC types work without patching or overrides. One codebase, every EVM chain.
Olympia Roadmap
Five stages from consensus upgrades to permanent protocol integration.
Consensus Upgrades
ActiveOlympia activates as a hard fork, and it is one of only two stages that change consensus rules. Glamsterdam-era EVM alignment means every Ethereum tool and framework runs on Ethereum Classic without modification. The EIP-1559 fee market redirects the base fee to a protocol treasury instead of burning it, and the treasury contract deploys at this fork. The governance suite that spends from it comes later.
- Glamsterdam-era EVM alignment: Dencun, Pectra, Fusaka, and Glamsterdam EIPs (ECIP-1121)
- EIP-1559 fee market with basefee redirected to the treasury (ECIP-1111)
- Protocol treasury contract deployed at the fork (ECIP-1112)
- Client security parameters: minimum miner tip, network-authoritative gas target, MESS restored (ECIP-1122)
Core Governance
ActiveCore development funding moves on-chain, open to any developer, infrastructure provider or critical service operator worldwide. No private employment contracts, and no prior relationships required. These are contracts on a chain whose rules are already settled, so no fork is involved. The gap after the first stage is an audit window, and the treasury accrues revenue throughout it.
- Governance suite deploys after the fork, against addresses reserved before it
- Full proposal lifecycle: submit, vote, queue, execute
- Governance and treasury contracts with timelock execution
- Core contributor voting with on-chain sanctions screening
- Open competitive bidding, any EVM developer or infrastructure provider can participate
- Core developers, infrastructure providers, and critical services funded on merit
- Direct on-chain contributions and ETC Cooperative donation channel
Prediction Markets
ResearchOpen prediction markets let anyone take a financial position on protocol decisions. Public participants trade on what Ethereum Classic is worth under a proposal accepted against what it is worth under the same proposal rejected, priced in Classic USD. Because a position pays in proportion to being right, prices carry information a poll cannot. Olympia DAO votes on whether, how much and within what scope to seed a grants season; once seeded, the market settles who is funded out of it, and the higher-priced branch is the allocation rather than a recommendation about one. Market activity also generates base fee revenue, which flows back into the treasury.
- Open to anyone with an ETC account
- Financially incentivizes the public to monitor and evaluate protocol proposals
- Onboards new participants to ETC through active market engagement
- Market activity generates base fee transactions that compound the treasury flywheel
- Collateral is ETC and Classic USD, both already live, custodied outside the treasury
- Market-informed proposal ranking alongside formal DAO votes, a signal layer, never binding
- Accurate predictions earn financial rewards, holding governance accountable
Treasury Distribution
FutureA smoothing curve supplements miner security budgets as fixed-emission block subsidies decline, spreading each block's contribution across a future window so payouts stay steady rather than volatile. ECIP-1115 runs the curve at the contract layer, where the allocation fraction, window length and curve shape are all adjustable through governance without a fork. Running it here first means the network learns the right curve by measuring it, while ECIP-1017 block rewards still secure the chain and a mistake stays cheap to correct.
- Treasury smoothing curve at the contract layer (ECIP-1115)
- Allocation fraction, window length, and curve shape adjustable through governance, no fork required
- Each candidate curve is funded through the ordinary proposal process, like any other line item
- Complements ECIP-1017's 5M20 emission schedule so the treasury responds as subsidies decline
- Runs while block rewards still secure the network, so the curve is measured rather than assumed
Protocol Integration
FutureThe second hard fork, and the only other stage that changes consensus rules. Once the smoothing curve has proven itself in production, ECIP-1116 embeds it into block finalization. The protocol pays it directly rather than disbursing it from the treasury, and governance can no longer adjust it. Changing it afterward costs a fork, which is the guarantee being bought: a security budget that does not depend on continued cooperation at the moment it matters most.
- Consensus-layer hardening of the demonstrated curve (ECIP-1116)
- Paid at block finalization rather than disbursed from the treasury, which takes governance out of the payment path
- Cannot activate until the contract-layer stage has produced real observational data
- Follows the ECIP-1017 precedent of encoding proven rules natively into the protocol
- Parameters deliberately unset until measured; hardening an unmeasured number repeats the mistake the staging avoids
Where to go next
Governance tooling, treasury figures, and the repositories behind all of it.
Frequently Asked Questions
A node still running the old rules at the activation block stops following the canonical chain. It keeps producing and accepting blocks under rules the rest of the network has left behind, so it is no longer on Ethereum Classic. Exchanges, wallets, RPC providers and services in that position cannot process transactions on the post-Olympia chain. Client releases are published well ahead of activation to give operators time, and the fix afterward is to upgrade the client and resync from the fork point.
Not if you upgrade before the activation block. A hard fork changes the rules a node applies from that block onward; it does not rewrite the chain behind it, so an upgraded node keeps the state it already has and carries on. Resyncing is only the recovery path for a node that missed the activation and followed the old rules past it.
Fukuii for anything new. It is Ethereum Classic's first native client, written for this network rather than adapted from an Ethereum client, and it is the primary client for the Olympia era. Core-Geth is a path for an operator already running it, so nobody has to migrate in order to take the upgrade, but it is in maintenance rather than active development and a node that does not exist yet should not be starting there. Both carry the Olympia parameters. What settles conformance is not a client's own account of itself: cross-client state-transition equivalence is demonstrated on Mordor before a mainnet activation block is scheduled.
Block rewards do not change. ECIP-1017's emission schedule is untouched, and Olympia changes where a fee component goes rather than ETC's supply or issuance. Tips still go to the miner in full. What Olympia adds is a base fee, which Ethereum Classic does not have today because EIP-1559 is not active here, and that base fee is redirected to the Treasury instead of being burned. At the minimum gas price the miner's position improves rather than worsens: the base fee is new cost paid by the sender, and the 1 gwei floor under the tip becomes enforceable for the first time, where the client default today is 1 wei. Above the floor it runs the other way, because at a fixed total gas price one gwei per unit of gas moves from the tip to the Treasury. ECIP-1111 puts that at a low single-digit percentage of fee income measured against Ethereum Classic's observed fee levels, and fee income is itself a fraction of a percent of total miner revenue while block subsidies dominate.
It is not set. ECIP-1111 and ECIP-1121 both carry TBD for Mordor and for mainnet, to be finalized through open coordination among client implementers, node operators, miners, exchanges and infrastructure providers. Olympia is targeted for mainnet activation in 2027. Mordor activates first; the mainnet block follows a clean Mordor run and a coordinated stakeholder readiness check with exchanges, mining pools, node operators and infrastructure providers. All client implementations publish Olympia-compatible releases well before activation, and the process follows the same sequence used for every previous ETC hard fork.
Olympia activates on the Mordor testnet first. Mordor is Ethereum Classic's Proof-of-Work testnet and mirrors mainnet conditions closely. Multiple independent client implementations run the Mordor fork before any mainnet activation is scheduled. Cross-client validation using the Hive integration testing framework confirms consensus compatibility across implementations. The mainnet activation block is not set until Mordor has run cleanly and major network stakeholders, including exchanges, custodians, and mining pools, have confirmed readiness.
In the unlikely event of a critical issue after activation, the same client teams that have managed every ETC emergency response since 2016 would coordinate a patch release promptly. The established stakeholder communication channels, including the ETC Cooperative, client maintainers, and major exchange contacts, are the same ones used for every previous upgrade. Olympia has broader test coverage across more independent client implementations than any previous ETC hard fork, and the Mordor testnet run provides a real network validation environment before mainnet activation.
ECIP-1121 closes years of execution-layer divergence in a single upgrade, filling the remaining Shanghai gaps left by Spiral's partial implementation and delivering the improvements from Dencun, Pectra and Fusaka that are independent of Proof-of-Stake and blob data availability, then carrying that work into Glamsterdam. Glamsterdam is the alignment target rather than a completed one: that upgrade is still being assembled on Ethereum, so ECIP-1121 adopts the pieces of it that are ready and stable, lists a further set for the Olympia Core Devs Call to classify, and tracks the rest behind the dependencies that gate them rather than rejecting any of it. What changes for a builder is tooling. Solidity 0.8.x, Foundry, Hardhat, wagmi, viem and ethers.js all work on ETC without modification, patching, or ETC-specific overrides, so one codebase deploys to every EVM chain. The consequences extend past tooling: wallets, exchanges, oracles and bridges make integration decisions based on EVM compatibility, and ETC re-enters the default support scope of those products without requiring custom work from their teams. Security auditing tools, compiler improvements and best practices the EVM community produces continuously now apply to ETC as well.
The Olympia Treasury is funded by EIP-1559 base-fee revenue, the only protocol-defined source, alongside voluntary on-chain donations. No ECIP directs mining revenue to the Treasury. A transaction pays a base fee plus a priority-fee tip; Ethereum burns the base fee and Olympia redirects it instead. Tips and ECIP-1017 block rewards remain untouched and go entirely to miners. Futarchy prediction market activity generates additional transaction volume that flows back into the treasury as base-fee revenue. Any stakeholder, whether exchanges, custodians, miners, investment product issuers, or institutions holding ETC on behalf of fund shareholders, can contribute directly on-chain with no overhead. Stakeholders who prefer a traditional giving model can instead contribute through the ETC Cooperative, which is a US 501(c)(3) non-profit and accepts tax-deductible donations.
Olympia is coordinated by the same developers, organizations, and community stewards who have delivered every Ethereum Classic network upgrade since 2016: Gotham, Die Hard, Defuse Difficulty Bomb, Thanos, and the full EVM compatibility series spanning Gas Reprice, Atlantis, Agharta, Phoenix, Magneto, Mystique, and Spiral. The ETC Cooperative, a US 501(c)(3) non-profit, funds Ethereum Classic's client development teams and has managed the hard fork coordination process throughout that history. Stakeholder outreach, client release sequencing, and cross-client testing are all established practice. Olympia is a significant upgrade carried forward by a team with a clean delivery record across a decade of ETC network upgrades.
The ETC Cooperative is a US 501(c)(3) non-profit that has funded Ethereum Classic's core client development for years, contributing millions of dollars to the network's client teams and infrastructure through every upgrade cycle. Every hard fork, every client release, and every cross-client coordination effort has been backed by their balance sheet. Olympia is what they were building toward: a protocol-native funding model that does not depend on any single organization's continued generosity. The Olympia Treasury, governed and paid out on-chain by the Olympia DAO, with a Wyoming DAO LLC standing behind it as an off-chain legal interface rather than as its executor, extends beyond institutional dependency to a durable financial foundation that scales with network usage. The model changes, not the commitment. The ETC Cooperative continues as an active steward, and any developer, mining operation, hardware manufacturer, or individual worldwide can now contribute directly on-chain without fielding a team or managing a non-profit to do it.
Grayscale launched the Grayscale Ethereum Classic Trust (ETCG) in 2018, years before Bitcoin ETFs existed as a product category, and became a major institutional donor to the ETC Cooperative, indirectly funding the network's core client development at a time when no other investment product issuer was doing anything comparable. What Grayscale was practicing on Ethereum Classic in 2018 is now a recognized trend: ETF issuers funding protocol development, corporate treasury strategies reinvesting in network ecosystems. Taking that model on-chain is only possible on Ethereum Classic because ETC is the only Proof-of-Work blockchain with native smart contracts. Olympia DAO makes it permissionless, opening a direct on-chain contribution path to every holder, whether through ETCG, a direct wallet, or any future investment product.
Olympia strengthens ETC's regulatory profile. As a Proof-of-Work blockchain with no pre-mine, no ICO, no foundation controlling the protocol, and now a community-governed on-chain treasury, ETC is positioned for classification as a digital commodity under the CLARITY Act. In the EU, ETC qualifies as a decentralized asset under MiCA, exempt from per-asset issuer requirements. Japan's FSA lists ETC among approved digital assets. UK and UAE regulatory frameworks treat Proof-of-Work assets with distinct treatment from staking-based networks. The three-layer governance structure, protocol clients, Wyoming DAO LLC, and on-chain Olympia DAO, maintains clear decentralization while satisfying compliance requirements at the legal entity layer. The network remains decentralized, and governance is open to any qualified participant worldwide.