Solana Priority Fees
Phantom automatically calculates and applies Priority Fees to all Phantom-generated transactions and dApp-generated transactions that meet our requirements.
Solana transactions fees are calculated based on two main parts:
• A statically set base fee per signature, and
• The computational resources used during the transaction, measured in Compute Units (CU)
Since each transaction requires different computational resources, they are allotted a maximum number of compute units, known as the Compute Budget. After the Compute Budget is exhausted, the runtime halts the transaction and returns an error, resulting in a failed transaction.
The maximum budget for a transaction is 1.4 million CU, while the total blockspace limit is 48 million CU. Only a few computationally heavy TXs, like a mint or a swap, could fill the entire block, halting other TXs—Hence the need for Priority Fees.
The fee priority of a transaction
Tcan be defined as
F(T)is the "fee-per compute-unit", calculated by:
This means that the more compute units a transaction requests, the more additional fee it will have to pay to maintain the priority in the transaction queue. This prevents computationally heavy transactions from being easily spammed or from filling blocks.
Priority fees are calculated as,
Although dApps can set their own priority fees on transactions they generate, we highly discourage doing so as it often surfaces unnecessary complexity to end-users. Instead, we recommend that dApp developers let Phantom apply priority fees on the user's behalf.
Phantom will calculate and apply Priority Fees to all dApp-generated transactions, provided:
• The transaction(s) do not already have signature(s) present
• The transaction(s) do not have existing priority fee instructions (
• After enhancing transaction(s) with Priority Fees, the size of each transaction will still be less than the byte size limit (1232 bytes)
If all of the above conditions are met, Phantom will automatically calculate and apply priority fees at the time of signing. This pattern applies to all Phantom provider methods (
signAllTransactions) across all environments (extension, mobile in-app browser, deeplinks, mobile wallet adapter).