Solana is often evaluated by one number: transactions per second. That number is useful, but it hides a more important question for application developers:
What happens when one application suddenly becomes extremely popular?
A blockchain can process enormous volumes of transactions and still give developers a poor experience during periods of contention. If one application creates a bidding war for blockspace, unrelated applications should not necessarily have to compete for the same scarce resource.
This is where Solana's local fee markets become interesting.
The important innovation is not simply that Solana can process transactions quickly. It is that its account-based execution model gives the network a way to make congestion local to the state being contested.
That distinction matters far more than another TPS headline.
The Problem With Treating Blockspace as One Market
On a blockchain, transactions ultimately compete for finite execution capacity. The simplest model is a global fee market:
More demand → more competition → higher fees for everyone.
That model works reasonably well when the scarce resource is effectively shared across the entire network. But applications do not necessarily compete for the same state.
Consider two transactions:
- Alice swaps tokens through a heavily used DeFi protocol.
- Bob transfers USDC to another wallet.
If Alice's application suddenly attracts enormous demand, why should Bob's transaction become more expensive? The answer depends on how the blockchain models contention.
Solana's account model gives it an important property: transactions explicitly identify the accounts they read from and write to. This information allows the runtime to reason about which transactions can execute concurrently and which ones conflict over state.
That same property creates the foundation for localized fee markets.
Solana's Key Insight: Congestion Can Be Local
Solana's fee model has a base fee and an optional prioritization fee. The prioritization fee increases the likelihood that the current leader schedules a transaction ahead of competing transactions.
But the more interesting part is where the competition exists.
Suppose thousands of users are interacting with the same popular application and therefore competing for access to the same accounts. Those users have a reason to pay higher priority fees.
A completely unrelated transaction touching different accounts does not face the same contention.
This creates a much more granular model: Global congestion is not necessarily the same thing as application-level congestion.
Solana's own developer documentation uses an NFT mint as an example. Heavy demand for one collection can increase fees for users interacting with that application's accounts without imposing the same increase on unrelated transactions.
That is a subtle architectural consequence of Solana's account model. It is also why TPS alone tells an incomplete story.
The Transaction Scheduler Is Part of the Economics
This is where things get more interesting for developers.
A transaction does not simply arrive at a validator and get placed into a queue based on its fee. The validator's scheduler has to make decisions under resource constraints.
Transactions consume compute units, access accounts, and can conflict with other transactions attempting to modify the same state.
Solana therefore exposes compute-budget instructions that let developers specify a compute-unit limit and a price per compute unit. The current documentation specifies a maximum of 1.4 million compute units per transaction.
The prioritization fee is calculated from the requested compute-unit price and compute-unit limit:
prioritization fee = compute unit price × compute unit limit
Importantly, this is based on the requested compute-unit limit, not the amount ultimately consumed.
That creates a practical engineering consequence: Fee optimization is partly transaction-design optimization.
A developer who blindly requests excessive compute capacity can pay more than necessary while also giving the scheduler a less precise description of the transaction's resource requirements.
Local Fees Change How Developers Should Think About Congestion
This leads to a useful mental model.
Don't ask:
"Is Solana congested?"
Ask:
"Which state is congested, and does my transaction compete for it?"
That is a much better question for application developers.
Imagine a trading application with a highly contested market account.
During normal conditions, users may submit transactions with relatively modest priority fees.
During a burst of demand, users interacting with that market may start bidding for inclusion.
Meanwhile, a payment application operating on unrelated accounts can continue functioning without necessarily participating in the same bidding war.
The network has effectively separated two demand curves that would otherwise be treated as one.
That is the real value of local fee markets.
But Local Fee Markets Are Not a Free Lunch
There is an important limitation. Localizing fees does not create additional execution capacity.
If thousands of users want to modify the same state, that state remains a bottleneck. Local fee markets can make the competition more targeted, but they cannot make a fundamentally serial workload parallel.
This is one of the most important distinctions between scalability and congestion management.
A protocol might process a huge number of independent transactions in parallel while still struggling with a single highly contested account.
For protocol architects, that means account layout is not merely a programming concern. It becomes a scalability decision.
State Design Becomes Performance Design
Suppose an application funnels too much activity through a single writable account. That account can become a hotspot.
If the application's state can instead be partitioned across independent accounts without breaking its correctness or security model, more transactions may become executable concurrently.
This is one reason Solana's account model matters beyond its transaction throughput claims.
The way an application structures state can influence how well the network can parallelize its workload.
The blockchain's architecture and the application's architecture are therefore coupled.
What Developers Should Actually Optimize
For teams building on Solana, chasing TPS should not be the first optimization target.
A better workflow is:
- Identify writable accounts.
- Find which accounts become hotspots under load.
- Measure compute-unit consumption.
- Set an appropriate compute-unit limit rather than relying blindly on defaults.
- Use priority fees when contention actually requires them.
- Look for opportunities to partition application state.
- Test the application under contention, not only under normal traffic.
Solana recommends simulating transactions to estimate compute consumption and adding a safety margin when setting the compute-unit limit.
This is a better production mindset than simply advertising that an application can theoretically process thousands of transactions per second.
The Bigger Lesson
TPS measures how much work a blockchain can process.
Local fee markets tell us something different: how the cost of that capacity is allocated when demand becomes uneven.
That distinction will become increasingly important as blockchains host more applications with radically different workloads.
A chain does not just need more throughput. It needs mechanisms that prevent one application's demand from unnecessarily becoming everyone else's problem.
Solana's local fee markets are interesting precisely because they approach that problem from the execution layer.
The deeper lesson for blockchain architects is even more important: Scalability is not only about how much work a network can process. It is also about how intelligently the network separates competing workloads.
And that is a metric TPS will never capture on its own.