XRP Ledger Sandwich Attacks: Former Ripple CTO Offers a Practical Solution

Former Ripple Chief Technical Officer David Schwartz has stepped into the debate over sandwich attack vulnerabilities on the XRP Ledger, arguing that while the threat is legitimate, it has been significantly exaggerated in recent discussions.

The conversation gained traction on social platform X after a post claimed that validators and well-connected network nodes enjoy a timing advantage by monitoring pending transactions before each ledger cycle closes. According to the argument, sophisticated participants can calculate whether front-running a specific trade would be profitable, then flood the network with multiple transactions to secure a strategically favorable position in the canonical ordering queue.

**How Sandwich Attacks Work on XRPL**

Transaction ordering on the XRP Ledger relies on a deterministic algorithm that incorporates transaction hashes — and crucially, this algorithm is publicly available. That transparency creates a potential opening for malicious actors to position their own transactions around a target trade on both the XRP Ledger DEX and its AMM pools, ultimately worsening slippage for regular users.

Critics expressed concern that this dynamic creates an unequal environment, especially for participants relying on widely-used wallets and decentralized applications built on the network.

**Schwartz: Coordination Would Be Immediately Visible**

While acknowledging the underlying concern, Schwartz outlined several factors that significantly limit the practical risk of such attacks. Drawing on his background in XRP Ledger architecture, he noted that all pending transactions are visible to every network participant before a ledger closes — meaning no single party holds an exclusive information advantage.

Moreover, a lone validator gains no meaningful edge. Executing a successful coordinated attack would require multiple validators acting in concert, and any such conspiracy would leave an unmistakable audit trail, since validators cryptographically sign all proposals and validations.

"Running a validator does not help you do this unless multiple validators conspire. If multiple validators did conspire, or a single validator attempted it, it would be very obvious to everyone exactly who was doing this and that validator would be immediately removed from everyone's trust lists," Schwartz stated.

He also pointed out that no confirmed real-world attacks — beyond controlled proof-of-concept demonstrations — have been documented. The economics work against attackers as well: a profitable sandwich attack requires simultaneously high liquidity to justify the overhead and low liquidity to generate meaningful price impact. These two conditions seldom align in practice.

**A Two-Step Reservation Model as a Fix**

For users seeking stronger execution guarantees, Schwartz proposed a transaction reservation mechanism. The process works in two stages: a user first broadcasts a reservation that specifies a future ledger sequence number, a unique transaction identifier, and a nominal fee. Once that reservation is confirmed on-chain, the actual trade executes ahead of any transaction submitted after the reservation became public knowledge. The trade-off is that each protected transaction requires two separate submissions.

This approach targets front-running at the execution layer rather than the data layer, complementing existing XRP Ledger privacy transfer proposals that address related concerns from a different angle.

**Broader Context**

The discussion arrives as XRP continues trading well below its historical all-time high. Market observers are watching whether fairness-enhancing improvements — such as the reservation scheme Schwartz described — could contribute to stronger long-term adoption by making the XRP Ledger DEX more competitive and trustworthy for everyday traders and institutional participants alike.