Solana SIMD 547: A Resource-Based Base Fee That Gets Fully Burned — Potentially Adding 1,500+ SOL in Daily Burns
Solana SIMD 547: A Resource-Based Base Fee That Gets Fully Burned — Potentially Adding 1,500+ SOL in Daily Burns
Solana’s “low fees, high throughput” design has helped it become a primary venue for onchain trading, consumer apps, and real-time payments. But as the network’s economic activity scales, a recurring question keeps surfacing in the broader crypto market: should SOL capture more value from resource-intensive usage, without harming the user experience that made Solana competitive in the first place?
A new community proposal, SIMD 547, explores one possible answer: introduce a resource-based base fee priced by “cost units,” and burn that fee entirely. The idea is gaining attention because it directly targets Solana tokenomics—specifically the gap between today’s relatively small fee burn and the network’s ongoing issuance.
Below is what the proposal suggests, why it matters, and what it could mean for developers, traders, and everyday users.
1) Why Solana Fee Burn Feels “Too Small” Today
Under Solana’s current fee model, transaction cost is broadly:
- Base fee (signature-based; currently 5,000 lamports per signature), plus
- Prioritization fee (optional; set via compute budget instructions).
You still pay fees even if a transaction fails.
See the Solana fee structure documentation. (solana.com)
Crucially for tokenomics:
- 50% of the base fee is burned, and the other 50% goes to the block-producing validator.
- 100% of the prioritization fee goes to validators (none is burned).
Details are also summarized in the same fee structure documentation. (solana.com)
In the SIMD 547 discussion, the proposer argues that the current burn from base fees is economically tiny, estimating roughly 648 SOL/day burned from the base-fee mechanism at high throughput assumptions—negligible next to a cited ~60,000 SOL/day inflation pace. (github.com)
This gap is the motivation: if SOL is meant to reflect network activity, some community members want the protocol’s burn dynamics to scale more with real resource consumption, not just signatures.
2) What SIMD 547 Proposes (In Plain English)
SIMD 547’s core suggestion is straightforward:
- Every transaction is already assigned an estimated “cost” based on multiple resource dimensions (not just compute).
- Add a new base fee computed from that cost, priced at:
0.1 lamport per cost unit requested, and burn 100% of it. (github.com)
If you need a quick refresher, a lamport is the smallest unit of SOL (1 lamport = 0.000000001 SOL). See Solana’s terminology reference for lamport. (solana.com)
“Cost Units” vs “Compute Units”
Many users are familiar with compute units because they show up in priority fee tuning. But “cost” in Solana’s scheduler is broader: it factors in items like write locks and loaded accounts data size, not only compute. This is reflected in the protocol’s fee and scheduling explanation in the fee structure documentation (see how “cost” is used in transaction scheduling). (solana.com)
In the SIMD 547 thread, the author also emphasizes that cost units include compute plus other implicitly requested resources (loaded data, heap, write locks, and more). (github.com)
3) Expected Burn Impact: “Meaningful, But Not Magic”
One of the most discussed points is how much additional SOL would actually be burned.
In the thread, a community member shared recent aggregates of requested compute unit limits per day, concluding that—at current usage levels—the mechanism would likely land around 1,500–1,800 SOL/day in additional burn, with the possibility of more during peak demand. (github.com)
This is materially larger than today’s base-fee burn, but still not enough on its own to “flip” Solana into a reliably deflationary asset under normal conditions—especially if higher fees reduce demand. That tradeoff is central to the debate.
4) Who Pays More? Makers vs Retail Users (And Why the Proposal Cares)
A key design goal is to avoid breaking high-frequency market structure while still charging more for resource-heavy transactions.
In the SIMD 547 write-up, the proposer argues that many high-frequency updates (often associated with makers/oracle updates) tend to request relatively few cost units, so the added fee could be bounded to a low single-digit percent increase in those workflows. (github.com)
However, for ordinary users who currently submit transactions with low or zero priority fees, the relative increase can look dramatic. The thread includes examples showing triple-digit percentage jumps, including a scenario with a +639% increase when moving from a minimal-fee transaction to one that also pays the new resource-based burn fee. (github.com)
Practical takeaway
- If you already rely on priority fees (e.g., competitive trading), the incremental impact may be modest in percentage terms.
- If you typically send “cheap” transactions (especially in low-urgency contexts), your cost sensitivity could be higher.
This is why the proposal is controversial: it improves value accrual to SOL holders via burn, but it could also reshape the “cheap default” UX that many users associate with Solana.
5) The Alpenglow Dependency: Why Timing Matters
SIMD 547 is not framed as something that can be switched on immediately.
The discussion explicitly notes that validator voting costs matter until Alpenglow is enabled, and the mechanism is assumed to activate after Alpenglow. (github.com)
Alpenglow itself is a major consensus redesign proposal, formalized as SIMD 0326, replacing the current Proof-of-History + TowerBFT-based consensus with Alpenglow (Votor) for better performance and resilience. See the SIMD 0326 document. (github.com)
So in practice, SIMD 547 is best read as part of a broader roadmap: first change consensus and vote mechanics, then revisit tokenomics knobs that would be painful under today’s assumptions.
6) Open Questions the Community Will Likely Debate
Even supporters usually agree the details matter. Based on the thread and Solana’s current fee mechanics, expect debate around:
- Requested vs used resources: charging on “requested cost” is simple and predictable, but may overcharge poorly configured transactions (similar to how priority fees depend on requested CU limit). (solana.com)
- App-level UX: wallets and dApps may need better fee estimation and clearer breakdowns (“how much is burn vs tip vs base”).
- Spam and DoS economics: a stronger burn could deter certain abusive patterns, but it can also penalize legitimate high-complexity use cases (DeFi routing, advanced program interactions).
- Tokenomics vs adoption: in 2025–2026, the industry trend has been toward more sustainable fee markets and clearer value capture—but networks that overshoot can push activity to alternatives.
For readers who want the primary discussion, the best starting point is the original SIMD 547 community thread. (github.com)
7) What Users and Builders Can Do Now
Even though SIMD 547 is still in discussion and not active, it’s a good moment to prepare:
For dApp teams
- Audit transactions that habitually request high limits “just to be safe.”
Solana’s docs explain how prioritization fees depend on requested compute unit limits in the fee structure documentation. (solana.com) - Track how often your users rely on “no priority fee” flows; these are the ones most exposed to a new mandatory burn component.
For traders and power users
- If you run automation, start modeling fees as (signature base fee + priority fee + potential resource-based burn), instead of treating burn as a rounding error.
- If you batch actions, consider whether fewer but heavier transactions would become less attractive than more granular interactions.
For everyone: self-custody still matters
Fee mechanics and tokenomics debates tend to increase onchain experimentation (new routing, new MEV strategies, new bots). That’s also when phishing and malicious approvals spike.
If you hold SOL long-term or frequently interact with Solana DeFi, a hardware wallet like OneKey can help by keeping private keys offline and requiring explicit transaction approvals—useful when transaction composition (and fee breakdowns) get more complex.
Conclusion
SIMD 547 is a tokenomics-focused proposal that tries to thread a difficult needle: increase SOL burn in a way that scales with resource consumption, while avoiding a blunt fee hike that could disrupt validators and high-frequency liquidity provision.
If implemented as proposed, community estimates suggest it could add roughly 1,500–1,800 SOL/day of additional burn at current usage levels—still modest relative to issuance, but no longer negligible. (github.com)
For now, the most important point is not the exact number—it’s the direction: Solana is actively exploring how to align network resources, fee markets, and SOL value capture, likely in tandem with larger protocol changes like Alpenglow. (github.com)
