
When the ledger is busy
4 minDifficulty Checked 2026-11-10- Each ledger has a soft size limit. Past it, the cost to get in climbs steeply.
- Transactions that pay less wait in a queue for a later ledger.
- The fee method shows the cost to enter the open ledger right now.
Think of a bus that leaves every few seconds. Each bus is one ledger. It has a comfortable number of seats.
While seats are free, the fare is the minimum, 10 drops. Once the seats fill, people can still squeeze on, but each extra rider pays much more than the last. The fare for standing room climbs fast.
If you paid only the minimum and the bus is full, you are not thrown out. You wait in line for the next bus. That line is the transaction queue. Riders who paid more stand nearer the front.
So on a busy day you have two choices: pay more and ride now, or pay the minimum and wait a ledger or two.
Most of the time the ledger is not full and none of this matters. Your wallet picks a fee and the transaction goes through in seconds.
When it does matter:
- A wallet may show a higher fee than usual. That is the network being busy, not the wallet taking a cut.
- A transaction may sit as pending for a short while. It is in the queue.
- A transaction with an expiry can time out in the queue. Then it never happens and costs nothing.
The seat count is not fixed. After a ledger with more transactions than the limit, the limit grows. If agreeing on a ledger takes too long, it shrinks.
A server applies two thresholds to Fee.
| Threshold | If the transaction is below it |
|---|---|
| Local load cost | The server ignores it and does not relay it |
| Open ledger cost | The server queues it for a later ledger, if it is likely to be included |
Open ledger cost. For each ledger the server picks a soft limit on transactions, based on the previous ledger. Up to that limit, the open ledger cost equals the minimum. Past it, the cost rises exponentially with each transaction added. The limit goes up after a ledger that exceeded it. It goes down if consensus takes more than 5 seconds.
Fee levels. Escalation is proportional, not absolute. The minimum cost of any transaction type is 256 fee levels. A multi-signed transaction with a higher minimum must pay more drops to reach the same level.
The queue. Rules for queuing include:
- At most 10 queued transactions per sending address.
- The sender must have enough XRP for every queued
Fee, the most XRP those transactions could send, and the reserve. - The total of queued fees cannot exceed the base reserve, 1 XRP.
- A
LastLedgerSequence, if set, must be at least the current ledger index + 2. - Transactions with
AccountTxnIDcannot be queued.
A queued transaction returns the provisional code terQUEUED. One that can be neither applied nor queued fails with telCAN_NOT_QUEUE. The queue ranks by fee level, highest first, then by hash.
Unsticking. A signed transaction cannot change its fee. Options: wait, let LastLedgerSequence expire it, or replace it with a new transaction using the same Sequence and a higher fee. A later transaction from the same sender can also pay enough to pull the earlier ones in. The docs call this fee averaging.
Reading the cost. Call fee:
| Field | Meaning |
|---|---|
drops.minimum_fee | Minimum for a reference transaction to be queued |
drops.open_ledger_fee | Cost to enter the open ledger now |
drops.median_fee | Median cost among transactions in the previous validated ledger |
current_ledger_size, expected_ledger_size | Transactions in the open ledger, and the number expected |
current_queue_size, max_queue_size | Queue depth and capacity |
server_info gives the load-scaled cost: validated_ledger.base_fee_xrp × load_factor.
Related: The transaction cost.
- Transaction CostRead 2026-11-10
- Transaction QueueRead 2026-11-10
- fee methodRead 2026-11-10
