Curveswap
Curveswap slippage can trigger a revert when swap output falls below the submitted minimum
Curveswap slippage is the difference between quoted output and execution output for the same swap input. A successful trade can return less than its quote while still meeting the minimum received. If execution falls below the submitted minimum, the swap reverts. Diagnose the mismatch by separating quote age, pool depth, route changes, and tolerance from transaction status. Price impact can already reduce the quote, so increasing tolerance cannot restore output that the selected trade was never quoted to receive.
A wider slippage tolerance lowers the output floor; a smaller trade can change price impact and the quoted exchange rate.
A low quote, a pending swap, and a revert
A low quote describes an offered exchange rate, a pending transaction has not established execution, and a reverted transaction records a failed attempt. A quote can worsen before any transaction exists, because pool state or the selected route has changed. A pending swap carries its signed input and output limit. A successful receipt establishes that the transaction ran, while its swap event and recipient transfers describe the exchanged amounts.
A failed contract call can return a reason that identifies the check that rejected execution. Curve Router NG uses the message Slippage when final output misses its floor. StableSwap-NG pool code can report Exchange resulted in fewer coins than expected for its minimum-output check. Neither message alone explains why output fell. A general execution error or failed gas estimate can also arise from permissions, balance, or transfer problems.
Transaction details before a new attempt
The submitted transaction provides the comparison baseline: its network, input token, output token, input amount, route, recipient, and minimum output. A later screen may display a refreshed quote or another route. Comparing that display with the original transaction can suggest a discrepancy that never existed in the signed swap. Keep the original quote or transaction preview where available, because a receipt does not reconstruct what an earlier screen showed.
An ERC-20 allowance permits a specified spender to draw the input token within its authorized amount. A direct pool swap and a router swap can require different spenders. The spending permission must match the contract that pulls tokens for the chosen call. Input-token balance and the native token needed for network execution are separate requirements.
A successful approval sets the token allowance; it does not confirm a swap or reserve the quoted exchange rate.
Quote age and changing pool state
A quote reflects the pool state at its query time, and intervening transactions can change the output available at execution. Other swaps, liquidity additions, and liquidity withdrawals can alter balances before execution. An approval delay or pending period gives those changes time to occur. Refreshing a quote updates the estimate; it does not reserve liquidity. A newly loaded screen can still rely on cached data, making its displayed freshness different from the freshness of the underlying quote.
Minimum received and the submitted tolerance
The minimum received is an output-token amount that the swap contract checks during execution. In Curve's swap library, tolerance converts the quote into that lower bound. With quoted output Q and tolerance t expressed as a fraction, the proportional relationship is M = Q × (1 - t). Conversion into the output token's integer units can affect the exact encoded amount through rounding. The submitted value governs execution even if the screen later refreshes.
Curve Router NG reverts an exchange when its final output is below the submitted minimum.
A tighter bound accepts less deterioration and can cause attempts to fail when prices move. A wider bound allows worse execution without improving pool liquidity or the quoted rate. Trading fees affect the quote itself; tolerance specifies permitted deterioration from that quote. Removing the floor removes this output protection.
Why can a fresh quote still offer poor output?
A fresh quote can offer poor output when the requested amount consumes scarce liquidity or the pool's assets have moved away from their pricing relationship. Price impact describes the effect of the trade's size on its exchange rate. It already enters the quoted output for that amount. Curve's StableSwap design concentrates liquidity around the relationship between correlated assets. Output can deteriorate as the pool becomes imbalanced or a trade reaches a steeper part of its pricing curve.
Effective depth depends on output reserves and the pool's pricing rule, so total pool value alone does not establish a good rate. A smaller input may receive a better rate per token while producing fewer output tokens overall. Changing tolerance leaves that trade-size effect intact. For assets intended to track a peg, a broken peg can change the economic exchange rate even when the transaction succeeds.
Route depth and intermediate pools
A routed swap depends on every pool that contributes to its final output, including intermediate exchanges that the recipient does not receive separately. The output from one step becomes the input to the next. In Curve Router NG, those exchanges can execute within one transaction, with a minimum check on final output. A shallow intermediate pool can therefore constrain an otherwise liquid route. More steps do not automatically mean a worse quote; accessible liquidity, pool pricing, and execution costs determine the comparison.
A bounded retry after a minimum-output failure
Suppose a swap fails its minimum-output check, although its saved quote suggested enough output. Confirm its reverted status before preparing a retry. Keep the input and output token identities fixed while diagnosing the gap.
Record the original input amount, route, minimum output, and error message. Refresh the same trade and compare its quote with the encoded floor. A fresh estimate below the old minimum shows that repeating that floor would require better execution than the refreshed estimate.
Next, lower only the input amount in a quote for the same route. If output per input token improves with the pool state unchanged, trade size contributes to the cost. Total output may still fall. Compare both amounts against the same pool state when possible; moving reserves can otherwise blur the result. Preserve the token pair and tolerance during this comparison.
- If the original transaction lacks a confirmed failure, establish its status before treating another submission as a retry.
- If the refreshed quote or the minimum you would submit falls below your acceptable output for that input amount, keep the swap unsubmitted.
- If reducing input improves the rate, assess that smaller amount with its own quote and minimum.
- If the route changes, compare it separately; that comparison no longer isolates trade size.
- If simulation still fails, resolve its specific error before broadcasting.
For an acceptable smaller trade, rebuild its minimum from the new quote. For an ERC-20 input pulled from your wallet, confirm that its allowance for the chosen spender covers the new input amount. Use a transaction simulation when available. Submit only the parameters that passed those checks; a simulation still describes an earlier state.
After a successful execution, compare the confirmed swap output and recipient transfer with that transaction's submitted minimum. Stop if the route cannot produce a quote, an available simulation fails, or another unexplained execution failure occurs. Further attempts that execute on-chain without addressing the cause add network execution costs while leaving the mismatch unresolved.
Failures that tolerance cannot fix
Allowance failures, insufficient balances, and token-transfer failures prevent execution independently of the minimum-output setting. Raising tolerance cannot grant spending permission or supply the native token required for network execution. A gas-estimation failure can expose one of these conditions before a transaction reaches the chain. The estimate's returned error may identify the blocked condition. An included transaction's receipt separately records an on-chain success or failure.
An out-of-gas failure concerns execution capacity; a minimum-output revert concerns the output that the contract can provide.
Execution ordering and adverse price movement
Transaction ordering can change pool state between a quote and a swap's execution, even within the same block. Ordinary trades and arbitrage can move the rate. A sandwich attack adds a trade ahead of a visible swap and another behind it, using the intervening price movement to extract value. This activity belongs to maximal extractable value, or MEV, and can worsen execution.
A wide tolerance leaves more room for adverse movement to remain within the accepted floor. A strict floor bounds allowed deterioration but cannot ensure inclusion or prevent every ordering strategy. A worse fill alone does not prove an attack, because ordinary liquidity changes produce similar symptoms. In CryptoSwap pools, changing asset prices and the pool's moving price scale also affect pricing.
Recorded output and the cost of another attempt
The successful swap's output and recipient transfers provide the comparison with its saved quote. A changing wallet valuation is a separate measurement: token units can match the transaction while their displayed market value changes. A stale balance display can also lag the recorded transfer. For a routed swap, intermediate token amounts do not describe the final token received. The input amount, final output token, and recipient must align before an output shortfall has a meaningful interpretation.
Pool charges can already be included in quoted output; StableSwap-NG quotes account for the swap's dynamic fee. Avoid subtracting that fee again while reconciling amounts. A reverted EVM swap rolls back its token movements, while gas already consumed remains a network cost. Smaller separate swaps can add repeated execution charges, and later quotes may change as earlier swaps alter reserves. A refreshed quote updates the original trade's estimate. A smaller input can change price impact; wider tolerance changes the deterioration that execution permits.
Questions and answers about Curveswap slippage
Can a successful Curveswap swap return more tokens than its quote predicted?
A successful swap can return more tokens when execution conditions improve relative to its quote. The minimum-output check permits execution at or above the submitted floor. For a Curve Router NG exchange, the router forwards the final output amount to the specified recipient after checking that floor.
Does raising the gas fee change a swap's slippage limit?
Raising the gas fee alone does not change the minimum output encoded in the swap call. A different fee can affect transaction inclusion, while pool state still determines execution output. Even faster inclusion cannot reserve a quote or repair an exchange rate that already falls below the submitted floor.
Will editing browser tolerance change a Curveswap swap that is already pending?
Editing browser tolerance does not alter the parameters of an already submitted transaction. Its signed call data contains the output bound that execution will use. A replacement with changed call data is a separate signed transaction, subject to the wallet's replacement support and the original transaction's status.
Do token decimals change the meaning of minimum received?
Token decimals determine how an output amount appears on screen and converts into the integer units used by the contract. The output token's precision governs this conversion, even when the input token uses different decimals. Rounded screen values can hide small differences, so the encoded minimum is the exact threshold.
Which details can I share when a Curveswap slippage error needs support?
The transaction hash, network, token contract addresses, submitted minimum, and exact error message can help locate the failing swap and its output threshold. A public address can reveal transaction history, so share it with that exposure in mind. A diagnosis does not require a recovery phrase, private key, or an unrelated signing request.
Updated on