Solana fees explained: calculate the cost of an operation

Start with SOL, lamports and the fee payer

One SOL equals one billion lamports. A fee of 5,000 lamports is 0.000005 SOL. A dollar estimate adds a market exchange rate; it is not a different network denomination.

Every transaction names a fee payer. That account supplies the network fee and signs under the applicable transaction rules. A payment app can sponsor processing, so its customer can approve an action while another account pays the fee.

The amount being transferred and the fee are separate quantities. A simple instruction sending 1 SOL asks the program to credit that amount to the recipient. If the sender is also the fee payer, its total debit includes the fee as well.

A wallet can hold valuable tokens and still lack SOL for an unsponsored operation. Diagnose the specific payer and required expense rather than assuming the total portfolio valuation can cover it.

The base component accounts for signatures

The base fee pays for chargeable signature verification. Solana's current fee documentation lists 5,000 lamports per chargeable signature. A common one-signer transaction with no additional signature-verification charges therefore has a 5,000-lamport base component.

A transaction can have several signers. Relevant signature-verification precompiles can also contribute chargeable signatures, so counting only the number of people looking at a wallet screen can miss part of the calculation.

For a teaching example, use one ordinary transaction signer and no charged precompile verifications. The base component is 5,000 lamports. A two-signer example under the same assumptions has 10,000 lamports before priority charges.

Use the final transaction message to estimate its fee. If the application changes the signer set or instructions during construction, an earlier estimate may no longer describe the message you will approve.

Legacy and v0 priority fees use the requested compute budget

A compute unit, or CU, measures metered runtime work. It is different from a second of time or a token amount. Programs consume units as the runtime executes operations.

For legacy and v0 transactions, the builder can choose a compute-unit limit and a price in micro-lamports per requested unit. The priority component is the price multiplied by that limit, divided by one million, rounded up to whole lamports.

Choose a 200,000-CU limit and 1,000 micro-lamports per CU for an arithmetic example. The priority component is 200 lamports. With the one-signer base example above, the network fee becomes 5,200 lamports, or 0.0000052 SOL.

Suppose execution uses 120,000 CU. Under this fee model, the priority calculation still uses the requested 200,000 limit. Doubling that limit while keeping the price unchanged doubles the priority component. Simulation helps a builder choose a relevant limit and margin.

The v1 transaction format configures an absolute priority-fee total in its message. Apply that format's rules instead of copying the legacy/v0 multiplication. See the transaction-version guide for the distinction.

Fees and account funding do different jobs

Paying priority changes scheduling, not program rules

A priority component influences scheduling among competing work. The actual path still depends on submission, account contention, validity and the program's conditions. An instruction that fails its authority or amount check continues to fail even if its fee is larger.

Estimate against the operation's relevant conditions. A transaction writing a busy shared account faces a different workload from an independent transfer. A provider's priority estimate should state what it measures and how recently it was observed.

For a user, start from the wallet's supported fee controls and the actual error. For a builder, retain simulation information, the chosen resources and the submission result so you can distinguish scheduling delay from execution failure.

A service can also add a tip or other payment. Read the instruction that makes it and keep it as its own cost category; a separately transferred tip does not automatically become the protocol's fee field.

Account funding stays separate from processing fees

Creating state can require a minimum lamport balance for the account. A first token transfer may include creating the recipient's token account. The payer then funds that account as well as paying the network fee.

Use the actual required size and current minimum balance for the account type. Builders can request the relevant rent-exempt minimum rather than hardcoding an amount copied from an old tutorial.

Let R represent the required funding for a newly created account. If a teaching transfer sends 1 SOL, pays the 5,200-lamport network fee above and funds that account, the payer must cover 1 SOL plus 0.0000052 SOL plus R, assuming no other debits.

The funded lamports are associated with the account. When its program permits closure, remaining lamports go to the specified destination under the close instruction. They do not automatically return to whoever originally paid. This is why account funding should not all be classified as a consumed processing fee.

Read the final cost from instructions and balances

Open the executed transaction and read its fee field. Then inspect transfers, account creation, closure and application-specific charges. Token trading fees can be taken from token flows and need separate asset units.

A swap involving wrapped SOL can close a temporary account and return its remaining lamports. That receipt can partly offset native SOL debits, making the net balance decrease smaller than the sum of outgoing payments. Reconcile both directions.

An execution failure can still pay its network fee. Application-state changes roll back under atomic execution, while special handling such as durable nonce advancement has its own rules. A send timeout alone does not establish that any fee was charged.

Builders can use getFeeForMessage for a supported message and current context. That estimate covers the network fee, not every application charge or account-funding requirement. If the method returns null or the message becomes stale, investigate its validity rather than using an old number as a paid amount.

Keep a cost record with named categories and units. For a payment, that can be amount delivered, network fee and setup funding. For a swap, add its trading costs and actual token output. The resulting explanation is much more useful than a single label reading transaction cost.

Common questions