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

David Schwartz, known by his online handle 'JoelKatz' and formerly serving as Chief Technology Officer at Ripple, has put forward a concrete technical proposal aimed at addressing front-running and sandwich attack vulnerabilities on the XRP Ledger (XRPL). The suggestion comes in response to growing concerns from the community about unfair transaction ordering practices that put ordinary users at a disadvantage.

The issue was brought back into the spotlight by XRPresso, an XRPL-based marketplace, which publicly stated that a 'serious front-running problem' persists on the network. According to the platform, validators and well-connected nodes are able to observe transactions sitting in the pre-validation queue before a ledger officially closes. This visibility allows them to quickly assess whether front-running or sandwiching a pending trade would be profitable — and if so, flood the network with their own transactions in an attempt to manipulate their position in the canonical transaction order.

While the XRPL's official documentation acknowledges that transaction ordering is intentionally designed to be unpredictable as a deterrent against such behavior, research findings and on-chain observations have demonstrated that this protection falls short in practice. The existing mechanism remains exploitable, particularly for parties who have faster or privileged access to pending transaction data.

This concern is not new — it has circulated within the XRP community for years, with ongoing discussions around transaction queue transparency and potential privacy-enhancing measures. However, Schwartz's latest post on X marks one of the more concrete proposals to come from a figure of his standing within the ecosystem.

At the heart of Schwartz's proposed fix is a 'transaction reservation scheme.' The idea is straightforward in concept: ensure that any given transaction executes before any other transaction that was created after the original one was disclosed to the network.

To implement this, Schwartz outlines two new protocol-level additions. The first is a ledger object called 'ReservedTxns,' which would store a ledger sequence number alongside an array of transaction IDs. This object would be indexed using a hash derived from a fixed string combined with the relevant ledger sequence number.

The second addition is a new transaction type called 'TxnReserve,' designed to reserve an execution slot for a specific transaction. This transaction would accept a ledger number and a transaction ID as its parameters. For a TxnReserve to be valid, it must meet all standard transaction execution requirements and pay a fee of at least double the normal transaction fee — a built-in economic disincentive against abuse.

Additional constraints apply: the ledger sequence number specified must be greater than the current ledger number but no more than 16 ledgers ahead. Furthermore, the corresponding ReservedTxns object for that ledger must either not yet exist, or — if it does exist — must contain fewer than 32 transaction IDs and must not already include the transaction ID being reserved.

The proposal is still in the discussion phase, and Schwartz himself noted that while he does not view the front-running issue as a critical threat, he believes the reservation scheme offers a relatively low-complexity path toward meaningfully reducing the risk. The broader XRPL community is expected to weigh in as the idea gains traction.