Solana transaction fees have two core components:
The base fee is at 5,000 lamports per signature, with prioritization fee used to increase scheduling likelihood under competition. This structure is why many users experience Solana as “cheap.” The base fee is small, and simple transactions often do not need a high prioritization fee.
The sudden “not cheap” moments usually come from the second component.
Prioritization fees are not a fixed surcharge. They are a bid that competes with other transactions for inclusion.
The key operational detail is how the prioritization fee is calculated. The priority fee is based on the requested compute unit limit, not the actual compute units used. That means fee bidding is intertwined with compute budgeting.
Compute units (CUs) are Solana’s meter for program execution cost. Transactions request a compute budget, and prioritization fee is charged per requested CU.
Solana’s maximum compute budget stands at 1,400,000 compute units per transaction. Two fee failure patterns show up repeatedly:
Over-requesting compute: If a transaction requests far more compute than it needs, the user pays priority fees on the unused portion because billing is based on the requested limit. This can turn a “cheap” transaction into an unexpectedly expensive one, especially when CU price is high.
Under-requesting compute: If a transaction requests too little compute, it can fail at execution even if the priority bid is high. This is a compute exhaustion failure, not a fee market failure.
Solana frequently describes its fee market design as local rather than global. The payments documentation describes local fee markets as each program’s transactions competing primarily with other transactions targeting the same state, which is intended to keep unrelated transaction flows from being priced out by activity elsewhere.
In practice, the “state” that drives contention is often:
When many transactions try to write to the same accounts, they cannot be processed fully in parallel. Inclusion and ordering pressure becomes concentrated, and the effective fee market for that slice of state becomes expensive.
This is the regime where users feel that Solana’s fees are no longer cheap. Not every transaction is expensive at the same time. Transactions that touch non-contended state can remain cheap even while one popular app becomes extremely costly to use.
Some transactions include account creation as a side effect.
This can produce a “why did this cost so much” moment for new token holders. The cost is not the fee market. It is the rent-exempt reserve placed into a new onchain account.
Launch-day congestion: NFT mints, token launches, and airdrops generate bursty demand. Users and bots push CU prices upward to land sooner.
Hot DeFi state: A single popular pool or program can create localized contention. Local fee markets concentrate the bidding on that state.
Retry storms: Wallets and bots retry aggressively when transactions do not land. Retrying increases load and can amplify fee spikes.
Over-sized compute budgets: Over-requested compute multiplies priority fee cost because billing is based on requested CU limit.
Solana “fee market” problems are usually reliability problems. Reliable sending is a workflow.
Right-size the compute budget: Simulate the transaction, observe compute usage, then set the compute unit limit slightly above observed usage. This reduces out-of-compute failures and reduces overpayment because priority fees are based on requested compute limit.
Bid with compute unit price, not guesswork: Most wallet “priority” sliders map to a compute unit price setting. Under congestion, the correct price changes quickly. Priority fees are increasing the chance the leader schedules a transaction ahead of competing ones but is not guaranteed.
Avoid unnecessary side effects: If a transaction can be simplified, it often becomes cheaper and more reliable. Examples include:
Watch the actual failure reason: “Transaction failed” can mean many things:
Treating all failures as “increase priority fee” is a common and expensive mistake.
Base fee and signature count: Base fee is per signature, and Solana’s fee doc lists 5,000 lamports per signature as the base fee. Multi-signer transactions can cost more even before priority fees.
Whether the transaction sets a priority fee: Wallets may set a compute unit price automatically. If the transaction is time-sensitive during congestion, a zero priority fee is often unreliable.
Requested compute limit: A very high requested compute limit can be a hidden cost multiplier because priority fee billing is based on requested limit, not actual usage.
Whether account creation is included: Account creation adds a rent-exempt reserve cost separate from transaction fees. If the action is optional, account creation can be moved to a quieter time.
Solana’s “cheap fees” experience is driven by a small base fee per signature and the ability for many transactions to clear with low priority bids. The fee spikes that surprise users are typically priority fee auctions under congestion plus localized contention on popular state, and the economics can be amplified when a transaction over-requests compute because priority fees are based on requested compute limit rather than actual usage.
A stable workflow treats Solana fees as two separate controls: compute budgeting and priority bidding. Right-size compute limits, bid for priority only when the action is time-sensitive, recognize that local fee markets concentrate costs around hot accounts and programs, and account for rent-exempt reserves when the transaction creates new accounts.
The post Solana Fee Markets Explained: When “Cheap Fees” Suddenly Aren’t appeared first on Crypto Adventure.
