XRPL Open Ledger Cost: Fee Escalation Explained
The XRPL open ledger cost is a second-tier fee mechanism that operates alongside the base transaction cost. While the base fee represents the minimum cost to submit a transaction, the open ledger cost determines whether a transaction can be included in the current open ledger or must wait for a future one.
Base Fee vs. Open Ledger Cost
These two concepts are related but distinct:
- Base transaction cost: The minimum fee required by the network at all times (10 drops under normal load)
- Open ledger cost: The minimum fee required to be included in the current, actively forming ledger — this can escalate as the ledger fills
A transaction might meet the base fee requirement (and thus be accepted and queued) but fail to meet the open ledger cost (and thus wait for the next ledger). Both mechanisms use fee levels rather than absolute XRP amounts for their comparisons.
How Open Ledger Cost Escalates
As each new ledger opens, the open ledger cost starts at the base fee. As more transactions enter the open ledger, the cost escalates to prioritize traffic. This escalation is proportional to the basic cost of the transaction type — so a multi-signed transaction must pay more to meet the open ledger cost than a simple payment.
The escalation formula is described in the XRPL documentation's "Fee Escalation explanation in rippled repository." The key insight is that the Open Ledger Cost is measured in fee levels (a ratio), not absolute drops, ensuring fair proportional treatment across different transaction types.
Practical Implications for Developers
For most users and developers, the open ledger cost is irrelevant — standard transactions at the base fee are processed in the next available ledger (3-5 seconds). However, for time-sensitive applications that need same-ledger inclusion, providing a higher fee signals priority to the network.
Client libraries like xrpl.js and xrpl-py have configurable maximum Fee values and raise errors if the auto-filled fee exceeds the configured maximum. This protects developers from accidentally paying unexpectedly high fees during load spikes while using auto-fill.
Failed Transactions Still Pay Fees
An important note: even failed transactions incur the transaction cost. This is by design — since the purpose of the fee is to protect the peer-to-peer network from excessive load (not just successful transactions), all transactions that are distributed to the network must pay, regardless of outcome.
