Solana Validator Fees: What the New Base-Fee Rule Changes

A few weeks ago, Solana’s memecoin mints were back-to-back and the network felt it. Wallets cranked up priority fees just to sneak in swaps, while validators quietly tallied a better month than usual.

Now the conversation is shifting from hot priority fees to the less flashy base fee. The rule that looks small on paper but decides who gets paid, how much gets burned, and whether spam remains cheap.

With on-chain governance finally live, the next vote that matters could be the one that reshapes the base fee itself. Here’s what that would actually change.

Two things happened in July that set the table. First, Solana switched on native on-chain governance, letting the community formally vote on protocol-level changes. Second, validators approved a change to where priority fees go. Put those together, and you get a real path to overhaul the base-fee rule next.

When fee policy stops being theoretical and starts being votable, incentives move fast — and network behavior follows.

Solana’s new governance framework requires a proposer to have 100,000 SOL staked to bring major protocol proposals to a vote, which is a high but intentional bar (CoinDesk). Meanwhile, validators approved SIMD-0096, a parameter change that routes 100% of transaction priority fees to block producers instead of burning half (Gate). The base fee still splits 50/50 between burn and validators, per the protocol docs, but a resource-based redesign is under active discussion (Solana Documentation).

How Solana fees work today

Base fee mechanics

Right now, every transaction pays a small base fee per signature. The split is simple: 50% is burned, 50% goes to the block producer that lands your transaction. That’s the part under review, not yet changed as of late July 2026 (Solana Documentation).

Priority fees after SIMD-0096

On top of the base fee, you can add a priority bid to jump the queue. Since the SIMD-0096 vote recorded in early July 2026, 100% of these priority fees are paid to the validator that includes your transaction (Gate). The formula Solana uses is:

priority_fee = ceil(compute_unit_price * compute_unit_limit / 1,000,000) lamports

That means heavy compute transactions can pay more if you set a high price per compute unit. The network doesn’t burn any of this priority fee under the new rule; it’s pure validator revenue.

Where your fee actually goes: step-by-step

1. You sign a transaction in your wallet; the base fee per signature is attached by default.
2. If you’re in a rush, you set a compute-unit price to add a priority tip.
3. Validators pick a bundle of transactions to fill a block. Higher tips get preferential treatment during congestion.
4. On inclusion, 50% of the base fee is burned and 50% goes to the block producer. 100% of the priority fee goes to the block producer too (Solana Documentation).
5. The network finalizes, and your program executes using the compute units you budgeted.

Component Until early July 2026 After July 2026 Status Base fee per signature 50% burned / 50% to validator Unchanged: 50% burned / 50% to validator Active (per docs) Priority (compute) fee Historically treated partly as burn 100% to validator (SIMD-0096) Approved and live Base-fee architecture Flat per-signature Resource-based model under discussion (SIMD-547) Proposed, not enacted

What the new base-fee rule would change

The big idea on the table is a resource-based base fee, discussed around SIMD-547. Instead of a flat charge per signature, the base fee would scale with the resources a transaction actually consumes. Think of it as paying a tiny amount per unit of network cost, not just paying once for a signature.

Why this matters

A flat base fee keeps spam cheap when the network is quiet and doesn’t price complex calls particularly well. A resource-based fee makes the baseline cost reflect real load — bandwidth, compute, maybe account locks. It also opens the door to more predictable burning and clearer incentives for validators.

Potential burn impact

Industry writeups that model a lamport-per-cost-unit schedule suggest Solana’s daily burn could rise significantly if a resource-based base fee is adopted. One estimate pegs today’s burn near ≈648 SOL/day, and projects a range of roughly 10,800–64,800 SOL/day under higher parameter and throughput settings. The actual outcome would depend on the per-unit price and utilization (BYDFi).

What Anatoly signaled

Solana co-founder Anatoly Yakovenko has publicly nodded at the push to overhaul base/burn mechanics, pointing to resource-based fees as part of a healthier market structure. He flagged support in early July, which the community has cited in fee debates (KuCoin).

Why validators backed SIMD-0096, and what it signals

Validators just voted to keep 100% of priority fees, which doesn’t touch the base fee but says a lot about incentives. During peak mania, the priority market is the only real-time pressure valve users can pull. Letting validators capture all of it tightens the alignment between block producers and the network’s most urgent traffic.

The message behind the vote

SIMD-0096 reads like a bet that fee markets, not ad hoc throttling, should deal with surges. If validators get paid more for scarce blockspace when demand spikes, they’ll invest in uptime and infra. It also removes the blurred line where some portion was burned, which masked actual earnings for operators (Gate).

What it doesn’t do

It doesn’t fix spam by itself. Cheap baseline costs still invite noise. That’s partly why a base-fee revamp is on deck. Without a resource-priced base layer, Solana relies heavily on priority tips and localized fee mechanics to rebalance queues.

Economics for users, validators, and SOL

Users and apps

If a resource-based base fee lands, simple transfers may look about the same most days, but complex calls that lock many accounts or consume more compute could pay a bit more by default. The trade-off is fewer surprise spikes when you didn’t set a tip high enough. You’d still have the option to add a priority bid if you need a guarantee during congestion.

Validators and operators

Priority fees now flow fully to block producers. If the base fee also starts scaling with resource use (while keeping some burn), validator revenue likely becomes steadier across cycles. That’s good for planning opex. It also cuts odd edge cases where a whale overpays for compute while a complex program contributes little to the burn budget.

Supply and burn

A higher, usage-linked base burn could tilt SOL supply more deflationary during high activity. That’s a background force, not a trading signal. Burn is only half the picture; issuance, staking dynamics, and demand for blockspace all matter. Still, models that add cost-per-unit to the base layer show burn rising by an order of magnitude in busy periods (BYDFi).

How this could pass governance

Solana’s on-chain governance is new, and fee rules are exactly the kind of system-level change it’s built to handle. There’s a minimum stake threshold to propose, snapshot windows, and voting periods that produce an authoritative result on-chain.

What a successful path looks like

1. Draft a concrete specification for resource-based base fees (parameters, caps, and the burn split).
2. Secure a proposer with at least 100,000 SOL staked to open the vote (CoinDesk).
3. Publish simulations and parameter ranges that show user costs and validator earnings across load scenarios.
4. Run a testnet pilot and stress tests, then lock parameters for mainnet consideration.
5. Hold the on-chain vote. If it passes, coordinate a rollout height and client updates among validators.

Who gets a say

Staked SOL controls votes. That typically concentrates influence with validators and large delegators, plus programs that manage pooled stake. The bar for proposals is high by design, to keep parameter churn low and align changes with operators who actually run the network.

Outlook and what to watch

In practical terms, the next 1–2 quarters are about parameter work. The hardest part of a resource-based base fee is not the code, it’s the numbers: how many lamports per unit, where to cap it, and whether special cases deserve discounts. Watch for drafts that show side-by-side traces of real transaction bundles under different per-unit prices.

Signals that matter

• Drafts or PRs referencing SIMD-547 with concrete per-unit fee schedules.
• Testnet metrics for average cost-per-transaction by category (DEX swaps, NFT mints, DeFi liquidations).
• Validator alignment language similar to the SIMD-0096 vote descriptions.
• Wallet updates that expose compute budgeting and base/priority breakdowns more clearly.
• On-chain governance proposals opening under the new framework with the 100k SOL proposer requirement (CoinDesk).

Risks & What Could Go Wrong

• Mispriced parameters that make everyday transactions noticeably pricier without curbing spam.
• Validator revenue spikes that attract opportunistic operators but don’t improve reliability.
• Unexpected interactions with local fee markets or account-locking behavior that create new bottlenecks.
• Governance capture if a few large stakers push through an aggressive fee schedule.
• Wallet UX lagging behind, causing users to overpay priority fees on top of a higher base.
• Lower-than-expected burn if utilization assumptions don’t hold, reducing the intended supply impact.
• Smart-contract breakage if programs assume fixed baseline costs and aren’t updated.

Fee rule changes are systemic. Get the parameters wrong, and you don’t just shift who pays — you risk changing who can afford to build.

If you want to keep tabs on the next governance steps and any parameter drafts, we track these shifts closely at Crypto Daily and link to primary sources so you can verify the details yourself.

Frequently Asked Questions

Is the new base-fee rule live on Solana right now?

No. As of late July 2026, the base fee remains a flat per-signature charge split 50% burned and 50% to validators according to Solana’s own docs. The priority fee is what changed in July: 100% goes to validators under SIMD-0096 (Solana Documentation; Gate).

What exactly would a resource-based base fee charge for?

The proposal direction is to charge a tiny amount per unit of network resource — mainly compute units and possibly other costs tied to account access. That aligns baseline cost with actual load instead of a one-size-fits-all signature fee.

Who pays more if this passes?

Likely transactions that are compute-heavy or touch many accounts during busy windows. Simple transfers and lean program calls may see little change in normal conditions. Priority bids remain optional for speed.

When could a vote happen?

Once a concrete spec is ready and a proposer with at least 100,000 SOL staked opens it under the new governance system. There’s no firm date; draft quality and validator alignment will drive timing (CoinDesk).

Will this make SOL deflationary?

It could increase burn during high activity, which pushes in that direction, but supply outcomes depend on issuance, staking, and demand. Research estimates point to a large burn increase under certain parameters, not a guarantee in all markets (BYDFi).

How is this different from Ethereum’s EIP-1559 base fee?

Ethereum’s base fee targets block fullness and burns that fee, with separate tips to miners/validators. Solana’s discussion leans toward charging by resource units consumed, with a policy choice about how much to burn versus pay to validators.

Did Anatoly endorse a specific parameter set?

No fixed numbers from him publicly. He signaled support for changing base-fee and burn mechanics, but the exact per-unit price and split would need to come from community drafts and testing (KuCoin).

Disclaimer: This article is provided for informational purposes only. It is not offered or intended to be used as legal, tax, investment, financial, or other advice.