Amendment XLS: Ticket Taxon

[bigcjat]

XLS-XXd: Ticket Taxon for Application Sequence Coordination

Title:       Ticket Taxon for Application Sequence Coordination
Author:      Chris Thompson
Status:      Draft
Type:        Standards Track (Amendment)
Created:     2026-08-06
Amendment:   featureTicketTaxon

---

Abstract

This proposal introduces an optional TicketTaxon (STUInt32) metadata field to the existing TicketCreate transaction and Ticket (ltTICKET) ledger object on the XRP Ledger.

TicketTaxon provides a standardized on-chain identifier for application-reserved sequence tickets. This allows self-custody mobile wallets and dApp client SDKs to identify, group, and respect tickets reserved by specific applications (such as automated bots or multi-step escrow systems), preventing accidental ticket consumption across multi-dApp user workflows without imposing restrictive consensus execution locks.

---

Motivation

The Multi-dApp Sequence Collision Problem

The XRP Ledger's Ticket primitive (ltTICKET) allows accounts to reserve sequence numbers for out-of-order transaction execution. This capability is vital for dApps, off-chain proposal builders, and automated processing systems that prepare transactions in advance.

However, sequence numbers are globally scoped to the account:

1. Application A creates 5 Tickets (e.g., Ticket Sequences 100 through 104) to prepare a multi-step transaction workflow.
2. While the workflow is pending, the user opens a mobile wallet or interacts with Application B to execute a separate transaction.
3. Application B queries account_objects for available tickets, selects the next available Ticket Sequence (Sequence 100), and consumes it.
4. Result: Application A's workflow is invalidated because its reserved ticket sequence was inadvertently consumed by an unrelated transaction from Application B.

The TicketTaxon Solution

Drawing inspiration from NFTokenTaxon (which groups NFTs by collection or application namespace), TicketTaxon adds a lightweight, non-restrictive STUInt32 identifier to the ltTICKET ledger object.

By adding TicketTaxon:

1. Application Namespace Identification: dApps tag created tickets with a unique identifier (e.g., 0x12345678).
2. Soft Client Coordination: Self-custody mobile wallets and SDKs inspect TicketTaxon when querying account tickets. Wallets politely skip tagged tickets during generic auto-sequence selection, reserving them for their intended application.
3. Zero Consensus Deadlocks: Consensus execution remains unrestricted. If a user explicitly chooses to spend or clear a ticket in their wallet UI, the protocol permits it. No rigid consensus locks or transaction failure edge cases are introduced.

---

Specification

1. Transaction Field Modification: TicketCreate

Add an optional TicketTaxon field to the TicketCreate transaction format.

Field	JSON Type	Internal Type	Required?	Description
TicketTaxon	Number	STUInt32	Optional	Application-defined namespace identifier for the reserved tickets.

---

2. Ledger Object Modification: Ticket (ltTICKET)

Update the Ticket ledger entry structure to store the optional TicketTaxon field.

Field	JSON Type	Internal Type	Required?	Description
TicketTaxon	Number	STUInt32	Optional	The application namespace identifier associated with this ticket.

---

Standard Workflow Example

Mobile Wallet & dApp Sequence Coordination

1. dApp Ticket Reservation: Application A creates 5 tickets for a user's account using TicketCreate with TicketTaxon = 305419896 (0x12345678).
2. On-Ledger Tagging: The 5 ltTICKET entries are stored on-ledger with TicketTaxon = 305419896.
3. User Mobile Interaction: The user opens their mobile wallet to send a separate payment.
4. Smart Sequence Selection: The mobile wallet queries account_objects. The SDK detects that Tickets 100–104 are tagged with TicketTaxon = 305419896. The wallet automatically selects the standard account sequence (or an un-tagged ticket), leaving the reserved tickets untouched for Application A.
5. Workflow Execution: When the user approves Application A's transaction, Application A consumes Tickets 100–104 cleanly.

---

Advantages Over Un-Tagged Tickets

Feature	Un-Tagged Tickets (Current)	TicketTaxon (Proposed)
dApp Namespace Identification	None	Explicit STUInt32 Tag
Mobile Wallet Awareness	Wallets cannot distinguish ticket origin	Wallets group & respect reserved tickets
Multi-dApp Collision Risk	High (tickets frequently stolen by other apps)	Minimal (client-side soft reservation)
Consensus Footprint	Standard ltTICKET	Zero new objects (1 field added to ltTICKET)

---

Backwards Compatibility

This amendment is fully backwards compatible:

• Existing TicketCreate transactions without TicketTaxon continue to function identically.
• Un-tagged tickets (TicketTaxon omitted) are treated as generic, unreserved tickets.
• Amendments required: featureTicketTaxon.

---

Security Considerations

1. No Non-Enforcement Risk: Because TicketTaxon is a client-coordination tag rather than a hard consensus lock, there is zero risk of locking user funds or causing unexpected tec transaction failures.
2. Replay Protection: Standard ticket sequence mechanics remain identical.
3. Reserve Unchanged: TicketCreate reserve requirements remain unchanged.