Ripple CTO Emeritus David Schwartz has proposed a transaction reservation system for the XRP Ledger, targeting concerns that some payments and offer-crossing transactions could be exposed to front-running or sandwich attacks before a ledger closes.
The proposal centers on a simple idea: users would reserve execution priority by broadcasting only a transaction ID before revealing the full transaction. That would let a user secure a slot without immediately disclosing the trade details that could make the transaction profitable to copy, front-run or sandwich.
The issue is tied to how pending transactions can be seen before validation. Validators and well-connected nodes may be able to observe transactions in the pre-validation queue, analyze whether a pending payment or trade can be exploited, then submit their own transactions in an attempt to influence the final execution order.
Schwartz’s proposal would add a ReservedTxns ledger object and a new TxnReserve transaction type. A user would submit the transaction ID, pay a higher fee, and reserve space in a future ledger before revealing the actual transaction content.
How The Reservation Scheme Would Work
The proposed TxnReserve transaction would include a target ledger number and transaction ID. It would need to pay at least twice the normal transaction fee and satisfy standard execution rules.
The ledger number would need to be greater than the current ledger sequence number and no more than 16 ledgers ahead. The ReservedTxns object for that ledger would either need to be empty or contain fewer than 32 transaction IDs, and it could not already include the same transaction ID.
Once a transaction is reserved, the full transaction would execute later based on reservation order. Schwartz’s design would place reserved transactions after consensus on the prior ledger, giving the network a way to honor execution slots without requiring users to reveal sensitive details too early.
That approach would not hide every transaction forever. It would instead narrow the window in which an attacker can see the full transaction, estimate its profit potential and try to reorder around it. The design is aimed at making certain forms of pre-ledger manipulation harder without removing normal ledger validation.
XRPL Security Debate Moves Back To Ordering Risk
The proposal adds a new technical angle to a long-running XRPL debate over validator visibility, transaction ordering and network control. Schwartz has previously pushed back against claims that Ripple can control the XRP Ledger, arguing that the network’s design limits any single party’s authority over validation and transaction acceptance. That dispute returned earlier this year when Schwartz challenged claims that the XRP Ledger is centralized.
Front-running risk is a different problem from centralization claims. It does not require one entity to control the chain. It can come from early visibility, faster connectivity, better monitoring and the ability to submit competing transactions before ledger close.
The reservation proposal also fits into a wider period of XRPL security discussion. Ripple has already outlined work on quantum-resistant XRPL planning, while developers and traders continue to evaluate how the ledger handles payments, liquidity, token activity and institutional use cases.
The reservation system has not been adopted as an XRPL amendment. It is a technical proposal from Schwartz, with debate now focused on fees, slot limits, validator behavior, transaction privacy and whether a reservation layer would reduce front-running without adding new complexity to the XRP Ledger. XRP recently traded near $1.04.
Be the first to comment