Why the subsidy shrinks
Ethereum Classic pays whoever produces a block a fixed amount of new ETC, and that amount has been shrinking since 2016 on a schedule the network chose deliberately. Every 5,000,000 blocks it drops by a fifth. It began at 5 ETC. Nothing in Olympia changes any of that, and nothing in Olympia could: the schedule is a consensus rule, settled on purpose and permanent by design.
That leaves the hardest question anyone asks about this network. Miners secure it because it pays them. If the part of that payment set by the protocol keeps halving away toward nothing, either something else pays them or the security paid for by that revenue shrinks alongside it.
The block subsidy, era by era
ECIP-1017- Era 1, from block 1
5 ETC
Era 1, from block 1
- Era 6, from block 25,000,001
1.6384 ETC
Era 6, from block 25,000,001
- The length of an era, and the subsidy drops by a fifth at each new one
5,000,000 blocks
The length of an era, and the subsidy drops by a fifth at each new one
Show every era in the schedule
| Era | First block | Subsidy in ETC |
|---|---|---|
| 1 | 1 | 5 |
| 2 | 5,000,001 | 4 |
| 3 | 10,000,001 | 3.2 |
| 4 | 15,000,001 | 2.56 |
| 5 | 20,000,001 | 2.048 |
| 6 | 25,000,001 | 1.6384 |
| 7 | 30,000,001 | 1.31072 |
| 8 | 35,000,001 | 1.048576 |
| 9 | 40,000,001 | 0.8388608 |
| 10 | 45,000,001 | 0.67108864 |
| 11 | 50,000,001 | 0.536870912 |
| 12 | 55,000,001 | 0.4294967296 |
What is left is transaction fees, and the specifications are direct about which part of them. A transaction under the fee market Olympia activates pays a base fee plus a tip, and the tip goes to the miner exactly as it does today. Tips are the component expected to take over from the subsidy, and tips track demand block by block, which nobody controls and nobody can forecast. A revenue stream made only of tips is a volatile one.
So the two specifications on this page do one thing: they make it possible to put a steadier component alongside that volatile one. The interesting part is how carefully they refuse to guess at it. Where the money comes from covers the base fee itself.
What does not change
Block rewards and tips. Both, in full, throughout. No part of Olympia alters issuance, the length of an era, the reduction at each one, or the subsidy itself. Priority tips continue to be paid in full to whoever produced the block, are not averaged across anything, and are not netted against any other payment. If you mine Ethereum Classic, every unit of revenue you receive today you still receive afterward.
This matters because Ethereum Classic has been asked twice before to fund a treasury out of the block reward, and both proposals are in the public register with their outcomes recorded. One was rejected and one was withdrawn. One split the block reward between two treasury addresses and the miner; the other sent four fifths of it to miners and the rest to a treasury contract that only named parties could withdraw from.
The direction of flow is the distinction that matters most. A reward split moves value out of miner revenue and into a treasury. What is described below moves value from the base-fee stream to miners, and that stream does not exist on Ethereum Classic until the fee market activates. No miner has ever received any of it.
| The earlier designs | These two |
|---|---|
| The source is the block reward, cut from all of it to a smaller share | The source is base-fee revenue the Treasury holds, which no miner receives today. Block rewards and tips are untouched |
| Recipients are named in the proposal and hold standing withdrawal rights | No privileged recipients, no admin keys and no discretionary veto, and registering as a recipient is open to anyone. No class of recipient, miners included, gets any priority or entitlement |
| The allocation is fixed in the protocol and changeable only by another consensus change | Every parameter is set by proposal, and the mechanism stays switched off until a proposal turns it on |
| Control rests with keyholders, or with voting weighted by holdings | Every payment is an ordinary funding proposal through the same public pipeline, and a vote is one seat per contributor with nothing to accumulate |
There is no point at which a miner is worse off than immediately before. Before the second step below, the whole base fee goes to the Treasury. After it, part of the base fee goes to whoever produced the block instead. Relative to the fee market as Olympia first ships it, activation moves block-producer revenue up rather than down. An argument that any of this takes revenue from miners has to establish an entitlement to a stream that does not exist yet, and that chains running the unmodified fee market destroy outright.
Step one: a curve governance can adjust
The first step does not touch consensus at all. Base-fee revenue arrives in the Treasury exactly as it does for every other purpose, and a share of it can be paid back out to block producers on a schedule that spreads each block’s contribution across a window of later blocks.
Spreading it is the point, not a detail of the plumbing. Base-fee revenue is volatile block to block, so paying it out as it arrives would hand that volatility straight to the recipient. Averaging each block’s contribution forward across a window turns a lottery into something closer to a wage, which is the property that makes fee revenue usable as a security budget in the first place. The idea is adapted rather than invented: it generalizes a mechanism from Roughgarden’s economic analysis of the fee market, which pays each block’s revenue forward across a fixed number of following blocks to reduce variance without disturbing incentives.
Three things are set by proposal: what share of each block’s revenue enters the mechanism, how long the window is, and how the weight is distributed across it. Every one of them can be changed, suspended or switched off again by another proposal, with no fork and nobody’s permission. The starting state is off, and nothing happens until a proposal turns it on.
Which is the whole reason this step exists before the next one. A wrong number here costs a proposal. The same wrong number written into consensus costs a hard fork. And it runs while the block subsidy is still large enough to be securing the network on its own, which is what makes running the experiment safe rather than reckless.
Nobody becomes owed anything
A schedule of intended payments is not a claim, a reserve, an earmark or a liability. Nothing is set aside inside any contract, no automatic transfer exists anywhere, and each payment is a separate proposal that has to pass on its own. No miner and no pool acquires a right to any of it, and neither does anyone else.
The share is a judgment, not a reading
There is no on-chain notion of a surplus, an excess or an unmet need, and no contract computes one. Whether revenue exceeds what the network otherwise needs is something voters decide when they approve a configuration and again when they approve each payment. Introducing a metric or a trigger claiming to establish it is forbidden outright.
Recipients are identified in the open
Governance may pick any method for identifying block producers as long as it is deterministic, transparent and set through the proposal process: addresses miners register themselves through an open process, pool payout addresses named by proposal, or a rule computed on-chain. Nothing may rest on a private feed, an interface nobody can verify, or anyone’s discretion.
The figure every payment is computed from is measured, and anyone can reproduce it. What a block produced in base-fee revenue is the gas it used multiplied by the base fee it charged, and both are in the block header. It is deliberately not taken from the accumulating contract’s balance or from what it reports moving on, because both of those can be gamed: anyone may trigger the transfer that moves funds along, so anyone could choose the period boundaries, and anyone may send money to that contract, so a voluntary contribution would be counted as fee revenue. The header product removes both rather than mitigating them.
There is a catch worth knowing, because it shapes the whole design. No contract can read how much gas a block used, not even the block it is executing in. So the figures are stated in the proposal itself, folded into the identifier that binds it, and recomputable by any independent party from public block headers. No oracle, no third-party indexer, and nothing resting on a privileged attestation.
Every payment then goes through the ordinary route: the same vote, queue and public execution as anything else the Treasury pays for. There is no separate channel and no shortcut.
Step two: a curve the protocol enforces
The second step is a hard fork, and it is the one place in the whole suite where a payment to miners stops being a governance decision. Once one configuration has been demonstrated in production under the first step, that configuration is written into the rules for finalizing a block. The protocol then computes what is due at each block and credits whoever produced it directly.
The substantive change is not that the number becomes fixed. It is that the payment path leaves governance entirely. The allocation no longer passes through the Treasury at any point: the accumulating contract never receives it, the Governor never sees it, the contract that holds the funds never releases it, and no proposal funds it. No proposal can alter it, withhold it or redirect it either, so a later DAO cannot set it to nothing through capture, apathy or a change of priorities. Changing it again needs a new specification and another hard fork, which is deliberately the same cost as changing any other consensus rule.
Why harden it at all
While the block subsidy still dominates miner revenue, an allocation a future vote could remove is a tolerable risk and a mistake is correctable. Once fee revenue is the primary security budget, an allocation a future vote could remove is a security budget a future vote could remove. This exists to close that specific risk at the point it starts to matter.
Why a curve, not a flat share
Hardening a flat percentage would fix the size of the allocation and throw away its shape, and the shape is what makes fee revenue usable as a security budget rather than a lottery. So what is embedded is the whole thing the first step demonstrated: the share, the window and the weighting across it, carried over with their meanings unchanged.
Why the Treasury keeps a share of it
The two allocations are not independent. Base-fee revenue is a function of demand, and demand depends on the work the Treasury funds: maintained clients, patched vulnerabilities, EVM alignment, explorers and RPC, audits. Handing the entire stream to block producers would permanently remove the funding for the work that generates the stream, at the layer where the decision cannot be revisited without another fork. A larger permanent share of a revenue source that stops growing is not an improvement.
So the share is bounded at both ends, strictly, and the bound is the only thing about it that can honestly be published. The fraction going to block producers has to be greater than nothing and less than all of it. Nothing would harden no allocation at all and make activation pointless; all of it would permanently reduce the Treasury’s protocol revenue to zero, leaving only what people choose to contribute voluntarily. Under the first step both ends are meaningful and the next proposal can undo either, which is why both are allowed there. At the consensus layer both are permanent and degenerate.
What the actual values are is deliberately unanswered, and this site will not guess at them. They are filled in from what the first step demonstrates in production, which is the entire reason for doing it in that order, and a client has to refuse to activate with them unset rather than fall back to a default. A number published here, or a shape drawn in a chart, would be an invented answer to the question the sequencing exists to ask, and it would be quoted back as a commitment.
The first step is not repealed
Its machinery stays available for the share the Treasury keeps, which goes on accumulating and can still be spread forward for the Treasury’s own purposes: client maintenance, audits, infrastructure. Spreading revenue forward was never only a miner-distribution mechanism. What graduates is the miner-facing part of it.
And it complements the fee market rather than replacing it
Everything the fee market specification establishes stays in force in full: the fee market itself, the permanent floor under the base fee, the way it is calculated and adjusted, the opcode that exposes it, and the redirection itself. What is amended is where the redirected revenue goes, and nothing else.
What has to happen first
The order is the design rather than a plan, and it is written as a requirement. Five things have to be true before the consensus-layer step has a block worth scheduling.
- 01
The fee market has to be running
There is nothing to allocate until Ethereum Classic charges a base fee at all, which is the first hard fork. The second step also may not activate at that same fork block, so the two are separated by design rather than by scheduling.
- 02
The adjustable version has to run, on mainnet, and be observed
Governance has to switch it on and leave it on long enough to produce real evidence about what allocation sustains block-producer participation without starving the work the Treasury funds. How long that takes is a community decision. That it has to happen at all is a requirement, not a recommendation.
- 03
The values have to be filled in from what that produced
They are deliberately unset in the specification, and a client has to refuse to activate with them unset rather than fall back to a default. Naming them now would be exactly what the sequencing exists to avoid: fixing a monetary parameter before the evidence justifying it exists, at the one layer where correcting it costs a hard fork.
- 04
The values have to be checked, and two of the checks are load-bearing
Every client verifies them at activation and refuses to proceed if any fails. Nothing downstream would catch two of those failures, which is why they are written as refusals rather than warnings.
- 05
The window length has to be argued against real chain history
It has to be evaluated against how deep reorganizations actually go on Ethereum Classic and against the chain-selection defense that comes back on at the same upgrade, and the records that evaluation rests on have to be cited. Only then is there a block worth scheduling.
Two of those checks exist because nothing afterward would catch the mistake. The weights have to add up to exactly one, in the whole-number form clients actually compute in rather than in the algebra. If they add up to more, the protocol pays out more at every block than was collected, permanently, and because every client computes the same excess no disagreement between them signals the error. And the window has to be at least one block long. If it is zero, the miner share is withheld at every block and never paid, silently. Both are correctable only by another hard fork, which is why a client has to refuse to start rather than proceed.
The arithmetic is specified too, and that is not fussiness. Each block’s payment passes through two successive rounding steps, in that order, and a client that folds them into one keeps more of the remainder and computes a different amount. Both versions are internally consistent and neither reports an error, so the disagreement would surface as a chain split at the first block where they differ. Test vectors have to be chosen at inputs where the two forms actually diverge, because a vector where they agree proves nothing at all. The order things are added in, by contrast, cannot cause a split, and an earlier revision that named it as the main risk was corrected: pointing the tests at the one property that cannot break is worse than not naming a property.
What rounding leaves over is destroyed rather than credited to either side, because the base fee was already taken from the sender when the transaction ran. The amount is at most one of the smallest units of ETC for each block in the window, which is negligible at any plausible window length. It is a real effect on the total supply, though, so it is stated rather than left to be discovered.
How long the window should be has to be argued, and three constraints bear on it simultaneously. A window shorter than the depth reorganizations plausibly reach means a reorganization rewrites payments already made. A much longer one smooths better, but it delays revenue and widens the ramp at activation, and it is re-evaluated at every block by every validating node forever, which lengthens the time to sync a chain from scratch. So the cost a proposed window implies has to be measured rather than estimated, and the trade has to be made deliberately instead of by attending to one side of it.
The third argument is the one the first step cannot settle, and that limit is worth stating plainly. Paying revenue forward at the consensus layer gives whoever produces a block a reason to reorganize one in order to capture a windfall landing on it, and that reason is strongest when the payment is concentrated across few blocks. Nothing like it arises under the first step, 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. That is structural rather than fortunate, which is precisely why running the first step cannot produce evidence about it. So a window that behaved well there is not thereby shown safe here, whoever proposes one has to argue this on its own terms, and it pulls toward a longer window, with the depth argument and against the validation cost.
The comparison also needs a conversion that is easy to skip. The chain-selection defense that comes back on at this upgrade measures the elapsed time of a competing segment rather than a number of blocks, and converting one into the other depends on block times that are neither fixed nor evenly spread. The conversion, and the period it was measured over, both have to be published alongside whatever window is proposed. So does the evidence: a chain does not record the segments it displaced beyond a depth of one, so the client and explorer records relied on have to be cited, and the stretch during which that defense was switched off has to be told apart from the stretch it was active.
One last mechanical detail, because its absence would double-pay. For the length of one window after activation, the payment ramps up from nothing, since blocks mined before the fork scheduled nothing forward. Reading their real revenue into the curve would pay the same money out to miners that the Treasury already received.
The first of these steps is a governance activation and the second is a hard fork, which is the distinction the roadmap is most often read past. The five stages shows which is which, and what ships at the fork covers the first one.