Skip to main content

Olympia Treasury

Live monitoring of Ethereum Classic’s base-fee revenue, from the Sovereignty Vault that receives it to the Treasury that holds it.

Vault and Treasury at a Glance

  • In the Vault: arrived and not yet swept
  • In the Treasury: funds under governance control
  • Last sweep: when the Vault was last emptied into the Treasury
  • Total received: lifetime inflow to the Vault, from every source
  • Mined to the Vault: miners choosing it as coinbase
  • Contributions: transfers sent from any address
  • Swept to the Treasury: the one route out of the Vault
  • Disbursed: paid out by executed proposals
  • Transactions: every movement at both addresses

Balance History

Both balances over time: base-fee revenue arriving in the Olympia Sovereignty Vault, and the sweeps that move it to the Treasury.

ECIP-1112 · ECIP-1113

How the money gets from one address to the other

Base-fee revenue lands in the Vault and lives in the Treasury. Those are two contracts with two jobs, and the whole design turns on keeping them apart.

  1. 01Consensus credits the Vault

    At block finalization the client adds the block's base fee to the Vault's balance directly. That write executes no EVM code, so no receive() body runs, no event fires, and the contract cannot observe or refuse the credit. It is also why the Vault keeps no internal counter: a contract releasing funds against a total it increments would release nothing.

  2. 02sweep() moves the balance

    Anyone may call it, and the caller pays the gas. It transfers the entire balance to one address fixed when the contract was built. There is no minimum threshold, deliberately — on a chain whose revenue is small until adoption grows, a threshold is a way for funds to be stranded below it.

  3. 03Swept is emitted

    Swept(destination, amount), before the external call, and it is the only event the Vault has. It carries no proposal identifier and no governance metadata, because the Vault knows nothing about either. A sweep log is not a receipt log: value arrives many times between sweeps, and anyone may contribute directly.

  4. 04The Treasury holds it

    Until a passed proposal releases it. The Governor is the Timelock's sole executor, a mandatory delay elapses between queueing and execution, and every externally-directed target is screened immediately before the funds move.

Why two contracts instead of one?

Because the address consensus commits to can only change by hard fork, and governance has to be able to change without one. Wire a permanent address straight into a governance stack and every part of that stack inherits the permanence.

So the network makes the smallest possible thing permanent: a contract with no owner, no role, no setter and no parameter, whose entire behavior is to receive value and forward it unchanged. Nothing to configure, therefore nothing to misconfigure. Everything mutable lives strictly downstream — and that is what makes the Treasury replaceable.

Exactly one contract in Olympia is permanent, and it is the Vault.

Permissionless because the destination is immutable

A caller of sweep() chooses only when the balance moves, never where. There is nothing for an unauthorized caller to gain and no authorization to administer. Elsewhere in the ecosystem the same function is a liability, because the recipient is mutable state behind a proxy — that is the one property of that design this contract must not copy.

Nothing causes a sweep to happen

It is permissionless and unincentivized at once, so at low revenue the gas can exceed the amount moved and no third party has a reason to call it. A proposal that executes while the balance still sits in the Vault reverts for want of funds in the Timelock, which is why a disbursement batch leads with a sweep. Nothing is stranded — anyone can call it at any time, including the DAO. What is required is only that someone does, and the balance above is how you tell whether anyone has.

Treasury Funding

Where the money comes from, and what it costs a miner.

Base-fee revenue funds Ethereum Classic’s own development

The base fee is not the transaction fee. Under EIP-1559 a transaction pays a base fee plus a priority-fee tip, and Ethereum burns its base fee while paying the tip to the block producer. Ethereum Classic has no base fee at all until ECIP-1111 introduces one — so nothing here is being taken from somewhere else. It is credited to the Vault at block finalization, and a 1 gwei floor keeps the revenue from decaying to zero at low utilization. Priority-fee tips and ECIP-1017 block rewards are untouched by the whole suite. Revenue scales linearly with gas consumed, so it grows with adoption automatically and without governance action, from usage rather than from a foundation or a donor.

Funding Flow

Transactions

Base fee + priority tip

Base Fee Only

Tips stay with the miner

Vault

Credited by consensus

Treasury

Swept in, held under governance

Proposals

Voted, queued, executed

Ecosystem

Development funding

Recent Transactions

Every movement at both addresses: contributions in, sweeps from the Vault to the Treasury, and disbursements executed by governance.

About the Vault and the Treasury

How Funds Flow

Base Fee Credited

A transaction pays a base fee plus a priority-fee tip. On Ethereum the base fee is destroyed — the burned half of what every transaction pays. Ethereum Classic has no base fee at all until ECIP-1111 introduces one, and credits it to the Vault at block finalization rather than burning it. Tips and ECIP-1017 block rewards go to miners in full.

A Floor Under Revenue

The base fee never falls below 1 gwei. Without that floor, sustained low utilization would decay it toward zero and eliminate the revenue entirely.

Swept to the Treasury

sweep() moves the Vault's whole balance to the Treasury. Anyone may call it and it costs the caller gas; it is safe because the destination is immutable, so a caller chooses only when the balance moves, never where.

Proposals Submitted

An OFP names recipient, amount and metadata, and states whether it is retrospective or prospective. Submission is permissionless and carries no bond, gated only by the Governor's proposal threshold measured against the author.

Governance Approves

Core contributors vote. A strict majority of For over Against carries, subject to quorum. The Governor is the Timelock's sole executor, and every execution passes its sanctions gate before the Timelock pays anyone.

Deployment Order

Nothing is predicted. No address is computed in advance from a salt or a deployer nonce, and no client recomputes one — each hardcodes the Vault’s real deployed address, published together with the network it is on. Mainnet and Mordor are independent values.

Dependency order, not a schedule

The Timelock deploys first, because CoreNFT holds its address as an immutable constructor argument and cannot be built before it exists. CoreNFT, then the Governor, then the Timelock’s role grants, then the Vault — whose immutable destination must be the Timelock’s real address. The sanctions oracle and the OFP Registry attach through Timelock-gated setters and are a constructor argument to nothing.

The fork commits to code that already exists

The activation fork is the last step. Everything the hardcoded address transitively commits to — the Vault, the Timelock it forwards to, the Governor and CoreNFT that spend from it — is deployed, audited and readable on-chain before the block that starts crediting it. The alternative asks the network to trust a future deployment rather than inspect a present one.

No account holds an admin role once the role grants complete, and the Timelock administers its own roles from that point on. The Governor holds EXECUTOR_ROLE and nothing else does, which is what makes the sanctions gate binding rather than advisory.

Core Contributors: the CoreNFT

Voting power comes from the CoreNFT and from nothing else. There is no fungible, transferable, purchasable token. There is nothing to buy, sell, lend, pool or accumulate, and therefore nothing on which a market in votes could form.

Earned, never bought

Minted on proof of substantive, net-positive contribution to Ethereum Classic, and on nothing else. No amount of capital admits anyone, and no identity verification is required or may be imposed.

One contributor, one vote

Soulbound and non-transferable, with delegation locked to the holder. A vote cannot be sold, lent, or leased.

Admitted by the DAO

One governance proposal per admission, with the evidence in its metadata. No minter role, no admissions committee, no unilateral account.

Revocable and resignable

A contributor may burn their own token at any time, and the DAO may revoke by proposal on the same footing as admission. Re-admission is possible, so exit is not exile.

Contribution is not only code: client and specification work, security research and responsible disclosure, infrastructure operation, documentation and sustained technical review all qualify. Trivial changes do not, and bad-faith conduct disqualifies rather than averaging out.

Membership grows by proposal and supply is unbounded, so the electorate is open to earn and closed to buy — never a fixed council. Quorum tracks admissions automatically, because it is measured as a fraction of the supply at each proposal’s snapshot.

Contributing Directly

Base-fee redirection is the protocol-defined funding source. Neither route below is a protocol mechanism: both are ordinary transfers any address can make, and the chain records each one.

Mine to the Vault

A pool or solo miner can set the Vault as their coinbase address, sending their own block rewards to it. That is a choice an operator makes, not something the protocol does. No ECIP directs mining revenue here.

Contribute directly

The Vault accepts incoming transfers unconditionally, and every one is visible in the transactions table above. Whatever arrives leaves by the same single route as base-fee revenue: a sweep to the Treasury, and then only a passed proposal.

Smart contracts can opt in on the same terms. A protocol forwarding a share of its fees on-chain gains no special claim over the funds it sends, and the Vault keeps no record distinguishing them — it holds no internal accounting at all.

The Five Stages

Stages 1 and 5 are hard forks; stages 2, 3 and 4 are not — they are contract deployments and governance actions on a chain whose consensus rules are already settled, and none can cause a client to diverge. Each stage depends only on the stages before it.

1Consensus UpgradesECIP-1111, 1112, 1121, 1122Hard fork. The Vault begins receiving base fee and sweeping it to the Timelock.
2Core GovernanceECIP-1113, 1114, 1119Governance goes live: binding the sanctions oracle and the OFP Registry, after which the DAO can spend.
3Prediction MarketsECIP-1117, 1118Contract deployment, seeded by an OFP the Governor passes.
4Treasury DistributionECIP-1115Smoothing runs as a governance-configured experiment on Treasury-held revenue.
5Protocol IntegrationECIP-1116A second, separate hard fork embeds the demonstrated curve into block finalization.
Core Invariants

No Minting

Neither contract can mint ETC. Each holds only what it receives.

Immutable Vault

No proxy, no delegatecall, no selfdestruct, no admin. Deployed exactly once.

No Authorization State

The Vault has no owner, role, guardian, or pause flag, so no sequence of calls can change who may do what.

One Way Out

Balance leaves the Vault only through sweep(), and sweep() can send only to the immutable destination. Both are provable by reading thirty lines.

No Internal Accounting

The Vault keeps no deposit counter. The consensus credit runs no EVM code, so a contract releasing funds against an internal total would release nothing.

Security Model

Protocol Consensus

Every client credits the base fee to the same hardcoded address at block finalization. Any deviation forks.

A Permanent Commitment, Minimized

What the fork makes unchangeable is only that revenue lands in the Timelock. Which Governor spends it, under which rules, stays replaceable.

Sanctions Screening

The Governor screens every externally-directed target immediately before execution and fails closed if the oracle is unset. It sits above the Timelock, so it sees whole batches rather than one recipient at a time.

Proposal Integrity

Enforced by OpenZeppelin Governor 5.x, whose proposal identifier is the hash of targets, values, calldatas and description. Neither the Vault nor the Timelock validates a proposal.

Contracts

The contract set

Six contracts. The Vault receives base-fee revenue and forwards it; the Timelock is the Treasury that holds it; the rest decide what leaves. Each links to the specification that defines it.

OlympiaSovereigntyVaultECIP-1112

The permanent address consensus credits. No owner, no role, no setter, no parameter. It holds nothing for long: sweep() forwards its whole balance, unchanged, to the Treasury

TimelockControllerECIP-1113 §1.3

The Olympia Treasury. Holds the funds and carries out approved proposals after a mandatory delay. Stock OpenZeppelin, and replaceable by governance without a fork

OlympiaGovernorECIP-1113 §1.1

Proposal lifecycle, vote tallying, and the execution-time compliance gate. The only account that can tell the Treasury to pay

Soulbound membership. One non-delegable vote per core contributor, minted only by a passed proposal

SanctionsOracleECIP-1119

The list the Governor screens every outward address against before the Treasury releases anything

OFPRegistryECIP-1114

Funding-proposal metadata, bound to the proposal that executes it so voters read what runs

The permanence boundary

One contract is permanent

The Vault sits at the address consensus credits, and changing that address takes a hard fork. It has no owner, no role, no setter and no parameter — nothing to configure, therefore nothing to misconfigure.

Everything downstream is replaceable

Governor, Timelock, CoreNFT, sanctions oracle and OFP Registry all change through ordinary governance without a fork. Making the Vault the smallest object the network is willing to make permanent is what buys that.

A Treasury replacement is a governance program rather than a single act: the incumbent stays the standing inbox for base-fee revenue, so it forwards to its successor for as long as revenue keeps arriving. What it never requires is a fork.