Fees on Solana | Solana (2024)

The Solana blockchain has a few different types of fees and costs that areincurred to use the permissionless network. These can be segmented into a fewspecific types:

• Transaction Fees - A fee to have validators process transactions/instructions
• Prioritization Fees - An optional fee to boost transactions processing order
• Rent - A withheld balance to keep data stored on-chain

Transaction Fees #

The small fee paid to process logic (instruction) within an on-chain program onthe Solana blockchain is known as a "transaction fee".

As each transaction (which containsone or more instructions) is sentthrough the network, it gets processed by the current validator leader. Onceconfirmed as a global state transaction, this transaction fee is paid to thenetwork to help support the economic design of the Solana blockchain.

Currently, the base Solana transaction fee is set at a static value of 5klamports per signature. On top of this base fee, any additionalprioritization fees can be added.

Why pay transaction fees? #

Transaction fees offer many benefits in the Solanaeconomic design, mainly they:

• provide compensation to the validator network for the expended CPU/GPU computeresources necessary to process transactions
• reduce network spam by introducing a real cost to transactions
• provide long-term economic stability to the network through aprotocol-captured minimum fee amount per transaction

Basic economic design #

Many blockchain networks (including Bitcoin and Ethereum), rely on inflationaryprotocol-based rewards to secure the network in the short-term. Over thelong-term, these networks will increasingly rely on transaction fees tosustain security.

The same is true on Solana. Specifically:

• A fixed proportion (initially 50%) of each transaction fee is burned(destroyed), with the remaining going to the currentleader processing the transaction.
• A scheduled global inflation rate provides a source forrewardsdistributed to Solana Validators.

Fee collection #

Transactions are required to have at least one account which has signed thetransaction and is writable. These writable signer accounts are serializedfirst in the list of accounts and the first of these is always used as the "feepayer".

Before any transaction instructions are processed, the fee payer accountbalance will be deductedto pay for transaction fees. If the fee payer balance is not sufficient to covertransaction fees, the transaction processing will halt and result in a failedtransaction.

If the balance was sufficient, the fees will be deducted and the transaction'sinstructions will begin execution. Should any of the instructions result in anerror, transaction processing will halt and ultimately be recorded as a failedtransaction in the Solana ledger. The fee is still collected by the runtime forthese failed transactions.

Should any of the instructions return an error or violate runtime restrictions,all account changes except the transaction fee deduction will be rolledback. This is because the validator network has already expended computationalresources to collect transactions and begin the initial processing.

Fee distribution #

Transaction fees arepartially burnedand the remaining fees are collected by the validator that produced the blockthat the corresponding transactions were included in. Specifically,50% are burnedand50% percent are distributedto the validator that produced the block.

Why burn some fees? #

As mentioned above, a fixed proportion of each transaction fee is burned(destroyed). This is intended to cement the economic value of SOL and thussustain the network's security. Unlike a scheme where transactions fees arecompletely burned, leaders are still incentivized to include as manytransactions as possible in their slots (opportunity to create a block).

Burnt fees can also help prevent malicious validators from censoringtransactions by being considered in fork selection.

Example of an attack: #

In the case of aProof of History (PoH) fork with amalicious or censoring leader:

• due to the fees lost from censoring, we would expect the total fees burned tobe less than a comparable honest fork
• if the censoring leader is to compensate for these lost protocol fees, theywould have to replace the burnt fees on their fork themselves
• thus potentially reducing the incentive to censor in the first place

Calculating transaction fees #

The complete fee for a given transaction is calculated based on two main parts:

• a statically set base fee per signature, and
• the computational resources used during the transaction, measured in"compute units"

Since each transaction may require a different amount of computationalresources, each is allotted a maximum number of compute units per transactionas part of the compute budget.

Compute Budget #

To prevent abuse of computational resources, each transaction is allocated a"compute budget". This budget specifies details aboutcompute units and includes:

• the compute costs associated with different types of operations thetransaction may perform (compute units consumed per operation),
• the maximum number of compute units that a transaction can consume (computeunit limit),
• and the operational bounds the transaction must adhere to (like account datasize limits)

When the transaction consumes its entire compute budget (compute budgetexhaustion), or exceeds a bound such as attempting to exceed themax call stack depthor max loaded account data size limit, the runtimehalts the transaction processing and returns an error. Resulting in a failedtransaction and no state changes (aside from the transaction fee beingcollected).

Accounts data size limit #

A transaction may specify the maximum bytes of account data it is allowed toload by including a SetLoadedAccountsDataSizeLimit instruction (not to exceedthe runtime's absolute max). If no SetLoadedAccountsDataSizeLimit is provided,the transaction defaults to use the runtime'sMAX_LOADED_ACCOUNTS_DATA_SIZE_BYTESvalue.

The ComputeBudgetInstruction::set_loaded_accounts_data_size_limit function canbe used to create this instruction:

let instruction = ComputeBudgetInstruction::set_loaded_accounts_data_size_limit(100_000);

Compute units #

All the operations performed on-chain within a transaction require differentamounts of computation resources be expended by validators when processing(compute cost). The smallest unit of measure for the consumption of theseresources is called a "compute unit".

As a transaction is processed, compute units are incrementally consumed by eachof its instructions being executed on-chain (consuming the budget). Since eachinstruction is executing different logic (writing to accounts, cpi, performingsyscalls, etc), each may consume adifferent amountof compute units.

Each transaction is alloted a compute unit limit, eitherwith the default limit set by the runtime or by explicitly requesting a higherlimit. After a transaction exceeds its compute unit limit, its processing ishalted resulting in a transaction failure.

The following are some common operations that incur a compute cost:

• executing instructions
• passing data between programs
• performing syscalls
• using sysvars
• logging with the msg! macro
• logging pubkeys
• creating program addresses (PDAs)
• cross-program invocations (CPI)
• cryptographic operations

You can find more details about all the operations that consume compute unitswithin the Solana runtime'sComputeBudget.

Compute unit limit #

Each transaction has a maximum number of compute units (CU) it can consumecalled the "compute unit limit". Per transaction, the Solana runtime has anabsolute max compute unit limit of1.4 million CUand sets a default requested max limit of200k CU per instruction.

A transaction can request a more specific and optimal compute unit limit byincluding a single SetComputeUnitLimit instruction. Either a higher or lowerlimit. But it may never request higher than the absolute max limit pertransaction.

While a transaction's default compute unit limit will work in most cases forsimple transactions, they are often less than optimal (both for the runtime andthe user). For more complex transactions, like invoking programs that performmultiple CPIs, you may need to request a higher compute unit limit for thetransaction.

Requesting the optimal compute unit limits for your transaction is essential tohelp you pay less for your transaction and to help schedule your transactionbetter on the network. Wallets, dApps, and other services should ensure theircompute unit requests are optimal to provide the best experience possible fortheir users.

Compute unit price #

When a transaction desires to pay a higher fee to boost its processingprioritization, it can set a "compute unit price". This price, used incombination with compute unit limit, will be used todetermine a transaction's prioritization fee.

By default, there isno compute unit price setresulting in no additional prioritization fee.

Prioritization Fees #

As part of the Compute Budget, the runtime supportstransactions paying an optional fee known as a "prioritization fee".Paying this additional fee helps boost how a transaction is prioritized againstothers when processing, resulting in faster execution times.

How the prioritization fee is calculated #

A transaction's prioritization fee is calculated by multiplying its computeunit limit by the compute unit price (measured in micro-lamports).These values can be set once per transaction by including the following ComputeBudget instructions:

• SetComputeUnitLimit -setting the maximum number of compute units the transaction can consume
• SetComputeUnitPrice -setting the desired additional fee the transaction is willing to pay to boostit* prioritization

If no SetComputeUnitLimit instruction is provided, thedefault compute unit limit will be used.

If no SetComputeUnitPrice instruction is provided, the transaction willdefault to no additional elevated fee and the lowest priority (i.e. noprioritization fee).

How to set the prioritization fee #

A transaction's prioritization fee is set by including a SetComputeUnitPriceinstruction, and optionally a SetComputeUnitLimit instruction. The runtimewill use these values to calculate the prioritization fee, which will be used toprioritize the given transaction within the block.

You can craft each of these instructions via their Rust or @solana/web3.jsfunctions. Each instruction can then be included in the transaction and sent tothe cluster like normal. See also thebest practices below.

Unlike other instructions inside a Solana transaction, Compute Budgetinstructions do NOT require any accounts. A transaction with multiple ofeither of the instructions will fail.

Rust #

The rust solana-sdk crate includes functions withinComputeBudgetInstructionto craft instructions for setting the compute unit limit and compute unitprice:

let instruction = ComputeBudgetInstruction::set_compute_unit_limit(300_000);

let instruction = ComputeBudgetInstruction::set_compute_unit_price(1);

Javascript #

The @solana/web3.js library includes functions within theComputeBudgetProgramclass to craft instructions for setting the compute unit limit and computeunit price:

const instruction = ComputeBudgetProgram.setComputeUnitLimit({ units: 300_000,});

const instruction = ComputeBudgetProgram.setComputeUnitPrice({ microLamports: 1,});

Prioritization fee best practices #

Below you can find general information on the best practices for prioritizationfees. You can also find more detailed information in this guide onhow to request optimal compute,including how to simulate a transaction to determine its approximate computeusage.

Request the minimum compute units #

Transactions should request the minimum amount of compute units required forexecution to minimize fees. Also note that fees are not adjusted when the numberof requested compute units exceeds the number of compute units actually consumedby an executed transaction.

Get recent prioritization fees #

Prior to sending a transaction to the cluster, you can use thegetRecentPrioritizationFeesRPC method to get a list of the recent paid prioritization fees within therecent blocks processed by the node.

You could then use this data to estimate an appropriate prioritization fee foryour transaction to both (a) better ensure it gets processed by the cluster and(b) minimize the fees paid.

Rent #

The fee deposited into every Solana Account to keepits associated data available on-chain is called "rent". This fee is withheldin the normal lamport balance on every account and reclaimable when the accountis closed.

All accounts are required to maintain a high enough lamport balance (relative toits allocated space) to become rent exempt and remain on theSolana blockchain. Any transaction that attempts to reduce an account's balancebelow its respective minimum balance for rent exemption will fail (unless thebalance is reduced to exactly zero).

When an account's owner no longer desires to keep this data on-chain andavailable in the global state, the owner can close the account and reclaim therent deposit.

This is accomplished by withdrawing (transferring) the account's entire lamportbalance to another account (i.e. your wallet). By reducing the account's balanceto exactly 0, the runtime will remove the account and its associated data fromthe network in the process of "garbage collection".

Rent rate #

The Solana rent rate is set on a network wide basis, primarily based on aruntime set"lamports per byte per year".Currently, the rent rate is a static amount and stored in theRent sysvar.

This rent rate is used to calculate the exact amount of rent required to bewithheld inside an account for the space allocated to the account (i.e. theamount of data that can be stored in the account). The more space an accountallocates, the higher the withheld rent deposit will be.

Rent exempt #

Accounts must maintain a lamport balance greater the minimum required to storeits respective data on-chain. This is called "rent exempt" and that balance iscalled the "minimum balance for rent exemption".

In the process of creating a new account, you must ensure you deposit enoughlamports to be above this minimum balance. Anything lower that this minimumthreshold will result in a failed transaction.

Every time an account's balance is reduced, the runtime performs a check to seeif the account will still be above this minimum balance for rent exemption.Unless they reduce the final balance to exactly 0 (closing the account),transactions that would cause an account's balance to drop below the rent exemptthreshold will fail.

The specific minimum balance for an account to become rent exempt is dependanton the blockchain's current rent rate and the desired amount ofstorage space an account wants to allocate (account size). Therefore, it isrecommended to use thegetMinimumBalanceForRentExemptionRPC endpoint to calculate the specific balance for a given account size.

The required rent deposit amount can also be estimated via thesolana rent CLI subcommand:

solana rent 15000 # outputRent per byte-year: 0.00000348 SOLRent per epoch: 0.000288276 SOLRent-exempt minimum: 0.10529088 SOL

Garbage collection #

Accounts that do not maintain a lamport balance greater than zero are removedfrom the network in a process known as garbage collection. This process isdone to help reduce the network wide storage of no longer used/maintained data.

After a transaction successfully reduces an accounts balance to exactly 0,garbage collection happens automatically by the runtime. Any transaction thatattempts to reduce an accounts balance lower that its minimum balance for rentexemption (that is not exactly zero) will fail.

Even after an account has been removed from the network (via garbagecollection), it may still have transactions associated with it's address (eitherpast history or in the future). Even though a Solana block explorer may displayan "account not found" type of message, you may still be able to viewtransaction history associated with that account.

You can read the validatorimplemented proposalfor garbage collection to learn more.