XRP Ledger Transaction Cost: How Fees Work, Rise and Get Burned

The fee goes unnoticed until a library fills in one that is too high. The number in the box above is the easy part. What bites is the Fee field you sign, which is not adjusted for you, and a transaction that sits in a queue because its fee was too low.

What a transaction costs

Heavy traffic can push the standard fee up for a while. The full rules sit in the Transaction Cost reference, and since validators can change the figure by vote, recheck it before you rely on it.

The “reference transaction” is the cheapest non-free transaction, measured by the cost it needs before load scaling. Everything else is priced relative to it.

Where the fee goes

Nowhere. The XRP is irrevocably destroyed. No validator, server operator or company receives it. The point is protection: to keep spam and denial-of-service attacks from disrupting the ledger, each transaction must destroy a small amount of XRP. One visible side effect, as the rippled docs note: the available supply of XRP decreases slowly as small amounts are destroyed to pay fees.

Drops

Fees are quoted in drops because they are tiny and whole numbers avoid long decimals. The xrpl.js library has a function that converts an amount in XRP to an amount in drops, which helps when you build a transaction in code. The xrpl.js guide covers the library.

Why the fee climbs

The network charges more when it is busy. The cost is designed to rise with load, so overloading the network on purpose or by accident becomes very expensive. The minimum sometimes increases due to higher than usual load. In calm periods fees stay low; once heavy traffic arrives they can grow quickly to extreme levels, as the rippled fee escalation notes lay out.

Two thresholds decide what a server does with a transaction. Below its load-based cost threshold, the server ignores the transaction completely. Below its open ledger cost threshold, it queues the transaction for a later ledger. The open ledger cost stays at the minimum un-scaled cost until the number of transactions in the open ledger reaches the soft limit, and after that it increases exponentially for each transaction included. A transaction enters the open ledger only if it meets that cost in XRP.

The Fee field

The sender sets the cost. Each transaction names how much XRP to destroy, and every signed transaction must carry that value in the Fee field. The ledger usually executes a transaction exactly as signed. Two consequences:

• The exact Fee is destroyed even if it is much more than the current minimum anywhere on the network. Overpaying is not refunded.
• Auto-filled fees can come out too high, and you do not want to burn a large fee to send a small transaction. Some client libraries, including xrpl.js and xrpl-py, let you set a maximum Fee and raise an error instead of signing above it.

When it is charged

Only when the transaction lands in a validated ledger. The cost comes out of the sender’s XRP balance when the transaction becomes part of a validated ledger, whether it succeeds or fails with a tec code. If a failure is final, the server does not relay the transaction at all.

Low balances have a floor. An account that cannot cover the cost pays all the XRP it can and ends with 0 XRP. The cost can even destroy XRP that would otherwise be set aside for the account’s reserve. The reserve guide explains that reserve.

The free exception

One case costs nothing. An account can send a SetRegularKey transaction with a cost of 0 as long as its lsfPasswordSpent flag is disabled. It is there so you can recover an account after a regular key is compromised, without worrying whether the compromised account holds any XRP. Everything else carries the cost, including payments that use destination tags.

Before you sign

• Look up the current load-based cost first.
• Set LastLedgerSequence so the transaction expires if it never confirms.
• Cap the Fee in your client library if it supports a maximum.
• Remember the cost is spent once the transaction is in a validated ledger, even on a tec failure.

Under the hood: the queue and fee voting

Neither matters to a one-off sender. They explain why the cost moves and how the network changes it.

The queue

The queue is the waiting room for a transaction whose fee is too low for the current open ledger. When a transaction misses the open ledger cost, the server estimates whether it is likely to be included in a later ledger, and queues it if so. That lets legitimate transactions be considered for future ledgers when the escalated fee gets too high.

It suits people who are not in a hurry: submit with a low fee and wait for high fees to drop. There is no timing guarantee, and in principle a queued transaction can stay queued indefinitely. Set a LastLedgerSequence so a stuck transaction expires instead of lingering in limbo.

Servers compare transactions by fee level, which is the proportional difference between a transaction’s minimum cost and its actual cost. The fee method shows the open ledger cost.

Fee voting

Validators vote on the network’s fee settings, and the network follows the median. It automatically adjusts the settings to the median of trusted validators’ preferences, and each validator expresses its preferences about once every 15 minutes.

Changes land on a fixed rhythm, laid out in the fee voting documentation. Every 256th ledger is a flag ledger. If a SetFee pseudo-transaction reaches consensus, the new settings take effect at flag ledger +2. The consensus guide explains how validators reach agreement.

The votes balance two goals. Fees exist to protect the network from spam, so decisions have to weigh making the network accessible to more users and use cases against protecting it from misuse and overuse. The reference cost mostly protects servers’ CPU and bandwidth, and if it is too low, malicious users can overload the network by spamming it. The ledger can also change the minimum to account for long-term changes in the value of XRP.

The payments guides cover escrow and the other features that move XRP.