David 'JoelKatz' Schwartz has proposed a transaction reservation plan for the XRPL after fresh claims that users may still face front-running and sandwich attacks on payments, offer crossing, DEX trades and AMM swaps. According to reports from XRPresso, some actors may be able to view pending transactions before a ledger closes and use that information to target trades. 'XRPresso stated that 'a serious front-running issue continues on the XRPL that disadvantages regular users'. The debate intensified after XRPresso revealed that validators and well-connected nodes can view transactions in the pre-validation queue, then submit their own transactions to seek a better position in the final ledger order. As reported by XRPresso, the issue matters most for users trading through wallets and dApps, where the final order inside each ledger follows a known deterministic process.
Schwartz's proposed solution involves creating a new ledger object called ReservedTxns that would hold a ledger sequence number and an array of transaction IDs. As reported by XRPresso, a new TxnReserve transaction would allow users to reserve a slot for a transaction in a future ledger, provided the request meets fee, timing and execution rules. The reservation should cost at least twice the normal transaction fee, with the target ledger needing to be greater than the current ledger and no more than 16 ledgers ahead. Each reserved object would hold fewer than 32 transaction IDs, unless the design later expands the cap. Under the proposal, a reserved transaction would be broadcast close to the point when the prior ledger's proposals are known, with XRPL software adding a feature to hold such transactions and release them only when that condition is met. For traders who want firmer guarantees, Schwartz outlined a 2-step reservation approach that requires two submissions per protected trade.
Under the proposed system, reserved transactions would be broadcast close to the point when the prior ledger's proposals are known. According to the proposal, XRPL software could add a feature to hold such transactions and release them only when that condition is met. When the target ledger executes, the network would first check whether a ReservedTxns object exists for the ledger sequence number and execute listed transactions that are in the consensus set before other transactions. The network would then remove them from the set to stop repeat execution and delete the reservation object. The transaction should also set its last valid ledger to the ledger where it is expected to run, ensuring proper execution timing. Schwartz described the protection plainly: 'This guarantees that you can execute your transaction ahead of any transaction that was formed after your transaction was disclosed. You would use this approach any time you want to perform a transaction that you want to ensure cannot be sandwiched or front run.'
Schwartz acknowledged the front-running concerns but pointed to several mitigating factors, drawing on his earlier positions in XRPL design debates. Schwartz emphasized that pending transactions are publicly visible to everyone before a ledger closes, with no party holding exclusive early access. He noted that a single validator gains no meaningful advantage, and coordinating multiple validators would leave clear evidence since validators sign all proposals and validations. 'Running a validator does not help you do this unless multiple validators conspire. If multiple validators did conspire, or a single validator attempted it, it would be very obvious to everyone exactly who was doing this and that validator would be immediately removed from everyone's trust lists,' Schwartz stated. He also pointed out that confirmed attacks, beyond proof-of-concept testing, remain unreported, and the core economic barrier is that profitable attacks need high liquidity to justify the effort and low liquidity to move the price, conditions that rarely coincide.
The proposal comes as community discussion around the XRPL payment infrastructure intensifies, coinciding with active community voting on the XRPL 3.2.0 upgrade. However, some community members have raised concerns about the 2× fee requirement and pre-validation visibility issues. XRPresso.io acknowledged that while the reservation idea is interesting, the 2× fee requirement complicates things without addressing the core issue of pre-validation visibility. They prefer a targeted confidentiality solution for pending order details, similar to the approach suggested by Binance co-founder Changpeng Zhao, which utilizes zero-knowledge cryptography to conceal order data until execution. However, critics argue that this privacy-centric method risks recreating insider information dynamics that public blockchains aimed to eliminate. No formal vote on the proposal has taken place, and the specifications are not finalized, with the community's direction influencing the AMM and DEX infrastructure as on-chain trading grows.
