# XRP Ledger proposes ReservedTxns to block front‑running bots

**Published:** 2026-07-04T17:04:06.046Z  
**Topic:** Xrp%5C  
**Sentiment:** neutral  
**Publisher:** TrendWatcher — https://www.trendwatcher.in/article/fbb5fb7b-d7ed-45ee-9595-9f159ff04027

XRP Ledger co‑creator David Schwartz proposes a reservation system costing double fees to stop front‑running, a $1.4 M loss estimate, and requires 80%

A proposed protocol change would let XRP Ledger users reserve a priority slot for a trade, costing at least twice the normal fee, to make front‑running and sandwich attacks impossible once the slot is locked [1].

| At a glance | |
|---|---|
| Proposal | ReservedTxns reservation system |
| Fee increase | ≥ 2 × standard transaction fee |
| Slot horizon | Up to 16 ledgers ahead |
| Approval needed | 80 % of validators for two weeks |

## How the reservation system works  
The design adds two new ledger objects. **ReservedTxns** stores a target ledger number and up to 32 transaction IDs; when that ledger closes, the listed transactions are processed first, then the object is deleted. **TxnReserve** lets a user claim a slot by submitting a reservation transaction that includes a fee at least double the base fee and a target ledger no more than 16 ledgers away [2]. The fee rises as slots fill, deterring any single actor from hoarding capacity. By the time the reserved transaction is revealed, other participants cannot insert a preceding order, eliminating the window that bots exploit on the public queue.

## Why the change is being discussed now  
Front‑running on the XRP Ledger is not impossible; its own documentation describes the transaction order as “hard to game” but admits attacks can succeed. A 2023 study estimated that bots could have extracted roughly **$1.4 million** from traders over two months [1]. The issue resurfaced after XRPresso highlighted that validators and well‑connected nodes can see pending transactions before the ledger finalises, enabling sandwich attacks especially on the network’s growing AMM pools—now over **27,500** [1]. As institutional inflows into XRP products increase, the potential profit from such attacks scales, prompting Schwartz’s proposal as a pre‑emptive safeguard.

## Governance and timeline  
The reservation mechanism is still a proposal; it must be formalised as a network amendment and receive a super‑majority vote from validators—at least **80 %** support for two consecutive weeks—before activation [2]. Until such a vote passes and code is deployed, the feature remains a discussion point rather than a live protection.

## What to watch
- **Validator voting**: Track any upcoming amendment proposals and validator support percentages.  
- **Fee dynamics**: Monitor the reservation fee multiplier as slots fill; a sharp rise would indicate high demand for protection.  
- **AMM activity**: Watch trading volume in XRP Ledger AMM pools; a surge could increase the incentive for front‑running and test the reservation system’s effectiveness.

If adopted, the ReservedTxns mechanism could close a known vulnerability just as the XRP Ledger’s trading activity expands, reinforcing its claim of institutional‑grade security while adding a cost layer for users seeking guaranteed execution order. The open question is whether the validator community will rally behind the change before the next wave of high‑volume trading arrives.

## Sources
1. AOL — [David Schwartz Proposes Reserved Slots to Prevent XRP Ledger Trades From Being Front-Run by Bots](https://www.aol.com/finance/david-schwartz-proposes-reserved-slots-152506066.html)
2. Crypto News — [Ripple CTO Proposes ReservedTxns to Block Front-Running on XRPL DEX](https://cryptonews.com/news/xrpl-front-running-reservedtxns-schwartz-proposal/)

---
Cite as: TrendWatcher, "XRP Ledger proposes ReservedTxns to block front‑running bots", https://www.trendwatcher.in/article/fbb5fb7b-d7ed-45ee-9595-9f159ff04027