Solana transaction fees have two parts: a base fee of 5,000 lamports per signature and an optional prioritization fee that a sender sets per compute unit, per Solana's fee documentation. A lamport is 0.000000001 SOL, per Solana's terminology reference, so a one-signature transaction with no priority fee costs 0.000005 SOL. The fee is charged whether the transaction succeeds or fails, per Solana's fee structure page.
​

This page explains how each part is calculated, where the money goes, how compute units drive the priority fee, and how developers estimate a competitive price. Every formula and constant comes from Solana's documentation, fetched October 13, 2026, which pins its constants to the Agave client source code.
​

The total fee equals the base fee plus the prioritization fee. The base fee depends only on how many signatures the transaction carries. The prioritization fee depends on the compute unit price the sender chooses and the compute unit limit the transaction requests, not on the compute it actually uses.
​

The formulas are quoted from Solana's fee structure page. The signature count includes every Ed25519 signature on the transaction plus signatures verified by the Ed25519, Secp256k1 and Secp256r1 precompile programs, so a transaction that verifies extra signatures onchain pays for each one. The micro-lamport unit exists so the per-unit price can be tiny: 1,000,000 micro-lamports make one lamport, per the same page.
​

A priority fee is an optional extra payment that raises a transaction's place in the leader's scheduling queue. The sender sets it by adding compute budget instructions that name a price per compute unit and a compute unit limit. Without those instructions the price is zero and no priority fee is charged.
​

Per Solana's fee docs, the prioritization fee "increases the likelihood that the current leader schedules your transaction ahead of competing ones." The scheduler ranks transactions by reward * 1,000,000 / (cost + 1), where reward is the priority fee plus the validator's half of the base fee and cost is the scheduler's estimate of the work involved, per the fee structure page. A transaction that requests fewer compute units therefore ranks higher at the same fee.
​

Newer v1-format transactions skip the multiplication. In that format the priority fee is an absolute lamport total set in the message config, with no per-unit price and no rounding, per Solana's fee docs.
​

A compute unit is the runtime's measure of work: every arithmetic step, memory access and syscall costs a fixed number of them. Each transaction has a compute unit limit, either set explicitly or calculated from its instructions, and the priority fee is charged on that requested limit.
​

The fee structure page warns that the priority fee is based on the requested limit, not actual usage, so setting a higher limit than needed means paying for unused compute units. The compute budget page also notes that SIMD-0286 proposes raising the per-block limit to 100,000,000.
​

Working one transaction through the formulas shows how small the numbers are and why the compute unit limit matters. The inputs below are illustrative, not observed market prices; real priority prices move with demand and should come from a fee estimate at send time.
​

Both calculations apply the formulas and the 5,000-lamport base fee from Solana's fee structure page, and the SOL conversion uses the lamport definition in Solana's terminology reference. Trimming the limit to match real usage cut the priority portion by three quarters at the same price.
​

Developers estimate a competitive compute unit price from recent fees paid by transactions that touched the same accounts. Solana's RPC exposes recent samples directly, and several RPC providers sell estimation APIs that summarize those samples. Either way, the estimate should be taken just before sending.

A USDC or USDT transfer on Solana pays the same base and priority fees as any other transaction. The extra cost appears when the recipient has no token account for that mint yet, because creating one requires a refundable minimum balance on top of the fee.
​

Per Solana's token docs, creating an associated token account requires a refundable minimum balance for its storage, and the instruction's payer funds it even when another wallet owns the account. That deposit is not a fee: it stays in the account and can be recovered when the account is closed. Stablecoin specifics on Solana are covered in USDC on Solana and What Is SPL Token?, and a chain-level comparison is in Solana vs Ethereum.
​

Solana's fees are low and predictable at the base layer, but three details regularly catch developers out. Priority fees raise the odds of scheduling without guaranteeing it, failed transactions still pay, and an oversized compute limit quietly multiplies the priority fee.

0.000005 SOL per signature with no priority fee: 5,000 lamports, per Solana's fee docs.
​

Yes. Half of the base fee is burned; the priority fee is not, per Solana's fee structure.
​

Yes, per Solana's fee structure.
​

Zero. The default compute unit price is 0 micro-lamports, per Solana's docs.
​

On devnet, using free devnet SOL; see Solana devnet faucet.
​

Formulas and constants come from Solana's documentation, fetched October 13, 2026, which links each constant to the Agave v3.1.8 source. The worked example uses illustrative inputs; no transactions were sent.