Ripple's Former CTO Proposes Transaction Reservation Scheme to Combat Front-Running on XRP Ledger

David Schwartz, who served as Chief Technology Officer at Ripple and now holds the title of CTO Emeritus, has stepped into the spotlight with a concrete proposal aimed at addressing a persistent vulnerability on the XRP Ledger — front-running and sandwich attacks.

The issue was brought to broader attention by XRPresso, an XRP Ledger-based marketplace, which flagged what it described as a "serious front-running problem" that continues to put ordinary users at a disadvantage. According to the platform's post on X, validators and well-connected network nodes are able to observe transactions sitting in the pre-validation queue before a ledger closes. This visibility allows them to quickly assess whether front-running or sandwiching a pending trade would be profitable — and then flood the network with their own transactions in an attempt to manipulate their position in the canonical transaction order for that ledger.

While official XRPL documentation states that transaction ordering is intentionally designed to be unpredictable as a deterrent against such manipulation, both academic research and real-world observation have demonstrated that this safeguard falls short in practice. Actors with privileged or faster access to pending transaction data can still exploit the system, undermining the fairness of the marketplace.

This vulnerability has circulated within the XRP community for years, with ongoing debates around transaction queue transparency and potential privacy-enhancing measures. However, Schwartz's latest contribution moves the conversation from diagnosis to remedy.

In a post published on June 29, 2026, Schwartz outlined a relatively straightforward mechanism he believes could effectively eliminate the threat of front-running and sandwich attacks on XRPL payments and offer crossings.

At the core of his proposal is a new ledger object called "ReservedTxns." This object would store a ledger sequence number alongside an array of transaction IDs and would be indexed using a hash derived from a fixed string combined with the corresponding ledger sequence number.

Complementing this new object is a proposed transaction type called "TxnReserve," which would allow a user to reserve an execution slot for a specific transaction. The TxnReserve transaction accepts a ledger number and a transaction ID as parameters.

For a TxnReserve to be accepted, several conditions must be met. First, the submitting party must pay a fee of at least double the standard transaction fee. Second, all typical transaction execution requirements must be satisfied. Third, the ledger sequence number specified in the transaction must be higher than the current ledger sequence number, but not exceed it by more than 16 ledgers.

Finally, the ReservedTxns object associated with the target ledger sequence either must not yet exist, or — if it does exist — must contain fewer than 32 transaction IDs and must not already include the transaction ID being submitted.

By reserving a slot in advance, this scheme would effectively guarantee that a transaction executes before any transaction created after the original intent was disclosed — stripping away the informational advantage that bad actors currently exploit.

Schwartz acknowledged that he does not personally view this as a critical threat at present, but noted that the proposal offers a clean and implementable solution should the community decide it warrants formal adoption. The idea has already generated discussion among developers and XRPL community members who have long called for stronger protections against order manipulation on the ledger.