Draft · SIMD-0553

Base Inclusion & Resource Fee

Split the 5000-lamport signature fee into inclusion fee + resource fee

The idea

Before
2500 leader fixed per signature
2500 burned fixed per signature
After
Base inclusion fee 2500 / sig → 100% leader (unchanged pay)
Resource fee requested_cost × 0.5 → 100% burned
Before
total = 5000×sig + priority
After
total = 2500×sig + priority + resource

Priority fee unchanged.

Motivation

  • Negligible burn today. ~648 SOL/day from signature fees vs ~60k SOL/day inflation — burn is orders of magnitude too small for meaningful tokenomics.
  • Base fee doesn’t price resources. Every txn pays the same 5000/sig regardless of scheduler cost (compute, locks, loaded data). Compute-heavy traffic underpays; efficient low-resource senders overpay.

Economic forecast (@ 0.5 lamports / cost unit)

~7.5–9k
SOL burned / day (est.)
~0.5%
deflation vs ~3.8% inflation
3010
min txn lamports (was 5000)

Low-resource usage wins — votes & oracle updates can pay less than today. Compute-heavy, zero-priority traffic pays more (see examples).

Example Total Fee Before Total Fee After Δ
Vote (w/ Compute Budget Instructions) 0.000005000 0.000004383 −12.3%
Zerofi oracle (66vm...mMAD) 0.000007568 0.000006288 −16.9%
DFlow swap (high prio) (V7X2...SGs8) 0.002007500 0.002202720 +9.7%
OKX swap (mid prio) (3cE8...8Udh) 0.000135980 0.000545640 +301%
Pump.fun (zero prio) (5oGd...fY2) 0.000005000 0.000162410 +3150%

FAQ

Why not just raise the 5000-lamport base fee?

Uniform hikes hit market makers and high-volume low-resource senders hardest, and still don’t price compute / locks / loaded data. This ties burn to requested scheduler cost instead.

Why requested cost units, not consumed?

Same reasons as priority fees: fee known before execution, faster fee payer check, better UX, and incentives to request accurate compute budgets.

Why not 50/50 burn / leader?

Replay cost hits every node, not just the leader. A leader share is a harder economic problem to model and risks second-order effects on validator incentives and market structure (e.g. favoring inefficient programs over efficient ones, favoring toxic swaps over maker updates). 100% burn keeps current validator incentives mostly unchanged.

What about votes?

Well-formed votes with ~3765 requested units are cheaper with a 2500 base fee + resource_fee_rate of 0.5. Naive votes requesting ~54k units would be much pricier pre-Alpenglow — operators should right-size requests (as the SIMD notes).