Ripple CTO David Schwartz has outlined a new mechanism for XRPL that would let users reserve execution slots for future ledgers. The proposal targets renewed concerns over front-running and sandwich attacks on the XRP Ledger, with the debate centered on transaction ordering and visibility before ledger finalization.
ReservedTxns would assign transaction IDs to future ledger slots
Under the proposal, XRPL would add a new ledger object called ReservedTxns. It would store transaction IDs that are assigned to a future ledger sequence. To claim a slot, a user would submit a new transaction type known as TxnReserve. If accepted, the transaction ID would be added to the reservation list and would receive priority execution in the designated ledger.
The reservation model comes with fixed limits. A TxnReserve would require at least double the normal transaction fee. The target ledger must be ahead of the current ledger and no more than 16 ledgers away. Each reservation object could hold no more than 32 transaction IDs, and it could not include a transaction ID that had already been submitted.
Timing rules are meant to narrow the attack window
Schwartz said reserved transactions should be broadcast after ledger X-1 reaches consensus. He also proposed that the last valid ledger be set to the ledger where execution is expected. In his view, that would reduce the chance that delayed transactions remain exposed long enough to become targets for front-running or sandwich attacks.
The execution flow would place reserved transactions before normal processing begins. XRPL would first check whether a ReservedTxns object exists. If it does, the network would execute each reserved transaction found in the consensus set, remove those transactions from the set, and then delete the reservation object after processing. Standard transaction execution would continue only after that sequence is complete.
Rising fees are part of the anti-abuse design
Schwartz also addressed denial-of-service risks. He said attackers could try to fill reservation slots across multiple ledgers. To reduce that risk, he proposed raising reservation fees as the number of available slots declines, so the cost would increase progressively as reservation capacity nears its limit.
The latest proposal comes as XRPresso.io has been detailing the current issue on XRPL. According to the platform, validators and well-connected nodes may be able to view pending transactions before ledger closure. That visibility can let participants analyze pending trades and submit multiple transactions to improve their place in the final ordering. XRPresso.io said the behavior can hurt DEX and AMM users through sandwich attacks and unfavorable slippage, and noted that transaction visibility, ordering design, and privacy upgrades have been under discussion in the XRPL community for years.