Definition and scope
Account Sequences vs. Tickets addresses a distinct part of accounts and wallet controls. Compare sequential transaction ordering with tickets that reserve future transaction numbers.
An XRPL account is a ledger object controlled by cryptographic authorization—not an app login. These topics explain how accounts begin, how transactions are ordered, and how master keys, regular keys, signer lists, and domain settings change operational control. Authorization changes should be rehearsed with independent recovery paths. No guide requires sharing a seed, family secret, or private key.
How it works
Ordinary account transactions consume the next AccountRoot Sequence. TicketCreate reserves TicketSequence values that later transactions can use with Sequence set to zero, allowing independently prepared operations without bypassing authorization.
- Sequence: verify this field, object, or component against the cited protocol documentation.
- TicketCreate: verify this field, object, or component against the cited protocol documentation.
- TicketSequence: verify this field, object, or component against the cited protocol documentation.
- owner reserve: verify this field, object, or component against the cited protocol documentation.
Comparison at a glance
Use these dimensions to choose between the concepts without treating their names as interchangeable.
| Dimension | Account Sequence | Ticket |
|---|---|---|
| Value source | Next AccountRoot Sequence | Pre-created TicketSequence |
| Preparation | Usually serial | Can prepare independent transactions |
| Reuse | Advances after use | Single use |
| Ledger cost | No owned Ticket object | Consumes owner reserve until used or canceled |
Practical example and checks
An organization can create a batch of tickets, assign each ticket to a separate approval workflow, and reconcile each validated transaction without forcing every signer to wait for the previous sequence.
For production use, preserve the exact signed or queried data, record the network and validated ledger reference, and compare the result with the current primary documentation before changing off-ledger state.
Open the related live demo or evidence lab →Limits, risks, and common confusion
Tickets consume owner reserve and cannot be reused. They do not create parallel consensus lanes or guarantee execution; each ticketed transaction still needs a valid fee, signature, and ledger result.
Authorization changes should be rehearsed with independent recovery paths. No guide requires sharing a seed, family secret, or private key.
Current network status
Enabled on XRPL Mainnet. The underlying protocol capability is available on XRPL Mainnet. Individual services can still impose additional rules, limits, or trust assumptions.
Status reviewed 2026-08-23. Amendment-dependent behavior must be rechecked against the network's live feature state before operational use.