EIP-8363 Declining issuance burn (Tapered Issuance Burn)

Declined for Inclusion · Consensus & staking · EIP status Draft · created 2026-07-14

As more ETH is staked, a set share of validator rewards is burned to reduce issuance. At the point where half of all ETH is staked, the burn rate reaches 100%, and the incentive to issue more for additional staking disappears.

Why it is needed

Today, even as staked ETH grows, the new ETH paid to validators, that is, issuance, keeps increasing. The yield of a single validator falls gently but does not drop below about 1.5%, so there is no point at which the staking incentive switches off. As the staking landscape matures and custodial institutions such as ETFs grow, the risk premium required for staking keeps declining, so the staking ratio can keep rising. The source argues that this creates two problems. First, if most ETH concentrates in a few operators such as exchanges, ETFs, and staking services, large operators become 'too big to fail' and the community has difficulty correcting problems by fork when they arise. Solo stakers, who pay tax on nominal income, see their real return after dilution turn negative first and are pushed out. Second, ETH holders who do not stake keep being diluted, so interest-bearing liquid staking tokens take the place of ETH as collateral and a means of payment. The base asset of the Ethereum economy would then bear the smart contract and governance risk of particular issuers.

What changes

Today

After EIP-8363

Who is affected

In depth

Burn rate b and SATURATION_BALANCE

The burn rate b is the total active balance D divided by the saturation balance SATURATION_BALANCE, raised to the power 3/2, and capped so that it does not exceed 1. SATURATION_BALANCE is in Gwei (60_250_000 * 10**9), about 60.25 million ETH, set to match half of the ETH supply at the time of the hard fork. It is written as a balance rather than a ratio because the protocol can read get_total_active_balance(state) but does not know the total ETH supply. So if the supply changes after the fork, the actual saturation ratio drifts slightly. The source states that this drift is small over a reasonable period and can be corrected if a later EIP makes the protocol aware of the total supply. The computation is handled by get_issuance_burn. It is written as the cube of the square root ratio so that it is handled with three Uint64 multiplications and divisions, keeping every intermediate value within 64 bits. The two square roots, sqrt_active and sqrt_sat, are computed by the caller once per epoch and passed in.

Why the exponent is 3/2: derivation of the linear taper

Let the staking ratio be f = D/S (S is total supply). The current consensus layer yield is y(f) = BE/√(fS) (B is BASE_REWARD_FACTOR, E is the number of epochs per year). The goal is to subtract a term that is 0 at f = 0, grows linearly in f, and exactly cancels the yield at the saturation ratio f_sat. In other words, the net yield is ỹ(f) = y(f) - (f/f_sat)·y(f_sat) for f ≤ f_sat, and 0 above that. Setting this as ỹ(f) = (1 - b(f))·y(f) and solving gives b(f) = (f/f_sat)^(3/2). The exponent is 3/2 rather than 1 because the reward curve itself shrinks as f^(-1/2). The absolute amount to subtract is linear in f, but expressing it as a fraction of a reward that shrinks as f^(-1/2) adds another half power. As a result, total issuance ĩ(f) = f·ỹ(f) is no longer monotonically increasing: it peaks at f* = 2^(-7/3) ≈ 19.8% and falls to 0 at f_sat = 50%. Because b does not depend on B, raising B during the transition period leaves b(f) unchanged.

Per-duty burns: attestation, proposer, and sync committee

The new step process_issuance_burn is inserted in process_epoch right after process_rewards_and_penalties and before process_effective_balance_updates. Effective balances still hold that epoch's values, so the proposer burn is charged accurately to the proposer that was actually selected. The attestation burn is charged to every validator that was active in the previous epoch. The base amount is computed by taking the participating balance per flag from get_participating_increments, rounding down for each flag separately, and then summing. Summing first and rounding down once would yield up to 2 Gwei more, and at saturation that difference would come out of the principal of a flawless validator. During an inactivity leak, only the attestation burn is paused. The proposer burn is charged to the 32 proposers of that epoch, and its base amount is the sum of attestation_component and sync_component, computed from current-epoch participation, divided by SLOTS_PER_EPOCH. Sync participation is not accumulated in state, so attestation participation is used as a substitute, and the error stays within 3.57% of the proposer's share. For the sync committee burn, rewards are paid every block, so process_sync_aggregate subtracts participant_reward × b from all 512 committee members regardless of whether they participated. If only participants were charged, abstaining would avoid the burn, and the balance gap between participating and not participating would shrink from 2× participant_reward to (2 - b)×. A get_beacon_proposer_index_at_slot lookup, which does not exist in the current spec, is also newly required.

Why the burn is based on idealised rewards and split by duty

If the burn were proportional to the rewards actually received, the marginal reward of every duty would shrink by a factor of (1 - b), weakening the incentive to participate correctly. So the burn is based on the reward the validator would have earned by performing perfectly, and it is deducted regardless of whether the validator actually performed. It does, however, reflect network-wide participation. The reward of a flawless attester also shrinks with network participation, and if the burn alone were charged on a full-participation basis, diligent validators would lose out whenever the offline share exceeds 1 - b. During an inactivity leak, when attestation rewards stop entirely, the attestation burn is paused in full. The reason for splitting by duty is the same. Taking one uniform deduction every epoch would keep the spec simple, but it would have to be large enough to cover the rarely occurring proposal and sync committee rewards, and as b grows it would exceed the attestation reward of an ordinary epoch. A validator that attests perfectly would then see its balance fall every epoch while waiting for its proposal turn. Charging per duty means a validator that attests diligently never goes negative merely because it has no proposal or sync committee assignment. The source explains that every base amount is determined only by network-wide aggregates, so no burn depends on the behavior of the validator that pays it, and a diligent validator keeps (1 - b) times the reward it received as net reward at any participation level.

18-month transition: base reward factor from 128 to 64

If the full burn applied at the moment of the fork, at the current staking ratio (f ≈ 33%) the net yield would be cut by more than half, from about 2.6% to 1.2%, which could trigger a large exodus. So the base reward factor read by get_base_reward_per_increment starts at TRANSITION_BASE_REWARD_FACTOR (128) and decreases linearly to BASE_REWARD_FACTOR (64) over TRANSITION_DURATION_EPOCHS (123,300 epochs, 548 days × 225 epochs per day, about 18 months). Doubling it to 128 makes the net yield curve meet the current curve near f ≈ 31%, so the starting point is similar to today's. Because the factor is an integer, the decrease is a staircase of 65 steps, and one step is about 1,927 epochs, or 8.6 days. Since rewards, penalties, and the burn all derive from the same base, everything moves together and the balance is not broken. The only place that changes in the existing reward code is get_base_reward_per_increment, and once the transition ends it behaves exactly as it does today. Meanwhile, the shape of the curve, namely the property that the burn reaches 100% at 50%, is independent of the factor and works from the first epoch of activation. Because a hard fork is usually Scheduled for Inclusion (SFI) at least six months in advance, the source expects an adaptation period of about two years from SFI to reaching the permanent yield.

Why a burn, and why 50%

There are four reasons for choosing a burn over redrawing the reward curve. First, the only permanent parameter is SATURATION_BALANCE, and its value has a natural reference point: half of the ETH supply. Second, preventing griefing attacks requires rewards and penalties to be paired, and then under any curve a diligent validator always earns a positive yield, leaving a yield floor. A burn removes this floor and lets the market set the equilibrium yield. Third, lowering yield by shrinking all rewards and penalties weakens the per-duty micro incentives and could let MEV crowd them out, whereas a burn leaves the schedule as it is and cuts only the macro yield behind the scenes. Fourth, if the deducted ETH were redirected to other validators or a foundation, total issuance would stay the same and a lobbying target would arise, so destroying it is neutral, like the base fee burn of EIP-1559. 50% is not a target but the point where the issuance incentive switches off completely, and the market settles somewhere below it. When a majority is staked, a rescue coalition would itself be the majority of the economy and there would be no larger group to counter it with a fork, so this is a qualitatively different threshold. There is no basis for distinguishing 60% from 70%, and conversely, setting it at or below today's 33% would make the burn 100% immediately on activation and push stake out. Since issuance peaks at about 20% and then declines, a large operator effectively splits an ever-shrinking pie more widely as it grows, and an operator holding half of the stake finds growth becomes a loss from the point when about 31% of supply is staked. MEV accrues in proportion to stake regardless of the burn, so it acts to raise this threshold.

Security considerations: downtime cost, economic security, MEV share

b is a public function determined solely by total active balance and applies equally to all validators, so no one can shift their share onto others and no new griefing path arises. The cost of downtime is the same as today in ETH terms, because the balance gap between performing and not performing a duty is unchanged. However, since net income shrinks by a factor of (1 - b), the number of days needed to recover a loss grows by a factor of (1 + b/p)/(1 - b). Here p = 40/54 ≈ 0.74 is the ratio of the penalty to the idealised reward, and at today's ratio (f ≈ 33%) the factor is about 3.8. A validator with 99% uptime keeps 96% of a perfect validator's net income, versus 98% today. On economic security, this EIP deliberately lowers the equilibrium stake, but the cost of an attack is set by the market value of the stake that would be forfeited, and the source considers that amount large enough even at ratios of a few tens of percent. As for the MEV share, over the year to July 31, 2026, total MEV-Boost relay payments were about 72,600 ETH across 2.42M blocks, an average of 0.030 ETH per block, and even if 190,000 locally built blocks are counted at the same average, execution layer rewards are below 78,300 ETH. That is at most 0.20% of roughly 40 million ETH staked. Consensus issuance is 64√D Gwei per epoch, about 1,054,000 ETH per year, or 2.62%, so issuance accounts for more than 93% of yield, and more than 80% even if the ratio settles at 40%. For computational cost, one O(1) deduction per validator, a 32-proposer pass, and one new iteration that sums current-epoch participating balances are added, so cost remains linear in the number of validators.

Original status and core developer call decisions

The source status is Draft. The constant values, the transition length, and the burn calculation method may all still change. Here is how it progressed in the core developer calls. At ACDC #184 on 08.06, the PFI of EIP-8363 was confirmed as procedurally valid and it was accepted as a Hegota fork candidate. There was no CFI or SFI decision, and it was stated firmly that community consensus is a prerequisite for acceptance. It was discussed at AMA #15 on 09.16, but no decision was made. At ACDC #187 on 09.17, the decision was deferred, and stokes was to propose a process for gathering broader community input before the next ACDC. At ACDC #188 on 10.01, the champions (the people responsible for pushing the proposal forward) withdrew EIP-8363, and it became DFI. Instead of scoping it in the core developer calls, they decided to follow a broader community-led process. In the debate, co-author pintail said the argument that excess issuance leads to capture is not a rhetorical ploy, while dapplion said opposing operators reject it simply because they stand to lose. The proposer's tweet on the day of publication gave the number as EIP-8361.

Original EIP · ← EIPs