Ex-Ripple CTO Says State-Backed XRPL Attack Would Be a ‘Financial Gift’ to XRP Holders

Ripple CTO Emeritus David Schwartz has defended his proposed solution for preventing front-running and sandwich attacks on the XRP Ledger (XRPL). 

He argued that even a state-sponsored attacker would struggle to make such an attack practical.

His comments came after X user @0xSCSamurai criticized the proposal. The user claimed its denial-of-service (DoS) protections would be ineffective because well-funded state actors could keep attacking the network indefinitely.

Schwartz rejected that argument. He said that if such an unlikely scenario ever occurred, the network could simply raise the cost of the attack.

“If that happens, we can just raise the cost of the attack, and it would either stop or be, in effect, a huge financial gift from state actors to XRP holders,” Schwartz wrote.

He also said the fee escalation mechanism could be adjustable through governance instead of being permanently fixed.

Proposal Would Let XRP Ledger Validators Adjust Fees

To strengthen the design, Schwartz proposed making the fee escalation system configurable through the XRPL’s existing voting process.

Under this approach, validators could adjust the parameters that control how reservation fees increase as transaction slots fill up. According to Schwartz, this would allow fees to rise only as much as necessary to discourage abuse without placing unnecessary costs on regular users.

He also questioned the assumption that a government-backed attacker would be willing to spend large amounts of money simply to keep the network at its current level of security.

It seems very weird to me to worry that any state actors or state-sposored actors would want to give thousands of dollars an hour to XRP holders just to make the XRPL no more vulnerable to front running and sandwich attacks than it is now.

— David ‘JoelKatz’ Schwartz (@JoelKatz) June 29, 2026

How the Reservation System Would Work

The discussion follows a detailed proposal Schwartz published earlier to eliminate front-running and sandwich attacks on XRPL payments and offer crossing.

His proposal introduces a new ReservedTxns ledger object and a TxnReserve transaction type.

Users could reserve an execution slot for a future ledger by paying at least twice the standard transaction fee. Reservations would only be valid for ledgers up to 16 ledger intervals in advance. Initially, each ledger would support up to 32 reserved transaction slots.

After reserving a slot, a transaction would be broadcast only after the previous ledger’s consensus process is effectively complete. This would prevent attackers from seeing the transaction early enough to insert competing transactions ahead of it.

During ledger execution, reserved transactions would be processed before the normal transaction set. They would then be removed from the reservation list, ensuring they execute in the intended order.

Rising Fees Aim to Prevent DoS Attacks

Schwartz acknowledged that an attacker could theoretically reserve every available transaction slot across multiple future ledgers. That could prevent others from using the protection mechanism.

To address this risk, he proposed gradually increasing reservation fees as available slots become scarce.

In his example, fee increases would begin once 16 of the 32 reservation slots had been filled. The fees would rise linearly until reaching three times the base reservation fee when 30 slots were occupied.

If demand increased, the reservation limit could also be expanded from 32 to 64 slots.

According to Schwartz, the escalating costs would make sustained attacks expensive. An attacker would have to spend several times more than legitimate users typically would to reserve transactions.

If an attacker still chose to continue, Schwartz argued that the fees collected would ultimately benefit the XRP Ledger ecosystem and, by extension, XRP holders.