Solana Prices Signatures and Nothing Else. SIMD-0553 Prices Everything.
Compute on Solana has been free at the margin since genesis. SIMD-0553 ends that: a resource fee priced on requested cost units, burned in full, merged July 20 and landing in 4.3. Votes get cheaper, waste gets expensive, and the burn grows about 13x. Our full analysis, including modeling nobody else has published on how it stacks with SIMD-0550.
By the Temporal team. SIMD-0553 was authored by our engineer cavey (@cavemanloverboy).
Actionable insights
SIMD-0553 replaces Solana's flat 5,000 lamport per-signature fee with a 2,500 lamport inclusion fee paid to the leader plus a resource fee, burned in full, computed from the cost units a transaction requests. The rate ramps through three feature gates to a terminal 1/2 lamport per cost unit. The proposal was merged on July 20, 2026, after being approved by the Anza and Firedancer teams, and implementation is expected to land in 4.3.
At current activity, the terminal rate burns an estimated 7,500 to 9,000 SOL per day, up from 648 today. Votes get 12.3% cheaper and oracle updates 16.9% cheaper; compute-heavy transactions that request far more than they use pay more, which is the point.
Our modeling below finds the burn removes roughly 15.8M SOL from supply over six years at constant activity, comparable to the 18.9M SOL that SIMD-0550's doubled disinflation saves on the issuance side. Together, the two put net supply growth near 1.05% per year by 2029, below the protocol's 1.5% terminal inflation target.
The problem
Solana charges 5,000 lamports per signature. That part is fine: signature verification is real work every node repeats, and it should cost something. The problem is everything after the signature check, because none of it costs anything. Whether your transaction updates one oracle price or grinds through 1.4 million compute units of swap routing, the fee is identical. Signatures are the only resource the base fee has ever seen.
The result: at roughly 3,000 TPS, the network burns about 648 SOL per day from signature fees. Issuance runs near 60,000 SOL per day. The only burn left on Solana offsets about 1% of inflation. Compute, meanwhile, is free at the margin. Once you have paid for your signatures, requesting 200,000 compute units costs exactly what requesting 2,000 does.
SIMD-0553 is our proposal to end both problems with one mechanism.
The mechanism
The current 5,000 lamport per-signature fee is replaced by two components. Priority fees are untouched.
A base inclusion fee of 2,500 lamports, flat per transaction, paid entirely to the leader. Leaders must earn something for including zero-priority transactions or a fee-maximizing leader would simply drop them. This also happens to be the fee structure that multiple concurrent proposers (MCP) will need anyway, so the proposal gets ahead of that migration rather than fighting it.
A resource fee, burned in full:
resource_fee = ceil(requested_cost_units * rate)
Total fee becomes inclusion fee + resource fee + priority fee. The rate ramps through three feature gates: 1/10, then 1/4, then a terminal 1/2 lamport per cost unit.
The design choice we care most about: requested_cost_units is not a new number. It is the exact cost the scheduler already computes for block packing, the saturating sum of signature cost, write-lock cost, instruction data bytes, execution cost from the requested compute limit, and loaded-accounts data size. The runtime already meters every one of these. SIMD-0553 just makes the meter bill.
Why requested and not consumed
The fee is computed from what a transaction requests, not what it consumes at execution. This was the most debated line in the proposal, and it is deliberate. Requested cost stays compatible with asynchronous execution, where consumed cost is not known at scheduling time. The runtime can validate a fee against the fee payer before executing anything, and wallets can show the exact fee before send. Over-requesting also gets expensive for the first time.
That last point drew the sharpest critique. On-chain analyst Umberto noted that the fraction of requested cost units actually consumed is "ridiculously low" and that requested cost units are significantly mispriced. We agree. That gap is the block-packing inefficiency the network has been eating for years: the scheduler reserves capacity for what you request, whether or not you use it. Cavey's response in the thread is the whole thesis in one line: "We are simply adding an incentive to request correctly, and to reduce CUs."
Who pays more, who pays less
The proposal includes worked examples from real mainnet transactions, computed at the terminal 1/2 rate:
| Transaction | Today | Under SIMD-0553 | Change |
|---|---|---|---|
| Vote (3,765 CU, with compute budget ixns) | 5,000 | 4,383 | -12.3% |
| Zerofi oracle update | 7,568 | 6,288 | -16.9% |
| DFlow swap, high priority | 2,007,500 | 2,202,720 | +9.7% |
| OKX swap, mid priority | 135,980 | 545,640 | +301% |
| Pump.fun swap, zero priority | 5,000 | 162,410 | +3,150% |
(Fees in lamports. Links to each transaction are in the SIMD.)
The pattern is not accidental. Votes get cheaper. Oracle updates and market-maker flow, the high-frequency low-resource traffic that keeps Solana's markets tight, get slightly cheaper. What gets more expensive is compute-heavy execution that currently pays the same 5,000 lamports as an oracle tick.
A 32x jump for a zero-priority Pump.fun swap looks dramatic until you price it: 162,410 lamports is still a fraction of a cent, and it lands on programs that request far more compute than they need. Those fees are a bug bounty for optimization. Request accurate limits, tighten your compute, and your users pay less. The minimum possible transaction fee actually drops, from 5,000 lamports to 3,010.
Why burn 100% of it
An earlier version considered splitting the resource fee 50/50 with the leader, mirroring today's split. We rejected it for a reason that matters if you think carefully about who bears costs: execution is replayed by every full node on the network, not just the leader who packed it. Additionally, paying the leader for resources metered would reward leaders for preferring inefficient transactions. Burning the resource component keeps the leader exactly neutral about what your transaction does, which is the property a fair scheduler wants.
Credit where due on the inclusion fee as well: Anza's Andrew Fitzgerald pushed to make it flat per transaction rather than per signature during review, and the draft adopted it. Signature work is currently priced twice, once in the per-signature fee and once, too cheaply, in the cost model. A follow-up SIMD will correct signature costs where they belong, in the cost model, where they get burned like every other resource.
What it does to the burn
While sizing the proposal we pulled network-wide requested cost units per day, thirteen consecutive days of it, May 17 through 29, and posted the raw table in the discussion. Demand ranged from 15.2 to 18.2 trillion cost units per day, with the average block carrying about 23M requested CU.
Price any of those days at the terminal rate and the arithmetic is one line. Take May 29:
17,517,381,813,538 cost units × 0.5 lamports = 8,758,690,906,769 lamports = 8,759 SOL burned in one day
Across all thirteen days the implied burn runs from 7,586 to 9,097 SOL, averaging 8,405. That is where the 7,500 to 9,000 figure everyone quotes comes from: not a projection, just recent mainnet demand multiplied by the rate.
The same data prices the full feature-gate ramp:
At the terminal rate, that is 7,500 to 9,000 SOL per day, 12 to 14 times today's burn, or about 0.5% of supply per year in deflationary pressure against 3.8% inflation.
An honest caveat that most coverage skips: these estimates assume nobody changes behavior, and the entire point of the fee is to change behavior. If developers respond by requesting fewer cost units, realized burn comes in lower than projected while blocks pack tighter. Both outcomes are wins. We would rather have a burn number that shrinks because the network got more efficient than one inflated by waste.
The combined picture: SIMD-0550 x SIMD-0553
The proposal composes with the issuance side of the debate. SIMD-0550 attacks inflation at the source by doubling disinflation from -15% to -30%; Helius modeled that change saving 18.9M SOL in emissions over six years. SIMD-0553 attacks it at the sink by making usage burn. Anza's CEO has said publicly he expects both to ship this year. What nobody has published is what they do together, so we modeled it.
We took the yearly inflation paths from Helius's SIMD-0550 analysis (including their 4.5-month activation lag), started from the current 627.5M SOL supply at 3.82% inflation, and subtracted the 553 burn at our mid-estimate of 8,250 SOL per day at the terminal rate, with year one averaged at half that while the feature gates ramp. Four scenarios: status quo, each proposal alone, and both.
Alone, the 553 burn removes about 15.8M SOL from supply by 2032 in our model, within shouting distance of what doubling disinflation saves (our model puts 550 at 18.1M; Helius's more granular version says 18.9M). A fee mechanism nobody votes on as a tokenomics headline turns out to be worth nearly as much SOL as the headline proposal.
Together they compound: roughly 33.8M SOL less supply by 2032, and once 550 hits the 1.5% terminal inflation rate in 2029, the 553 burn keeps working underneath it. Net supply growth settles near 1.05% per year, the only scenario of the four that gets below the protocol's terminal target. Issuance policy has a floor; a usage burn does not.
The same caveat from above applies twice over here: this assumes activity holds and nobody optimizes their compute requests. Treat the curves as a ceiling on burn and a direction of travel, not a promise.
Alpenglow, votes, and what comes next
The fee calculation is identical before and after Alpenglow. Pre-Alpenglow, validators should send votes with compute budget instructions requesting 3,765 CU, which is what makes votes 12% cheaper under this proposal rather than more expensive; the spec covers the TPU plumbing that SIMD-0458 makes necessary for that. Post-Alpenglow, vote transactions disappear entirely and the question becomes moot.
Longer term, MCP introduces an inclusion fee paid to proposers and pushes toward fully burned execution pricing. SIMD-0553 is shaped so that migration is a rate change, not a redesign.
Drawbacks
No fee change is free, and it would be dishonest to present this one as an exception.
The minimum transaction fee falls from 5,000 to 3,010 lamports, which lowers the cost floor for spam. The spec's answer is that such transactions are nearly free to execute anyway, but it is a real reduction in the DoS price floor and reviewers weighed it.
Fee anatomy gets more complicated. A transaction now has an inclusion fee, a resource fee, and a priority fee, and in practice many add a success fee on top (we have opened a separate SIMD discussion proposing to formalize these). App developer gwalen raised this in review: four payment components is worse DX than two, and "fees went up 3,150%" is a headline someone will write about Pump.fun swaps regardless of the absolute numbers involved.
Anza economist Max Resnick argued the opposite direction entirely in the PR thread: "I'm in favor but would prefer to keep the base signature fee where it is at 5000 lamports. I think its too low already at about $0.0003 per tx." And any projection of burn revenue inherits the behavioral uncertainty we flagged above; if the incentive works, the burn undershoots the estimate.
We think each of these trades well against pricing compute at zero forever. But they are trades.
The proposal absorbed 47 inline review comments and a rework of the inclusion fee on its way to approval from both Anza and Firedancer. Merged does not mean live: the resource fee arrives through the three feature gates, so the burn ramps up epoch by epoch as they activate. Read the full spec, the originating discussion, or play with the numbers at burn.cavey.xyz. This repricing reaches you whether you run a validator or just hold SOL.
Temporal is a Solana R&D firm. We build some of the fastest infrastructure on the network and live downstream of its fee mechanics every day, so transaction pricing is not an abstract interest for us. We have been arguing about Solana fee design in public since 2023, when our co-founder Ben told Helius that local fee markets are a lie. SIMD-0553 is the constructive version of that argument: if the network is going to price resources, it should price the ones it actually spends.