What priority fee should you pay?

What we measure

Rather than estimate, we read what was actually paid. A weekly job pulls finalized blocks, reads the fee charged on every transaction, and subtracts the fixed base fee to isolate the priority component.

The base fee on Solana is 5,000 lamports per signature. Anything above that on a single-signature transaction is priority payment, so the arithmetic is direct rather than inferred. Percentiles are computed across the raw values, and the block range and sample size are published alongside the result on the measured data page.

The reason to do this rather than cite an estimator is that estimators tell you what they think you should pay. This tells you what the network actually charged, which is a different and more checkable question.

The distribution is a long tail

The consistent finding across samples is that priority fees are not a toll everyone pays. They are a bidding war that most transactions sit out entirely.

A large majority of transactions in our samples pay no priority fee at all. Of the remainder, the amounts climb steeply through the upper percentiles, so that the ninety-ninth percentile pays orders of magnitude more than the seventy-fifth.

That shape has a simple explanation. Most Solana activity is not competing for anything. It happens when the network has capacity, it gets included promptly on the base fee, and paying more would buy nothing. The transactions paying heavily are the ones contesting a specific moment, and there are not many of them relative to the whole.

Why the median misleads

Given that distribution, the median is close to useless as guidance, and it is exactly what a naive summary would report.

The median describes the typical transaction, which is one that was not competing for anything. If you are competing, which is the situation in which the question arises at all, the median describes everyone you are not competing with. Setting your fee there during a contested minute means being outbid by every participant who cared.

The opposite error is equally available. Reading the top percentile and paying that on every transaction means paying launch-auction prices on a quiet Tuesday afternoon, hundreds of times, for a position nobody was contesting.

The useful reading of the distribution is not a number at all. It is the recognition that the correct value is conditional, and that any fixed setting is wrong most of the time in one direction or the other.

Under-paying costs more than over-paying

The asymmetry here is the practical heart of the question and it is worth making concrete.

A transaction that misses inclusion has paid its base fee and produced nothing, and if it waits long enough its blockhash expires and it is rejected entirely. Against that, the incremental cost of a healthier priority fee is very small in absolute terms. The fee breakdown puts both numbers alongside the venue costs that dwarf them, which is the context that makes over-paying obviously the cheaper mistake.

There is a second asymmetry that reinforces the first, and it concerns what happens to your competitors' fees. During a genuinely contested moment, everyone raising their bid raises the clearing level without changing how many transactions fit in a block. That means escalation is only worth it if you specifically need to be in that block, which is a launch-sniping requirement rather than a campaign one. A campaign that simply waits for a calmer minute pays nothing extra and loses nothing it cared about, which is an option a race does not have.

Picking a number

1. Read a live estimate rather than a figure from any article, including this one.
2. Check the levels rather than a single value. Estimators publish several tiers, and the spread between them tells you how contested the moment is.
3. Decide what you are competing for. A deadline justifies the upper tiers; a campaign spread across hours does not.
4. Remember the limit multiplies it. The priority fee is the compute unit price times the requested limit, so a generous limit raises what any price costs you, which the compute units explainer covers.
5. Re-read during the run. Conditions move, and a value set an hour ago describes an hour ago.

One detail about how the fee is actually charged is worth knowing, because it changes the risk calculation during bad periods. The priority fee is paid whether the transaction succeeds or fails, since the validator processed it either way. That means an aggressive fee on a run with a high failure rate is money spent twice over: once on the priority you paid for, and once on the swap that did not happen. On venues where failures are structurally common, the sensible response is usually to reduce swap size rather than to escalate the fee, because the first lowers the failure rate and the second only raises the cost of each failure.

What changes for a campaign

Two things distinguish a campaign from a single trade, and both push the sensible answer downward rather than upward.

There is no deadline. A campaign produces activity across a window. No individual swap has to land in a particular block, which removes the entire justification for the upper tiers. Paying launch-grade fees on hundreds of routine swaps is one of the more common and least visible ways to double a bill for nothing.

The multiplier is large. A generous fee that seems trivial on one transaction is being applied hundreds or thousands of times. That does not make it wrong, but it does mean the decision deserves more thought than the per-transaction amount suggests.

The balance most campaigns want is a fee comfortable enough that transactions land reliably without waiting, adjusted for conditions during the window, and nowhere near the levels that a contested launch commands. Setting it once and never revisiting it is the error, in either direction, and it is the reason this is one of the figures we re-measure rather than assume.