Every transaction on Solana costs a small amount of SOL. For most users, that cost is so small it barely registers – a simple transfer costs around 0.000005 SOL, which at $150 per SOL works out to roughly $0.00075. A token swap on Jupiter costs a little more. A complex DeFi transaction with multiple steps might reach a few cents. Compared to paying $5 to $50 in gas on Ethereum, the difference is substantial enough to change which financial operations are worth doing at all. This article explains what you actually pay, why Solana can charge so little, how the three separate fee components work, and what changed in early 2025 that most fee guides have not caught up on.
The short answer: what you actually pay on Solana
Solana fees are denominated in lamports, the smallest unit of SOL. One SOL equals one billion lamports. The numbers involved are small enough that most users never notice individual transactions, but understanding what drives the cost helps when transactions fail, when priority fees spike during a popular token launch or when a wallet asks you to approve a larger-than-expected fee.
The table below shows typical costs for common transaction types. These figures reflect base fees only. Priority fees and Jito tips, covered in the next section, can add to these amounts during high-demand periods.
| Transaction type | Typical cost (lamports) | USD at $150/SOL |
|---|---|---|
| SOL transfer (1 signature) | 5,000 | ~$0.00075 |
| Token transfer (SPL) | 5,000 + compute | ~$0.001 |
| Jupiter swap (simple) | 15,000 – 50,000 | ~$0.002 – $0.0075 |
| NFT mint | 20,000 – 100,000+ | ~$0.003 – $0.015 |
| Complex DeFi (multi-hop) | 100,000+ base + priority | $0.01 – $0.05+ |
The median Solana transaction fee across all transaction types in 2024 and early 2025 was approximately $0.0038, according to Token Terminal data. That figure includes periods of high congestion and complex program calls. Simple transfers cost far less.
The three fees on Solana: base fee, priority fee and Jito tip
When you approve a transaction in Phantom or Solflare, you might see a single fee number. Behind that number, up to three separate components can be present. Most users only ever encounter the first one. Understanding all three explains why some transactions cost more than others and what you can do about it.
Base fee: the fixed cost every transaction pays
The base fee is a fixed protocol charge applied to every signature in a transaction. The current rate is 5,000 lamports per signature. A standard single-signature transaction – sending SOL from one wallet to another – costs exactly 5,000 lamports regardless of network conditions, SOL price or how busy the network is at that moment. The base fee does not change with demand. It has been 5,000 lamports since mainnet launch and any change would require a network-wide governance vote.
Of those 5,000 lamports, 50% is burned permanently – removed from the circulating SOL supply. The other 50% goes to the validator that processed the transaction. This split applies only to the base fee. Multi-signature transactions – which are common in complex DeFi protocols – charge 5,000 lamports per required signature, so a transaction requiring three signatures costs 15,000 lamports in base fees alone.
One point that surprises many users: the base fee is charged even when a transaction fails. The validator performed the work of verifying signatures and checking the transaction, and that work gets paid regardless of whether execution succeeded. This is why you will see a small SOL deduction from your wallet even after an error message.
Priority fee: paying to move up the queue
The priority fee is optional and variable. Users who want their transaction processed faster – particularly during periods when many transactions are competing for the same block space – can attach a priority fee expressed in microlamports per compute unit. The total priority fee equals the microlamport price multiplied by the number of compute units the transaction requests.
During normal network conditions, a priority fee of zero works fine for most transactions. When a competitive NFT launch, a popular token airdrop or a sharp market move brings many traders into the network simultaneously, setting a higher priority fee increases the likelihood that a validator includes your transaction in the current block rather than a future one.
The current priority fee system is not a strict auction. A higher fee makes inclusion more likely but does not guarantee it – the scheduler runs multiple parallel threads and handles priority within each thread independently. Most modern wallets estimate the right priority fee automatically by checking recent blocks, so most users never need to set this manually. The compute budget can be increased up to a maximum of 1,400,000 compute units per transaction.
Jito tip: the direct payment outside the protocol
The third component is the most misunderstood. A Jito tip is a direct payment to a validator running the Jito-Solana client, made outside the standard protocol fee mechanism. Where priority fees go through the Solana scheduler, Jito tips go through a separate system called the Jito block engine, which runs an off-chain auction every 200 milliseconds.
Jito bundles allow users to package up to five transactions into an atomic group – either all five execute in sequence or none of them do. The block engine auctions the right to include that bundle in the next block, and the winning bid is the Jito tip. The minimum tip is 1,000 lamports.
As of early 2026, roughly 95% of staked SOL is on validators running the Jito client. This means Jito tips are effectively available across almost the entire network. For users, the practical implication is straightforward: for a simple SOL transfer or a routine token swap, a Jito tip is unnecessary. For time-sensitive operations where bots may front-run you, for complex multi-step DeFi where partial execution would be worse than no execution, or for competitive mints where dozens of wallets submit identical transactions simultaneously, a Jito tip provides meaningful advantages that priority fees alone cannot.
To understand more about how Solana processes transactions at the validator level, including how blocks are assembled and propagated, the network architecture provides important context for why these three fee components exist as separate mechanisms.
Why are Solana transaction fees so low?
The cheapness of Solana fees is not a subsidy or a temporary promotional structure. Low fees follow directly from architectural decisions that allow Solana to process far more transactions per second than older networks, which keeps supply of block space high relative to demand.
Proof of History removes coordination overhead
Proof of History is a cryptographic timekeeping mechanism that gives every validator on the network an independent, verifiable record of transaction order. On networks like Bitcoin and Ethereum, validators must communicate extensively with each other to agree on which transactions happened first before processing them. That communication takes time, which limits throughput and forces the network to charge higher fees to allocate scarce block space.
Because Solana validators can verify the order of transactions without waiting for peer agreement, they spend far less time on coordination and far more time on actual processing. That higher processing rate per unit of time is one of the primary reasons Solana gas fees stay low even as transaction volume grows.
Parallel processing means more capacity for the same cost
Solana’s Sealevel runtime executes transactions in parallel across multiple CPU cores. Because every Solana transaction must declare upfront which accounts it will read and which it will write, the scheduler can identify transactions that touch completely separate accounts and run them simultaneously. A USDC transfer and a Raydium swap that involve entirely different accounts execute at the same time on different cores.
On Ethereum, the EVM processes transactions one at a time regardless of how many cores the validator hardware has. Sequential execution creates a hard ceiling on throughput. Sealevel removes that ceiling, increasing the supply of processing capacity and keeping the per-transaction cost down.
Local fee markets mean one congested app does not affect the rest
This is the architectural point that most fee guides underexplain. Ethereum uses a global fee market – when one popular application floods the network with transactions, fees rise for everyone. If a popular NFT mint saturates Ethereum, you pay more to send a simple ETH transfer that has nothing to do with the mint.
Solana uses local fee markets. Congestion and fee pressure are isolated to the specific program accounts being contested. If Pump.fun is overwhelmed with activity, priority fees for Pump.fun transactions rise. Your USDC transfer, your staking delegation and your Jupiter swap on a different pool are not affected. That isolation is one of the concrete reasons why Solana fees stay predictable for most users even when parts of the network are under stress.
What happens to the fees you pay: the burn and the validator split
Fee revenue on Solana does not all go to the same place, and the rules changed in early 2025 in a way that affects SOL’s long-term supply dynamics. Understanding the split matters if you hold SOL or stake it.
Base fee: 50% burned, 50% to the validator
The base fee split has been consistent since mainnet launch. Half of every base fee is burned – permanently removed from circulation. The other half goes to the validator that produced the block. This burn mechanism creates a deflationary counterforce against Solana’s inflation schedule. In periods of very high transaction volume, the burn rate can offset a meaningful portion of new SOL issuance.
The SOL burn from base fees is transparent and verifiable on-chain. Tools like Solana Compass track real-time fee revenue and the daily burn figure. In high-activity periods during 2024, the network burned several thousand SOL per day from base fees alone.
Priority fee: what changed on February 12, 2025
Before February 2025, priority fees followed the same 50/50 split as base fees – half burned, half to the validator. SIMD-0096, a Solana governance proposal that passed with 77.7% validator support, changed this. From February 12, 2025, 100% of priority fees go directly to the validator that includes the transaction. Nothing is burned.
The reasoning behind SIMD-0096 was economic: burning priority fees created an incentive for validators to make side deals with high-volume trading firms, accepting payments outside the protocol to avoid the burn. Routing 100% to validators through the protocol removes that incentive and makes the fee mechanism more transparent. The base fee burn is unchanged.
A companion proposal, SIMD-0123, passed in March 2025 and added an automatic distribution mechanism so that stakers – not just the operating validator – receive a share of priority fee revenue proportional to their delegated stake. This changed the economic relationship between validators and delegators in a way that benefits long-term SOL holders who stake through delegating rather than running their own nodes.
What SIMD-0096 means for SOL supply
Because priority fees no longer burn, the effective SOL burn rate dropped after February 2025. During periods of high priority fee activity – competitive mints, market volatility spikes – a significant amount of SOL that previously would have been destroyed now stays in circulation and goes to validators. Network-level inflation moved from approximately 3.7% to around 4.6% in the months following the change, before Solana’s standard inflation schedule continued its annual 15% decline. For SOL holders, this is a modest negative for price pressure from deflation but a positive for validator security incentives. For stakers, SIMD-0123 means more direct exposure to network fee revenue. For more on how SOL’s tokenomics work including inflation, staking rewards and the burn rate, the full breakdown is worth reading alongside this fee guide.
How compute units determine what your transaction costs
The base fee covers the cost of verifying your signature. The actual cost of executing your transaction – running the program logic – is measured in compute units. Every operation a Solana program performs consumes compute units: reading an account, doing arithmetic, calling another program through Cross-Program Invocation. The more complex the transaction, the more compute units it consumes.
What compute units measure
Each transaction is allocated a compute budget – a limit on how many compute units it can consume. The default limit is 200,000 compute units. A simple SOL transfer uses a few hundred compute units and never gets close to that limit. A Jupiter swap routing through multiple pools might use 150,000 to 300,000. A complex liquidation or a transaction involving many program calls can exceed 600,000.
The priority fee, when set, is expressed as a price per compute unit in microlamports. If you set a priority fee of 10,000 microlamports per compute unit and your transaction uses 200,000 compute units, the priority fee is 2,000,000 microlamports, or 2,000 lamports on top of the 5,000 lamport base fee. The maximum compute budget per transaction is 1,400,000 compute units, set via a Compute Budget instruction.
Why a failed transaction still charges a fee
When a transaction fails – because it exceeded its compute budget, because a smart contract condition was not met or because slippage exceeded the user’s tolerance – the base fee is still charged. The reason is straightforward: validators performed real work to verify the transaction’s signatures and load the accounts before discovering the failure. That work gets paid. The compute units consumed up to the point of failure also determine the priority fee charged, capped at the requested budget.
The practical consequence: if a DeFi transaction fails during a competitive period where you set a high priority fee, you may lose more than just the base fee. Setting a compute budget that is too low – a common cause of failure – wastes the base fee and any priority fee attached up to the point of failure. Most wallets and DeFi frontends now estimate compute requirements automatically and add a margin, which is why the compute limit in your wallet approval screen is often set higher than the transaction actually needs.
How to set the right compute budget
For most everyday transactions, you do not need to touch compute settings manually. Wallets like Phantom and Solflare auto-estimate both the compute limit and the appropriate priority fee based on recent network data. Where manual adjustment matters is in competitive situations: if you are participating in a token launch where thousands of transactions compete simultaneously, raising the compute limit and the microlamport price increases your chances of landing the transaction in the target block.
RPC providers like Helius offer a Priority Fee API that analyses recent blocks for specific program accounts and returns a recommended fee level. This is more accurate than a flat estimate because it accounts for local demand on the specific program you are calling rather than network-wide averages. For how Solana programs and accounts work – which directly affects compute unit consumption – the architecture behind these costs is worth understanding.
Jito tips explained: what they are and when you actually need one
The standard fee mechanism – base fee plus priority fee – routes through Solana’s built-in scheduler. Jito tips route through a completely separate system. Understanding the difference tells you when each mechanism is worth using.
How Jito works differently from the standard fee queue
Jito Labs developed a modified version of the Solana validator client called the Jito-Solana client. Validators running this client participate in a secondary block space market called the Jito block engine. The block engine runs an off-chain auction every 200 milliseconds, accepting transaction bundles from users and searchers and selecting the highest-paying bundle to include at the front of the upcoming block.
A Jito bundle is a group of up to five transactions that execute atomically – all of them succeed or none of them do. When you submit a bundle with a Jito tip, you are paying to guarantee that your specific sequence of transactions lands in a specific position in the block without any other transactions inserted between them. This is valuable for operations where the order of execution matters or where a partial result would be harmful.
MEV – maximal extractable value – is the reason Jito exists. Arbitrage bots and searchers compete intensively to place transactions at optimal positions in blocks. Jito provides the infrastructure for that competition to happen through an explicit auction rather than through spam. Searchers submit bundles with Jito tips; the highest bidder gets priority. Validators running Jito earn more fee revenue per block because they capture tip auction proceeds on top of standard fees.
When a Jito tip helps and when it does not
For ordinary users, Jito tips are relevant in specific situations:
- Competitive token launches and mints: when hundreds of wallets submit identical transactions, a Jito bundle with a tip can secure a position at the front of the block, ahead of bots and other users.
- Multi-step DeFi where partial execution is dangerous: bundling a borrow, a swap and a repay atomically guarantees they all execute or none do, preventing a situation where the borrow succeeds but the swap fails, leaving you with an exposed position.
- Arbitrage and liquidations: these are time-sensitive and order-dependent. Jito bundles are designed for exactly this use case.
- MEV protection: certain Jito-aware wallets and aggregators use bundles to prevent sandwich attacks, where bots insert buy and sell orders around your swap to profit at your expense.
For a simple SOL transfer, staking delegation or routine token swap during normal network conditions, a Jito tip adds cost without meaningful benefit. The minimum tip is 1,000 lamports (0.000001 SOL). In competitive situations, effective Jito tips often run between 0.001 SOL and 0.1 SOL depending on the value of securing the position.
Why Jito tips now account for a majority of non-base fees on Solana
In 2024 and into 2025, Jito tip volume grew to represent over 60% of non-base fee revenue on Solana. The reason is the memecoin trading surge. During periods of intense activity on Pump.fun and similar platforms, bots and traders compete aggressively for block position. The most effective tool for that competition is a Jito tip rather than a protocol priority fee, because Jito tips buy deterministic ordering through the auction rather than a probabilistic position in the scheduler queue.
This also means that MEV on Solana is increasingly explicit rather than hidden. On Ethereum, MEV extraction happens through opaque bundle auctions that most users never see. On Solana, Jito’s public auction structure makes tip revenue visible on-chain and attributable to specific validators and block positions.
Stake-weighted Quality of Service: why your wallet and RPC matter
Even with the right base fee, priority fee and Jito tip, a transaction can still fail to land if it never reaches the validator. Stake-weighted Quality of Service (swQoS) is the mechanism that determines how much network bandwidth different nodes receive for forwarding transactions to the current block leader.
Validators allocate incoming transaction bandwidth proportionally to the stake weight of the node submitting the transaction. Nodes with higher stake get reserved capacity. Those with zero stake – which includes most public RPC endpoints – get whatever bandwidth is left over after staked nodes are served. During congestion, unstaked nodes can be effectively frozen out.
The practical consequence for users: if your wallet connects to a public RPC with no stake, your transactions may fail to reach the validator during high-demand periods regardless of your priority fee. Wallets and DeFi applications that pay for staked RPC access – Helius, QuickNode, Triton and similar providers maintain validator relationships – give your transactions a higher probability of landing without needing a high priority fee. This is why the choice of wallet infrastructure sometimes matters more than the fee setting itself.
Solana transaction fees compared to Ethereum and Layer 2 networks
The comparison that most users care about is Solana against Ethereum. The gap at the base layer is significant and has remained consistent even as both networks have evolved. Solana gas fees at L1 are roughly 40 times lower than Ethereum L1 on a median transaction basis.
| Network | Median fee (2026) | Fee market type | Bridging required |
|---|---|---|---|
| Ethereum L1 | ~$0.15 | Global (EIP-1559) | No |
| Arbitrum | ~$0.013 | L2 rollup | Yes (from ETH L1) |
| Base | ~$0.011 | L2 rollup | Yes (from ETH L1) |
| Solana | ~$0.0038 | Local (per-program) | No |
| Optimism | ~$0.0008 | L2 rollup | Yes (from ETH L1) |
The Layer 2 comparison is worth examining carefully. Optimism’s median fee is lower than Solana’s, but using Optimism requires bridging assets from Ethereum L1, which costs gas and takes time. The liquidity on Optimism for any given token is a fraction of what exists on Solana. A DeFi trade on Solana can atomically touch multiple protocols in one transaction. The equivalent on a Layer 2 cannot cross to another Layer 2 without bridging, which adds cost, delay and counterparty risk.
Solana vs Ethereum fees at the L1 level is not a close comparison: Ethereum L1 costs roughly 40 times more per median transaction. The more honest comparison is Solana versus Ethereum’s Layer 2 rollups, where Solana’s native composability and single-chain liquidity partially offset any fee disadvantage against the cheapest rollups. For more background on what Solana is and how it approaches scalability at the base layer, the architectural context behind these fee differences is worth reading.
Hidden fees: rent deposits and what they cost
Not every SOL deduction from your wallet is a transaction fee. Rent on Solana is a refundable deposit charged when a new account is created on-chain. Every account must hold a minimum SOL balance proportional to the data it stores to remain rent-exempt – if the balance drops below this threshold, the account can be reclaimed by the network.
The most common rent deposit users encounter is the token account deposit. When you receive a token you have never held before, a new token account must be created to store your balance. This costs approximately 0.002 SOL (2,039,280 lamports) at current rent rates. That deposit is not a fee – it comes back to your wallet in full when you close the token account. Wallets like Phantom include a “burn and collect” or “close account” feature specifically for reclaiming these deposits from tokens you no longer hold.
The same logic applies to opening positions in DeFi protocols, creating stake accounts and deploying programs. Each new account costs a deposit. Complex transactions that create several new accounts can appear to cost significantly more than their raw fee suggests, because the rent deposits are lumped in with the fee in many wallet approval screens.
Will Solana fees stay this low?
The current fee structure has two known pressure points. The first is demand: if Solana’s transaction volume grows faster than throughput improvements, base fee pressure and priority fee competition will increase. The Firedancer validator client from Jump Crypto, currently in staged rollout, targets throughput significantly higher than the current Agave client, which would increase block space supply and reduce fee pressure. The Alpenglow consensus upgrade, expected in 2026, changes how blocks are produced and propagated in ways that could alter fee dynamics further.
The second pressure point is economic design. There is ongoing discussion within the Solana developer community about introducing a dynamic base fee similar to Ethereum’s EIP-1559 mechanism, which adjusts automatically based on recent block utilisation. A proposal along these lines (SIMD-0228) was voted on in March 2025 and did not pass, receiving 43.6% validator support – short of the two-thirds threshold required. The discussion continues, and future governance proposals may revisit dynamic pricing.
For most users, the near-term outlook for Solana transaction fees is stable. The combination of Sealevel parallel processing, local fee markets and incoming throughput improvements from Firedancer means supply of block space is growing alongside demand. Jito tip auctions will continue to capture value from competitive block positions, but routine transfers and straightforward swaps are unlikely to see meaningful fee increases in the absence of a structural change to the protocol. For full context on the team behind Solana and how protocol decisions are made, understanding the governance structure helps frame how fee changes get proposed and voted on.
Frequently asked questions
What is the average Solana transaction fee?
The median Solana transaction fee across all transaction types in 2024 and early 2025 was approximately $0.0038. Simple SOL transfers cost around $0.00075 at $150 per SOL. Complex DeFi transactions with priority fees can reach $0.01 to $0.05. The base fee is fixed at 5,000 lamports per signature regardless of network activity.
Why does Solana charge fees in lamports?
Lamports are the smallest unit of SOL, named after computer science pioneer Leslie Lamport. One SOL equals one billion lamports. Fees are expressed in lamports because the amounts involved are too small to express usefully in whole SOL. The base fee of 5,000 lamports equals 0.000005 SOL – a number that requires lamport precision to communicate clearly.
What is the difference between a base fee and a priority fee on Solana?
The base fee is a fixed charge of 5,000 lamports per signature, paid for every transaction regardless of conditions. It is split 50% burned and 50% to the validator. The priority fee is optional and variable, paid in microlamports per compute unit. It goes entirely to the validator since February 2025. The base fee buys the right to submit a transaction. The priority fee increases the probability of faster inclusion during congestion.
What is a Jito tip and is it the same as a priority fee?
No. A priority fee routes through Solana’s built-in scheduler – it makes your transaction more likely to be included but does not guarantee ordering. A Jito tip is a direct payment to a validator running the Jito-Solana client, processed through an off-chain auction every 200 milliseconds. Jito tips allow atomic bundles of up to five transactions and buy deterministic ordering within a block. For simple transactions, a priority fee is sufficient. For competitive mints, MEV-sensitive trades or complex multi-step operations, a Jito tip provides stronger guarantees.
Why did my Solana transaction fail but I still paid a fee?
The base fee is charged for the validator’s work of verifying signatures and loading accounts, which happens before execution begins. That work gets paid regardless of whether execution succeeds. If your transaction failed because it exceeded its compute budget, because a smart contract condition was not met or because slippage tolerance was breached, the base fee and any priority fee consumed up to the point of failure are still deducted.
What is SIMD-0096 and how did it change Solana fees?
SIMD-0096 was a governance proposal that passed on February 12, 2025 with 77.7% validator support. Before SIMD-0096, priority fees followed the same 50/50 split as base fees – half burned, half to the validator. After SIMD-0096, 100% of priority fees go to the validator that includes the transaction. The base fee burn of 50% was not changed. The effect was to reduce the total SOL burned per transaction and increase validator revenue from priority fees.
Does Solana burn transaction fees?
Partially. 50% of the base fee is permanently burned on every transaction. This has been the rule since mainnet launch and was not changed by SIMD-0096. Priority fees are no longer burned – since February 2025 they go entirely to validators. Jito tips were never subject to the burn mechanism. So for a transaction with all three fee components, only the base fee contributes to supply reduction.
What is a compute unit on Solana?
A compute unit is the measure of computational work required to execute a transaction. Every operation a program performs – reading an account, doing arithmetic, calling another program – consumes compute units. The default limit per transaction is 200,000 compute units. Complex DeFi transactions can require 600,000 or more. The maximum is 1,400,000. Priority fees are set as a price per compute unit in microlamports, so the total priority fee cost depends on both the microlamport price and the number of compute units consumed.
Why are Solana gas fees so much lower than Ethereum?
Three architectural factors drive the difference. First, Proof of History lets validators agree on transaction order without constant peer communication, which increases processing speed. Second, the Sealevel runtime executes non-conflicting transactions in parallel across multiple CPU cores, where Ethereum’s EVM processes one transaction at a time. Third, local fee markets on Solana isolate congestion to the specific programs being contested, so a popular NFT launch does not raise fees for unrelated transfers. On Ethereum, one congested application raises costs for the entire network.
What is rent on Solana and is it a fee?
Rent is a refundable deposit, not a fee. Every account on Solana must maintain a minimum SOL balance proportional to the data it stores. A token account holding an SPL token balance requires approximately 0.002 SOL. That deposit is returned in full when the account is closed. It does not go to validators or get burned. The confusion arises because wallet approval screens sometimes combine rent deposits and transaction fees into a single SOL amount.
Does setting a higher priority fee guarantee my transaction lands first?
Not strictly. The current Solana scheduler runs multiple parallel threads, and priority fees operate within each thread independently. A transaction with a higher priority fee is more likely to be included in the next block but is not guaranteed a specific position. True ordering guarantees require a Jito tip and bundle submission, which goes through the Jito block engine’s explicit auction rather than the standard scheduler.
What is stake-weighted Quality of Service on Solana?
Stake-weighted Quality of Service (swQoS) is a mechanism that allocates transaction forwarding bandwidth proportionally to the stake weight of the submitting node. Validators reserve bandwidth for high-stake nodes and process their transactions first. Wallets and applications that use RPC providers with significant stake get their transactions forwarded more reliably to block leaders, particularly during congestion. Users of public zero-stake RPC endpoints may find their transactions dropped during high-demand periods regardless of the priority fee attached.
