Consensus-Based Transaction Ordering on XRPL Carries Significant Tradeoffs, Schwartz Warns

David Schwartz, Ripple CTO Emeritus, has outlined a potential approach to addressing front-running and sandwich attack risks on XRP Ledger payments and offer crossing — while simultaneously flagging why the most viable solution may not be worth implementing.

Schwartz proposed a transaction reservation scheme earlier in the week, designed to eliminate front-running risks by reserving transaction slots. Under this model, a transaction would be guaranteed to execute before any subsequent transactions created after it are disclosed to the network.

The proposal drew responses from across the XRP community. One user on X suggested adding a timestamp accurate to the second, so that transactions could be ordered chronologically — meaning any transaction submitted after another would automatically be placed behind it in the queue.

Ripple software engineer Mayukha Vadari addressed that suggestion directly, explaining it would not be feasible. Different nodes across the peer network receive transactions at slightly different times due to propagation delays, making second-level timestamp ordering unreliable in practice.

Schwartz then outlined what he described as the closest practical alternative: consensus-based transaction ordering, where validators vote on the sequence of transactions as part of the existing consensus process. He acknowledged, however, that this approach carries substantial drawbacks.

The most significant disadvantage, according to Schwartz, is speed. Introducing transaction ordering into the consensus process would increase the number of bits on which validators must reach agreement, slowing the entire consensus mechanism considerably.

Schwartz also described a more limited option: a flag that individual transactions could set to request sequencing. Transactions carrying that flag would receive priority in relaying over unflagged transactions within the same ledger, and their ordering would be determined by consensus. An extra fee would apply to transactions using the flag.

Despite its targeted scope, Schwartz rejected this option as well. His concern is that a two-tier system — flagged transactions ordered by consensus, unflagged ones not — would actually make it easier to front-run or sandwich the unflagged transactions.

'I don't think it's worth it though, particularly because it makes it easier to front-run or sandwich transactions that don't set the flag,' Schwartz stated.

The discussion reflects ongoing efforts within the XRP Ledger development community to harden the protocol against manipulation strategies common in decentralized exchange environments. No formal proposal or amendment has been submitted to the XRPL for a vote at this stage.