Who can propose
Asking for money is deliberately open. There is no application, no committee to get past, no affiliation to declare and nobody who can decline to put a request in front of the vote. A proposal names who is to be paid, how much, and where to read the case being made.
One setting decides how far open goes. The Governor carries a proposal threshold, a minimum amount of voting power an author has to hold. Left at zero, any account on Ethereum Classic can author a proposal. 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 has to be chosen deliberately rather than inherited from a default, and it is a governance decision like any other.
What a proposal is bound to, and why it cannot be edited afterward. The recipient, the amount and a fingerprint of the supporting document are folded into the proposal’s own identifier. Change any of them and it becomes a different proposal with a different identifier, so what voters read is provably what executes. Revising is possible only before submission; afterward it means withdrawing and starting again.
The document itself says whether the work is already finished or is being asked for in advance, and carries the evidence either way. It lives at a content address rather than a link somebody controls, so it cannot be quietly rewritten between the vote and the payment.
A standard route, and not a chokepoint
Proposals normally arrive through a registry that records them and binds the metadata. Nothing forces that, and a proposal can be put straight to the Governor instead. It then faces the identical delay, voting period, quorum, approval rule and execution screen. What it skips is the audit trail: no registry record, no bound document for voters to check. Voters are expected to reject a Treasury proposal that arrives without one, which is a norm they enforce by voting rather than a rule a contract applies.
Authorship has to be claimed
A proposal is identified by its contents, all of which are public before it is submitted. Somebody watching could copy it word for word and submit it first, becoming its recorded author and acquiring the right to withdraw it repeatedly. The defense is one line at the end of the document naming the intended author, which locks the proposal to that address. It is opt-in and silent when malformed, so it is written as a requirement rather than a convention.
Who votes
Core contributors, and one vote each. The vote is carried by a token that is minted to a contributor and can never leave them: it cannot be sold, lent, pooled or delegated, and holding two of them would still be one vote. There is no second token, and no fungible or purchasable Olympia token exists at all, so there is nothing on which a market in votes could form.
A seat is earned and cannot be bought. It is minted on evidence of contribution to Ethereum Classic and on nothing else. No amount of capital admits anyone, and no holder can pass one on. Every admission is a proposal that passed, with the evidence attached where anyone can inspect it afterward.
| The property | What it rules out |
|---|---|
| It cannot be transferred | Buying a seat, or any market forming in them |
| The vote cannot be lent or delegated | Renting influence while keeping the token |
| One vote per address, however many exist | Accumulating until one holder outweighs the rest |
| Only a passed proposal can create one | Any single account handing out seats |
Nobody has to identify themselves
No identity check is required and none may be imposed. The work is what is being judged, and merged changes, published research and operated infrastructure are all public and attributable without knowing who did them. A pseudonymous contributor holds a seat on exactly the same terms as a named one.
What counts as a contribution
Substantial and good for the network. Client and specification work, security research and disclosure, running infrastructure, documentation and sustained review all qualify, so it is not only code. Typo and dependency-bump volume does not, and attacking the network or its users disqualifies rather than being averaged against a good record.
Leaving, and being asked to leave
A contributor can surrender their seat at any time without permission or a reason. The DAO can revoke one by proposal, on the same footing as admission and for conduct that would have disqualified the holder in the first place. Neither reaches backward into a vote already cast, and a former contributor can be admitted again later.
How many seats there are is not fixed, and the honest reading of that matters. Membership is expected to grow, and the quorum a proposal needs is a fraction of the whole, so it rises automatically as contributors are admitted. The cost is that each admission slightly dilutes everyone already there, and nothing caps it. What holds it in check is that admitting anyone is itself a public proposal.
The starting set is minted from a list published before the contracts are deployed, against a single verifiable criterion: contribution to the Olympia specifications or to the client implementations that carry them. It is narrower than the ongoing test on purpose, because at the beginning there is no membership to judge admissions. At that size a quorum percentage is not much of a guarantee and should not be presented as one. What is actually load bearing early on is that the contributors are named, their work is checkable, and every vote they cast is on the public record.
Voting on Treasury spending is restricted to core contributors. Deciding who receives an ecosystem grant is not: a seeded season is allocated by markets open to anyone holding ETC or Classic USD, with no seat and no application. What stops it being captured.
How a proposal becomes a payment
Four steps, all on-chain, none of which anyone can skip. A proposal waits before voting opens, is voted on for a fixed window, sits in a public queue for a delay, and is then carried out exactly as it was approved. Every one of those durations is a governance setting, and the specification forbids setting any of them to zero.
There is no separate execution contract, and nothing that could turn into one. The Treasury carries out operations itself, and exactly one account is permitted to tell it to: the Governor. That is what makes the compliance screen unavoidable rather than customary, because every payment that leaves passes through the same account, whatever route the proposal took to get there.
- 01
Submit
The proposal is created and voting has not opened yet. That delay is deliberate: it gives everyone a window to read the proposal and check the document it is bound to before a single vote can be cast.
- 02
Vote
For, against or abstain, one vote each, for a fixed period. Voting power comes from a snapshot rather than being read live, so admitting or revoking a contributor mid-vote cannot rewrite a tally in flight. A proposal that reaches quorum only near the deadline extends it, so a late surge cannot close the window before anyone can answer it.
- 03
Queue
An approved proposal is scheduled and waits. The operation is public for the whole delay, which is the point of it: anyone can see what is about to happen, and a counter-proposal can cancel it before it does.
- 04
Execute
The Governor screens every address the operation is directed at, and then the Treasury pays. The operation runs exactly as queued, in full or not at all, with nothing inserted between approval and release. What it leaves behind is a permanent public record, joinable to the proposal that authorized it and to the vote that carried it.
Passing is a strict majority, not a setting
More for than against, with abstentions counting toward whether enough people turned out and toward nothing else. That rule belongs to the module that counts the votes, so unlike quorum and the delays it is not a number governance can raise. Requiring a supermajority for anything would mean deploying a different Governor and auditing it.
Withdrawing, and being stopped
An author can withdraw their own proposal at any stage, including after voting opens, and nobody else holds that power over it.
Separately, a queued operation can be cancelled by a proposal that passes. That is what gives governance any way at all to stop something already approved, and without it an approved proposal would simply be unstoppable.
Funding work that is already done
A proposal comes in one of two forms, and it has to say which. In the preferred one the work is finished and independently checkable before anyone votes, so contributors are paid for what they delivered rather than for what they promised.
Paying afterward removes a problem instead of managing it. Funding a plan asks voters to price an undertaking, and every control that follows exists to cover the gap between what was promised and what arrives. Funding finished work has no such gap: it can be inspected at the moment of the vote, a proposal that overstates its own value is refuted by the evidence attached to it, and non-delivery costs the Treasury nothing because nothing was paid out. It also asks the easier question. Recognizing which work turned out to be useful is something a distributed group does well; forecasting which team will succeed is not.
Finished work, the preferred form
The proposal carries evidence rather than a plan: merged changes, a published audit, or a service that has been running long enough to have a usage record.
Work paid for in advance
Still available, and it has to say why the work cannot reasonably be delivered first. Some genuinely cannot: a third-party audit and infrastructure that has to be paid for before it can run both cost money up front, and sustained work is not something every contributor can self-finance. Payment should be structured against verified milestones rather than handed over in one piece.
Two things are easy to get backwards, in opposite directions. Finished work creates no claim on the Treasury. A proposal for completed work can be declined like any other, and doing the work confers no entitlement to be paid for it.
And the preference is a norm rather than a rule in code. Nothing on-chain tells the two forms apart, both reach the Treasury by the same route, and voters enforce the preference by how they vote. The reason it is not absolute is real: paying only in arrears asks contributors to carry the cost and the risk of rejection, which favors whoever can afford to work unpaid.
The pattern is established rather than novel. Optimism’s Retro Funding runs it at treasury scale through elected evaluators and explicit impact measures, and Base’s Builder Grants run it as small frequent awards for work already shipped, with no application at all. Olympia sits nearer the first, since its evaluators are the contributors themselves and every payment passes through a public on-chain pipeline. What the DAO funds, and why.
What a vote cannot change
Governance changes almost everything beneath it, and that is the design: the Governor, the Treasury, the voting model and the compliance oracle are all replaceable by ordinary proposal, with no fork and nobody’s permission. Four things sit outside that reach.
The fee rule and the permanent contract
No proposal can amend the consensus rule that creates the base fee, or change the contract consensus credits. Both take a hard fork, which is a decision for everyone running a node rather than for the people holding a vote.
Turning the safeguards off
Quorum, the proposal threshold and the delays cannot be set to zero, voting cannot be disabled, and no contract may be swapped for another behind the same address. A proposal attempting any of it is invalid on its face.
Creating an owner
No owner-only function, no privileged multisig and no standing committee. Nothing outside the process may approve or veto what comes through it, and no emergency route skips the public queue.
Changing the bar for approval
How votes are counted is a property of the module that counts them, not a dial. Requiring a supermajority for anything means a different Governor, audited on its own terms, rather than a number somebody edits.
The last three of those are maintained rather than enforced, and saying otherwise would be the one dishonest sentence on this page. They are established when the contracts are deployed, published so anyone can check them, and kept in place by governance afterward. What actually stands between a hostile proposal and the money is the ordinary machinery: a vote it has to win, a public queue it has to sit in, and a counter-proposal that can cancel it in the meantime. Who owns the Treasury says the same thing about the permissions on the contract that holds the money.
One limit is not about governance at all. Some addresses cannot be paid, whatever a proposal says, and the check runs at the moment the money leaves. Who cannot receive it.