Schwartz Pushes for Better Protection Against Sandwich Attacks on XRP Ledger
Schwartz says the risk is real, but limited on the XRP Ledger. He outlines a reservation mechanism to make front-running on the DEX and AMM harder.
Key Takeaways
- David Schwartz says sandwich attacks on the XRP Ledger are real, but he thinks the impact on regular traders is overstated.
- He points out that pending transactions are visible to everyone and that the consensus structure makes large-scale manipulation harder.
- Schwartz outlined a two-step reservation mechanism to reduce front-running and slippage for traders.
Ripple founder and former CTO David Schwartz says the concerns around sandwich attacks on the XRP Ledger are worth taking seriously, but not to the extent some traders fear. In his view, the threat is real, yet the effect on everyday users is being exaggerated. He also floated a potential fix: a reservation system designed to make front-running more difficult.
Why the Fear of Attacks Is Growing
The debate picked up on X after one account argued that validators and well-connected nodes have a timing edge because they can see pending transactions before a ledger closes. In that setup, more advanced traders could estimate whether front-running would pay off and then send several transactions to improve their place in the final order.
On the XRP Ledger, transaction ordering comes from a deterministic formula tied to transaction hashes. Because that formula is public, an attacker can try to get ahead of a target trade on the DEX or AMM. For ordinary users, that can mean worse slippage, especially when liquidity is thin. The worry is mostly centered on traders using popular wallets and dApps.
Schwartz Points to the Built-In Limits
Schwartz acknowledged that the issue is not imaginary, but he also said the XRP Ledger has some built-in constraints that limit the damage. He noted that pending transactions are visible to everyone before a ledger closes, so no one gets a private early look. He added that a single validator does not create a major edge, since any real coordination across multiple validators would be visible in their proposals and validations.
If a validator tried to push that kind of coordination, Schwartz said it could be dropped from the trust lists quickly once the behavior became obvious. The XRP Ledger’s broader Federated Consensus model depends on independent validators working together to determine transaction order and validity, which makes it harder for one actor to quietly game the system. Validators also rely on a Unique Node List, a trusted group of nodes, so large-scale coordination tends to stand out even faster.
Schwartz also said confirmed attacks, outside of proof-of-concept tests, have not been reported. On top of that, he argued the economics are not easy: an attacker would need enough liquidity to make the effort worthwhile, while the market would also need to be thin enough for the price to move.
Possible Fix for Traders
For users who want a stronger layer of protection, Schwartz described a two-step reservation model. In the first step, a trader submits a reservation that includes a future ledger sequence number, a transaction ID, and a small fee. If that reservation goes through, the actual trade would be processed ahead of any later published transaction. The tradeoff is that each protected transaction would require two separate submissions.
The idea builds on earlier privacy and infrastructure work around the XRP Ledger, but this version is aimed squarely at execution. For European crypto readers, that matters because fairness and order execution are becoming more important as more trading shifts to onchain order books and AMMs. Those choices affect not just how the platform feels to use, but also how appealing it is for serious trading and wider adoption.
XRP is still trading far below its all-time high, and the discussion around market structure and front-running protection shows how much layer-1 design details can shape user trust.
