Local Fee Markets Explained: Congestion, Priority Fees, Inclusion

TL;DR

• Ethereum prices all block space through one base fee under EIP-1559, so one popular mint raises costs for every user.
• Solana caps each writable account at 40% of the block compute limit (SIMD-0306). At current 250ms slots, that is about 25M of a 62.5M CU block.
• During congestion, a Solana transaction can miss the leader entirely and expire after about 150 blocks.
• Priority fees set order inside the leader’s scheduler, while SWQoS controls whether the packet reaches that scheduler.
• Everstake offers SWQoS and ShredStream for teams that need predictable inclusion and faster confirmation data on Solana.

In a global fee market, one popular application could raise the price of block space for every user on the chain. Local fee markets price congestion per account, so heavy demand on one program leaves unrelated transactions near their normal cost.

Local fee market isolation is partial, because block compute and leader bandwidth remain shared by all traffic. Time-sensitive payments need inclusion before a deadline, and fee bidding alone leaves that outcome to probability.

Stake-weighted quality of service (SWQoS) and dedicated transaction paths act at the network entry point, before any fee comparison happens.

Global vs local fee markets

A global fee market sets one chain-wide price for block space, while a local fee market prices each piece of contested state. The model decides who pays when one application draws a traffic spike.

Ethereum introduced a protocol base fee through EIP-1559 on August 5, 2021, and every transaction in a block pays it. When one contract fills blocks, the base fee rises for all transactions, including unrelated payments.

Global fee pricing creates the noisy neighbor problem, where one application’s demand raises the price paid by unrelated users. The Otherside land mint by Yuga Labs on April 30, 2022 pushed daily average Ethereum gas above 800 gwei.

Decrypt estimated that users spent around $180M on gas during the Otherside mint.

Solana transaction lists the accounts it will read or write, and marks which ones it will modify, before it executes. Transactions that write to the same account run in sequence, stimulating fee competition around that account.

SIMD-0286 raised the block limit to 100M CU on July 29, 2026. Since then, slot-time reductions under SIMD-0525 have scaled it to 62.5M CU per 250ms block. SIMD-0306 sets the per-account cap at 40% of the block limit, about 25M CU today.

Example: token launch versus payroll batch

Assume a token launch saturates writes to one liquidity pool account on Solana. That pool can absorb at most 25M CU per block (40% of the 62.5M CU limit at 250ms slots), which leaves 37.5M CU for transactions touching other accounts.

A payroll batch of USDC transfers writes to sender and recipient token accounts and only reads the USDC mint. At the account level, the batch competes only with transactions writing those same token accounts, so its priority fee stays near baseline.

However, every transfer in the batch writes the same sender token account, so the batch’s own transactions cannot run in parallel and are processed in sequence. Large payroll runs can fund several source token accounts and split payouts across them, so no single sender account becomes the bottleneck.

Spike behavior	Global fee market (Ethereum)	Local fee market (Solana)
Price signal	One base fee per block	Priority fee per contested account
Unrelated payments	Pay the higher base fee	Pay near-baseline priority fees
Cap on one app/account	Block gas limit only	40% of the block limit
Base fee	Burned under EIP-1559	5,000 lamports per signature, 50% burned
Priority fee recipient	Block proposer	100% to the validator

How priority fees work on Solana

A Solana priority fee is an optional per-compute-unit payment that raises a transaction’s position in the leader’s scheduler.

For legacy and v0 transactions, the fee equals the compute unit price in micro-lamports multiplied by the requested CU limit, divided by 1,000,000.

Transaction v1, live since September 15, 2026, replaces this with a flat priority fee in lamports set in the message’s transactionConfig field.

A v0 transaction requesting 200,000 CU at 10,000 micro-lamports per CU pays a 2,000 lamport priority fee. With one signature, the 5,000 lamport base fee brings the total to 7,000 lamports, or 0.000007 SOL.

Solana charges priority fees on the requested CU limit, so a padded limit raises cost without adding priority. Simulating each transaction and setting the limit at measured usage plus some extra margin is typical.

What happens during blockchain congestion

Blockchain congestion occurs when demand for block space or leader bandwidth exceeds what the network processes per slot. Operators see it as transactions that land late or miss their validity window.

Solana faced heavy congestion in April 2024, during a wave of memecoin bot traffic. Dune data cited by Unchained showed 75.3% of non-vote transactions failed on April 4, 2024, alongside a QUIC networking issue.

Jon Wong of the Solana Foundation told Blockworks that failed transactions reflect smart contract logic, while dropped transactions signal congestion. Payment teams need separate monitoring for each, because the fixes differ.

Every Solana transaction references a recent blockhash that stays valid for about 150 blocks, roughly 40 seconds at today’s 250ms slots, and shorter once 200ms slots arrive. A transaction that misses that window is rejected and must be re-signed with a fresh blockhash.

Re-signing a pending payment with a fresh blockhash creates double-payment risk if both versions land.

Why payment traffic is the worst fit for fee auctions

Payments combine fixed deadlines with fixed fee budgets, and a fee auction favors whoever bids most at that moment. A payment operation cannot bid without limit, and it cannot land after its cutoff.

Deadline-bound payment traffic includes:

• Payroll batches, where every transfer must land before the published pay date.
• Card settlement, where banks settle obligations with a card network inside fixed windows.
• Liquidations, where collateral positions must close before prices move further.
• Treasury sweeps, where balances move between accounts before a daily cutoff.

Visa announced USDC settlement on Solana for U.S. banks on December 16, 2025, starting with Cross River Bank and Lead Bank. Its stablecoin settlement volume had passed a $3.5B annualized run rate by November 30, 2025.

For institutions, a missed settlement window becomes an operational incident with reconciliation work and possible contractual penalties. Payment blockchain scalability is therefore measured by landing rate and confirmation time at peak load.

Where local fee markets stop working

Local fee markets isolate the price of contested accounts, and shared resources stay shared. Three limits affect payment traffic during spikes.

Shared transaction throughput (TPS)

All transactions draw from the same block compute limit and the same leader bandwidth, whatever accounts they touch. At today’s 250ms slots, that limit is 62.5M CU per block. Under the earlier 60M CU limit, 11.2% of Solana blocks used 56M CU or more.

Network ingress is also shared across all accounts. The April 2024 Solana congestion was traced partly to QUIC connection handling, which operates before account-level pricing applies.

Hot state

A payment that writes to a contested account inherits that account’s price and delay. Common cases include routing a payment through a popular swap pool or writing to a shared program configuration account.

The per-account cap, set at 40% of the block limit, limits one account’s share of a block. At current slot times that is about 25M CU, and every transaction bidding for that account competes for the same 25M CU.

Cross-program contention

A composable transaction locks every writable account it touches across all programs it calls. One hot account anywhere in the instruction list sets the price and delay for the whole transaction.

Inclusion beyond fees: stake-weighted QoS and dedicated paths

Reliable inclusion comes from controlling the path into the leader and the data used to confirm results. Priority fees act only after a transaction reaches the leader’s scheduler.

Since Agave 4.0, Solana leaders no longer reserve fixed capacity for staked traffic. SWQoS now acts as a congestion backstop: when a leader’s TPU nears saturation, it prioritizes connections from staked validators according to stake. Unstaked traffic keeps full access when the network is not congested.

A validator can assign virtual stake to a trusted RPC node through the staked-nodes-overrides setting. Agave 4.0 reworks SWQoS into a dynamic, congestion-aware allocation model.

Tool	Stage it controls	What it addresses	What it leaves open
Priority fee	Scheduler ordering	Position among received transactions	Packet admission
SWQoS	Leader ingress over QUIC	Dropped packets during spikes	Order inside the block
ShredStream	Data delivery	Slow confirmation, blind retries	Inclusion itself
Durable nonce	Transaction validity	Double sends on retry	Landing speed

Everstake offers SWQoS access that routes whitelisted customer transactions through Everstake validator stake during congestion. Teams can compare tip-based and monthly plans for Everstake stake-weighted quality of service.

Everstake ShredStream streams raw Solana shreds from leaders ahead of standard RPC delivery. Faster visibility of landed transactions reduces blind retries and the duplicate sends they cause.

Everstake packages SWQoS and ShredStream within Blockspace by Everstake, the Solana inbound path sold as products.

Everstake has operated validator infrastructure since 2018 across 130+ networks to date.

Everstake reports 99.98% observed infrastructure uptime and holds SOC 2 Type II and ISO 27001 certifications. Institutions can assess the transaction path through the same vendor due diligence they apply to staking.

A payment team can raise landing rates during spikes with five steps:

1. Simulate each transaction and set the CU limit near measured usage.
2. Estimate priority fees from the accounts the transaction writes.
3. Send through a staked SWQoS connection during peak windows.
4. Track confirmations from shred-level data before retrying.
5. Use durable nonces or idempotency keys for payouts that must land once.

The alternative: separate the chain entirely

Separating the chain means running payments on an appchain or dedicated blockspace that no unrelated application shares. That design removes contention with other apps and adds trade-offs in validator operations and liquidity access.

The capacity argument appears in the case for more blockspace. The institutional argument for isolated chains appears in appchains and dedicated infrastructure for institutions.

FAQ

Why are gas fees high during an NFT mint?

Gas fees rise during an NFT mint because buyers compete for the same blocks within minutes. During the Otherside mint on April 30, 2022, Coin Metrics recorded daily average Ethereum gas above 800 gwei.

On Solana, local fee markets confine that bidding to the mint’s accounts. Validators cap each writable account at 40% of the block’s compute, so one mint cannot fill a whole block.

What is a local fee market?

A local fee market prices block space per account, so contention on one account raises fees only for transactions writing to it. On Solana, one writable account can use about 25M CU of a 62.5M CU block at today’s 250ms slots.

Does one app slow down the whole blockchain?

Yes, one app can slow a whole chain when it saturates shared resources such as block compute or leader bandwidth.

Local fee markets price contested accounts but leave leader bandwidth shared. Stake-weighted QoS protects that bandwidth during congestion.

How do Solana priority fees work?

For legacy and v0 transactions, the priority fee equals the compute unit price multiplied by the requested CU limit. At 10,000 micro-lamports per CU and a 200,000 CU limit, the fee is 2,000 lamports. Transaction v1, live since September 15, 2026, replaces the per-CU rate with a flat priority fee in lamports.

In both formats, the fee sets order in the leader’s scheduler and applies only after the transaction reaches the leader.

Why did my transaction fail during congestion?

During congestion, most missing transactions were never executed at all. They were dropped before reaching the leader, and their blockhash expired. A Solana blockhash stays valid for about 150 blocks, roughly 40 seconds at today’s 250ms slots.

Shred-level data shows whether a transaction landed sooner than standard RPC, so teams can check status before retrying and avoid duplicate sends.

How can I make transaction inclusion more reliable?

Inclusion becomes more reliable when account-aware priority fees are combined with a staked connection to the leader. During congestion, Solana leaders prioritize stake-weighted connections once their TPU nears capacity.

Everstake offers staked access through its SWQoS product, and faster confirmation data through ShredStream, both part of Blockspace by Everstake.