SIMD-0550 and SIMD-0553: What They Do to Validator Economics

Three proposals hit an on-chain vote at epoch 1021. Two of them change how much SOL exists, and almost every writeup so far has been about the price.

Fair enough. But validators earn the issuance one of these proposals cuts, and nobody seems to be doing that math.

So, the operator's version.

SGP-0002 cuts issuance twice as fast.

This one started life as SIMD-0550. Helius's 0xIchigo and Lostin want to double the rate Solana's inflation declines. Today it tapers 15% a year toward a 1.5% floor. This makes it 30%.

Nothing already issued changes, and the starting rate stays put. Only the speed of the decline moves, which brings the floor forward to roughly 2.8 years from 5.7. About 18.9 million SOL that would have been minted over the next six years just doesn't get minted, leaving total supply some 2.6% below where it was headed.

If you earn staking rewards, that shows up as a shrinking number on a schedule you can read in advance. The proposal models it at 68% participation: 5.84% now, then 4.34%, then 3.00%, then 2.25%.

It also does the math on who gets pushed out. Of the 738 validators it modeled, two go from profitable or breakeven to unprofitable in year one, thirteen the next, thirty the year after that.

Those are the authors' own figures. Most of the ecosystem has read them and decided the trade is worth making.

SIMD-0553 rebuilds the transaction fee instead.

SIMD-0553, from cavemanloverboy, leaves inflation alone and rebuilds the transaction fee instead.

Right now a signature costs 5,000 lamports, split down the middle, half burned and half to the leader. This breaks it into two pieces. A flat base inclusion fee of 2,500 lamports goes to the leader, and sitting on top of it is a resource fee tied to how much compute the transaction requests. The resource fee burns entirely.

It doesn't arrive at full strength either. The rate climbs through three gated steps, a tenth of a lamport per requested cost unit, then a quarter, then a half, and burn at those stages runs roughly 1,500 to 1,800 SOL a day, then 3,750 to 4,500, then 7,500 to 9,000. Issuance is around 60,000 a day for comparison. At the terminal rate the proposal puts it near 0.5% deflation against 3.8% inflation.

So the burn stops being a flat toll and starts tracking what the network does.

Leader pay is where most coverage has this backwards.

The 2,500 is per transaction now, not per signature. Today a leader collects 2,500 on every signature, so a two-signer transaction pays double. Under this model it pays the same 2,500 as a single-signer one, and the proposal doesn't hide the consequence: multi-signer transactions pay less than they do under today's per-signature model, at least until a follow-up SIMD reprices signatures inside the cost model.

Most traffic is single-signer, and there nothing changes. Where transactions carry several signatures, the leader takes less than before. Still a long way from the "both proposals cut validator income" line you'll find in most writeups, since the resource fee burns rather than skimming anything that used to reach you. But it isn't nothing, and how it lands depends on your traffic mix.

Votes are the part to act on.

A vote carrying Compute Budget instructions that reflect the work it really does requests about 3,765 cost units. At the terminal rate that comes to 2,500 plus 1,883, roughly 12% less than the flat 5,000 you pay today. Good news, if your client sends votes that way.

Legacy votes don't. As sent today they ask for something like 54,000 cost units, most of it padding, and the proposal reckons that would push pre-Alpenglow vote costs to nearly six times today's fee once the terminal rate lands. Client implementations should be setting Compute Budget instructions on votes to reflect real vote work. Leaving them off stays valid. It's just no longer recommended.

Six times, or twelve percent cheaper, on the same proposal, depending on how your client is configured.

Slot times are halving, and vote costs follow.

On its own, SGP-0002 is a revenue decline you could plan around. It's three years out, you can see it coming, and most operators would survive it.

Then you remember slot times are getting cut in half first.

SIMD-0525 does it in four 50ms steps, and the software is already out. Agave v4.2 is the recommended release for mainnet validators, v4.2.1 as of Thursday, and the feature gates start activating the week of the 17th. Testnet took the first step down to 350ms on August 5.

Epoch length in slots doesn't change, so epochs simply finish faster. Vote costs are charged per slot, which means the bill per epoch holds steady while the number of epochs in a year climbs.

Helius put it plainly in their v4.2 writeup: if 200ms slots arrive before Alpenglow, validator voting costs could roughly double, because validators would be voting twice as often.

And they do arrive first. Alpenglow is feature-complete in v4.2 but doesn't activate, that's now expected with Agave 4.3, targeted for October. So the upgrade that removes on-chain voting lands after the upgrade that doubles how often you pay for it.

Worth being precise about the pace, because none of this happens overnight. Each of the four steps is separately feature-gated, each needs roughly two thirds of staked validators to opt in, and the network won't advance to the next one if skip rates run high. The full doubling is the end state rather than next week. Which means operators are voting for their own cost increase, one gate at a time.

You can do this one on a napkin. Take the end state, 200ms. A vote costs 0.000005 SOL, there are 432,000 slots in an epoch, so an epoch runs about 2.16 SOL in vote fees. Call it 180 epochs a year and you land near 389 SOL. Double the epochs at the same cost each and you're closer to 778.

Alpenglow eventually swaps on-chain votes for a Validator Admission Ticket, about 1.6 SOL an epoch, burned. Cheaper per epoch than voting is now, but charged twice as often, so on the same assumptions it lands near 576 SOL a year. Better than 778, and still nowhere near the 389 operators have got used to.

Layer SGP-0003's vote-fee change on top and the per-vote price moves as well, in whichever direction your client config points it. Separate levers, same line item, and they turn up in three unrelated release notes. We flagged vote fees as one of the two costs most operators underestimate back in May, which has aged into being more relevant than we'd have liked.

To be fair about the other side, v4.2 does cut costs somewhere. SIMD-0437 drops the rent-exempt minimum by roughly 90% across five stages, taking an SPL token account from about sixteen cents to under two. Real money for anyone creating accounts at volume. It doesn't touch vote fees.

The epoch counts above are rough, and the totals are arithmetic rather than official projection. The direction is the point. Costs up, revenue down, at the same time, for reasons that have nothing to do with each other.

The validator set has already shrunk hard these past two years, which the Foundation's own delegation data shows clearly enough. These proposals squeeze the economics at the small end, and that's exactly the end that's been emptying out. For anyone near that line, how stake finds validators in the first place stops being an academic question.

Where the proposals stand and when voting opens.

This is the first time tokenomics have gone through Solana's new governance process, which only went live in July. Both proposals are in discussion now, and voting opens August 23rd.

Who gets to vote changed this year, and it's not just validators anymore. Stake natively and you vote your own stake, and if your validator votes a way you don't agree with, you can override them.

This is important, because the last one barely made it. Seventy-six validators out of 697 backed SGP-0003, just enough to clear the 15% of stake it needed.

None of this is an argument against either proposal.

Less dilution is good, a burn that tracks real usage is good, but the people it costs should be in the room while it gets decided, and if you're staking, the validator you picked is part of this decision.