Solana’s recent bursts of memecoin minting placed renewed pressure on the network’s fee market, with users raising priority fees to get swaps included while validators collected higher-than-usual fee revenue. The discussion has now moved from priority fees to Solana’s base fee, a less visible rule that determines who receives transaction fees, how much SOL is burned, and whether low-cost spam remains economical.

The debate is becoming more concrete because Solana’s native on-chain governance is now live. That framework gives the community a formal route to vote on protocol-level changes, including possible revisions to the base-fee model. In July 2026, two developments set up the next stage of the discussion: Solana activated on-chain governance, and validators approved a change to the destination of priority fees.

Under Solana’s new governance system, a proposer must have 100,000 SOL staked to bring major protocol proposals to a vote, according to CoinDesk. Validators also approved SIMD-0096, a parameter change that routes 100% of transaction priority fees to block producers rather than burning half, according to Gate. The base fee still remains split 50/50 between burning and validators under current Solana documentation, while a resource-based redesign is under discussion.

How Solana fees work today

Base-fee mechanics

At present, every Solana transaction pays a small base fee per signature. That fee is divided evenly: 50% is burned, and 50% goes to the block producer that includes the transaction. This is the part of the fee system currently under review, but it had not changed as of late July 2026, according to Solana’s protocol documentation.

Priority fees after SIMD-0096

Users can add a priority bid on top of the base fee to improve the chance that a transaction is processed sooner during congestion. Since the SIMD-0096 vote recorded in early July 2026, 100% of those priority fees are paid to the validator that includes the transaction.

Solana’s priority-fee formula is:

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

This means transactions that require more compute can pay more when a user sets a higher price per compute unit. Under the new priority-fee rule, none of the priority fee is burned; it is entirely validator revenue.

Where a transaction fee goes

A user signs a transaction in a wallet, and the base fee per signature is attached by default. If speed is important, the user can set a compute-unit price to add a priority tip. Validators then select transactions to fill a block, with higher tips receiving preferential treatment when the network is congested.

Once the transaction is included, 50% of the base fee is burned and 50% goes to the block producer. In addition, 100% of the priority fee now goes to the block producer. After finalization, the relevant program executes using the compute units that were budgeted.

What a new base-fee rule would change

The main proposal under discussion is a resource-based base fee, associated with SIMD-547. Instead of charging a flat amount per signature, the base fee would scale according to the resources a transaction consumes. In practical terms, the model would charge a small amount per unit of network cost rather than charging only once for a signature.

A flat base fee can keep spam inexpensive when the network is quiet and may not price complex calls precisely. A resource-based fee is intended to make the baseline cost reflect actual load, including compute, bandwidth, and possibly account locks. It could also create a more predictable burn mechanism and clearer incentives for validators.

Industry analyses 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 cited by BYDFi places the current burn near approximately 648 SOL per day and projects a range of about 10,800 to 64,800 SOL per day under higher parameter and throughput assumptions. The actual effect would depend on the per-unit price and network utilization.

Solana co-founder Anatoly Yakovenko has publicly signaled support for revisiting base-fee and burn mechanics, with resource-based fees described as part of a healthier market structure. His comments in early July have been cited in community discussions about fee policy, according to KuCoin. He has not publicly endorsed a specific parameter set.

Why validators supported SIMD-0096

Validators recently voted to keep 100% of priority fees. That change does not alter the base fee, but it is important for understanding incentives. During periods of heavy activity, the priority-fee market is the main real-time mechanism users can use to improve transaction inclusion. Allowing validators to receive all priority fees aligns block producers more directly with users seeking scarce blockspace.

SIMD-0096 reflects a preference for fee markets to manage surges rather than relying on ad hoc throttling. If validators earn more when demand for blockspace rises, supporters argue they have stronger incentives to invest in uptime and infrastructure. The rule also removes the previous ambiguity created when a portion of priority fees was burned, which made operator revenue less transparent.

However, SIMD-0096 does not resolve spam on its own. Low baseline costs can still encourage noisy activity. That is one reason a base-fee redesign remains under discussion. Without a resource-priced base layer, Solana continues to rely heavily on priority tips and localized fee mechanics to rebalance transaction queues.

Implications for users, validators, and SOL

For users and applications, a resource-based base fee could mean simple transfers look similar on most days, while complex calls that use more compute or lock many accounts may pay more by default. Users would still be able to add a priority bid during congestion, but a resource-based model could reduce situations where users face sudden delays because they failed to set a sufficiently high tip.

For validators and operators, priority fees now flow entirely to block producers. If the base fee also begins scaling with resource usage while retaining some burn component, validator revenue could become steadier across cycles. That would affect operating-expense planning and could reduce edge cases in which a high-compute transaction pays a large priority fee while contributing relatively little to the burn budget.

For SOL supply dynamics, a higher usage-linked base burn could increase burn during periods of high activity. That effect is not a trading signal, and burn is only one factor. Issuance, staking dynamics, and demand for blockspace also matter. Still, models that add cost-per-unit pricing to the base layer show burn rising by an order of magnitude during busier periods under certain assumptions.

How a base-fee change could move through governance

Solana’s on-chain governance system is designed for system-level changes such as fee rules. The process includes a minimum stake threshold for proposals, snapshot windows, and voting periods that produce an on-chain result.

A possible path for a resource-based base-fee proposal would start with a concrete specification covering parameters, caps, and the burn split. A proposer with at least 100,000 SOL staked would then be needed to open the vote. Supporters would likely publish simulations and parameter ranges showing user costs and validator earnings across different network-load scenarios.

A testnet pilot and stress tests could follow, after which parameters would be locked for mainnet consideration. If an on-chain vote passed, validators would need to coordinate a rollout height and client updates.

Voting power is controlled by staked SOL. That means validators, large delegators, and programs that manage pooled stake typically carry significant influence. The high proposal threshold is intended to limit frequent parameter changes and align major decisions with the operators responsible for running the network.

What to watch next

The next 1–2 quarters are expected to focus on parameters. The most difficult part of a resource-based base fee may not be the code, but the specific numbers: how many lamports to charge per unit, where to cap the fee, and whether any special cases should receive discounts. Drafts that compare real transaction bundles under different per-unit prices will be especially relevant.

Important signals include drafts or pull requests referencing SIMD-547 with concrete per-unit fee schedules; testnet metrics showing average cost per transaction by category, such as DEX swaps, NFT mints, and DeFi liquidations; validator statements similar to those seen during the SIMD-0096 vote; wallet updates that show compute budgeting and base-fee versus priority-fee breakdowns more clearly; and on-chain governance proposals opened under the new framework with the 100,000 SOL proposer requirement.

Risks and open questions

Several risks remain. Mispriced parameters could make everyday transactions noticeably more expensive without reducing spam. Validator revenue spikes could attract opportunistic operators without improving reliability. New fee rules could interact unexpectedly with local fee markets or account-locking behavior, creating different bottlenecks.

Governance concentration is another concern if a small number of large stakers push through an aggressive fee schedule. Wallet user experience may also lag, causing users to overpay priority fees on top of a higher base fee. Burn could be lower than expected if utilization assumptions do not materialize, reducing the intended supply impact. Smart contracts may also need updates if they assume fixed baseline costs.

Fee rules are systemic. Incorrect parameters would not only change who pays; they could also affect which users and developers can afford to build on the network.

Frequently asked questions

Is the new base-fee rule live on Solana?

No. As of late July 2026, Solana’s base fee remains a flat per-signature charge split 50% burned and 50% to validators, according to Solana’s documentation. The fee change approved in July concerned priority fees: under SIMD-0096, 100% of priority fees go to validators.

What would a resource-based base fee charge for?

The proposal direction is to charge a small amount per unit of network resource, mainly compute units and possibly other costs tied to account access. The goal is to align baseline costs with actual load instead of applying a uniform signature-based fee.

Who would pay more if the change passes?

Transactions that are compute-heavy or touch many accounts during busy periods would likely pay more. Simple transfers and efficient program calls may see little change in normal conditions. Priority bids would remain optional for users seeking faster inclusion.

When could a vote happen?

A vote could happen after a concrete specification is ready and a proposer with at least 100,000 SOL staked opens the proposal under the new governance system. No firm date has been set; timing depends on draft quality and validator alignment.

Could this make SOL deflationary?

A resource-based base fee could increase burn during high activity, but supply outcomes depend on issuance, staking, and demand for blockspace. Research estimates indicate a large burn increase under certain parameters, not a guaranteed result in all conditions.

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

Ethereum’s EIP-1559 base fee targets block fullness and burns that fee, with separate tips paid to miners or validators. Solana’s discussion is focused on charging by resource units consumed, with a policy decision still needed on how much is burned versus paid to validators.

Did Anatoly Yakovenko endorse a specific parameter set?

No. Yakovenko has signaled support for changing base-fee and burn mechanics, but specific per-unit prices and fee splits would need to come from community drafts and testing.

Source: CryptoDaily