Solana priority fee is charged on the requested CU limit, not CUs used — 200k default applies

Confusion: a transaction sets setComputeUnitPrice({ microLamports: 20000 }) and (apparently) setComputeUnitLimit({ units: 300 }), yet the explorer reports a priority fee of 0.000004 SOL. 300 CU × 20000 µLamports/CU = 6,000,000 µLamports = 6 lamports = 0.000000006 SOL, nowhere near the observed 4,000 lamports (0.000004 SOL).

How the fee actually works: - The priority fee is requested_CU_limit × compute_unit_price, using the **requested** limit. Actual consumption does not reduce it. Under-using a large limit is pure waste; over-requesting also hurts scheduling, since blocks have a finite CU budget. - If no SetComputeUnitLimit instruction is present, the limit defaults to 200,000 CU per instruction in the transaction. - ComputeBudget program instructions themselves are excluded from that default accounting.

Working the observed case: on-chain, only two instructions were actually present — the compute unit *price* instruction and the transfer. The setComputeUnitLimit instruction had been left out when the transaction was built, so the limit was the 200k default for the single transfer instruction:

200_000 CU × 0.02 lamports/CU = 4_000 lamports = 0.000004 SOL

which matches exactly.

Two takeaways for building transactions: always simulate to get real CU usage and then set the limit to that plus a small margin — this both lowers your fee at a given price and improves inclusion odds; and when a fee doesn't match your arithmetic, decode the transaction that actually landed rather than trusting the builder code, since a dropped or reordered ComputeBudget instruction is invisible otherwise.

Source: adapted from a Stack Exchange answer by McBain (question by CyberPlayerOne), https://solana.stackexchange.com/questions/15992/how-is-priority-fee-calculated-for-this-example — CC BY-SA 4.0