# OlympiaDAO. On-Chain Governance for Ethereum Classic

> On-chain governance and treasury infrastructure for Ethereum Classic, the largest Proof-of-Work smart contract platform.

## Pages on This Site

- https://olympiadao.org/: home. What Olympia is, the one-way path base-fee revenue takes, and the contract architecture
- https://olympiadao.org/overview: the primary Olympia explainer. Routes into one page per question below
- https://olympiadao.org/overview/funding: Where the money comes from (ECIP-1111)
- https://olympiadao.org/overview/treasury: Where it goes, and who owns it (ECIP-1112)
- https://olympiadao.org/overview/proposals: Who decides how it is spent (ECIP-1113, ECIP-1114)
- https://olympiadao.org/overview/prediction-markets: What stops it being captured (ECIP-1117, ECIP-1118)
- https://olympiadao.org/overview/eligibility: Who cannot receive it (ECIP-1119)
- https://olympiadao.org/overview/security-budget: What happens to miners when the subsidy runs out (ECIP-1115, ECIP-1116)
- https://olympiadao.org/overview/what-ships: What ships at the fork (ECIP-1121, ECIP-1122)
- https://olympiadao.org/upgrade: how to upgrade a node through the Olympia hard fork
- https://olympiadao.org/governance: what the DAO funds, and why
- https://olympiadao.org/clients: Ethereum Classic client implementations, and why the network carries more than one
- https://olympiadao.org/clients/fukuii: Fukuii, Ethereum Classic's first native client and the primary client for Olympia
- https://olympiadao.org/clients/core-geth: Core-Geth, a go-ethereum derivative maintained through the upgrade

The `/overview/*` pages explain the framework. The top-level pages are where a reader acts.

## What is Olympia?

Olympia is Ethereum Classic's most significant protocol upgrade: a coordinated suite of ECIPs that closes years of EVM execution-layer divergence in a single activation, delivering Glamsterdam-era EVM alignment, the EVM ecosystem's most widely adopted fee market, and a protocol-controlled treasury to the only Proof-of-Work smart contract platform in the world.

The headline change is EVM execution-layer alignment. Olympia advances ETC through Dencun, Pectra and Fusaka, and carries that work into Glamsterdam. Every Solidity compiler version, Foundry, Hardhat, wagmi, viem, and ethers.js works on ETC without modification, patching, or ETC-specific overrides. One codebase deploys to every EVM chain. ETC could not credibly claim this before Olympia. After Olympia, it can.

The Olympia era marks a shift from reactive maintenance to active development. ETC inherits the commodity classification path that Proof-of-Work networks established and the programmable finance frameworks being built around smart contract platforms, positioning it across every major regulatory trajectory simultaneously.

## Four Client-Facing ECIPs

**ECIP-1121. Glamsterdam EVM Alignment:** Fills the remaining Shanghai gaps from Spiral's partial implementation and advances the ETC execution layer through Dencun (Cancun-Deneb), Pectra (Prague-Electra), and Fusaka (Fulu-Osaka), then carries that work into Glamsterdam (Gloas-Amsterdam). ETC implemented partial London EIPs in Mystique (2022) and partial Shanghai EIPs in Spiral (2024), deferring the EIP-1559 fee market for independent governance design. ECIP-1121 delivers the remaining execution-layer EIPs that are independent of Proof-of-Stake and blob data availability. Together, Olympia brings ETC current through Fusaka and opens Glamsterdam. Glamsterdam is the alignment target rather than a completed one: that upgrade 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) 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; EIP-7708 waits on EIP-4788, which is itself excluded as Proof-of-Stake. After Olympia, every Ethereum tool works on ETC without modification.

**ECIP-1111. EIP-1559 Fee Market:** Activates two EIPs, not one: EIP-1559, the fee market itself, and EIP-3198, the BASEFEE opcode at 0x48 that gives a contract access to the current block's base fee. Unlike Ethereum where the basefee is burned, ETC credits it to the Olympia Sovereignty Vault, which forwards it to the Olympia Treasury, the mechanism that funds open-source core development without any foundation or donor dependency. Dynamic gas pricing delivers predictable fees for users and applications. Fully additive: a new transaction type and a new opcode, so legacy transactions remain valid indefinitely. Miner block rewards and tips remain completely untouched.

**ECIP-1112. Sovereignty Vault:** Establishes the Olympia Sovereignty Vault, the permanent immutable address where Ethereum Classic's own base-fee revenue accumulates, owned by no company, foundation, or individual. It holds nothing for long: it forwards its balance to the Olympia Treasury (ECIP-1113), the timelock from which core development, critical infrastructure and network security are funded. Vault and Treasury are two contracts with two jobs, and this ECIP specifies only the first: the address consensus credits at every block, with no owner, no role, no setter and no parameter, whose entire behavior is to receive value and forward it unchanged to one address fixed at construction. That address is the Olympia Treasury, the ECIP-1113 TimelockController, which is what actually holds the money and is never ECIP-1112's. Exactly one contract in the Olympia suite is permanent and it is the Vault; changing it would cost a hard fork. Everything below it, the Treasury included, is replaceable through ordinary governance, with one qualification worth stating plainly: the Vault's destination is immutable, so it fixes where new revenue lands rather than who spends it. The Timelock holding the funds stays the standing inbox for base-fee revenue, and a successor is deployable and fundable by ordinary proposal, because the incumbent can forward its whole balance onward and can do so again for any later accrual. Replacing it costs no hard fork; what it costs is a recurring forwarding step rather than a single act. Nothing is predicted: no CREATE2 derivation, no init-code freeze and no reserved deployer nonce is permitted as the basis of the consensus commitment. Contracts deploy in ordinary dependency order, the real deployed address is published, and the fork points clients at that published address afterward. For the first time, institutions, developers, and network stakeholders can directly fund Ethereum Classic's core development without fielding their own team. Miners receive everything they do today: tips and ECIP-1017 block rewards remain completely untouched. No admin keys, no multisig. Only on-chain governance can release funds.

**ECIP-1122. ETC Network Security Client Configuration:** Three parameters every Olympia client is required to enforce identically: a 1 gwei minimum effective miner tip, so miners keep an economic incentive to process transactions once the basefee is redirected, which combines with ECIP-1111's separate 1 gwei base-fee floor to set a minimum gas price of 2 gwei; a network-authoritative gas target that overrides operator flags (Spiral era 8,000,000; Olympia era 60,000,000), closing the gas-limit manipulation vector the chain's own block headers record in late 2023; and re-activation of Modified Exponential Subjective Scoring (ECIP-1100), restoring the chain-reorganization resistance that was switched off at Spiral. These are chain configuration rather than consensus rules, a client that omits them provides weaker guarantees without forking. That distinction bounds the fee floor: only ECIP-1111's base-fee floor is consensus-enforced, so the 2 gwei minimum is the conformant-network figure rather than a protocol guarantee, and 1 gwei is what holds against a block producer that declines to enforce the tip floor.

Included EIP categories:
- Gas & State Access: EIP-7702 (set EOA account code), EIP-7623 (increase calldata cost), EIP-7825 (transaction gas limit cap, 2^24), EIP-7823 (MODEXP input bounds, 8192 bits), EIP-7883 (MODEXP gas cost increase), EIP-7935 (default gas limit 60M)
- EVM Safety: EIP-6780 (SELFDESTRUCT only in same tx), EIP-7910 (eth_config JSON-RPC method), EIP-7934 (RLP block size limit, 8 MiB, the same execution-layer constant Ethereum enforces), EIP-7997 (deterministic CREATE2 factory at the same address as every other EVM chain)
- Cryptographic Precompiles: EIP-2537 (BLS12-381 for ZK-friendly proofs), EIP-7951 (secp256r1 / P256VERIFY for WebAuthn and passkeys)
- Execution Context: EIP-1153 (transient storage TSTORE/TLOAD), EIP-2935 (historical block hashes in state), EIP-5656 (MCOPY memory copy), EIP-7939 (CLZ opcode)
- Networking: EIP-7642 (eth/69, drops receipt bloom filters), EIP-7975 (eth/70, paginates receipts for blocks above the p2p size limit). Both activate through devp2p capability negotiation rather than a hard fork.

Explicitly excluded: all blob-dependent EIPs (EIP-4844, EIP-7516, EIP-7691). Ethereum Classic is a pure Layer 1 execution chain with no data availability requirement. Blobs are L2 scaffolding ETC does not need.

Developer impact: Solidity 0.8.x+, Foundry, Hardhat, wagmi, viem, and ethers.js all work on ETC without modification or ETC-specific forks after Olympia.

## How It Works

1. **Base Fee Revenue:** A transaction under EIP-1559 pays a base fee plus a priority-fee tip. Ethereum Mainnet burns the base fee and pays the tip to the block producer; Olympia changes the destination of the base fee only, crediting it to the Olympia Sovereignty Vault, which forwards it to the Olympia Treasury. Tips and ECIP-1017 block rewards remain completely untouched. Miners are unaffected. Treasury revenue is gas consumed multiplied by the base fee, it is not a share of the gas limit, and raising the gas limit creates no revenue on its own.
2. **Treasury:** The Olympia Treasury is the ECIP-1113 TimelockController, and it is what holds the money: base-fee revenue swept in by the Vault, plus voluntary donations. It does not invest, allocate, or choose recipients, and the Governor is its only executor. No new token issuance. Non-inflationary by design.
3. **Governance:** Community proposals allocate treasury funds through on-chain voting with timelock security. There is no separate executor contract: execution is TimelockController.execute(), gated on EXECUTOR_ROLE, which ECIP-1113 grants to the Governor and to nothing else. The sanctions check runs inside the Governor at execution time, and that single role grant is what makes it unavoidable for Treasury funds.

## The Framework, Question by Question

https://olympiadao.org/overview is the primary Olympia explainer and the page the rest of the suite links for depth. It carries the whole framework in one place and routes into one page per question below.

It draws the money's path as five stations on one rail. In: every transaction pays a base fee, credited in consensus as each block is finalized, with no transaction involved. Tips and ECIP-1017 block rewards are drawn as a branch leaving the rail at that first station, because they never enter it. Credited: the Olympia Sovereignty Vault, the one permanent contract, which forwards everything unchanged to one address fixed when it was built. Held: the Olympia Treasury, which is what actually holds the money and is replaceable by ordinary governance. Decided: three layers, Propose, Decide and Release, which a payment clears in order. Out: core development, critical infrastructure and network security, which are the purposes the Treasury exists for, allocated by whatever proposals passed rather than by formula.

It also carries the five stages as a visual sequence rather than a flat list, because ECIP-1121 names conflating a rollout schedule with a deployment mechanism as the most common misreading of the roadmap. The fork distinction is carried on three independent channels, a bar, a glyph and a text badge, rather than on color alone.

### Where the money comes from (https://olympiadao.org/overview/funding, ECIP-1111 and ECIP-1122)

A transaction buys room in a block and room is priced in gas. Under the fee market Ethereum has run since 2021 that price has two parts: a base fee the network sets for everyone in the block, and a tip the sender adds for whoever produces it. Ethereum destroys the base fee. Olympia keeps it. Ethereum Classic had no base fee before Olympia, so the component is created rather than redirected, and nothing was being burned or discarded that Olympia then captures. Per unit of gas: the base fee is at least 1 gwei and goes to the Treasury, the miner tip is at least 1 gwei and goes to the miner, so the least a transaction can pay is 2 gwei where the enforced floor beforehand was 1 wei. A plain transfer consumes 21,000 gas, which puts the cheapest possible transfer at 0.000042 ETC: friction at spam scale and nothing at human scale. Two gwei is what a conformant network charges rather than a promise the protocol makes, because only ECIP-1111's base-fee floor is a consensus rule every node checks while ECIP-1122's tip floor is chain configuration, so 1 gwei is the figure that holds regardless. Miners keep everything they earn: block rewards are untouched, tips are paid in full, and the tip floor becomes enforceable for the first time. At the minimum a miner is better off rather than worse, since the Treasury's gwei is new cost carried by the sender; 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, which ECIP-1111 puts at a low single-digit percentage of fee income. Revenue is gas consumed multiplied by the base fee. The gas limit is not an input, so a percentage quoted against the limit describes the limit rather than the money, and raising the target creates no revenue on its own. The money does not come from inflation, from block rewards, from a foundation or a premine, or from Ethereum's burn.

### Where it goes, and who owns it (https://olympiadao.org/overview/treasury, ECIP-1112 and ECIP-1113)

Two contracts are named and there is no third term. "Sovereignty Vault" is the ECIP-1112 contract's name and never a name for the money; the Treasury is ECIP-1113's and never ECIP-1112's. The Olympia Sovereignty Vault is the one permanent contract, at the address consensus credits, around thirty lines with no owner, no role, no setter and no parameter, so there is nothing to configure and nothing to misconfigure. The Olympia Treasury is the ECIP-1113 TimelockController that actually holds the money and is the only place a payment leaves from. Exactly one contract is permanent and that single boundary is the architecture: consensus has to name something in place of the burn, whatever it names cannot change again without a hard fork, so the design puts as little as it can on the permanent side of the line. Everything below it, the Treasury included, is replaceable by ordinary governance. The qualification ECIP-1113 requires be stated plainly is that the Vault's destination is immutable, so it fixes where new revenue lands rather than who spends it: a successor Treasury is deployable and fundable by ordinary proposal because the incumbent forwards its whole balance onward, which makes replacement a governance program with a recurring step rather than a single act. Moving a balance from the Vault to the Treasury takes one call anyone may make, and the caller chooses when the money moves and never where. No address is worked out in advance: contracts deploy by ordinary transactions, the real address is published, and only then is it written into the clients. Ownership rests with no company, foundation or individual, it is not a multisig, and one account can tell the Treasury to pay, which is the Governor. An administrative role exists briefly during setup and is given up in the same sequence, before the Vault exists, before any address is published, and while the Treasury holds nothing. The Treasury does not invest, does not allocate by formula, does not choose recipients, and keeps no books of its own, since consensus credits the Vault by writing to its balance without running code, so a contract totaling its own deposits would total zero.

### Who decides how it is spent (https://olympiadao.org/overview/proposals, ECIP-1113 and ECIP-1114)

Submission is permissionless subject to one setting. The Governor carries a proposal threshold, a minimum amount of voting power an author must hold: left at zero any account on Ethereum Classic can author a proposal, and set above zero authorship narrows to core contributors, because voting power comes from one place and nowhere else. It is the only anti-spam control the specification requires, so the value is a stated decision rather than a default. The recipient, the amount and a fingerprint of the supporting document are folded into the proposal's identifier, so changing any of them produces a different proposal and what voters read is provably what executes. Proposals normally arrive through a registry that records them and binds the metadata, but nothing forces that and one can be put straight to the Governor, which faces the identical delay, voting period, quorum, approval rule and execution screen. What a direct proposal skips is the audit trail, not the vote, and voters enforce the norm by how they vote rather than a contract applying a rule. Voting is core contributors and one vote each, carried by a soulbound CoreNFT that cannot be transferred, lent or delegated, where one address is one vote however many exist and only a passed proposal can create one. No identity check is required and none may be imposed. A payment clears four on-chain steps, none skippable and none settable to zero: Submit, Vote, Queue, Execute. Voting power is fixed by a snapshot rather than read live, so admitting or revoking a contributor mid-vote cannot rewrite a tally in flight, and a proposal reaching quorum near its deadline extends it. There is no separate execution contract and nothing that could become one: the Treasury carries out operations itself and exactly one account may tell it to, which is what makes the compliance screen unavoidable rather than customary. Passing is a strict majority, a property of the module that counts votes rather than a dial governance can turn, so requiring a supermajority would mean a different Governor audited on its own terms. Retrospective funding is the preferred form, where work is finished and independently checkable before anyone votes; prospective funding stays available and must say why the work cannot reasonably be delivered first. Completed work creates no claim on the Treasury, and the preference is a governance norm rather than a contract-level rule. Four things sit outside a vote's reach: the fee rule and the permanent contract, turning the safeguards off, creating an owner, and changing the bar for approval.

### What stops it being captured (https://olympiadao.org/overview/prediction-markets, ECIP-1117 and ECIP-1118)

A vote answers two questions at once and is good at one. What the network should want is a question about values, and the people accountable to the network are the right ones to settle it. Which proposal actually gets there is a question about the world, and the answer often depends on what people holding no seat know. A market pays for the second answer: a position pays in proportion to being right and costs in proportion to being wrong, so research stops being a favor and becomes how a participant makes money. A market here does not ask whether a proposal will pass. It prices what Ethereum Classic is worth under two futures, the proposal accepted and the same proposal rejected, both at once and in the same unit, and the gap between them is the estimate of what the decision does. Collateral splits into two claims, a pool trades each branch, both open at the price ETC is trading at right then, and the unit on the other side is Classic USD, issued natively on Ethereum Classic rather than bridged, because a bridged unit would put the bridge's risk inside every denominator. Resolution is a time-weighted average of each branch across a set window, compared, with no reporter, no bond, no challenge period and no vote, because the comparison is the resolution. It decides who is funded, and it does not decide whether there is anything to fund: Olympia DAO votes on whether, how much and within what scope to seed a season, and once that sum has transferred it has no say in how the season allocates, so the higher-priced branch is the allocation rather than a recommendation about one. What a market cannot reach is anything the Treasury still holds: a season allocates a sum an ordinary proposal already transferred to it, nothing in a market moves a unit out of the Treasury, and the markets run as an Affiliated DAO alongside Olympia DAO holding no permission, no key and no way to start a payment. No base fee reaches these contracts and none may be made to; the flow runs the other way and indirectly, since activity pays base fees that accumulate in the Treasury like any others. The Treasury is not the counterparty either, because collateral sits in a general-purpose conditional-token contract nobody in Olympia deployed, so there is no settlement pot to drain and a per-market spending limit would bound nothing. A pro-rata exit against the Treasury is prohibited rather than merely absent. Not every decision warrants a market: two separate limits apply, how big the decision is next to the network, which nothing enforces, and how deep the branch pools are, which the depth floor enforces when a market opens. Depth is the security parameter of the mechanism, and the floor binds at promotion rather than for a market's lifetime, which may not be described as bounding manipulation cost throughout. Any proposal may choose to be paid in instalments against milestones fixed at submission and verified objectively, and the paying contract screens whoever is about to receive value every time it releases any, with returns to the Treasury or the Governor as the only exclusion.

### Who cannot receive it (https://olympiadao.org/overview/eligibility, ECIP-1119)

Treasury money cannot reach a sanctioned address. The binding check sits inside the Governor and runs at the last possible moment, after the vote and after the queue, in the same transaction that releases the money: it reads every address the operation is directed at and reverts the whole thing if any is listed. There is no way around it, and the reason is structural rather than vigilant, since exactly one account may tell the Treasury to pay and the check lives inside that account. It runs at release rather than at approval because somebody clear when a proposal passed may be designated during the weeks of voting and delay that follow. The Governor's general-purpose recovery function is overridden to fail, since left in place a proposal naming the Governor itself would pass the screen and then pay an unscreened address. The Governor and the Treasury are skipped deliberately, and the contract refuses a list that flags either, because a list naming the Governor would revert every proposal that could fix it. ECIP-1119 names four checkpoints and they are not equally strong, so reading them as four layers of one defense is the mistake to avoid. Coverage stops at the Treasury path. The registry screen at submission is advisory and skippable by a direct proposal, so treating it as redundant cover overstates the control by exactly what one direct proposal removes, and it is mistimed besides. The other two bind inside the contracts that take custody after the Treasury releases, the milestone-gated streaming contract and an Affiliated DAO's own vault and promotion path, and each is satisfied when its contract is deployed carrying the rule and an audit confirms it. For an ordinary payment the screen is exact at the address the money settles at, and that holds only while the address carries no code: a contract routes value onward by its own logic and an ordinary account can carry a delegation that makes it behave like one, so neither is exactly screened and neither may be described that way. Every checkpoint consults a list somebody maintains, which is the one point of central control the design cannot remove and is disclosed rather than glossed. Editing the list and deciding who may edit it are separated on purpose, because a designation has to be reflected in hours while granting the ability to edit is not urgent. A stale list looks exactly like a clean one, so the list publishes when it was last updated and its operator discloses source, polling arrangement and observed lag. Being wrongly listed costs a payment and never the money, and no appeal is needed because the question is asked fresh every time. The rule reaches the contracts Olympia deploys and not the third-party contracts underneath them: a sanctioned address can trade in a prediction market and redeem its own collateral, and no Olympia contract can stop it. A sanctioned address can also still author a proposal, because the guarantee is over receipt rather than participation and must not be described as covering both.

### What happens to miners when the subsidy runs out (https://olympiadao.org/overview/security-budget, ECIP-1017, ECIP-1115 and ECIP-1116)

Ethereum Classic pays whoever produces a block a fixed amount of new ETC, and that amount drops by a fifth every 5,000,000 blocks under ECIP-1017, starting at 5 ETC. Nothing in Olympia changes it and nothing in Olympia could, since the schedule is a consensus rule settled on purpose. That leaves the hardest question about this network: if the protocol-set part of a miner's payment keeps decaying, either something else pays them or the security bought by that revenue shrinks with it. What is left is transaction fees, and tips track demand block by block, so a revenue stream made only of tips is volatile. Two specifications make it possible to put a steadier component alongside it, and the interesting part is how carefully they refuse to guess. The direction of flow is the distinction that matters most: this is not a block-reward split. Value moves from the base-fee stream to miners, from a stream that does not exist before the fee market activates and that no miner has ever received, and ECIP-1017 rewards and priority tips are untouched throughout. Ethereum Classic has been asked twice before to fund a treasury out of the block reward, and both are in the public register, one rejected and one withdrawn. Step one does not touch consensus: base-fee revenue arrives in the Treasury as it does for any purpose, and a share can be paid back to block producers on a schedule spreading each block's contribution across a window of later blocks, which turns a lottery into something closer to a wage. Three things are set by proposal, the share, the window length and the weighting across it, and every one can be changed, suspended or switched off by another proposal, starting from off. A wrong number there costs a proposal; the same number written into consensus costs a hard fork. Nobody becomes owed anything, no contract computes a surplus, and recipients are identified by a method that is deterministic, transparent and set through the proposal process. The figure each payment is computed from is gas used multiplied by the base fee, both in the block header, deliberately not read from the accumulating contract's balance, which anyone can pay into or trigger. No contract can read how much gas a block used, so the figures are stated in the proposal, folded into its identifier, and recomputable by anyone from public headers. Step two is a hard fork that writes a demonstrated configuration into block finalization, and the substantive change is not that the number becomes fixed but that the payment path leaves governance entirely: the allocation never passes through the Treasury, no proposal funds it, and none can alter, withhold or redirect it. It complements the fee market rather than replacing it, and does not repeal step one, whose machinery stays available for the share the Treasury keeps. The fraction going to block producers is greater than nothing and less than all of it, and that bound is the only thing about it that can honestly be published: the values are deliberately unset, filled in from what step one demonstrates in production, and a client must refuse to activate with them unset rather than fall back to a default. Five things must be true before the consensus-layer step has a block worth scheduling, and two of its checks exist because nothing afterward would catch the mistake: the weights must sum to exactly one in whole-number form, and the window must be at least one block long. Three arguments pull on the window length, and one of them is a limit on what the first step can establish rather than a trade against it. Paying revenue forward at the consensus layer gives whoever produces a block a reason to reorganize one to capture a windfall landing on it, strongest when the payment is concentrated across few blocks. That does not arise under the first step at all, where every payment is a governance-approved withdrawal rather than a credit attached to producing a block, so no windfall rides on any particular block and a reorganization has nothing to take. Because the exclusion is structural, running the first step cannot produce evidence about it: a window that behaved well there is not thereby shown safe at the consensus layer, and whoever proposes one has to argue this separately. It pulls toward a longer window, with the reorganization-depth argument and against the per-block validation cost every node carries forever.

### What ships at the fork (https://olympiadao.org/overview/what-ships, ECIP-1121 and ECIP-1122)

Two specifications activate at the first hard fork and change nothing economic. One brings the machine that runs contracts back into line with Ethereum's; the other writes down three network settings that had been held together by habit. ECIP-1121 is written as an inventory rather than a redesign, and every entry passes three tests: not already delivered at Spiral in 2024 or Mystique in 2022, execution layer only, and no dependency on validators, a beacon chain or blob data availability. The exclusions are content rather than omissions, because a proposal appearing in no section is indistinguishable from one considered and declined, and collapsing them into "not supported" is the most common misreading: Proof-of-Stake work is excluded as not applicable rather than postponed, blob work is deferred without implying rejection, fee-market governance is excluded as a filing decision since EIP-1559 and EIP-3198 ship at this same block under ECIP-1111, and a further set is blocked behind dependencies and tracked rather than rejected. A further group is listed without being decided, left for the developer call that sets the activation block. Glamsterdam is the alignment target rather than a completed one, since that upgrade is still being assembled, so ECIP-1121 adopts the pieces that are ready and stable and tracks the rest; reading it as full parity overstates it in one direction and as sitting the upgrade out overstates it in the other. Fusaka is a delivered cycle and its execution-layer work is in the set wherever it does not depend on blobs or Proof-of-Stake. ECIP-1122 sets three values every Olympia client is required to enforce identically, and configuration here means the opposite of what it usually means: not a value each operator picks, which is precisely the defect all three exist to close, but a value every client ships and no operator flag can override. The gain from keeping them out of the block rules is that a number can be revised by releasing client software rather than by scheduling another hard fork, and the cost is that a node ignoring them still follows the same chain, so nobody is forced off the network for non-conformance. Both specifications are stage one, which is a hard fork. Nothing is deployed at that fork: every contract it commits to is already on-chain, audited and readable beforehand, which puts the audit window in front of the fork rather than in a gap after it. Two pieces are deliberately outside that set, the sanctions oracle and the funding-proposal registry, each attaching through a governance-only setter and a constructor argument to nothing, so both may be deployed and audited on either side of the fork; until the oracle is attached the spending gate refuses to open, and failing shut is what makes deferring that audit safe.

## Governance Architecture

Three complementary systems designed to work together. Each tier is mutually dependent, no single group controls the protocol.

### Binding On-Chain Protocol Governance (Core Development Governance)

Five stages from proposal to execution. Every step on-chain, transparent, and auditable:

1. Propose: Submitting is permissionless, bounded only by the Governor's proposal threshold, which the DAO sets for itself
2. Vote: Olympia DAO core contributors cast on-chain votes via the OpenZeppelin Governor 5.x contract suite
3. Queue: Approved proposals enter a configurable security timelock
4. Execute: After timelock expires, proposals execute automatically on-chain
5. Disclose: All outcomes publicly recorded and independently verifiable

### The Olympia Futarchy Grants DAO (ECIP-1117)

Ethereum Classic's public mechanism for funding ecosystem growth, where the community decides which projects receive grants and markets rather than a committee aggregate the decision. **It is an Affiliated DAO under ECIP-1113 §6: a separate body working alongside Olympia DAO, not beneath it.** The two have different mandates. Olympia DAO is scoped to the network's core, meaning client development, network security and critical infrastructure. This one is scoped to everything built on top of it. Neither replaces the ECIP process.

Anyone holding ETC or USC may take a position. No membership, application, sponsor or CoreNFT is required:

1. Seed: Olympia DAO votes, per season, on an ordinary ECIP-1114 proposal that transfers a specific sum for that season, competing in the same Governor and under the same quorum against client maintenance and security response. It may confine the season to a stated theme
2. Open: a market is promoted for a candidate grant, pricing ETC under two branches, the grant funded and the grant not funded
3. Resolve: the two branch prices are averaged across a set window and compared, with no reporter, no bond and no vote, because the comparison is the resolution
4. Allocate: the higher-priced branch decides. Once a season is seeded, Olympia DAO has no say in how it allocates within that scope

**The allocation unit is a season, and between seasons this DAO holds nothing to allocate.** A season is seeded before it opens, must not draw on another season's seed, must not roll an unallocated remainder forward, and is never automatic. The DAO is permanent; its seasons are not. Its own operating costs are funded by a separate ordinary proposal and are not season-scoped.

**Core needs are funded first, and that ordering is deliberate.** Every season-seeding proposal competes against client maintenance, security response and critical infrastructure in the same Governor. Olympia DAO decides whether and how much to seed, and never what the seeded funds are then spent on. Client development, network security and critical infrastructure are not available as Affiliated DAO mandates.

**The funding path runs one way:**

```
BASEFEE -> ECIP-1112 Vault -> ECIP-1113 Treasury -> OFP seeds a season -> ECIP-1117 allocates
                                (Olympia DAO votes)     (ECIP-1114)        (the public decides)
```

### Software Adoption as Governance Signal (Network Participant Layer)

Miners, exchanges, wallets, and infrastructure providers govern through the client software they run. Protocol changes achieve distributed consensus when the broader network adopts them:

1. DAO Approval: Olympia DAO votes to approve a protocol upgrade through on-chain governance
2. Client Releases: Independent client teams publish compatible implementations of the approved upgrade
3. Network Adoption: Miners, exchanges, wallets, and node operators upgrade their software across the network
4. Distributed Consensus: The upgrade activates when the broader network has adopted the new software, distributed participation made real

The three tiers are mutually dependent. Developers build the software, users create the value, and network participants make the network real. No single group controls it.

## Key Design Principles

- Miner rewards intact: 100% of block rewards and tips remain unchanged
- Opt-in participation: legacy Type-0/1 transactions remain valid indefinitely
- EVM compatibility: Type-2 transactions integrate seamlessly with existing tooling
- Transparent funding: treasury revenues and disbursements fully auditable on-chain
- Non-inflationary: treasury funded by basefee revenue, not new token issuance

## Safeguards

- Configurable security timelock on all proposals
- On-chain sanctions screening (OFAC compliance): the binding check runs inside the Governor at execution time, unavoidable because the Governor is the Timelock's only executor. ECIP-1119 names four checkpoints and the guarantee covers the Treasury path and nothing beyond it: the proposal-registry screen is advisory and skippable, and the other two bind the contracts that take custody after the Treasury releases, which is the milestone-gated streaming contract and the Affiliated DAO's liquidity vault. Each is satisfied when its contract is deployed carrying the rule and an audit confirms it. A recipient that holds code is target-screened rather than exactly screened.
- Non-transferable membership NFTs prevent vote buying
- Emergency pause capability

## Olympia Roadmap

Olympia arrives in five stages. **Stages 1 and 5 are hard forks; Stages 2, 3 and 4 are not**, the middle three are governance actions and one contract deployment on a chain whose consensus rules are already settled, and none of them can cause a node to diverge. **Staging is a rollout schedule, not a deployment mechanism.** Every contract the Stage 1 fork commits to is deployed, audited and readable on-chain before that block: the contributor NFT, the Timelock, the Governor and the Vault. The audit window therefore sits before the fork rather than in the gap between the two stages. Two Stage 2 components are deliberately outside that set: the sanctions oracle and the funding-proposal registry each attach through a Timelock-gated setter, are a constructor argument to nothing, and may be deployed, audited and bound after activation, which is safe because the Governor's gate fails closed until the oracle is bound. Roadmap order and deployment order legitimately diverge, and flattening them is the most common misreading of the roadmap. Each stage depends only on the stages before it. Each fork stage takes an activation block settled by open coordination among client implementers, node operators, miners, exchanges and infrastructure providers, with Mordor first and mainnet following a clean run there.

1. **Stage 1. Consensus Upgrades** (ECIP-1111, ECIP-1112, ECIP-1121, ECIP-1122), hard fork. EIP-1559 activates, the execution layer advances through Glamsterdam, and client security parameters take effect. The Vault, already deployed and audited, begins receiving basefee at this block and sweeping it to the Treasury. What happens at the fork is consensus starting to credit a published address, not a deployment.
2. **Stage 2. Core Governance** (ECIP-1113, ECIP-1114, ECIP-1119), no fork. Governance goes live. The voting and custody contracts are already on-chain, and what happens here is binding the sanctions oracle and the funding-proposal registry, after which the DAO can spend. Those two may themselves be deployed on either side of the fork. Until the oracle is bound the Governor's execution gate fails closed and revenue accrues unspendably. What genuinely phases in later is operational: a tuned Governor, broader DAO membership, and those two bindings.
3. **Stage 3. Prediction Markets** (ECIP-1117, ECIP-1118), no fork. The one contract deployment among the middle three, seeded by a funding proposal from the Stage 2 DAO. A futarchy Affiliated DAO alongside membership voting, never replacing it. Collateral is ETC and Classic USD, custodied by the conditional-token contracts rather than the treasury. Needs those contracts and an ERC-1155 wrapper on ETC: deployment work, not a capability gap, since both target EVM semantics ETC has had since Spiral in 2024. Its position is a sequencing choice, not a technical dependency.
4. **Stage 4. Treasury Distribution** (ECIP-1115), no fork. A governance activation, not a deployment: a smoothing curve routing a share of treasury-held basefee back to miners, every parameter adjustable through governance so the curve is measured rather than assumed, while ECIP-1017 block rewards still secure the chain.
5. **Stage 5. Protocol Integration** (ECIP-1116), second hard fork. The demonstrated curve is embedded into block finalization, paid by the protocol rather than disbursed from the treasury and no longer adjustable by governance. Cannot activate before Stage 4 has produced observational data.

## Contract Architecture

Six contracts, and the boundary between the first two is the whole design. No address appears here or on the site: an address is a property of a deployment, and this is the architecture the specifications define. ECIP-1112 publishes no address in the specification either, deliberately. Nothing is predicted: no CREATE2 derivation, no init-code freeze and no reserved deployer nonce is permitted as the basis of the consensus commitment. Contracts deploy in ordinary dependency order, the real deployed address is published, and clients hardcode that published value afterward.

- OlympiaSovereigntyVault (ECIP-1112): the permanent address consensus credits. No owner, no role, no setter, no parameter. Holds nothing for long, forwarding its balance unchanged to one address fixed at construction. The only contract in the suite that cannot be replaced
- TimelockController (ECIP-1113 §1.3): the Olympia Treasury. Holds the funds and carries out approved proposals after a mandatory delay. Replaceable by ordinary governance, with no hard fork
- OlympiaGovernor (ECIP-1113): proposal lifecycle, vote tallying, and the execution-time compliance gate. The only account that can tell the Treasury to pay
- CoreNFT (ECIP-1113 §1.2): soulbound membership, one non-delegable vote per core contributor, minted only by a passed proposal
- SanctionsOracle (ECIP-1119): the list the Governor screens every outward address against before the Treasury releases anything
- OFPRegistry (ECIP-1114): funding-proposal metadata, bound to the proposal that executes it so voters read what runs

## Network

- Mordor Testnet: Chain ID 63
- ETC Mainnet: Chain ID 61
- Activation Block: TBD, announced after the Olympia Upgrade core developers call
- Targeted for mainnet activation in 2027. Mordor testnet activates first; the mainnet block follows a successful Mordor run and a coordinated stakeholder readiness check.

## Client Implementations

Two active clients at Olympia launch:

- **Fukuii** (fukuii.org). EVM execution client in Scala 3 LTS on Pekko Typed Actors. One binary runs several networks at once in one JVM process, each isolated with its own state, metrics registry, and configuration; a further network is configuration rather than a new client. Consensus is selected per deployment behind one interface: native Proof-of-Work for ETC mainnet and Mordor, or Proof-of-Stake with a built-in consensus layer or an external client over the Engine API V1–V4. Ships an MCP server exposing node state to AI agents. Apache 2.0, with Cosign-signed build provenance and a CycloneDX SBOM on release artifacts. Ethereum Classic's first native client, built ground-up for ETC rather than derived from an Ethereum client, and the primary ETC client for the Olympia era. By The Fukuii Authors (Chippr Robotics LLC and White B0x Inc.).
- **core-geth**. A go-ethereum derivative maintained for Ethereum Classic, in maintenance only. It carries the Olympia parameters (ECIP-1111, 1112, 1121, 1122), so an operator already running it has a path through the upgrade without changing client. New deployments should use Fukuii.

What settles conformance is not a client's own account of itself. ECIP-1122 requires the minimum-tip check at both points a transaction can enter a block, at pool admission and again at block production, and requires the era gas target to override an operator's own flags. Cross-client state-transition equivalence is demonstrated on Mordor before a mainnet activation block is scheduled, which is the point at which a claim about any client stops being an assertion.

### Fukuii (https://olympiadao.org/clients/fukuii)

An execution client: it holds a copy of the chain, checks every block against the rules, keeps the account state that results, and answers questions about it over a public interface. What makes it unusual for Ethereum Classic is where it came from, since every client this network had run until now began life as an Ethereum client and had Ethereum Classic support added afterward. It is written in Scala 3 and runs on the JVM, and that choice is not incidental: the type system makes a class of consensus mistake impossible to write down, so it is caught at compile time rather than when a block is processed. One process runs more than one network at once, each with its own state, metrics and configuration and each supervised separately, so a failure in one does not take the others down and adding a network is configuration rather than another client to install, learn and audit. Ethereum Classic is chain 61, Mordor is chain 63 and activates first, and Ethereum mainnet and Sepolia run from the same binary. Consensus sits behind a single interface and is selected per deployment: native Proof-of-Work on Ethereum Classic and Mordor, where Fukuii implements ETChash and the ECIP-1099 epoch schedule and serves the work interface mining software connects to, so it can be the node behind a mining operation rather than only beside one. On Proof-of-Stake networks it can run a consensus layer in the same process, which is an option rather than a requirement, since the Engine API is implemented either way. The interfaces an operator integrates against are in the binary rather than in a sidecar: JSON-RPC and GraphQL, SNAP, full and archive sync modes, Prometheus and Grafana metrics with liveness and readiness endpoints, and an MCP server offering node state, sync progress, peer counts and block data as structured tools to any Model Context Protocol agent. It is maintained by The Fukuii Authors, whose members are Chippr Robotics LLC and White B0x Inc., with no foundation or steering body between the code and the people accountable for it. Development is in the open, changes arrive as pull requests and ship in tagged releases, and each release carries a build signature and a software bill of materials so a running binary traces back to the commit that produced it. Apache 2.0, which permits commercial use, modification and redistribution and carries a patent grant. The authors include a credited contributor to the EEA Enterprise Ethereum Client Specification, which is a contribution to that specification and not a conformance claim about Fukuii. It is distributed for Windows, macOS and Linux and as a container image that bundles a Java runtime; the platform distributions need the current JDK LTS.

### Core-Geth (https://olympiadao.org/clients/core-geth)

A derivative of go-ethereum, the most widely deployed Ethereum client, with the chain rules Ethereum Classic needs added to it. Most Ethereum Classic infrastructure runs it, and for years it was the network's default answer to what a node should run. Being a derivative is the whole of both its strength and its limit: it inherits a large body of tested Ethereum work for free, and inherits that work's assumptions, dependencies and release pace with it, whether or not those suit this network. It carries the Olympia parameters: the base-fee floor, the credit at block finalization, the destination address, the era gas targets and the MESS re-activation block. Carrying the parameters is not the same as conforming to the specification, and ECIP-1122 is precise about the difference. An operator already running it does not have to change client to take the upgrade, which is deliberate, because an upgrade is harder to land safely if it forces every operator to migrate simultaneously. Maintenance is a real status rather than a polite word for old. The upstream repository at etclabscore received no substantive code commit after June 2024 and the gap that followed ran 21 months, the longest in this network's history. During it six security vulnerabilities went unpatched: two let a remote attacker crash a node and one of those needs no authentication at all, since a single crafted message during the opening handshake is enough; a third lets any connected peer exhaust a node's processor; the remaining three weaken the cryptography the peer-to-peer layer depends on, and one can leak bits of a node's own private key. In March 2026 Ethereum Classic mainnet bootnodes came under active attack and an emergency release followed within hours of the pull request carrying it. All six are fixed, the client lives in the ethereumclassic organization where the patches were published, and the Go toolchain it builds on was brought back to a supported version at the same time. Two repositories exist and the difference matters operationally: run the ethereumclassic build, because an operator on an older etclabscore release is running a node with known remote-crash vulnerabilities in it, and rotating the node key afterward is a sensible precaution on any long-running node. For anything new, use Fukuii. Core-Geth exists in the Olympia era to carry the operators already on it rather than to be the choice for a node that does not exist yet.

ETC plugins for Besu, Erigon, Ethrex, Go-Ethereum, Nethermind, and Reth are future work. Upstream Ethereum clients separate the consensus engine from the execution engine, and a plugin uses that seam to add ETC chain support to an existing client without maintaining a full fork of it. A plugin is not a client of its own and carries no mining or Proof-of-Work consensus, so plugins serve exchanges, RPC providers, block explorers and indexers rather than miners. None of the six plugins ships today. Two of those clients are separately in scope, which is a different thing from a plugin for them: ECIP-1111 and ECIP-1122 track Besu and Nethermind as Olympia implementations, carrying the era gas target hardcoded so miner configuration cannot override it. Erigon, Ethrex, Go-Ethereum and Reth remain untracked.

Why more than one client: a single implementation's bugs are indistinguishable from the network's rules, because nothing is in a position to disagree with them. The concrete case is Ethereum Classic's own. The upstream etclabscore/core-geth repository received no substantive code commit after June 2024, and the 21-month gap that followed left six security vulnerabilities unpatched. Two allow a remote attacker to crash a node and one of those needs no authentication at all, one is a CPU exhaustion denial of service, and the remaining three weaken the peer-to-peer cryptography, one of them leaking bits of a node's own private key. In March 2026 ETC mainnet bootnodes came under active attack. All six are fixed, and the maintained line is ethereumclassic/core-geth rather than etclabscore. Full record: https://ethereumclassic.com/build/clients/core-geth-security-audit

Node operators must upgrade before the activation block. Block rewards and tips remain completely untouched. The Olympia upgrade only redirects EIP-1559 basefee to the treasury.

## Regulatory Positioning

ETC's regulatory surface spans two distinct trajectories: the commodity classification path that Proof-of-Work networks established, and the programmable finance frameworks being built around smart contract platforms.

- United States: digital commodity classification under the CLARITY Act (CFTC jurisdiction)
- United States: Proof-of-Work EVM platform positioned for regulated stablecoin deployment under the GENIUS Act, enacted in July 2025 and taking effect on the earlier of 18 January 2027 or 120 days after final rulemaking
- European Union: decentralized asset under MiCA (Markets in Crypto-Assets Regulation), exempt from issuer obligations as a fully decentralized protocol
- Japan: recognized crypto-asset on the FSA Green List (JVCEA), fast-track listing across all Japanese regulated exchanges

## Olympia Upgrade FAQ

**What happens if I do not upgrade my node?** 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.

**Do I have to resync?** 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.

**Which client should I run?** 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.

**Will my miner rewards change?** 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.

**When is the mainnet activation block?** 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.

**How was Olympia tested before mainnet?** 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.

**Can I roll back if something goes wrong?** 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.

**What does EVM alignment to Glamsterdam actually mean for builders?** 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.

**How does the protocol treasury work?** 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.

**Who is coordinating the Olympia upgrade?** 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.

**What role has the ETC Cooperative played, and what changes with Olympia?** 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.

**What is Grayscale's role in Ethereum Classic's development?** 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.

**Is Ethereum Classic a security or commodity after Olympia?** 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.

## Governance FAQ

**Who can participate in governance?** Submitting a funding proposal is permissionless: no application, no affiliation, and no gatekeeper who can decline to put it in front of the vote. The one bar is the Governor's proposal threshold, a minimum amount of voting power an author must hold, which the DAO sets for itself; at zero any ETC account can author a proposal, and above zero authorship narrows to core contributors. Voting is limited to Olympia DAO core contributors, who hold a soulbound CoreNFT carrying one non-delegable vote each. Prediction markets are open to anyone, with no contributor NFT and no identity check. Network participants such as miners, exchanges, wallets and infrastructure providers govern through the client software they run.

**Does the DAO fund work before or after it is done?** Both are available, and retrospective is the preferred form. In a retrospective Olympia Funding Proposal the work is already complete and independently verifiable when the proposal is submitted, so the DAO votes on delivered work carrying evidence, merged changes, a published audit, an operated service with a usage record, rather than on a plan. Prospective funding remains available where work cannot reasonably be delivered first, such as a third-party security audit, infrastructure that must be paid for before it can run, or sustained work no contributor can reasonably self-finance; a prospective proposal must state why. Two points are easy to get backwards in opposite directions. Completed work creates no claim on the Treasury: a retrospective proposal may be declined like any other, and performing work confers no entitlement to payment. And the preference is a governance norm, not a contract-level rule, nothing on-chain distinguishes the two forms, both reach the Treasury through the same Governor and Timelock path, and voters enforce the preference by how they vote. The closest precedents are Optimism Retro Funding and Base Builder Grants.

**How does voting work?** Proposals pass through five on-chain stages: Submit, Vote, Queue, Execute, Disclose. Voting power is fixed by a snapshot rather than read live, so admitting or revoking a contributor mid-vote cannot rewrite a tally already in flight, and each core contributor holds exactly one vote. A proposal that reaches quorum only near its deadline extends it, so a late surge cannot close the window before anyone can answer it. Approved proposals enter a configurable timelock before execution. All outcomes are publicly recorded and verifiable on-chain via the Olympia DAO governance app at app.olympiadao.org.

**When does Olympia activate?** Olympia is targeted for mainnet activation in 2027. The testnet activation block on Mordor is announced first. The mainnet activation block follows after a successful 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.

## Web Properties

- olympiadao.org: This site. The primary Olympia explainer and execution surface: what the upgrade is, where the money comes from and where it goes, who decides how it is spent, and how to upgrade a node
- olympiatreasury.org: Treasury monitoring dashboard
- app.olympiadao.org: Proposal submission, voting, and execution
- ethereumclassicdao.org: Institutional (Ethereum Classic DAO LLC)
- github.com/olympiadao: Open-source repositories

## Authors

- Cody Burns (github.com/realcodywburns)
- Chris Mercer (github.com/chris-mercer)

## Parent Organization

Ethereum Classic DAO LLC. Wyoming DAO LLC (Filing ID 2025-001671865)