What happens if transaction fee is too low?
Last updated:
If an XRPL transaction fee is too low, the transaction will likely be dropped from validators' transaction queues without being included in any ledger. The specific behavior depends on network congestion, how low the fee is, and the transaction's priority compared to others competing for inclusion.
XRPL validators maintain transaction queues where unvalidated transactions wait for inclusion in upcoming ledgers. When transactions arrive faster than ledgers can process them, queues fill and validators must prioritize which transactions to include. Transactions with higher fees receive priority over those with lower fees.
The minimum transaction fee under normal conditions is 10 drops (0.00001 XRP), remarkably low by cryptocurrency standards. However, during network congestion, the effective minimum increases as validators preferentially process higher-fee transactions. A transaction offering only the baseline fee might wait indefinitely or get dropped during high-traffic periods.
When a transaction's fee is below validator thresholds, several outcomes are possible. The transaction might remain in validator queues indefinitely without processing. It might get dropped from queues after some time, particularly if LastLedgerSequence expires or validators need space for higher-priority transactions. Or it might eventually process if congestion decreases.
The tefMAX_LEDGER_SEQ error occurs when a transaction expires via LastLedgerSequence before validating. Low-fee transactions are particularly susceptible because they wait longer in queues, increasing the chance of expiration. This combination of low fees and short expiration windows often results in failed submissions.
Validators won't accept transactions with fees below 10 drops - these are rejected immediately as malformed. The transaction never enters queues and no sequence number is consumed. This represents the absolute minimum, below which transactions cannot even be submitted regardless of network conditions.
Fee escalation mechanisms exist to handle congestion periods. When the network is very busy, validators automatically increase their effective minimum fees. Transactions offering fees below these escalated minimums get queued at lower priority or rejected. The fee_cushion and max_fee parameters in transaction submission APIs help applications adapt to these dynamics.
Applications should implement dynamic fee calculation based on current network conditions. The fee command in rippled servers provides information about current fee levels, including the minimum, median, and open ledger fee. Using these values to set transaction fees ensures reliable processing even during congestion.
The risk-reward of low transaction fees depends on urgency. If a payment isn't time-sensitive, using minimum fees saves XRP and transactions will eventually process. For urgent transactions or during busy periods, using higher fees ensures quick validation. Many applications use 12-15 drops as standard fees, slightly above minimums for better reliability.
Transaction fee markets on XRPL are generally minimal compared to other blockchains. Ethereum gas fees can spike to hundreds of dollars during congestion. Bitcoin fees similarly fluctuate dramatically. XRPL's 4-second ledger times and high throughput mean congestion is rare, and even escalated fees remain a tiny fraction of a cent.
The Fee field in transactions specifies fees in drops (millionths of an XRP). Common mistakes include specifying fees in XRP rather than drops (off by a factor of one million) or using integer arithmetic improperly. Such errors can result in fees that are far too low or absurdly high.
Excessively high fees are also possible and represent wasted XRP. A transaction offering 1 XRP as a fee when 0.00001 XRP would suffice burns unnecessary value. Validators don't refund overpaid fees - the entire specified amount is destroyed. Applications should validate fee calculations to prevent such waste.
Some specialized transaction types have higher minimum fees. Multi-signed transactions and transactions creating new ledger objects may require higher fees reflecting their greater computational cost. The protocol enforces these minimums, rejecting transactions with insufficient fees for their complexity.
During the extremely rare events of sustained network congestion, fee markets provide load management. Users willing to pay higher fees get priority, while less urgent transactions wait or fail. This market mechanism prevents network collapse during traffic spikes while keeping normal-case fees minimal.
Monitoring transaction validation status after submission reveals fee-related issues. If transactions consistently fail to validate or take unusually long, fee levels may be insufficient. Increasing fees slightly usually resolves such problems without significant cost given XRP's low transaction fees.
The destroyed transaction fees create slight XRP deflation. While individual fees are minuscule, aggregate fees across millions of transactions gradually reduce total XRP supply. This deflationary pressure is generally imperceptible but theoretically benefits XRP holders by making each unit slightly scarcer over time.