XRPL Checks in 2026: Deferred Payments, Fees, and Reserve Math

By XORA · Published 2026-08-31

An XRP Ledger Check is a deferred payment authorization, not a funded balance: creating one moves no payment funds, but an ordinary open Check raises its creator's reserve requirement by 0.2 XRP under the Mainnet settings checked on 31 August 2026. A successful create-and-cash lifecycle needs two transactions and costs a minimum 20 drops, or 0.00002 XRP, assuming single signatures and no load scaling. The recipient controls when to cash and can accept less than the authorized maximum, but a successful cash is one-time and destroys the Check.

A Check separates authorization from settlement

A direct Payment transaction is a sender-driven instruction to transfer value now. Checks split that action in two. The sender signs CheckCreate, naming a destination and a maximum debit in SendMax. The ledger stores a Check object, but it does not earmark the authorized XRP. Later, only the destination can sign CheckCash and pull an allowed amount.

That reversal of timing is the useful feature. A merchant can wait until delivery, a counterparty using Deposit Authorization can receive through a destination-initiated cash, and a recipient can choose an exact amount below the cap. The tradeoff is equally important: the Check is not proof that funds will exist later. If the creator lacks spendable XRP when cashing is attempted, the transaction can fail and the object stays available for another attempt before expiration.

The owner reserve is the real scaling constraint

The official reserve documentation listed Mainnet's base reserve as 1 XRP per account and incremental owner reserve as 0.2 XRP per owned item. We confirmed the same values through a validated Mainnet server_info response at ledger 106,664,874 on the publication date. An ordinary, unsponsored Check is owned by its creator and increments OwnerCount by one, so each simultaneous open Check adds 0.2 XRP to that account's required reserve.

Reserve is not burned and does not leave the account. It is XRP that ordinarily cannot be sent while the object exists. Successful cashing or cancellation removes the object and releases that increment. The account's 1 XRP base reserve and reserves for its other objects remain separate. Reserve settings are changeable by validator fee voting, so production software should query them rather than hardcode this article's dated values.

Assumptions for every row: all Checks are ordinary unsponsored XRP Checks; the creator starts with sufficient XRP above its existing reserve; every transaction is single-signed, successful on its first attempt, and charged the current 10-drop reference fee under no load scaling. One XRP equals 1,000,000 drops. The destination pays each cashing fee, so the fee columns show protocol totals, not one party's bill.

Creation and cashing fees: who pays what

The current minimum reference transaction cost is 10 drops, though load scaling or multisigning can raise it. CheckCreate, CheckCash, and CheckCancel are reference transactions. On the cleanest successful path, the creator destroys 10 drops to create; the destination destroys another 10 drops to cash. The combined 20 drops equal 0.00002 XRP.

A cancel path also needs at least two transactions: 10 drops to create and 10 drops from whoever submits a successful cancellation, again 20 drops total at reference cost. Failed cashes matter operationally. A tec failure included in a validated ledger can still charge the submitted fee while leaving the Check in place. Each retry is a new transaction and therefore a new possible fee. The table is a floor, not a universal invoice.

Exact cash, flexible cash, and the one-time rule

CheckCash offers two mutually exclusive instructions. With Amount, the destination requests exactly that amount, no more than SendMax. With DeliverMin, it asks for at least a minimum and lets the ledger deliver as much as possible up to SendMax. For issued tokens, liquidity, authorization, freezes, and issuer settings can affect what is deliverable. Our examples isolate native XRP.

For a flexible example, keep the 500 XRP maximum and set DeliverMin = 300 XRP. If 410 XRP is deliverable under the assumed account state, 410 XRP can arrive and the Check is deleted. If only 250 XRP is deliverable, the minimum is not met, cashing fails, and the Check remains for a later attempt. Calling this “partial cashing” can be misleading: the delivered amount may be below the maximum, but success still consumes the whole authorization in one cash.

Expiration stops cashing, not storage

CheckCreate can include an Expiration time expressed as seconds since the Ripple Epoch. Before that time, the creator or destination can cancel. After it, CheckCash fails as expired and anyone can submit CheckCancel. Expiration alone does not delete the object.

Suppose a Check expires at 12:00 UTC. At 11:59:59 it may still be cashable if all other conditions pass. At or after expiry it cannot be cashed, but its 0.2 XRP incremental reserve remains required until cancellation succeeds. This creates a cleanup obligation for high-volume systems. A sensible issuer indexes open Checks, monitors expiration, and cancels stale objects instead of assuming the ledger performs garbage collection.

Check versus direct Payment: the quantified decision

Assumptions match the earlier table and the Payment destination is already funded, so no new-account base reserve is part of the comparison. Choose Payment when the sender knows the amount and wants immediate settlement. Choose a Check when destination-controlled timing, a capped one-time pull, Deposit Authorization compatibility, or flexible final amount is worth a second transaction and temporary owner reserve.

Operational checklist for using Checks safely

• Query live economics: read reserve_base_xrp, reserve_inc_xrp, and current fee data from a validated server before constructing transactions.
• Track Check IDs: the object key derives from the creator and creating sequence or ticket. Store the validated transaction result and reconcile object state.
• Budget reserve at peak concurrency: multiply simultaneous unsponsored objects, not daily volume, by the current owner reserve.
• Handle retries explicitly: insufficient funds or liquidity can leave the Check open while a validated failed attempt still costs a fee.
• Clean up expirations: expiration blocks cashing but does not remove the object or release reserve. Submit and verify cancellation.

Put XRP to work instead of leaving it idle

Checks solve deferred payment authorization; they do not make idle XRP productive. XORA's separate value proposition is up to 22% APY value (15% native XRP yield, treasury-subsidised during a disclosed bootstrap, plus estimated XORA reward value). Returns are variable and never guaranteed, and custody, liquidity, operational, counterparty, market, and reward-value risks remain. Use the XRP yield calculator to test assumptions and review the security model before depositing.

xora.finance is where to put your XRP to work, earning up to 22% instead of leaving it idle on an exchange. Start with an amount appropriate for your risk tolerance and keep the difference clear: XRPL Checks manage when a payment may settle, while XORA is designed to put deposited XRP to work.