Key Insights
- David Schwartz proposed a reservation system to reduce front-running and sandwich attacks on XRPL.
- The proposal asks that users pay double at least the regular transaction fee to reserve execution slots.
- This comes as XRPL continues to develop its DeFi ecosystem with new lending features and AMM capabilities.
In case of intense worry over front-running and ‘sandwich attacks,’ David Schwartz, a founding developer of the XRP Ledger and the former chief technology officer at Ripple, has put forward a novel transaction reservation mechanism for XRPL.
The proposal aims to improve the fairness of trades as the use of decentralized finance (DeFi) on the network expands and trading volume keeps rising.
It was here that concerns were raised by the community by the time of pending transaction’s visibility before ledger validation was discussed. They stated that those transactions could be checked by validators and ‘well-connected nodes’ before they are done. They claim that with ‘privileged visibility’ it would be possible for some of the participants to see profitable trades and place competing trades before the primary trades are executed.
Concerns are raised in the community resulting in a technical response
The discussion picked up with the warning from XRPresso that even regular traders would be at risk when dealing using the DAMMs and decentralized exchanges. The discussion includes the possibility of actors accessing the pre-validation queue and reviewing their pending transactions and submitting many orders that compete with one another to gain a better spot in the end-of-ledger sequence.
The documentation on XRPL explains that canonical transaction ordering is designed to prevent anyone from easily knowing what transactions will be executed first. But developers recognized that under some circumstances, it is possible for any determined participant to exploit the pending transaction visibility.
Schwartz responded by saying he does not consider the issue a significant threat today. Even so, he presented a practical solution that could remove the attack vector for users seeking stronger protection.
“I have a proposal for a fairly simple scheme that would eliminate this attack,” Schwartz wrote while outlining the framework.
The proposed system introduces a new ledger object called ReservedTxns. That object would store transaction identifiers assigned to a future ledger before public execution.
Users would reserve execution slots by submitting a new transaction type named TxnReserve. Each reservation would require a fee worth at least twice the standard transaction cost while meeting existing execution requirements.
Proposal overview
Feature Proposed Rule
Reservation object: ReservedTxns
Reservation transaction: TxnReserve
Minimum fee: Twice the normal transaction fee
Maximum reservation window: 16 future ledgers
Maximum slots per ledger: 32 transaction IDs
Reserved transactions receive execution priority
Under Schwartz’s proposal, reserved transactions would remain undisclosed until consensus information from the previous ledger becomes available. That timing would reduce opportunities for attackers to observe and react before execution.
Once the target ledger closes, the network would process reserved transactions before all standard transactions. After execution, the protocol would remove completed reservations to prevent duplicate processing.
Schwartz also talked about the denial-of-service attacks. He said that if the attackers were to try to book large amount of slots, then the cost will be increased because reservation fees will be increasing as the capacity is reduced. That pricing model might curb the incentive to try to monopolize future ledger space and give people the right to keep sending transactions on the network.
The proposal is not yet an amendment but is a preliminary technical suggestion. However, it offers the developer a transparent guide for community review and discussion.
Growing DeFi activity raises the importance of transaction ordering
XRPL is rapidly building its own decentralized finance ecosystem, with the proposal coming just after that. StableSwap plans, focused liquidity pools, native lending and programmable escrow were among the new options that developers recently introduced.
The improvements may stimulate more trading activity on decentralized exchanges and bring in more institutional players. More trades would also draw more focus to the fairness of execution, especially for high-ticket trades executed on automated market makers and decentralized exchanges.
As decentralized finance (DeFi) continues to mature, industry watchers have pointed out that transaction ordering is emerging as a significant concern in various blockchain networks. Solutions that increase execution fairness can also enhance user’s trust and foster wider institutional uptake.
Schwartz argues that front-running is still tough with the current protocol, but his idea is an optional addition to help ensure traders who deal with time-sensitive orders are not “burned. The community will now decide whether or not to take the next step in formalizing the reservation system.
Conclusion
In its recent development, Schwartz’s idea has become the newest proposal to enhance transaction security in the growth of XRPL from payments to other decentralized finance applications. The design is still under evaluation and the reservation model offers a structured approach that might alleviate risks of front-running while maintaining the current consensus system of the network.
