Solana transaction fees come in two parts that behave nothing alike. The base fee is a flat 5,000 lamports per signature — about $0.00025 — charged on every transaction regardless of what it does, with half burned and half paid to the validator. The priority fee is optional, priced by you, and buys placement when block space is contested; since a governance vote in 2026 all of it goes to the block producer, none of it is burned. Almost every failed memecoin swap traces back to the second number being set too low, not to the first.

Key Facts

• Base fee: 5,000 lamports (0.000005 SOL) per signature, flat. A transaction with two signers pays 10,000.
• Base fee split: 50% burned, 50% to the validator that produced the block.
• Priority fee: optional, set in micro-lamports per compute unit, multiplied by the compute budget you request.
• SIMD-0096 passed with roughly 77% validator support and routes 100% of priority fees to the block producer — nothing burned.
• Fees are charged even when a transaction fails, as long as it was included in a block.
• Fees are always paid in native SOL. No SPL token, including wrapped SOL, can pay them.
• A base-fee redesign priced by resource usage rather than a flat per-signature charge has been under governance discussion through 2026.

The Base Fee Is Not the Interesting One

The base fee exists to make spam cost something. It is charged per signature, not per instruction, not per byte, and not per amount transferred — send 0.001 SOL or 10,000 SOL and the base fee is identical. That flatness is why Solana fees are quoted as a fraction of a cent and why the number barely moves regardless of network conditions. Half of it is burned, which permanently removes SOL from supply; the other half lands with the validator whose slot included the transaction.

Because it is denominated in SOL, the dollar cost drifts with price rather than with demand. That predictability is also its weakness: a flat per-signature charge does not reflect how much work a transaction actually asks the network to do, which is exactly the criticism driving current proposals to price the base fee by resource consumption instead. Whatever replaces it, the requirement that every transaction needs unstaked SOL to pay with does not change.

The Priority Fee Is an Auction

When a leader has more transactions than fit in its block, it orders them by how much they are paying per unit of compute. You set the priority fee as a price in micro-lamports per compute unit, and your actual cost is that price multiplied by the compute units you request. Two knobs, not one — this is why “I set a high priority fee and still failed” usually means a high price on a tiny compute budget.

	Base fee	Priority fee
Amount	5,000 lamports per signature	You choose, per compute unit
Optional	No	Yes
Varies with congestion	No	Yes, sharply
Who receives it	50% validator, 50% burned	100% validator
Effect on inclusion	None	Determines ordering
Charged on failure	Yes	Yes

The economics changed meaningfully with SIMD-0096. Before it, half of every priority fee was burned; now the full amount reaches the block producer. That strengthened validator revenue at the cost of one deflationary sink, and it sharpened the incentive to build blocks that maximise fee revenue — which is the same incentive that makes MEV extraction worth doing.

Why You Pay for Failed Transactions

Fees pay for execution attempted, not execution succeeded. A swap that reverts because slippage was exceeded still consumed validator resources — the transaction was decoded, the accounts were loaded, the program ran and returned an error — so the fee is taken. During a launch frenzy a trader can burn through a stack of small fees on failed attempts, which feels punitive but is exactly what prevents free retry spam from flooding the network.

The transaction that costs nothing is the one never included at all. If it never reaches a leader, or its blockhash expires while it sits in a queue, it simply disappears with no fee charged and no record. That is the difference between “failed” and “dropped”, and explorers show them differently: a failed transaction appears on Solscan with an error, while a dropped one was never there.

Setting Fees That Actually Land

Wallets and routers estimate priority fees from recent block data, which works fine in normal conditions and badly during the exact minutes that matter. When a token is trending, the fee level that cleared blocks thirty seconds ago is already stale. Practical approach: raise the priority setting deliberately when you know you are competing, keep the compute budget realistic rather than minimal, and accept that a few cents of priority fee is trivial next to missing a fill. Aggregators like Jupiter expose these controls directly, which is one reason routing through them beats hand-built transactions — the comparison between launchpad buying and aggregator routing comes down partly to how each handles fees under load.

What Fee Mechanics Mean for $DOLAN

DOLAN Duck ($DOLAN) has a fixed 98.3M supply, roughly 10,700 holders and a fair launch with no presale — meaning the earliest buyers had no protocol-level advantage over anyone else. What they did have, in practice, was fee discipline. On a fair-launch token the entire allocation race is decided by which transactions land in which slot, and that ordering is bought with priority fees, not privilege. Every one of those ~10,700 wallets paid the same flat base fee to get there, and the ones that filled during busy minutes paid more on top. Budget for it: keep a few tenths of a SOL unstaked purely as fee capital, separate from the amount you intend to trade with.