How To Optimize Solana Transactions with Priority Fees
Learn how to land your Solana transaction faster using priority fee and GetBlock
Solana processes thousands of transactions per second, but during periods of high network activity, your transactions may compete for block space. Priority fees let you bid for faster inclusion in the validator's queue, ensuring your time-sensitive transactions reach the network quickly.
In this guide, you'll learn about priority fees, when you should use them, how to calculate compute uint(CU), and how to create one for yourself.
What Are Priority Fees?
Priority fees are optional fees you add to a Solana transaction to increase its scheduling priority. Think of them as a tip to validators—transactions with higher priority fees get processed before those with lower fees or no fees at all.
The formula is simple:
Priority Fee = Compute Units × Compute Unit PriceWhere:
Compute Units (CU) measure the computational resources your transaction consumes
Compute Unit Price is how much you're willing to pay per CU, measured in microLamports
Quick conversion:
1 SOL = 1,000,000,000 lamports
1 lamport = 1,000,000 microLamports
Therefore: 1 microLamport = 0.000000000001 SOL
When Should You Use Priority Fees?
Priority fees aren't always necessary. Here's when they make sense:
Simple wallet transfers during normal activity
Skip or use minimal fees
DeFi swaps and trades
Medium priority recommended
NFT mints during launch
High to urgent priority
Arbitrage opportunities
Extreme priority
Network congestion detected
Increase from baseline
Time-sensitive operations
High priority minimum
During normal network conditions, transactions land fine without priority fees. Only add them when speed matters or when the network is congested.
Understanding Compute Units
Every Solana transaction consumes compute units. The more complex your transaction, the more CUs it uses.
Typical CU usage:
Simple SOL transfer: ~450 CU
Token transfer (SPL): ~20,000-30,000 CU
DEX swap: ~100,000-200,000 CU
Complex DeFi operations: ~200,000-400,000 CU
You're charged based on the compute unit limit you set, not what you actually use. If you set a limit of 200,000 CU but only use 50,000, you still pay for 200,000. This is why simulation matters.
Default behavior:
Without
SetComputeUnitLimit: Solana defaults to 200,000 CU per instructionWithout
SetComputeUnitPrice: No priority fee is charged (only base fee)
Prerequisites
You must have the following:
Node.js v23+ is installed on your laptop
Solana Devnet RPC URL (Optional: GetBlock Solana RPC URL)
A package manager installed on your laptop(Preferrably npm)
Devnet RPC URL is used for this guide. If you want to interact with the Mainnet, then make use of GetBlock Solana RPC URL
Project Setup
Create a new project directory
Create a .env file and add the following details:
Create index.ts file, this is where you will be writing your script
Import your dependencies and load the .env variables:
Build the Transfer Instruction
This creates the instruction to move SOL. LAMPORTS_PER_SOL (1,000,000,000) converts from SOL to the smallest unit (lamports).
Simulate to Estimate Compute Units
This:
Wraps the transfer instruction in a versioned transaction (the modern Solana format) for simulation.
Gets a recent blockhash — required to build a valid transaction even for simulation.
Dry-runs the transaction against the network without actually submitting it. Returns how many compute units it would use.
Takes the simulated CU count, adds a 10% buffer, then adds 600 extra to account for the two
ComputeBudgetinstructions that will be in the final transaction but weren't in the simulation. Falls back to 200,000 if the simulation returned nothing.
Get a Dynamic Priority Fee and calculate the total cost
This helps gain insight into what was recently paid for priority fees and calculate what you paid, rather than guessing, which can prevent wastage or setting the fee too low.
Build the final transaction
This:
Assembles 3 instructions: CU limit → priority fee → SOL transfer, then attaches blockhash and fee payer.
Signs with the private key, submits, waits for confirmation, and returns the signature.
Decodes private key, creates wallet keypair, parses recipient address, calls function with
0.001 SOL.
Run the code using this command
Result
You will get a response like this: This should show the estimated CU, the total priority fee used, and the transaction hash
Best Practices
Never hardcode compute unit limits. Simulation catches errors before they cost you fees:
Network conditions change. Fetch recent fees instead of using static values:
Conclusion
Priority fees are a powerful tool for ensuring your Solana transactions reach their destination quickly during network congestion. The key steps are:
Build your instructions - Create the core transaction logic
Simulate - Get actual compute unit requirements
Fetch network fees - Understand current market rates
Add compute budget - Set limit and price (in that order, before main instructions)
Send - Sign and submit with appropriate commitment level
Additional Resources
Last updated
Was this helpful?