Skip to content
Submit bugs here.

Please submit any typos you come across to GitHub issues.


This doc explains transaction fees. Stellar also requires accounts to have a minimum balance, which you can read about in the Minimum Balance doc.

To prevent ledger spam and maintain the efficiency of the network, Stellar requires small transaction fees and minimum balances on accounts. Transaction fees are also used to prioritize transactions when the network enters surge pricing mode.

Fee Formula

Stellar transactions can contain anywhere from 1 to a defined limit of 100 operations. The fee for a given transaction is equal to the number of operations the transaction contains multiplied by the base fee for a given ledger.

Transaction fee = # of operations * base fee

Stellar deducts the entire fee from the transaction’s source account, regardless of which accounts are involved in each operation or who signed the transaction.

Base Fee

The base fee for a given ledger is determined dynamically using a version of a VCG auction. When you submit a transaction to the network, you specify the maximum base fee you’re willing to pay per operation, but you’re actually charged the lowest possible fee based on network activity.

When network activity is below capacity, you pay the network minimum, which is currently 100 stroops (0.00001 XLM) per operation.

Surge Pricing

When the number of operations submitted to a ledger exceeds network capacity (currently 1,000 ops/ledger), the network enters surge pricing mode, which uses market dynamics to decide which submissions are included. Essentially, submissions that offer a higher fee per operation make it onto the ledger first.

If there’s a tie — in other words multiple transactions that offer the same base fee are competing for the same limited space in the ledger — the transactions are (pseudo-randomly) shuffled, and transactions at the top of the heap make the ledger. The rest of the transactions, the ones that didn’t make the cut, are pushed on to the next ledger, or discarded if they’ve been waiting for too long. If your transaction is discarded, Horizon will return a timeout error. For more information, see transaction life cycle.

The goal of the transaction pricing specification, which you can read in full here, is to maximize network throughput while minimizing transaction fees.

Fee Stats and Fee Strategy

The general rule of thumb: choose the highest fee you’re willing to pay to ensure your transaction makes the ledger. Wallet developers may want to offer users a chance to specify their own base fee, though it may make more sense to set a persistent global base fee multiple orders of magnitude above the market rate — 0.1 XLM, for instance — since the average user probably won’t care if they’re paying 0.8 cents or 0.00008 cents.

If you keep getting a timeout error when you submit a transaction, you may need to increase your base fee, or wait until network activity abates and re-submit your transaction. To help inform that decision, you can consult the Horizon /fee_stats endpoint, which provides detailed information about per-operation fee stats for the last five ledgers. You can find the same information on the fee stats panel of the dashboard. All three of the SDF-maintained SDKs also allow you to poll the /fee_stats endpoint: Go, Java, Javascript.

Fee Pool

The fee pool is the lot of lumens collected from transaction fees.

SDF does not retain these lumens. They go into a locked account and sit there unused by anyone.

Last updated Aug. 05, 2022

Next Up: Inflation
Page Outline