X

getRecentPrioritizationFees

Solana RPC Method for Real-Time Fee Estimation

getRecentPrioritizationFees — Solana RPC Method Guide

getRecentPrioritizationFees — Solana RPC Method Guide

getRecentPrioritizationFees is a native Solana JSON-RPC method that returns a list of minimum prioritization fees observed in the most recent slots (up to 150 blocks). It is the foundation for any dynamic fee estimation system on Solana.

Method Signature

getRecentPrioritizationFees(accountAddresses?: string[]) → Array of {slot: number, prioritizationFee: number}

The optional accountAddresses parameter is critical for accurate localized fee data. When provided, the RPC returns fee samples only from transactions that locked at least one of the specified accounts — giving you program-specific fee floors rather than global network averages.

Understanding the Response

Each item in the response array contains:

  • slot: The slot number for this fee sample
  • prioritizationFee: The minimum priority fee (in microLamports per CU) observed in that slot for the queried accounts

A prioritizationFee of 0 means transactions in that slot had no priority fee attached — useful for identifying when the network is lightly loaded.

Limitations of the Raw RPC Method

The raw method returns up to 150 slot samples, but interpreting them requires additional processing:

  • The data represents minimum observed fees — not average or median fees
  • Rapidly changing conditions make the 150-slot window stale within seconds during high volatility
  • Single-value extraction (e.g., taking the maximum) can lead to over-paying during brief spikes

For these reasons, the Helius Priority Fee API wraps this method with statistical analysis and returns a single recommended value per priority tier — simplifying integration significantly.

Best Practices for Using getRecentPrioritizationFees

  • Always pass the relevant account addresses (program ID + writable accounts) for localized estimates
  • Filter out zero-fee slots before calculating your median or percentile
  • Use the 50th–75th percentile of non-zero samples for standard production transactions
  • Cache results for 2–5 seconds between transaction batches to reduce RPC load
  • Cross-reference with global tracker data during unusual network conditions

Related Resources

Editor

About The Editor

The editorial team at SolanaPriorityFee.org specializes in Solana transaction infrastructure, fee optimization, and developer tooling. Our guides are built from real-world transaction data, RPC documentation, and hands-on testing across Mainnet and Devnet environments.

Leave A Comment