Tokens missent to the 1inch Aggregation Router? Forget about them

One of the most notorious missteps in the blockchain space is accidentally transferring tokens to the wrong address. Sometimes users send their funds directly to a contract instead of calling it properly. And the more widely used the contract, the more often this happens.

Among Ethereum’s top gas guzzlers are 1inch Aggregation Routers. And yes, you guessed it — people keep sending tokens there by mistake. Sometimes it’s $20K USDT, sometimes $5K USDT.

Luckily, 1inch Aggregation Routers include a function designed to recover accidentally sent funds:

/**
 * @notice Retrieves funds accidentally sent directly to the contract address
 * @param token ERC20 token to retrieve
 * @param amount amount to retrieve
 */
function rescueFunds(IERC20 token, uint256 amount) external onlyOwner {
    token.uniTransfer(payable(msg.sender), amount);
}

Seems safe, right? But what if we told you anyone can rescue those funds?

While digging into interactions with Ethereum’s popular gas guzzlers, we found a user who sent 4.2 WBTC to 1inch Aggregation Router V6 in November 2024.

Were they recovered? Well… not by the owner. In fact, a savvy searcher pocketed the funds for themselves — and did it pretty easily by creating a contract that called this method:

/**
 * @notice Called by Curve pool during swap operation initiated by _curfe.
 * @dev This can be called by anyone assuming no tokens are stored on this contract between transactions.
 * @param inCoin Address of the token to be exchanged.
 * @param dx Amount of tokens to be exchanged.
 */
function curveSwapCallback(
    address /* sender */,
    address /* receiver */,
    address inCoin,
    uint256 dx,
    uint256 /* dy */
) external {
    IERC20(inCoin).safeTransfer(msg.sender, dx);
}

Done. Funds “rescued”. Not to mention, one can skip the contract altogether and call the function directly.

Correct. This callback exists in Aggregation Router V6. Then you might think older routers like v4 and v5 must still be holding funds until the owner runs rescueFunds. Not always.

Here’s the catch: in other routers, including Uniswap’s SwapRouter, pool addresses are calculated or fetched dynamically during the swap. But in 1inch Aggregation Routers, pool addresses are passed externally.

That design opens the door for the method that accepts a chain of pools as a parameter:

/// @param amount Amount of source tokens to swap
/// @param minReturn Minimal allowed returnAmount to make transaction commit
/// @param pools Pools chain used for swaps. Pools src and dst tokens should match.
function uniswapV3Swap(
    uint256 amount,
    uint256 minReturn,
    uint256[] calldata pools
) external payable returns(uint256 returnAmount);

During a swap, UniswapV3 requires you to send your liquidity via uniswapV3SwapCallback. For the first pool, 1inch uses msg.sender’s funds, and the returnAmount comes from the UniswapV3 pool.

Normally you can’t control this. Unless you create your own “pool”:

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.26;


contract CustomPool {
    function swap(
        address recipient,
        bool zeroForOne,
        int256 amountSpecified,
        uint160 sqrtPriceLimitX96,
        bytes calldata data
    ) external returns (int256 amount0, int256 amount1) {
        amount0 = -amountSpecified;
        amount1 = -amountSpecified;
    }
}

This fake pool just echoes back the value it received. Put it first in the chain, and it returns whatever you need without calling uniswapV3SwapCallback. After that, the next pool can be called normally, and voilà — the mistakenly sent tokens are “recovered” and swapped.

Is this a bug? Not really, since 1inch even acknowledged this in v6. So it’s more of a tradeoff for gas efficiency than a vulnerability. But it’s definitely something worth knowing.

We found users accidentally sent about $520K in tokens (adjusted prices) to routers v4, v5, and v6. It seems all of it was “rescued” by opportunistic users who knew how to drain funds using fake pools or trigger the callback function. 

Here’s a detailed breakdown:

Total: $1,836.23

Total: $38,953.55

Total: $479,273.73

If you’d like us to perform this level of analysis for a security audit of your own contract — get in touch!