David Schwartz, co-founder of the XRP Ledger and Ripple CTO Emeritus, has proposed a two-component transaction reservation mechanism to address front-running and sandwich attack risks on XRPL’s native DEX and AMM.
The proposal, surfaced in response to concerns raised by XRP-focused analytics account XRPresso.io, introduces priority execution guarantees for users willing to pay a reservation fee, a market-integrity measure with direct relevance as institutional inflows into XRP products continue to scale.
Xrp (XRP)24h7d30d1yAll time
The proposal is currently under community discussion and has not been formalized as a network amendment. That distinction matters: on the XRP Ledger, protocol changes require a supermajority of validators to vote in favor before activation, meaning Schwartz’s design carries weight but faces a defined governance process before it touches mainnet.
Discover: The Best Token Presales
How the Ripple XRP ReservedTxns Mechanism Actually Works
The scheme introduces two new protocol components. The first is a ReservedTxns ledger object, which stores a target ledger sequence number and an array of up to 32 transaction IDs.
When that specific ledger executes, any listed transactions present in the consensus set are processed first, ahead of all other transactions, after which the object is deleted. The second component is a TxnReserve transaction type, which allows a user to claim a priority slot for one or more future transactions by submitting a reservation before the target ledger closes.
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
Three constraints govern the TxnReserve: the reservation fee must be at least twice the standard transaction fee; the target ledger must fall within 16 ledgers of the current one; and the actual transaction must set its LastLedgerSequence to match the reserved ledger.
Those rules are not incidental, they define both the economic cost of using the system and the narrow time window in which it operates. The 16-ledger ceiling keeps reservations tightly coupled to near-term execution, preventing the mechanism from being weaponized as a general-purpose queue-gaming tool.
DoS protection is built in through dynamic fee scaling: as reservation slots fill past 16, fees step upward, reaching several multiples of the base reserve near 30 slots. Schwartz also specified that XRPL server software would hold reserved transactions and release them only close to when the prior ledger’s proposals are known, compressing the pre-execution visibility window.
“This guarantees that you can execute your transaction ahead of any transaction that was formed after your transaction was disclosed,” Schwartz said. “You would use this approach any time you want to perform a transaction that you want to ensure cannot be sandwiched or front run.”
The XRPL-Specific Front-Running Problem Schwartz Is Solving
XRPresso’s concern centers on a structural feature of the XRP Ledger: pending transactions sit in a publicly visible queue before a ledger closes, giving validators and well-connected nodes advance sight of incoming trades.
Because canonical transaction ordering on XRPL is determined by a known, deterministic formula involving transaction hashes, a sophisticated actor can submit similar transactions repeatedly to increase the probability of landing in a favorable slot relative to a target trade, the mechanistic basis for a sandwich attack on the DEX or AMM.
Reserved transactions in a particular ledger execute in the order in which they were reserved. I don't show my transaction until after it's got a reserved slot in the very next ledger. So the only way you could do this is if you already had a reserved slot before my reservation…
— David 'JoelKatz' Schwartz (@JoelKatz) June 29, 2026
Schwartz acknowledged the exposure but contested the framing. He argued that all participants have equal access to the public queue, and that validators gain no structural ordering advantage unless several conspire.
“If multiple validators did conspire, or a single validator attempted it, it would be very obvious to everyone exactly who was doing this,” he said, adding that no such attempt has been confirmed outside of a proof-of-concept.
He also flagged a practical profitability constraint: extracting meaningful value requires simultaneously high liquidity (to generate volume worth targeting) and low liquidity (to move price at manageable cost), a combination rarely present on XRPL.
That argument has not fully satisfied critics, but it does distinguish XRPL’s current risk profile from Ethereum’s historically active MEV environment.
The front-running debate in DeFi is not isolated to the XRP ecosystem. Binance co-founder Changpeng Zhao proposed a dark pool perpetuals DEX last year using zero-knowledge cryptography to conceal order data until execution, an approach that drew its own criticism from decentralization advocates who argued it recreates the information asymmetries crypto was designed to eliminate.
XRPresso made a similar argument in response to Schwartz, contending that targeted confidentiality for pending transaction details would be a cleaner long-term fix than a reservation fee layer, and pointing to implementations already live on competing chains.
Don’t Miss Out on Our $1,000 USDT Airdrop on ByBit
The post Ripple CTO Proposes ReservedTxns to Block Front-Running on XRPL DEX appeared first on Cryptonews.
