Solana's RPC layer provides built-in methods for querying recent priority fee data, and third-party providers extend this with more sophisticated estimation APIs. Using these tools is essential for any production application that wants reliable transaction landing rates.

‍

Real-time fee data is the foundation of any robust Solana transaction strategy.

‍

getRecentPrioritizationFees RPC Method

The standard Solana RPC method getRecentPrioritizationFees accepts an optional array of account addresses and returns a list of recent priority fees — one per slot for the last 150 slots — along with the slot number. This gives you a view of what fees were actually used to land transactions involving those specific accounts.

‍

The limitation of this method is that it shows the minimum fee from successful transactions, not a distribution. For a more nuanced picture — especially on accounts with high contention — you need percentile data.

‍

Third-Party Fee APIs

Providers like Helius offer a Priority Fee API that computes six tiers of fee estimates based on recent network activity: min, low, medium, high, very high, and unsafe max. Passing your serialized transaction to this API gives you the most accurate estimate because the fee is calculated based on the actual accounts and programs your transaction touches.

‍

QuickNode also provides a Solana Priority Fee API as an add-on, available through their marketplace. It includes percentile-based fee data and is well-suited for applications that need granular control over fee tiers.

‍

Implementing Dynamic Fee Selection

A practical pattern is to query the fee API before building your transaction, select the appropriate tier based on urgency, then set that value with ComputeBudgetProgram.setComputeUnitPrice(). Cache the API response for a few seconds to avoid rate limits, and invalidate the cache during observed congestion spikes.