David “JoelKatz” Schwartz, Ripple’s former chief technology officer and a prominent XRPL architect, has outlined a transaction reservation proposal aimed at addressing concerns about front running and sandwich attacks on XRP Ledger payments, offer crossing, decentralized exchange activity and AMM usage. The proposal was posted on X after XRPL-focused account XRPresso.io argued that transaction visibility before ledger close can disadvantage regular users and create opportunities for sophisticated actors to extract value.
XRPL Slot Reservations Target Front Running
XRPresso.io framed the issue as one involving access to pending transaction information before a ledger closes, particularly for validators and well-connected nodes. The account wrote: “Validators and well-connected nodes can view transactions in the pre-validation queue before a ledger closes. They can quickly analyze a pending trade, determine if front-running or sandwiching it is profitable, and then spam their own transactions to try and game their position in the canonical order for that ledger.” The concern, as described in the post, is that repeated submissions can improve the odds of landing in a favorable ordering position because ledger ordering is tied to transaction hashes.
Schwartz responded that he is “not that concerned” about the issue for reasons he said he had previously explained, but still proposed a mechanism intended to remove the attack path. “But I have a proposal for a fairly simple scheme that would eliminate this attack. It’s a transaction reservation scheme that can ensure that a transaction executes before any transaction that was formed after it was disclosed.” In his design, users would reserve an execution slot for a specific transaction in a future ledger, creating a priority window that prevents later-formed transactions from being placed ahead of it.
The proposed mechanism introduces a new ledger object called ReservedTxns, containing a ledger sequence number and an array of transaction IDs. It would be stored at an index derived from a hash of a fixed string and the ledger sequence number. Schwartz also proposed a new TxnReserve transaction, which would take a ledger number and transaction ID as parameters and succeed only if it pays at least twice the normal transaction fee, satisfies normal execution requirements, targets a ledger more than the current sequence but no more than 16 ledgers ahead, and fits within a ReservedTxns object holding fewer than 32 transaction IDs without duplicating the same ID.
Fee Ratchets Aim to Deter Reservation Spam
The execution model would add reserved transactions before ordinary transaction processing in the relevant ledger. If a ReservedTxns object exists for that ledger sequence number, each transaction ID in the reserved set would be checked; if the transaction is in the consensus set, it would execute and then be removed so it cannot execute again. The reserved transaction object would then be removed from the ledger, returning execution to normal transaction handling.
Schwartz also described how reserved transactions should be broadcast to preserve the intended ordering protection. “If a transaction has a reserved slot in ledger X, the transaction should be broadcast as soon as it is known ledger X-1’s initial proposals are all received or the final consensus transaction set is known. The XRPL software should be modified to provide a feature to disclose when that occurs and, if desired, to hold a list of transactions to broadcast when, and only when, that happens.” He added that software should rebroadcast a reserved transaction if it has not been broadcast recently, even if the server expects the transaction to fail, because the relaying cost has already been paid through the doubled reservation fee.
The proposal also addresses denial-of-service concerns, including the possibility that an attacker could continuously fill future reservation slots to block other users from using the protection. Schwartz wrote that a fee ratchet could make that strategy impractical: “A simple fix is to ratchet up the fees for the reservation transaction as the object starts to get full. For example, when we hit 16 reserved slots, we could begin to raise the fee linearly up to the base reserve. By the time we hit 30, the fee could go up to three times the base reserve.” He further noted that the slot limit could rise to 64 if users were willing to keep paying, while an attacker would have to pay “every five seconds” several times more than what others would likely pay to protect a transaction.
Schwartz’s post presents the reservation model as a technical proposal rather than a completed XRPL change, and the post did not state whether it has entered a formal amendment process. Still, the design directly responds to community concerns around pending-transaction visibility, deterministic ordering and value extraction on XRPL trading venues by proposing explicit execution priority for pre-reserved transactions, paired with escalating costs to discourage slot exhaustion.
AI Transparency Note: This article was prepared with the assistance of an AI system based on the sources listed and was reviewed, edited, and approved by a human editor before publication. All quotes, data points, and factual claims are intended to be grounded in the cited source material; however, errors cannot be ruled out entirely.
About Me
Hodl Herald is the fastest and most honest reporter in the entire crypto universe. With glowing Bitcoin and Ethereum eyes, he scans the news, on-chain data, and expert commentary around the clock—always cool-headed, always fact-based, and completely immune to hype. No moonboy promises, no fake analysts, no paid shills. Just verified analysis from real industry leaders and respected research firms.
Of course, even the best AI journalist is not perfect. That is why every single article is thoroughly reviewed, fact-checked, corrected, and approved by our human editor-in-chief before publication.
That is how we combine the incredible speed and precision of AI with real human accountability and journalistic rigor. Hodl Herald stands for a new era of crypto journalism: fast, transparent, independent, and trustworthy.
Hodl on—the future has a robot.
