Analysis · August 25, 2026

What SIMD-0553 would have cost

A per-transaction replay of the resource-fee burn proposal over the ten most recent complete epochs in the archive. Every non-vote transaction was re-priced under the SIMD’s formula from its own requested compute, accounts and signatures; votes were priced from the proposal’s own figures.

Across 2,855,660,233 transactions the network collected 125,860 SOL in fees. Under SIMD-0553 at ½ lamport per requested cost unit, the same transactions would have paid 447,593 SOL — +255.6%, a 3.56× increase. The whole increase is burned: leader income is essentially unchanged, priority fees are untouched, and the burned share of fees goes from 6.2% to 73.8%.

The median transaction pays 8.0× what it pays today; 41% of transactions pay more than ten times as much.

A flat fee becomes a metered one — and the meter reads requested, not used

Today every signature costs 5,000 lamports, half burned and half to the leader, and that is the only base charge. SIMD-0553 replaces it with a flat 2,500-lamport inclusion fee per transaction (all to the leader) plus a resource fee that is burned in full and scales with the transaction’s pre-execution scheduler cost — its signatures, write locks, instruction bytes, requested compute-unit limit and requested loaded-accounts data size. The rate ramps through three feature gates: 1/10, 1/4, then 1/2 lamport per cost unit. Priority fees are untouched.

Two design choices drive everything below. Charging on requested rather than consumed compute means a transaction that never set a compute budget is billed for the runtime default — 200,000 CU per instruction, up to 1.4M — and 64 MiB of loaded data (16,384 CU). And burning 100% of it means none of the new revenue reaches validators; the change is a pure transfer from fee payers to SOL holders, through deflation.

Most transactions pay more; a large tail pays an order of magnitude more

The fee multiple — new total divided by today’s total — for every non-vote transaction in epoch 1006, the epoch modelled with exact per-transaction inputs, at the terminal ½ rate. 15.1% of transactions get cheaper: they set tight compute and loaded-data budgets and request little. 41.3% pay more than 10× (between 41.3% and 45.6% in every one of the ten epochs) and 7.8% more than 50×. Even at the opening 1/10 rate, 51.3% of transactions at least double.

The bill lands on transactions that never set a compute budget and pay no priority

Splitting transactions by whether they set an explicit compute-unit limit and whether they pay any priority fee separates the population cleanly. Transactions with no limit are billed for the 200k-per-instruction default; transactions with no priority fee had nothing else in their fee to dilute the new charge.

Failed transactions pay too

1,094,735,139 transactions (38.3%) failed on-chain. Today they paid 30,759 SOL; at ½ they would pay 126,611 SOL (4.12×). The proposal preserves fee-only processing, so a transaction that fails during account loading still owes the full resource fee.

Multi-signer transactions get a discount

The flat 2,500 inclusion fee replaces 5,000 per signature, so a transaction with extra signers keeps most of its savings unless it also requests a lot of compute. Leaders lose that per-signature income: 703 SOL over ten epochs.

Which applications absorb the increase

Epoch 1006 is modelled with the exact loaded-data-size requests and instruction bytes from the instruction sidecar, so it carries the per-program attribution. Transactions are attributed to their first top-level program (ComputeBudget excluded). Added SOL is the difference between the ½-rate total and today’s fees for that program’s transactions in the epoch.

Across the epoch, 3,941,807 distinct fee payers were active; 1,204,040 of them would see their total bill rise more than tenfold, 3,381,240 more than double, and 720 would pay less. The heaviest single payers are high-frequency bots and market makers running millions of transactions per epoch, with multiples between 3.4× and 19.8×.

Until Alpenglow, voting gets almost six times more expensive

Votes are still on-chain transactions in these epochs — 2,973,367,099 of them, about 690 per slot from ~689 voting validators. The proposal’s own figure for a vote sent the way validators send them today is ~54,000 requested cost units, because a legacy vote carries no compute-budget instructions and inherits the defaults. At ½ that is a 27,000-lamport burn on top of the 2,500 inclusion fee: 29,500 lamports per vote against 5,000 today. Validators who update their clients to attach a tight compute budget (the SIMD’s 3,765-unit vote) pay 4,383 — slightly less than today.

At the intermediate gates legacy votes cost 23,490 SOL (+58.0%) at 1/10 and 47,574 SOL (+220.0%) at 1/4 over the same ten epochs.

Real deflationary pressure, but only at the terminal rate

Inflation rewards (staking + voting) in these epochs totalled 1,288,306 SOL — 61,365 SOL/day. Today’s burn of 2,500 lamports per signature (votes included) destroys 15,276 SOL over the same period, 1.2% of issuance.

The SIMD projects 7,500–9,000 SOL/day of resource-fee burn at ½ from May 2026 data; this replay lands at 15,732 SOL/day from non-vote transactions alone, 19,556 with legacy votes (15,999 with budgeted votes). The replay is higher because it prices every transaction that landed — including the 38% of non-vote transactions that failed and still pay — at its requested cost, with the runtime defaults for the 12% that never set a compute budget. Either way the direction is the same: net issuance falls by roughly 30.7% of today’s inflation at the terminal rate, and a meaningful slice of that comes from vote fees the proposal simultaneously tells validators to eliminate.

What this replay says the network would give up

• Zero-priority, no-budget traffic is repriced by an order of magnitude. The “No CU limit, zero priority” segment — 8.4% of transactions — goes from 1,668 to 78,563 SOL (47.09×). This is the long tail of wallets, bots, oracles and consumer apps that have never needed a fee strategy.
• Insufficient-funds rejections. Any payer funded for today’s flat fee whose new total exceeds its balance is dropped at block packing. 77.5% of transactions at least double, so pre-funded flows (Helium-style device uploads, custodial hot wallets, airdrop claimers) will fail until every sender re-estimates.
• Validator operating cost. 72,847 SOL more per ten epochs in vote fees for un-updated clients — an involuntary 20.6% levy on voting rewards until Alpenglow removes on-chain votes.
• Nothing new reaches validators. The entire increase is burned. Leader income is flat to slightly down (−0.6%) because the per-signature base fee becomes a per-transaction one.
• Failed transactions pay the resource fee too — 95,852 SOL of the ten-epoch increase falls on transactions that did nothing.
• Cheaper spam at the floor. A minimal transaction costs 3,010 lamports at ½ (less at the earlier gates) instead of 5,000: 15.1% of real transactions get cheaper, and so does the cheapest possible DoS transaction.
• Requested ≠ consumed. The fee rewards accurate budgeting, but it is set at submission, so a wallet that over-estimates to avoid failures now pays for the headroom. The incentive pushes toward under-requesting and more compute-exhaustion failures.

What it buys: 395,283 SOL of additional burn over ten epochs at the terminal rate, and a fee floor that finally scales with scheduler cost.

How the replay was built

Source: the sol-view events corpus for epochs 1002–1011 (one row per non-vote transaction with fee, compute-unit price and limit, signer and writable-account counts and program list), the per-slot aggregates for vote counts, and the rewards tables for issuance. 2,855,660,233 transactions were re-priced individually with DuckDB.

• Requested compute. The explicit compute-unit limit when set; otherwise the runtime default (200,000 CU per non-builtin instruction, 3,000 per builtin, capped at 1,400,000). Priority fee = ceil(price × limit / 10⁶).
• Signatures. Recovered from the observed fee: (fee − priority) / 5,000. Transaction signatures cost 720 CU; precompile signatures 2,400 (ed25519) or 6,690 (secp256k1). The decomposition is exact for 100.00% of transactions in every epoch, which validates the default-compute rules.
• Loaded-accounts data size. Epoch 1006 uses each transaction’s actual request from the instruction sidecar (47.4% of transactions set one; median 13 MB → 3,216 CU vs the 16,384 default). The other nine epochs impute the 1006 mean by segment. Using the default for every transaction instead would raise the ½-rate burn by 2.8% — the imputation is a second-order term.
• Instruction data. Exact for 1006 (mean 149 bytes ≈ 1 CU); 1 CU elsewhere.
• Votes are not in the events corpus. They are priced from the SIMD’s own numbers: ~54,000 requested cost units for a legacy vote, 3,765 for a compute-budgeted one.
• Distribution statistics (median, percentiles, share cheaper or above a multiple) are reported from epoch 1006 only, because the imputed loaded-data term in the other epochs is a class mean and cannot reproduce the low tail; ten-epoch figures are totals and segment sums, where the imputation is mean-preserving.
• Not modelled: behavioural response. Wallets would tighten budgets and some traffic would stop; both push the realised burn below these figures and the failure count above them. Fee-only (load-failed) transactions are priced like any other.

Generated from sol-view epoch artifacts · epochs 1002–1011 · 2,855,660,233 non-vote and 2,973,367,099 vote transactions · cost-model constants from Agave (SIMD-0170 defaults). Epoch 1006 exact; others imputed as described.