The XRP Ledger employs a dynamic transaction cost system that balances network access with spam prevention. Understanding this system helps developers and users ensure their transactions are processed promptly without overpaying.

The Three Thresholds

Every rippled server maintains internal cost thresholds based on its current load:

1. Load-Based Cost: If your transaction fee is below this threshold, the server rejects it entirely and does not relay it to the network (terINSUF_FEE_B error).
2. Open Ledger Cost: If your fee meets this threshold, the transaction is included in the current open ledger immediately.
3. Queue: Transactions falling between the two thresholds are queued for inclusion in a future ledger once the open ledger cost drops.

How to Query Current Fees

Use the XRPL fee API method to get real-time fee information. The response includes drops.base_fee, drops.minimum_fee, drops.median_fee, and drops.open_ledger_fee — all in drops. For typical transactions, setting the fee equal to the open_ledger_fee value ensures immediate processing.

Special Transaction Types

Some transaction types have higher minimum costs. For example, an EscrowFinish transaction with a cryptographic condition requires 330 drops plus an additional 10 drops for every 16 bytes of the fulfillment preimage. This reflects the extra computational work these transactions require.

Fee Destruction

Every drop paid as a transaction fee is permanently destroyed — burned from the total XRP supply. Fees are not collected by validators, operators, or any central party. This deflationary mechanism, while small, contributes to long-term XRP scarcity and aligns network participants' incentives with network health rather than fee collection.