Ripple CTO Emeritus David Schwartz has reignited discussion about front-running and sandwich attack vulnerabilities on the XRP Ledger, analyzing community-proposed transaction ordering solutions. In a series of posts on X, Schwartz examined a transaction reservation scheme intended to prioritize transactions based on submission time, but concluded that available fixes carry significant trade-offs.
One community suggestion involved using precise per-second timestamps to enforce chronological execution. Ripple software engineer Mayukha Vadari pointed out this is unworkable because validator nodes receive transactions at slightly different times across the peer-to-peer network, making a unified timestamp impossible. Schwartz responded that the closest realistic alternative is consensus-based transaction ordering, where validators would vote on the sequence of each transaction as part of the consensus process. However, he warned that this approach would drastically increase the data validators must agree on, slowing the ledger’s consensus mechanism and adding complexity.
Schwartz also evaluated a compromise: an optional flag that users could activate on their transactions, paying an additional fee to gain relay priority and consensus-determined ordering. While this might help some transactions, Schwartz identified a paradox — the existence of the flag would create an asymmetry that could actually make front-running and sandwich attacks easier against transactions that do not use the flag. "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 flatly, dismissing the proposal as a net solution.
The analysis underscores the XRP Ledger's ongoing struggle with transaction ordering risks and highlights the Ripple development team’s cautious approach. Schwartz emphasized that future changes must strengthen security without introducing new attack vectors or degrading performance.
