See your slippage before the bots do.
Simulate a swap, watch how a sandwich bot would extract value, and measure how XRPL's TxnReserve protection changes the outcome — live.
Trade Inputs
Configure pool liquidity & trade size
Reserves your execution slot in the next ledger to neutralize sandwich bots.
Live Slippage
Ledger execution queue
TxnReserve places your transaction at the front of the next ledger. Attacker orders execute around an already-settled trade — their profit is 0.
Financial impact
Standard transaction vs. TxnReserve protection — fees, slippage, and attacker profit.
| Metric | Without Protection | With TxnReserve |
|---|---|---|
| Effective slippage | 2.548% | 0.99% |
| Total tokens received | 4,872.61 TKN | 4,950.5 TKN |
| Attacker profit | +158.88 XRP | 0 XRP |
| Network fee paid | 0.00001 XRP | 0.00002 XRP (2×) |
| Net savings with protection | +155.77 XRP |
How it works
The math and mechanism behind the simulator, in plain English.
1. AMM slippage
A constant-product pool keeps x × y = k. The larger your trade relative to the pool, the more the price moves against you — that movement is slippage.
2. Sandwich attack
Without protection, a bot can place a buy order before yours and a sell order after yours. Your swap executes at the worse price, and the bot pockets the difference as profit.
3. XRPL TxnReserve
David Schwartz proposed a slot-reservation mechanism: pay at least 2× the normal fee to reserve a slot in a future ledger. Your transaction is committed to that slot before others learned about it, removing the front-running opportunity entirely.
What David Schwartz proposed
“The idea is simple: you pay at least 2× the normal fee to reserve a slot in a future ledger. Your transaction executes in that reserved slot, and any transaction created after your transaction was disclosed cannot execute before your reserved slot. This effectively prevents front-running and sandwich attacks on XRPL because the attacker cannot buy before your transaction and sell after it.”