ExceededSlippage
Raydium AMM V4 · Custom(30) · 0x1e
custom program error: 0x1e
What it means
The swap would have paid out less than the minimum this transaction allowed (or cost more than its maximum). The price moved between the moment the quote was taken and the moment the transaction executed, by more than the slippage tolerance set in the swap.
The program's own message: “instruction exceeds desired slippage limit”
What to do
Get a fresh quote and resend with the same tolerance; the price has moved on. Widen the tolerance only if it keeps failing on a fast-moving token, and know that a wide tolerance is what sandwich bots feed on.
Seen on mainnet
swap_base_in (minimum out) and swap_base_out (maximum in), both the OpenBook-era layout and the newer one. The price is read from the program's own ray_log line in the failed run. This instruction carries a limit, not a tolerance, so a fresh quote is the wrong idea. TxWhy keeps the amount and every account, and moves only the limit to the price the chain itself computed in the failed run (read from the program's own check in the logs, or from a simulation with the limit lifted), with a 1% tolerance and never more than 25% against you. The result is returned only after it passes simulation, and the offline verifier refuses anything else. When the rebuilt swap fails again on the same check, the pool moved past the tolerance between pricing and the final check; TxWhy says so instead of returning it.
From replaying real landed failures through the repair engine, around the clock since September 21, 2026. Every verdict and its reason is on the failure index.
TxWhy can repair this one
This instruction carries a limit rather than a tolerance. TxWhy keeps the amount and every account, moves only the limit to the price the chain computed in the failed run (never more than 25% against you), keeps every other instruction byte for byte, and returns the result only after it passes simulation.
Code 30 means something else in other programs
Custom codes are private to each program. Check which program actually raised it: it is the innermost failed call, not necessarily the program you called.