Skip to main content

getRecentPrioritizationFees

Returns a list of prioritization fees from recent blocks.

Common use cases
Calculate optimal transaction fees with compute budget awarenessQuery recent prioritization fees, apply statistical methods (median, percentile) to determine base fee, then combine with compute unit estimation for total cost calculation. Use setComputeUnitPrice instruction with the calculated value. Essential for cost-sensitive applications that need responsive fee adjustment during varying network congestion.
Estimate fees for transactions targeting specific accountsProvide account addresses as parameters to get fee estimates that reflect actual competition for those specific writable accounts. Critical for high-value transactions involving contested accounts like popular AMM pools or token vaults.
Implement intelligent transaction retry with escalating feesUse getRecentPrioritizationFees in retry loops to dynamically adjust priority fees when transactions fail to land. Start with median fee, escalate to 75th or 90th percentile on retries. Improves transaction success rates without overpaying.
Track network congestion and fee market trendsPoll getRecentPrioritizationFees periodically to monitor fee trends over time. Useful for dashboards, alerting systems, and understanding network demand patterns. Combine with getRecentPerformanceSamples for comprehensive network health metrics.

Parameters

address (array, optional)

An array of Account addresses (up to a maximum of 128 addresses), as base-58 encoded strings If this parameter is provided, the response will reflect a fee to land a transaction locking all of the provided accounts as writable.

Request

curl https://solana-mainnet.api.syndica.io/api-key/YOUR_API_KEY \
-X POST \
-H "Content-Type: application/json" \
-d '{
"jsonrpc": "2.0",
"id": 1,
"method": "getRecentPrioritizationFees",
"params": [
["CxELquR1gPP8wHe33gZ4QxqGB3sZ9RSwsJ2KshVewkFY"]
]
}'
Network Selection

Replace mainnet with devnet in the URL to query devnet instead.

Response

{
"jsonrpc": "2.0",
"result": [
{
"slot": 348125,
"prioritizationFee": 0
},
{
"slot": 348126,
"prioritizationFee": 1000
},
{
"slot": 348127,
"prioritizationFee": 500
},
{
"slot": 348128,
"prioritizationFee": 0
},
{
"slot": 348129,
"prioritizationFee": 1234
}
],
"id": 1
}

Response Fields

Return value: array

An array of prioritization fee objects containing:

FAQ and Troubleshooting

Why does getRecentPrioritizationFees return 0 or very low values?

During periods of low network congestion, prioritization fees can be 0 or near-zero because transactions land successfully without additional fees. This is normal behavior. When congestion increases, fees will rise naturally. If you need a minimum fee for reliability, use a fallback default (e.g., 1000 microlamports).

Should I pass an empty array or specific accounts as the parameter?

For accurate transaction-specific estimates, always provide the writable accounts your transaction will lock. Empty array returns the global minimum fee, which may be insufficient for transactions involving contested accounts. Extract writable accounts from your transaction message and pass them to get relevant fee data.

How should I calculate a single fee value from the array of results?

Use statistical aggregation rather than raw values. Median (50th percentile) is most common and robust against outliers. For higher reliability during congestion, use 75th or 90th percentile. Avoid using average or maximum, as these are skewed by extreme values.

The method sometimes returns errors or empty arrays. How should I handle this?

Implement graceful fallback strategies. Wrap calls in try-catch blocks, check for empty results, and use sensible defaults (1000-5000 microlamports). During RPC outages or when cache is empty (e.g., shortly after validator restart), fallback ensures your application continues functioning.

Is getRecentPrioritizationFees sufficient for production fee estimation?

For basic use cases, yes. For high-stakes transactions or competitive environments, consider supplementing with enhanced fee estimation services that provide additional context like percentile breakdowns, account-specific analytics, and predictive models. The default RPC method provides raw slot data but limited statistical analysis.

getRecentPerformanceSamples
While getRecentPrioritizationFees reveals fee market dynamics, getRecentPerformanceSamples measures network throughput and transaction volume. Together, they provide comprehensive network health insights for intelligent fee strategies.

getFeeForMessage
Calculates the base transaction fee (not including priority fees) for a given message. Use alongside getRecentPrioritizationFees to compute total transaction cost: base fee + (priority fee × compute units).

simulateTransaction
Simulates transaction execution to estimate compute unit consumption. Essential companion to getRecentPrioritizationFees for accurate total fee calculation. Determine compute units needed, then multiply by prioritization fee to estimate additional cost.

sendTransaction
Submits transactions to the network. Use getRecentPrioritizationFees to determine optimal fee before calling sendTransaction with setComputeUnitPrice instruction. Proper fee setting improves landing success rate.

External Resources