Ripple CTO Proposes Reserved Transactions to Block Front-Running on XRPL DEX
David Schwartz, co-founder of the XRP Ledger (XRPL) and Ripple CTO Emeritus, has put forth a proposal for a two-component transaction reservation mechanism designed to combat front-running and sandwich attack risks on XRPL’s native Decentralized Exchange (DEX) and Automated Market Maker (AMM).
The proposal emerged in response to concerns voiced by XRP-focused analytics account XRPresso.io. It introduces a system that guarantees priority execution for users willing to pay a reservation fee. This measure is intended to bolster market integrity, particularly as institutional investment in XRP products continues to grow.
Currently, the proposal is under community discussion and has not yet been formalized as a network amendment. This distinction is significant, as protocol changes on the XRP Ledger require a supermajority of validators to approve before activation. Schwartz’s design, while influential, must navigate a defined governance process before potentially being implemented on the mainnet.
The proposed scheme involves two new protocol components. The first is a ReservedTxns ledger object, which will store a target ledger sequence number and an array of up to 32 transaction IDs. When the specified ledger executes, any transactions listed in this object that are present in the consensus set will be processed first, ahead of all other transactions. The object will then be deleted. The second component is a TxnReserve transaction type, enabling users to claim a priority slot for one or more future transactions by submitting a reservation before the target ledger closes.
Concerns have been raised regarding the potential for front-running and transaction sandwich attacks on XRPL payments and offer crossing. Schwartz, however, has expressed less concern about this issue, citing his proposed solution as a “fairly simple scheme that would eliminate” these risks.
Three constraints govern the TxnReserve mechanism. The reservation fee must be at least double the standard transaction fee. The target ledger must be within 16 ledgers of the current one. Crucially, the actual transaction must set its LastLedgerSequence to match the reserved ledger.
These rules are designed to define both the economic cost of using the system and the narrow operational timeframe. The 16-ledger limit ensures that reservations are tightly linked to near-term execution, preventing the mechanism from being exploited as a general-purpose tool for queue manipulation.
Denial-of-Service (DoS) protection is integrated through dynamic fee scaling. As reservation slots fill beyond 16, fees increase incrementally, reaching several multiples of the base reserve near 30 slots. Schwartz also indicated that XRPL server software would hold reserved transactions and release them only as the proposals for the preceding ledger become known, thereby 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 stated. “You would use this approach any time you want to perform a transaction that you want to ensure cannot be sandwiched or front run.”
XRPresso’s concerns stem from a structural characteristic of the XRP Ledger: pending transactions reside in a publicly visible queue before a ledger closes, granting validators and well-connected nodes advance insight into incoming trades. Because canonical transaction ordering on XRPL is determined by a known, deterministic formula involving transaction hashes, a sophisticated actor could repeatedly submit similar transactions to increase their chances of securing a favorable slot relative to a target trade, forming the basis for a sandwich attack on the DEX or AMM.
Schwartz acknowledged this potential exposure but contested the framing of the issue. He argued that all participants have equal access to the public queue and that validators gain no inherent ordering advantage unless multiple parties collude. “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 confirmed attempts have been made beyond proof-of-concept exercises.
He also highlighted a practical profitability constraint: extracting significant value requires both high liquidity (to generate substantial volume) and low liquidity (to influence price at a manageable cost), a combination rarely found on XRPL. This argument, while not fully satisfying all critics, does differentiate XRPL’s current risk profile from the historically active Miner Extractable Value (MEV) environment seen on Ethereum.
The debate surrounding front-running in decentralized finance is not confined to the XRP ecosystem. Binance co-founder Changpeng Zhao proposed a dark pool perpetuals DEX last year that utilized zero-knowledge cryptography to obscure order data until execution. This approach, however, drew criticism from decentralization advocates who argued it recreated the information asymmetries that cryptocurrency was intended to eliminate.
XRPresso echoed a similar sentiment in response to Schwartz, contending that targeted confidentiality for pending transaction details would represent a more robust long-term solution than a reservation fee layer, and pointed to existing implementations on competing blockchain networks.
Leave a Reply