David “JoelKatz” Schwartz has proposed a transaction reservation plan for the XRP Ledger after fresh claims that users may still face front-running and sandwich attacks on payments, offer crossing, DEX trades and AMM swaps.
Summary
- Schwartz proposed reserved XRPL transaction slots to place protected trades before later disclosed transactions first.
- XRPresso claimed queue visibility may expose payments, offers, DEX trades and AMM swaps to targeting.
- XRPL’s growing DeFi roadmap makes transaction ordering fairness a larger concern for users and builders.
The debate started after XRPresso said some actors may be able to view pending transactions before a ledger closes and use that information to target trades.
“A serious front-running issue continues on the XRPL that disadvantages regular users.” XRPresso said 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.
XRPresso said the issue matters most for users trading through wallets and dApps. According to the post, the final order inside each ledger follows a known deterministic process, and repeated submissions may raise the chance of landing near a target trade. That could worsen slippage for the original trader when a sandwich strategy succeeds.
Schwartz lays out a reservation scheme
“For the reasons I’ve explained, I’m not that concerned about this issue.” Schwartz wrote that the concern still deserved a practical answer. He then proposed a transaction reservation scheme that could make a disclosed transaction execute before any transaction formed after it became visible.
The plan would add a new ledger object called ReservedTxns. That object would hold a ledger sequence number and an array of transaction IDs. A new TxnReserve transaction would let a user reserve a slot for a transaction in a future ledger, as long as the request meets fee, timing and execution rules.
Schwartz said a reservation should cost at least twice the normal transaction fee. The target ledger would need 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.
Reserved transactions would run first
Under the proposal, a reserved transaction would be broadcast close to the point when the prior ledger’s proposals are known. Schwartz said XRPL software could add a feature to hold such transactions and release them only when that condition is met. The transaction should also set its last valid ledger to the ledger where it is expected to run.
When that ledger executes, the network would first check whether a ReservedTxns object exists for the ledger sequence number. If it exists, the network would execute listed transactions that are in the consensus set before other transactions. It would then remove them from the set to stop repeat execution and delete the reservation object.
XRPL documentation says canonical ordering is built to be deterministic, efficient and hard to game. Its DEX documentation also says transaction order is designed to discourage front-running because trades execute when a new ledger closes. However, XRPL’s algorithmic trading documentation says front-running is difficult, but not impossible.
DeFi upgrades raise the stakes
The timing comes as XRPL developers continue to expand the network’s DeFi stack. The XRPL Foundation recently proposed AMM Swappable Curves, a draft upgrade that would add StableSwap and concentrated liquidity options to the native automated market maker. XRPL is also preparing native lending and programmable escrow tools.
Those upgrades could bring more on-chain trading, credit and settlement activity to XRPL. Recent coverage also showed institutional use cases, including a tokenized Treasury settlement involving Ripple and JPMorgan. As activity grows, transaction ordering and pending trade visibility may draw more attention from builders, traders and validators.
Schwartz also addressed possible denial-of-service risks. He said an attacker could try to fill reservation slots across many ledgers, but rising fees could make that costly. Under one example, fees would rise once 16 slots are filled and could reach several times the base reserve near 30 slots. The proposal is not yet a formal amendment, but it gives the XRPL community a clear technical path to review.
Be the first to comment