TL;DR:
David Schwartz, CTO Emeritus of Ripple, reopened the debate over one of the structural problems of the XRP Ledger: the possibility that malicious actors execute front-running or sandwich attacks on payments and order crosses within the network. His analysis made clear that the available solutions carry costs that could outweigh the benefits.
Earlier in the week, Schwartz presented a transaction reservation scheme designed to ensure that each transaction is executed before any other created after its disclosure. The proposal generated multiple reactions within the XRP community, with many users questioning the technical feasibility of the mechanism on the ledger.
About the closest thing to this you could actually do is have transaction ordering determined by consensus with validators voting on transaction ordering as part of the consensus process. But there are a lot of disadvantages to this.
The big one is that it would slow the…
— David 'JoelKatz' Schwartz (@JoelKatz) July 1, 2026
One of the questions that emerged was whether incorporating precise per-second timestamps would allow transactions to be ordered chronologically. Ripple software engineer Mayukha Vadari responded that this is not feasible: different nodes receive each transaction at slightly different times, since they must propagate through the peer-to-peer network.
Schwartz noted that the closest alternative is consensus-based ordering, where validators vote on the order of transactions as part of the validation process. He warned, however, that this solution presents certain drawbacks. The main one is that it would considerably increase the number of bits over which consensus must be reached, slowing down the process significantly.
Schwartz also evaluated an intermediate option: an optional flag that users could activate on their transactions to request priority ordering, in exchange for an additional fee. Transactions with that flag enabled would have relay preference and their order would be determined by consensus.
However, Schwartz himself identified the central problem with this approach. Activating the flag for some transactions and not others would create an asymmetry that would facilitate precisely the attacks it seeks to prevent. “I don’t think it’s worth it, especially because it makes it easier to front-run or sandwich transactions that don’t activate the flag,” he stated. Based on that reasoning, he dismissed the proposal as a net solution to the problem.
