- David Schwartz proposed reserving transaction slots to improve ordering and reduce front-running on XRPL.
- The system would prioritize reserved transactions while using higher fees to discourage spam and abuse.
- The proposal follows renewed concerns over transaction visibility and sandwich attacks on the XRP Ledger.
Concerns over front-running and sandwich attacks on the XRP Ledger have resurfaced after Ripple CTO David Schwartz proposed a new transaction reservation system. Schwartz shared the proposal while addressing ongoing discussions around transaction ordering on XRPL. At the same time, XRPresso.io highlighted how validators and well-connected nodes can potentially exploit visibility into pending transactions before ledger finalization.
Schwartz Details Transaction Reservation Model
According to David Schwartz, the proposal introduces a new ledger object called ReservedTxns. The object would store transaction IDs assigned to a future ledger sequence. To secure a slot, users would submit a new transaction type called TxnReserve.
The transaction would require at least double the normal transaction fee. However, several conditions would apply. The target ledger must be ahead of the current ledger and within 16 ledgers. In addition, the reservation object could contain no more than 32 transaction IDs.
The object also could not already contain the submitted transaction ID. If approved, the transaction ID would enter the reservation list. Consequently, the transaction would receive priority execution in its designated ledger.
Schwartz said users should broadcast reserved transactions after ledger X-1 reaches consensus. He also proposed setting the last valid ledger to the expected execution ledger. According to the proposal, those steps would prevent delayed transactions from becoming targets for front-running or sandwich attacks.
Execution Process Prioritizes Reserved Transactions
As the proposal advances, Schwartz outlined how execution would work. Before normal transaction processing begins, XRPL would check for a ReservedTxns object. If one exists, the network would execute each reserved transaction found in the consensus set.
The system would then remove those transactions from the set. After processing completes, XRPL would delete the reservation object. Normal transaction execution would then continue. Schwartz also addressed potential denial-of-service concerns.
He noted that attackers could attempt to fill reservation slots across multiple ledgers. To counter that risk, he proposed increasing reservation fees as available slots decline. Fees could rise progressively as reservation capacity approaches its limit.
XRPresso.io Highlights Existing Concerns
While Schwartz presented a solution, XRPresso.io described the current issue in detail. According to the platform, validators and connected nodes can view transactions before ledger closure.
The report stated that participants can analyze pending trades and submit multiple transactions. By doing so, they may improve their position in the ledger’s final ordering.
XRPresso.io said this behavior can affect DEX and AMM users through sandwich attacks and unfavorable slippage. The report added that discussions around transaction visibility, ordering mechanisms, and privacy improvements have remained active within the XRPL community for years.
