Skip to main content
Save money, improve performance: Get precise priority fee estimates based on real-time network conditions. Pay only what you need for the speed you want.

What Are Priority Fees?

On Solana, priority fees allow your transactions to jump ahead in the validator queue during network congestion. Think of them as express lanes for your transactions.

Base Fees vs Priority Fees

Base fees are fixed costs for transaction processingPriority fees are optional payments for faster processing

How They Work

You set a price per compute unit - higher prices get processed first during network congestion

Why Use Priority Fees

Priority fees are now a standard part of Solana transactions, helping ensure reliable confirmation times and optimal network performance.

Reliable Confirmation

Ensure your transactions confirm quickly and reliably, even during varying network conditions

Competitive Edge

Stay competitive in time-sensitive operations like trading, minting, and DeFi interactions

User Experience

Provide consistent, fast transaction processing for better user experience

Network Efficiency

Help optimize network resource allocation and overall performance

Priority Levels Explained

Our API provides six priority levels based on recent network activity:
Lowest observed fee - Based on minimum fees seen in recent slotsBest for: Non-urgent transactions when cost optimization is priorityNote: May result in slower confirmation times
25th percentile - Budget-friendly option with reasonable confirmation timesBest for: Standard operations where speed isn’t criticalNote: Good balance of cost and reliability
75th percentile - Higher fees for faster processingBest for: Time-sensitive operations and competitive scenariosNote: Prioritized processing during network activity
Upper tail, with headroom - Premium fees for maximum speedBest for: Critical operations, MEV strategies, urgent transactionsNote: Sits above the 95th percentile of observed fees and is not outlier-trimmed. Treat it as a landing target, not as a measure of what the network is paying
Maximum observed - Highest fee seen in recent slots, with no outlier filteringBest for: Emergency situations onlyWarning: A single extreme bid anywhere in the lookback window sets this value. It regularly reaches billions of micro-lamports per compute unit - use with caution

How Estimates Are Calculated

Estimates are derived from fees paid in recent slots (up to 150, controlled by lookbackSlots). Two details matter when you compare these numbers against your own on-chain measurements:
  • Non-vote transactions that set no compute unit price count as zero. A large share of non-vote transactions in a typical slot include no SetComputeUnitPrice instruction at all. They enter the distribution as zero-fee samples, which is why min and low frequently return 0. If you compute percentiles over priced transactions only, your numbers will be higher than ours at every level.
  • veryHigh and unsafeMax are not outlier-trimmed. A handful of transactions bidding extreme amounts within the lookback window can raise both levels substantially, and veryHigh carries additional headroom above the 95th percentile so that it stays a viable landing target.
Do not use veryHigh or unsafeMax as network fee statistics. Both are deliberately tail-weighted and sit above what most transactions actually pay.
Cost Calculation: Total priority fee = Price per compute unit × Compute units consumedA typical transaction uses 200,000-400,000 compute units. At current Medium level (~40,000 microlamports per unit), that’s 0.000008-0.000016 SOL in priority fees. Always check current network conditions for accurate estimates.

Scope: Global vs Account-Specific Estimates

What you pass determines what the API measures.
  • Pass a serialized transaction - the estimate is scoped to the writable accounts your transaction locks. This is the recommended method when you are setting a fee to send with.
  • Pass accountKeys - the estimate is scoped to those accounts. Include the writable accounts your transaction will lock, since those are the accounts you compete for.
  • Pass neither - you get a global estimate across all recent network activity, not a fee tailored to your transaction.
A global estimate is not a fee to pay. With no transaction or accountKeys, the response describes network-wide conditions, including congestion on accounts your transaction never touches.Solana prices priority fees per writable account, so paying a global veryHigh usually means overpaying by a wide margin without improving your landing rate. Always pass a transaction or the writable accountKeys when the estimate will set a fee on a transaction you are about to send.

Implementation Methods

Serialized Transaction (Recommended)

Primary Method - Analyzes your exact transaction for maximum accuracyBest for: Most applications and production use casesBenefits:
  • Instruction-specific analysis
  • Highest accuracy
  • Production-ready
  • Considers transaction complexity

Account Keys (Advanced)

Specialized Use Cases - Estimates based on account patternsBest for: Pre-transaction analysis, batch operations, specialized architecturesBenefits:
  • Account-level pattern analysis
  • Useful for planning and research
  • Batch account analysis

Quick Start Example

API Reference

getPriorityFeeEstimate

Complete API documentation with all parameters and response formats

Real-Time Network Monitoring

Pro tip: Monitor network conditions to optimize your priority fee strategy. During normal conditions, use lower priority levels. During congestion, consider higher levels for time-sensitive operations.You can check current network conditions using Solana explorers or the getRecentPerformanceSamples RPC method.

Support & Resources

Discord Community

Get help from the community and Helius team

Direct Support

Priority fee questions and optimization assistance