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 Price

Where:

  • 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:

Scenario
Recommendation

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

circle-info

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

circle-info

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 instruction

  • Without SetComputeUnitPrice: No priority fee is charged (only base fee)

Prerequisites

You must have the following:

  1. Node.js v23+arrow-up-right is installed on your laptop

  2. Solana Devnet RPC URL (Optional: GetBlock Solana RPC URLarrow-up-right)

  3. A package manager installed on your laptop(Preferrably npm)

circle-info

Devnet RPC URL is used for this guide. If you want to interact with the Mainnet, then make use of GetBlock Solana RPC URLarrow-up-right

Project Setup

1

Create a new project directory

2

Install the dependencies:

chevron-rightPackage Descriptionhashtag
Package
Description

@solana/web3.js

Standard library for talking to the Solana blockchain and RPCs

dotenv

Loads your .env file so secrets are not hardcoded in the source

base58

Decodes base58 private keys into a format the code can use

3

Create a .env file and add the following details:

4

Create index.ts file, this is where you will be writing your script

5

Import your dependencies and load the .env variables:

6

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).

7

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 ComputeBudget instructions that will be in the final transaction but weren't in the simulation. Falls back to 200,000 if the simulation returned nothing.

8

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.

9

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.

chevron-rightComplete Working Examplehashtag

Here's a full example that puts everything together:

10

Run the code using this command

11

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

  1. Never hardcode compute unit limits. Simulation catches errors before they cost you fees:

  1. 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:

  1. Build your instructions - Create the core transaction logic

  2. Simulate - Get actual compute unit requirements

  3. Fetch network fees - Understand current market rates

  4. Add compute budget - Set limit and price (in that order, before main instructions)

  5. Send - Sign and submit with appropriate commitment level

Additional Resources

Last updated

Was this helpful?