Axiomtrade slippage

Axiom's Max % setting specifies the maximum slippage you are willing to accept. Price movement between quotation and execution can put a swap outside that boundary.

A quote reflects pool conditions when it was calculated. Other trades can change those conditions before your transaction executes, even if your input amount stays the same. Time spent reviewing an order and delays before confirmation leave room for the available output to change. A refreshed quote reflects the new conditions without restoring the earlier price.

The reported error matters when diagnosing a failed swap. A failure alone does not establish that the slippage setting caused it.

Price impact comes from executing the requested amount against the liquidity available along the swap route. It can already be reflected in a quote, even when no other trader changes the pool between quotation and execution.

Axiom's token view includes liquidity-pool information, market capitalization, and trading volume. Market capitalization and past volume do not establish the liquidity available to fill a particular order. A large swap relative to pool depth can receive a poor quoted rate while still using a tight slippage tolerance: the tolerance limits deterioration from that quote.

An enforced minimum received amount is an output-token floor for a fixed-input swap. Expected output describes the quoted amount; minimum received defines the lower bound the transaction must satisfy. A swap enforcing that bound fails if execution would deliver less.

For the same input and unchanged quote, a tighter tolerance keeps the output floor closer to expected output. A wider tolerance allows a lower floor. That wider range can reduce slippage-related failures when prices move, while permitting a worse fill. Changing tolerance does not improve the quoted rate or add liquidity.

Where a preview provides minimum received, judge the amount in the token you would receive. A tolerance percentage alone does not express whether that output is acceptable to you.

Priority fees pay validators for transaction prioritization. They can improve the likelihood of faster confirmation during congestion, potentially shortening the interval exposed to price movement. They leave the slippage tolerance unchanged.

View full-size image

MEV protection targets transaction-ordering attacks such as sandwiching. Axiom's Solana Fees guide describes Secure mode as waiting for a whitelisted validator, which can delay execution. This protection does not prevent ordinary market movement or remove price impact. Priority fees, protection settings, and tolerance therefore affect different aspects of execution; none guarantees the earlier quoted price.

• If the reported error identifies slippage, obtain a fresh quote before deciding whether to change the tolerance.
• If quoted output is poor relative to the order size and available liquidity, assess a smaller input with a new quote. Increasing tolerance leaves the starting price impact in place.
• If minimum received is shown, compare that output-token amount with the lowest amount you would accept. Widen tolerance only while the resulting floor remains acceptable.
• If confirmation is slow, review the priority fee and MEV mode separately from tolerance. Submit a replacement only after confirming the original swap failed or expired without executing. Secure mode's validator wait can contribute to delay, while a higher priority fee leaves the permitted price movement unchanged.