Axiom’s official market-order documentation describes slippage as an allowed percentage change while a transaction is waiting to confirm, and its Solana-fee documentation describes a configurable maximum percentage. Treat that setting as a transaction condition—not as the amount you expect to lose. Actual execution also depends on the route or pool, order size, price impact, market movement, competing transactions and how the transaction encodes its minimum output. Review the live quote and expected received quantity before signing; there is no universal ideal percentage for every token and market.
01 / CORE CONCEPT
What Slippage Means
Slippage is the difference between the price or output visible when an order is prepared and the result obtained when it executes. The difference may be favourable or adverse, although trading interfaces usually focus on protection from an adverse change. Onchain execution is not instantaneous: a quote is calculated, a transaction is built and signed, then the network and relevant programs process it. The state of the market may change during that interval.
For a token swap, it is often clearer to compare the quoted output quantity with the final output quantity. A headline price can conceal route changes, token decimals or several pool interactions. The transaction record and balance changes provide the final evidence.
02 / LIMIT, NOT FORECAST
Slippage Tolerance Versus Actual Execution Price
A tolerance tells the transaction-building system how much adverse movement may be accepted before the trade should no longer proceed under its encoded conditions. It does not mean the trade will use the entire allowance, nor does it promise that every implementation measures the boundary in exactly the same way. Some systems express protection as a minimum amount received; others derive that amount from a quoted output and a percentage.
The actual execution price is the average result of the fills or pool state used by the transaction. It can land close to the quote, move within the permitted range, or fail when the protection condition is not met. Always inspect the interface’s current wording and the wallet transaction rather than assuming a percentage has one universal meaning.
A tolerance normally constrains output relative to a quote. It does not include every other cost, and it cannot turn a volatile token’s later price movement into a capped loss.
03 / TWO DIFFERENT EFFECTS
Price Impact Versus Slippage
Price impact is the change caused by the order consuming available liquidity along a pool’s pricing curve or order route. It may already be reflected in the quote. Slippage is the additional difference between that quote and execution as market state changes. The terms are sometimes presented together, but combining them hides useful information.
| Concept | Primary cause | Question to ask |
|---|---|---|
| Price impact | Your order size relative to usable market depth | How much does this quoted order move through the pool? |
| Slippage | Quote-to-execution state changes and route mechanics | How different was the final output from the quote? |
| Tolerance | A user or system-defined execution boundary | Under what adverse change should the transaction stop? |
| Platform/network charges | Separate service and transaction mechanisms | Which amounts are explicit charges rather than execution effects? |
04 / MARKET CONDITIONS
Why Low Liquidity, Volatility and Timing Matter
In a shallow pool, fewer assets are available near the displayed marginal price. A modest order can therefore consume a meaningful part of the pool and produce a worse average rate. Market capitalisation does not solve this: it is a price-times-supply calculation, not cash waiting to buy your tokens. Thin markets can move sharply even when their displayed market cap looks large.
Volatility adds another layer. Other swaps, liquidity withdrawals, arbitrage and launch activity can alter reserves between quote and execution. Priority mechanisms may affect scheduling likelihood, but they do not freeze the price or guarantee confirmation. A longer delay gives the market more opportunity to change, while a faster path cannot remove price impact that already exists in the quote.
Use Pulse as a discovery and research workspace, not as proof that a visible token has enough depth for your intended order.
05 / DOCUMENTED WORKFLOW
How to Review Slippage Controls on Axiom
Axiom’s current Market documentation tells users to consider priority fee, slippage and MEV protection before a market order. Its Solana Fees page documents a “Slippage Limit” with a configurable maximum percentage. Because interfaces and defaults can change, this article does not state a default or prescribe a setting.
- Open the intended token using the exact mint address rather than relying only on a ticker.
- Enter the intended order amount and inspect the quote, estimated output, price impact and any warning shown.
- Open the current transaction settings and read the slippage control’s label and units.
- Review priority and MEV-related settings separately; they are not substitutes for a sensible execution boundary.
- Check the wallet prompt and do not sign if the transaction’s asset, amount or instructions are unexpected.
The broader Axiom workflow guide explains order preparation, while the fee guide separates platform charges from network and execution costs.
06 / WHEN CONDITIONS CHANGE
What Happens When Tolerance Is Exceeded?
The outcome depends on the transaction and program design. If a swap instruction includes a minimum acceptable output and the available result is lower, the program can return an error and roll back its state changes. That protects against receiving less than the encoded minimum, but it does not make the attempt costless: Solana’s official fee documentation states that transaction fees are charged whether a processed transaction succeeds or fails.
Other failure points are possible, including expired blockhashes, insufficient funds, compute limits or account-state changes. A rejected quote in the interface is not the same event as an onchain transaction that executes and fails. Review the signature and error details in an explorer before deciding what happened.
07 / HYPOTHETICAL EXAMPLES
How to Reason About a Changing Quote
A $100 quoted purchase and a 2% adverse move
Assume a hypothetical interface quotes a $100 purchase at 1,000 tokens before explicit charges. Before execution, the relevant market price moves adversely by 2%. A simplified constant-dollar comparison would put the output near 980 tokens, but a real result can differ because the pool curve, route, price impact, rounding, token mechanics and minimum-output calculation all matter. A 2% tolerance must not be read automatically as a guaranteed $2 maximum loss. It may define a boundary relative to quoted output, while fees and the token’s value after settlement remain separate.
Same notional, different depth
Suppose Pool A is deep enough that a $100 order barely changes its reserves, while Pool B is very shallow. The first quote may show little price impact; the second may already show a materially worse average output before any waiting-time slippage. Raising tolerance on Pool B does not create liquidity—it only permits execution across a wider adverse range.
Conditions improve
If pool state moves favourably before processing, a design may deliver more output than quoted. That possibility does not justify using an excessively broad adverse boundary. The decision should be based on what outcome you are willing to authorise, not a hope that movement will be favourable.
08 / RISK CONTROL
Risks of Very High Slippage Settings
A very wide setting can make execution more likely, but it also authorises a much worse result. In volatile or low-depth markets, the transaction may consume liquidity at progressively poorer prices. Public pending-order information and routing can also create MEV exposure depending on the submission path. Axiom documents separate MEV modes; none should be interpreted as a guarantee against adverse execution.
Repeated failure can be evidence that the quote is unstable, liquidity is inadequate, the route is changing or another transaction condition is wrong. Choosing not to trade is a valid control.
09 / BEFORE SIGNING
Practical Pre-Trade Checklist
- Verify the exact token mint and intended pool or route.
- Compare the order size with visible liquidity and market depth.
- Separate quoted price impact from the slippage boundary.
- Read expected output or minimum received, not only the headline price.
- Check platform, base network, priority and optional transaction charges separately.
- Confirm the live Axiom control rather than relying on an old screenshot or default.
- Review the wallet prompt and reject unexplained instructions.
- After submission, verify status, fees and balance changes using the transaction signature.
For wallet and domain precautions, read the Axiom safety guide.
10 / PRIMARY EVIDENCE
Sources and Method
- Axiom — Market orders
- Axiom — Solana fee and slippage settings
- Solana — Transaction fees
- Solana — Fee structure
Checked 19 October 2026. Axiom-specific statements are limited to its published documentation. Execution examples are simplified and hypothetical; they do not model a specific pool or promise a result.
11 / FAQ
Frequently Asked Questions
What is Axiom slippage?
Axiom’s documentation describes slippage as the price change allowed while a transaction waits to confirm and documents a configurable maximum percentage for Solana trading.
What is the best Axiom slippage setting?
There is no universal best percentage. The appropriate boundary depends on liquidity, order size, volatility, route mechanics and the outcome the user is prepared to accept.
Does 2% slippage mean I can lose only $2 on $100?
No. It may constrain output relative to a quote, but explicit fees, price impact already in the quote, implementation details and later token price movement are separate.
Is price impact a fee?
No. It is an execution effect caused by consuming market depth. Slippage is also generally an execution difference rather than a separately invoiced fee.
Do failed transactions cost anything?
A processed Solana transaction can still incur its transaction fee when execution fails, according to Solana’s fee documentation.
Does a higher priority fee prevent slippage?
No. Priority can affect scheduling likelihood, but it does not freeze pool state, remove price impact or guarantee confirmation.
12 / THE TAKEAWAY
Treat Slippage as an Authorisation Boundary
Start with the quote, expected output and liquidity—not a memorised percentage. Keep price impact, slippage and explicit charges separate, verify the current Axiom control, and authorise only an outcome you understand. When depth is inadequate or the quote is unstable, declining the transaction is often the clearest risk control.