Fees and priority fees

The base fee does not let a transaction compete for space, because everyone pays the same amount. The prioritisation fee is the mechanism that does. It is optional, and a transaction that does not set one pays nothing beyond the base fee and receives the lowest scheduling priority.

The fee is set through two compute budget instructions. One sets the compute unit price, denominated in micro-lamports per compute unit; the other sets the compute unit limit, the maximum number of compute units the transaction may consume. The runtime multiplies the two and divides by one million to get the fee in lamports, rounding up. A transaction that sets a price but no limit uses the default limit derived from its instructions.

The critical detail is that the fee is based on the limit the transaction requests, not on the compute units it actually consumes. A transaction that requests a large limit and uses a fraction of it pays for the whole limit. That is why the documentation advises requesting the minimum compute units required: over-requesting is simply paying for capacity that goes unused, and it also makes the transaction look more expensive to the scheduler.

Unlike the base fee, the prioritisation fee is not burned. Under the current schedule it goes entirely to the validator that produced the block. That difference matters for incentives: the validator's marginal reward for including a transaction comes from the prioritisation fee, not from the base fee, which is why the prioritisation fee is the lever that actually influences inclusion.

A transaction that fails still pays. The fee payer's balance is debited before execution begins, and if an instruction later returns an error — an exhausted compute budget, a failed assertion, a program error — the transaction is recorded as failed and the fee is kept. The runtime does not refund it.

This is a deliberate anti-spam property rather than an oversight. If failed transactions were free, an attacker could flood the network with transactions designed to fail, consuming the compute and bandwidth of every validator that processed them at no cost. Charging the fee regardless makes that attack expensive. It also means that a user who submits a transaction with a bug pays for the attempt, which is why simulating a transaction before sending it is a standard practice.

The failure case interacts with the prioritisation fee in a way worth noting. Because the prioritisation fee is computed from the requested compute unit limit, a transaction that fails by exhausting its budget pays the full prioritisation fee it set. A transaction that fails early, having consumed few compute units, still pays the fee based on the limit it requested rather than the units it used.

The prioritisation fee does not directly order transactions. The scheduler converts it into a priority by comparing the reward the validator will keep against the estimated cost of executing the transaction. The reward is the prioritisation fee plus the non-burned portion of the base fee; the cost is an estimate built from signature verification, write locks, instruction data and program execution. The ratio of the two is the priority.

The consequence is that a transaction's priority depends on more than the fee it pays. A transaction that touches many accounts, or that requests a large compute budget, carries a higher estimated cost and therefore needs a larger fee to reach the same priority as a simple transfer. This is why the documentation recommends setting an accurate compute unit limit: a transaction that leaves the default limit in place is treated as more expensive than one that declares a tight limit, and is ranked accordingly.

The fee also does not guarantee inclusion. It raises the likelihood that a transaction is scheduled ahead of competing ones, but the scheduler's ordering is not a strict auction, and a transaction can still fail to land if it conflicts with others on the same account. That case — contention on a specific account rather than on block space in general — is the subject of the local fee markets page.

The price-times-limit formula described above applies to the legacy and v0 transaction formats. The documentation notes that an upcoming v1 format changes the mechanism: the prioritisation fee becomes an absolute total in lamports, set directly in the message configuration, with no per-compute-unit price and no multiplication or rounding. That is a change to how the fee is expressed rather than to the principle that a transaction may pay extra for priority.

It is described here as upcoming rather than deployed, because that is how the project's own documentation describes it. A reader building against the current network should use the price-times-limit formula, and should check the documentation for the status of the v1 format before relying on it.