Detailed Instructions

On the aggregator's swap page, identify the slippage tolerance control, typically represented as a percentage input field or a toggle for preset values (e.g., 0.1%, 0.5%, 1%). This setting is usually found near the transaction summary, often next to or below the token pair selection. On interfaces like 1inch or Matcha, it may be hidden behind a settings cog icon. The displayed value is your maximum acceptable price deviation from the quoted price at the moment your transaction is mined. For stablecoin pairs, a lower tolerance like 0.05% is common, while for volatile assets, a higher setting may be necessary.

• Sub-step 1: Initiate a swap by selecting your input and output tokens.
• Sub-step 2: Look for a gear or slider icon labeled "Settings," "Advanced," or "Slippage."
• Sub-step 3: Click to expand the settings panel and reveal the slippage input field.

Detailed Instructions

Enter a specific numerical value representing your slippage tolerance. This is the maximum percentage price movement you will accept for the trade to execute. For example, entering 0.5 means you accept a 0.5% worse price than initially quoted. Consider network congestion (high gas times may cause slower execution) and pool liquidity (low liquidity pools are more prone to large price impacts). A good starting point for major ETH/USDC pairs on Ethereum mainnet during normal conditions is 0.1-0.3%. For a new memecoin on a DEX with thin liquidity, you might need 3-5% or higher, understanding the increased risk of front-running and sandwich attacks at higher tolerances.

• Sub-step 1: Delete the default value in the input field.
• Sub-step 2: Type your desired tolerance, e.g., 0.15 for 0.15%.
• Sub-step 3: Confirm the interface updates the expected output amount based on this new parameter.

Detailed Instructions

Some aggregators offer advanced slippage modes beyond a simple percentage. Dynamic Slippage automatically adjusts based on real-time market volatility. Transaction Deadline sets a time limit (in seconds) for your transaction to be included in a block, after which it will revert. A common deadline is 20 minutes (1200 seconds). Another feature is Partial Fill Protection, which ensures the trade only executes if the entire specified input amount can be swapped, preventing unfavorable partial fills in illiquid markets. Review these options in the advanced settings panel. Enabling a deadline is a critical safeguard against stale transactions being executed at bad prices minutes later.

javascriptCopy
// Example structure for a transaction parameters object including deadline
const txParams = {
  from: userAddress,
  to: routerAddress,
  data: calldata,
  value: inputAmount,
  deadline: Math.floor(Date.now() / 1000) + 1200 // 20 minutes from now
};

• Sub-step 1: Check for a toggle or checkbox for "Advanced Settings" or "Expert Mode."
• Sub-step 2: If using a deadline, input a value like 1200 for 20 minutes.
• Sub-step 3: Enable "Partial Fill" or "Dynamic Slippage" if the conditions warrant it.

Detailed Instructions

Before signing the transaction, the interface will simulate the swap and display key outcomes. Scrutinize the minimum received amount, which is calculated as quoted output * (1 - slippage tolerance). Verify this minimum is acceptable. Check the price impact percentage shown separately; a high price impact (e.g., >2%) indicates your trade size is significant relative to pool liquidity and is the primary cause of slippage, not just network latency. The aggregator may also show an estimated gas cost and the route through which your trade will be split. Confirm that the final configuration aligns with your intent: a low slippage tolerance for a safe, liquid trade, or a higher, calculated tolerance for a speculative asset.

• Sub-step 1: Locate the "Minimum Received" field in the transaction summary.
• Sub-step 2: Compare the quoted output and minimum received to see the worst-case outcome.
• Sub-step 3: Review the breakdown of the routing path and associated fees.

Tip: If the minimum received is unacceptably low, cancel the transaction, adjust your slippage or trade size, and simulate again.

Detailed Instructions

Define the slippage tolerance as a basis points (bps) value, such as 50 for 0.5%. Implement a validation function that rejects values exceeding a safe maximum (e.g., 500 bps or 5%) to prevent user error. For limit orders or MEV protection, also define a deadline parameter (e.g., deadline: block.timestamp + 600) to revert transactions that are not mined promptly.

• Sub-step 1: Accept slippage input from the UI and convert percentage to basis points.
• Sub-step 2: Validate the input is within your application's configured min/max bounds.
• Sub-step 3: Pass the validated bps value and deadline to your quote or swap function parameters.

javascriptCopy
// Example validation in a frontend service
function validateSlippage(userInputPercent, maxAllowedPercent = 5) {
  const bps = userInputPercent * 100;
  if (bps > maxAllowedPercent * 100) throw new Error('Slippage tolerance too high');
  return bps;
}

Tip: For aggregators like 1inch or 0x API, slippage is often passed as slippagePercentage or slippageBips in the request body.

Detailed Instructions

Integrate with a DEX aggregator API (e.g., 1inch, ParaSwap, LI.FI) to fetch a swap quote. The API will calculate the minimum output amount based on your slippage tolerance. For a swap of 1 ETH to USDC with 0.5% slippage, if the quoted price is 3000 USDC, the minOutput would be 2985 USDC. Always use the minOutput or equivalent field from the API response for the subsequent transaction, not the estimated output.

• Sub-step 1: Construct the API request with fromToken, toToken, amount, and slippage parameters.
• Sub-step 2: Parse the response to extract the toTokenAmount and the critical minReturn or minAmountOut value.
• Sub-step 3: Store the transaction data and value fields for on-chain execution.

javascriptCopy
// Example fetch for a 1inch quote
const quote = await fetch(`https://api.1inch.io/v5.0/1/quote?fromTokenAddress=0xEee...&toTokenAddress=0xA0b...&amount=1000000000000000000&slippage=0.5`);
const data = await quote.json();
const minAmountOut = data.toTokenAmount; // This is already adjusted for slippage
const txData = data.tx.data;

Tip: For multi-step bridge aggregators, slippage may need to be defined per leg. Verify the API documentation.

Detailed Instructions

Using the quote data, construct the transaction payload for the user's wallet. The core action is setting the minimum received parameter in the transaction call. For a direct Uniswap V3 swap, this is amountOutMinimum. For an aggregator router contract, it might be minReturn. Always include the deadline parameter. Use the value field for native token swaps. Estimate gas accurately, as low gas can cause tx failure and missed deadlines, effectively increasing slippage.

• Sub-step 1: Populate transaction parameters: to (router address), data, value, gasLimit.
• Sub-step 2: Set the minReturn or amountOutMinimum argument within the data to the value from the quote.
• Sub-step 3: Prompt the user's wallet (e.g., via Ethers.js sendTransaction) with the full transaction object.

solidityCopy
// Example interface for a generic aggregator router
interface IAggregationRouter {
    function swap(
        IAggregationExecutor caller,
        SwapDescription calldata desc,
        bytes calldata data
    ) external payable returns (uint256 returnAmount);
}
// SwapDescription includes `minReturn` and `deadline`

Tip: For better UX, perform a simulated eth_call of the transaction first to catch potential reverts before the user signs.

Detailed Instructions

Transactions can revert with errors like TooLittleReceived or MinReturnError. Implement robust error handling to inform the user. Monitor the transaction receipt; a failure likely means market price moved beyond the slippage tolerance before confirmation. In this case, you should fetch a new quote with updated parameters. Consider implementing an auto-retry logic with a slightly increased slippage tolerance (capped), or notify the user to approve a new quote.

• Sub-step 1: Listen for the transaction receipt and check the status field (0 for failure).
• Sub-step 2: Parse revert reasons from transaction simulation or event logs to identify slippage as the cause.
• Sub-step 3: If failed, re-initiate the quoting process, optionally with a higher tolerance or later deadline.

javascriptCopy
// Error handling example with ethers.js
try {
  const tx = await signer.sendTransaction(txObject);
  const receipt = await tx.wait();
  if (receipt.status === 0) {
    throw new Error('Transaction reverted. Likely price movement exceeded slippage.');
  }
} catch (error) {
  // Check error message for keywords like 'min return' or 'slippage'
  console.error('Swap failed:', error.reason || error.message);
}

Tip: Use Tenderly or OpenZeppelin Defender to simulate transactions and debug complex revert reasons off-chain.

Detailed Instructions

For professional users, implement dynamic slippage strategies. Use an oracle like Chainlink to get a reference price and calculate tolerance based on market volatility. For large orders, implement partial fill protection by requiring a minimum fill percentage (e.g., 90%). Consider positive slippage capture: set a high minimum output but allow the transaction to succeed if the actual output is better, which some aggregators support natively. Expose these as advanced options in your UI with clear explanations of the trade-offs.

• Sub-step 1: Query a price feed to calculate the current 5-minute volatility and adjust the bps tolerance algorithmically.
• Sub-step 2: For the swap function, add a minFillPercent parameter that works alongside minReturn.
• Sub-step 3: Configure your aggregator request to enable disableEstimate or allowPartialFill flags where available.

javascriptCopy
// Concept for dynamic slippage based on volatility
async function getDynamicSlippage(baseSlippageBps, tokenPair) {
  const volatility = await fetchVolatilityFromOracle(tokenPair);
  const dynamicBps = Math.min(baseSlippageBps * (1 + volatility), MAX_BPS);
  return Math.floor(dynamicBps);
}

Tip: Aggregators like CowSwap offer kind: 'sell' orders with partiallyFillable: true for MEV-protected, slippage-tolerant swaps.