TL;DR:
- The mechanism introduces a ledger object named ReservedTxns that stores an index with a strict limit of up to 32 transaction identifiers per block.
- Users who wish to secure a priority execution space must register a TxnReserve type transaction with a minimum fee equivalent to twice the standard network cost.
- The time window to apply the reservation is restricted to a maximum of 16 ledgers into the future relative to the block analyzed in real time.
The co-founder of XRP Ledger and Emeritus CTO of Ripple, David Schwartz, presented a technical proposal to mitigate transaction manipulation risks on the network. The mechanism introduces a transaction reservation infrastructure specifically designed to block front-running activities and sandwich attacks within the platform’s native decentralized exchange (DEX) and automated market makers (AMM). The initiative comes as a direct response to analytical concerns regarding the visibility of priority trades in the order book.
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
Technical operation of the anti-blocking system on XRPL
The framework designed by Schwartz proposes two main components in the protocol’s consensus structure. The first element, the ReservedTxns ledger object, inherently stores the target ledger sequence number along with the vector of authorized transactions. The technical report indicates that once the specific block enters execution, all listed operations that are part of the consensus set receive absolute priority, processing before any other commercial transfer on the network.
The second component is integrated through the TxnReserve transaction type. This modality empowers financial operators to claim an execution slot by paying an indexed fee regulated by network dynamism. According to the provided technical specifications, to prevent the system from being used as a tool for malicious saturation or spam, the XRPL server software retains reserved transactions and restricts their mass disclosure. The system releases data only in the immediate proximity of the previous ledger’s closing, compressing the visibility window prior to validation.
The front-running problem and the governance debate
The vulnerability originally pointed out by the analysis firm XRPresso.io lies in the pending transactions that remain in the XRPL public queue before each block closes. Because the execution order in this ecosystem is governed by deterministic formulas based on hashes, market agents with highly connected nodes can repeatedly send transactions to position themselves advantageously against a large retail trade.
Although Schwartz stipulates that all nodes have the same technical access to this public data queue and that the real risk requires a complex scenario of simultaneous low and high liquidity, the proposal seeks to equip the system with a rigid layer of economic integrity.
It is worth noting that this approach is currently under community evaluation and has not acquired official amendment status. In the XRP Ledger governance design, any structural modification requires the favorable vote of a supermajority of network validators before its definitive deployment on the mainnet.
