XRPL Tickets in 2026: Parallel Transactions, Reserve Cost, and Sequence Risk

By XORA · Published 2026-08-31

XRPL Tickets let one account prepare up to 250 independently numbered transactions instead of forcing every transaction through one consecutive sequence. At the Mainnet settings checked on 31 August 2026, each unused Ticket locks 0.2 XRP of owner reserve, so 100 Tickets require 20 XRP and the maximum inventory requires 50 XRP. Under a clearly stated 10-drop standard-fee assumption, creating and then consuming 100 Tickets costs 0.00101 XRP in fees, while the 20 XRP reserve becomes available again as the Tickets are used.

Why one missing sequence can block an account's pipeline

Every ordinary XRPL transaction carries the sending account's next Sequence. Validation consumes it and advances the account. This prevents replay but creates an ordered dependency chain: transaction 108 cannot validate while 107 is unresolved.

The official transaction queue documentation sorts transactions from one sender by sequence. A low-fee transaction without an expiry can remain queued and block later numbers. Operators can wait, replace it at a higher fee, or use fee averaging.

A Ticket changes the dependency graph. It is a ledger object containing a reserved TicketSequence. A Ticket-backed transaction sets normal Sequence to 0 and supplies that Ticket number. Different Tickets can be signed, submitted, and validated outside normal sequence order. This is especially useful when several workers, approval groups, or multi-signature ceremonies need to prepare transactions without first completing every earlier one.

TicketCreate reserves a block of future numbers

The mechanics are easiest to audit with the official example. Suppose an account's current sequence is 101 and it submits TicketCreate with TicketCount: 3. The ledger creates Tickets 102, 103, and 104, then advances the normal account sequence to 105. The owner can next use normal sequence 105 or any of those three Tickets, in any order.

TicketCreate is the only XRPL transaction that advances an account's sequence by more than one. Its increase is 1 + TicketCount: one number for the creation transaction and one reserved number for every Ticket. The transaction reference also specifies all-or-nothing creation. If an account would exceed 250 outstanding Tickets or lacks reserve for every requested Ticket, none are created.

Using Ticket 103 deletes that Ticket object and does not change normal sequence 105. The reserve attached to Ticket 103 is released. The other Tickets stay valid until consumed. There is no ordinary expiration field on the Ticket object itself, so inventory management matters: forgotten Tickets continue occupying ledger space and reserve until the owner uses them, often with a no-op AccountSet if the goal is cancellation.

The exact reserve and fee math

We queried Ripple's public Mainnet server_info endpoint on 31 August 2026. Validated ledger 106,664,878 reported a 1 XRP base reserve, a 0.2 XRP incremental reserve, and a 0.00001 XRP base fee. The calculations below use those dated settings, assume the account owns no other reserve-bearing objects, use single-signed standard transactions, and assume no load-based fee escalation.

The incremental reserve is TicketCount × 0.2 XRP. The lifecycle fee for creating N Tickets and then validating one standard transaction with each is (N + 1) × 0.00001 XRP. Reserve is locked, not spent. Fees are destroyed and do not return.

The “total reserve” column is deliberately narrow: it adds the 1 XRP account base to the Ticket reserve only. A real operational account may own signer lists, trust lines, offers, escrows, or other objects, increasing its actual reserve. Multi-signed transactions also cost more than the standard-fee assumption: the official formula is 10 drops multiplied by one plus the number of signatures provided, before load scaling.

A 100-transaction audit: 20 XRP locked, 0.00101 XRP destroyed

Consider a treasury preparing 100 independent payments. First, one TicketCreate transaction creates 100 Ticket objects. That immediately adds 100 to OwnerCount and raises the reserve requirement by 20 XRP. It also destroys the creation fee, assumed here to be 0.00001 XRP.

Next, 100 separately signed transactions each use a unique Ticket. If all 100 enter validated ledgers as standard single-signed transactions at the assumed base fee, they destroy another 0.001 XRP. As each validates, its Ticket object disappears and 0.2 XRP stops counting toward reserve. After the final one, all 20 XRP is available again. Total fees are 101 transactions multiplied by 0.00001 XRP, or 0.00101 XRP.

Failure semantics matter. The sequence-number reference states that ledger inclusion consumes a sequence or Ticket even when the result is a tec-class failure. Such a transaction also pays its fee. By contrast, a malformed transaction rejected before ledger inclusion has no ledger effect and does not consume its Ticket. Monitoring must distinguish provisional submission responses from final validated results.

What Tickets solve, and what they do not

Tickets solve sender-side sequencing. They allow parallel signing, independent submission, and out-of-order completion. A multi-signature treasury can circulate five proposals at once without assigning fragile consecutive sequences. Separate withdrawal workers can use distinct Ticket pools. Offline signers can use known unique Tickets, although fee and ledger-expiry choices still need care.

Tickets do not multiply XRPL throughput. Consensus still decides what enters each validated ledger, load-based fees can still rise, and Ticket transactions from the same account have a defined within-ledger order. Official documentation says normal-sequence transactions from the account execute first, then Ticket transactions execute from lowest to highest TicketSequence. Independent eligibility is not simultaneous execution.

Nor do Tickets make conflicting state changes safe. Two payments can independently compete for the same balance. Two offers can interact with liquidity changed by earlier execution. A key-setting transaction may invalidate authorizations expected by another transaction. Every candidate needs an appropriate LastLedgerSequence, a current fee policy, idempotent business records, and finality monitoring by transaction hash.

Designing a practical Ticket inventory

The 250 ceiling is a maximum, not a recommended target. A system peaking at 20 concurrent approvals might keep 25 Tickets: 20 working slots plus a five-Ticket buffer. That locks 5 XRP rather than 50 XRP. Wait for TicketCreate to validate before assigning new numbers.

Track four quantities: unused Ticket count, assigned but unsubmitted count, submitted but unvalidated count, and reserve headroom. Query Tickets from ledger state rather than trusting only a local database. Alert on old unused Tickets and candidates nearing LastLedgerSequence. Because the official rippled implementation checks the reserve for the entire requested count, calculate headroom before creating a batch.

Finally, separate the account's normal sequence lane from its Ticket lanes in application logic. The normal lane is useful for Ticket replenishment and carefully ordered account administration. Ticket lanes are useful for independent business actions. Tickets cannot be combined with AccountTxnID, so systems that rely on previous-transaction hash chaining must choose which ordering guarantee they actually need.

Put XRP to work, not idle on an exchange

Tickets are transaction-coordination infrastructure, not a source of XRP yield. XORA's separate offering 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 users should assess custody, liquidity, operational, counterparty, market, and reward-value risks.

xora.finance is where to put your XRP to work, earning up to 22% instead of leaving it idle on an exchange. Model the potential outcome with the XRP yield calculator, read how XRP yield works, and review the security model before depositing an amount appropriate for your risk tolerance.