Share
Ripple’s former Chief Technology Officer David Schwartz has unveiled a proposal aimed at eliminating one of the most controversial issues affecting decentralized trading on the XRP Ledger: front-running and sandwich attacks.
The proposal comes after renewed criticism from members of the XRP community, who argue that sophisticated validators and well-connected nodes can exploit pending transactions to profit at the expense of ordinary users.
While Schwartz, known online as JoelKatz, said he is “not that concerned” about the scale of the issue today, he acknowledged that a relatively simple protocol change could remove the attack vector altogether without significantly altering the XRP Ledger’s existing transaction flow.
At the center of the proposal is a new feature called ReservedTxns, a ledger object that would allow users to reserve execution slots for future transactions before revealing their contents.
Under the proposed design, users would first submit a TxnReserve transaction containing only the transaction hash and the target ledger number. To discourage abuse, the reservation would require paying at least twice the standard transaction fee and could only target ledgers up to 16 blocks into the future.
Concerns have been raised about the possibility of front running or transaction sandwich attacks on XRPL payments and offer crossing.
For the reasons I've explained, I'm not that concerned about this issue. But I have a proposal for a fairly simple scheme that would eliminate… https://t.co/lnhTv1bhBK
— David 'JoelKatz' Schwartz (@JoelKatz) June 29, 2026
Each future ledger would be limited to 32 reserved transaction slots, with reservations recorded in the order they are received.
The actual transaction would remain private until shortly before execution. Wallets and XRPL servers would broadcast it only after validators had finalized proposals for the previous ledger, dramatically reducing the opportunity for malicious actors to inspect the transaction and submit competing orders beforehand.
According to Schwartz, this guarantees that a reserved transaction executes before any transaction created after its details become public, effectively preventing front-running and sandwich attacks.
To further reduce risk, reserved transactions would expire if they missed their designated ledger, ensuring delayed transactions could not later be exploited.
The proposal follows renewed debate sparked by XRPresso.io, which argued that the XRP Ledger’s current architecture still leaves traders vulnerable despite existing safeguards.
According to the analysis, validators and highly connected network participants can inspect transactions sitting in the pre-validation queue before a ledger closes. Because transaction ordering follows a deterministic algorithm based partly on transaction hashes, attackers can submit multiple competing transactions to improve their chances of being placed before or after a profitable trade.
A serious front-running issue continues on the XRPL that disadvantages regular users.
Validators and well-connected nodes can view transactions in the pre-validation queue before a ledger closes.
They can quickly analyze a pending trade, determine if front-running or…
— XRPresso.io (@xrpresso_io) June 29, 2026
This behavior enables classic sandwich attacks on XRPL’s decentralized exchange (DEX) and automated market maker (AMM), where traders surround a victim’s order with their own transactions to extract value while worsening execution prices for the original user.
XRPresso noted that although XRPL documentation describes transaction ordering as intentionally unpredictable, real-world observations suggest determined participants with privileged network visibility can still exploit the system.
The platform warned that the practice creates an uneven playing field, particularly disadvantagering retail users trading through popular wallets and decentralized applications.
Schwartz’s proposal also considers potential denial-of-service attacks against the reservation mechanism itself.
An attacker could theoretically reserve all available slots across multiple future ledgers, preventing legitimate users from protecting their transactions. However, Schwartz argues that continuously paying double transaction fees would already make such attacks expensive.
This is true, but is mitigated by a number of factors.
For one thing, everyone has an equal opportunity to do this. Transactions are publicly visible before a ledger closes.
Running a validator does not help you do this unless multiple validators conspire. If multiple…
— David 'JoelKatz' Schwartz (@JoelKatz) June 29, 2026
To further discourage abuse, he suggested introducing dynamic reservation fees that automatically increase as reservation slots fill up. For example, fees could begin rising after 16 reservations and reach roughly three times the base reserve cost when nearly all slots are occupied.
If demand eventually exceeded current capacity, the maximum number of reservations could also be expanded from 32 to 64, provided users remained willing to pay the higher fees.
The proposal reflects Ripple’s continued focus on improving fairness as the XRP Ledger expands its decentralized finance ecosystem. With native DEX functionality and growing AMM adoption attracting more on-chain trading activity, reducing opportunities for transaction manipulation has become increasingly important for user confidence.
Share
preferred on
