Lenders cannot claim their tokens in some cases

[howlbot-integration]

Lines of code

https://github.com/code-423n4/2024-05-loop/blob/0dc8467ccff27230e7c0530b619524cc8401e22a/src/PrelaunchPoints.sol#L254

Vulnerability details

Impact

If a lender for example deposit 100 rswETH in prelaunchPoints contract when they want to claim their tokens actually frontend part calls https://api.0x.org/swap/v1/quote?buyToken=0xeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeee&sellAmount=100&sellToken=0xFAe103DC9cf190eD75350761e95403b7b8aFa6c0&includedSources=uniswap_v3 to generate calldata but 0x protocol always doesn't return 0x803ba26d and 0x415565b0 selectors even if frontend forces 0x to just include uniswap_v3 and this causes some lenders cannot claim their tokens

Proof of Concept

Please add this test to PrelaunchPoints.t.sol contract and run that with this command
forge test --match-test test_lockrswETHAndClaim -vvv --evm-version shanghai

        function test_lockrswETHAndClaim() external {
        address rswWhale = 0x22162DbBa43fE0477cdC5234E248264eC7C6EA7c;
        vm.startPrank(rswWhale);
        uint pre_lock_bal = rswETH.balanceOf(rswWhale);
        uint256 lockAmount = 100;
        rswETH.approve(address(prelaunchPoints), lockAmount);
        prelaunchPoints.lock(address(rswETH), lockAmount, referral);
        assertEq(rswETH.balanceOf(rswWhale), pre_lock_bal - lockAmount);
        vm.stopPrank();
        assertEq(prelaunchPoints.totalSupply(), 0);
        prelaunchPoints.setLoopAddresses(address(lpETH), address(lpETHVault));
        vm.warp(prelaunchPoints.loopActivation() + prelaunchPoints.TIMELOCK() + 1 days);
        prelaunchPoints.convertAllETH();

        vm.warp(prelaunchPoints.startClaimDate()  + 1 days);
        
//data response from 0x endpoint
        bytes memory data = hex"d9627aa400000000000000000000000000000000000000000000000000000000000000800000000000000000000000000000000000000000000000000000000000000064000000000000000000000000000000000000000000000000000000000000005800000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000002000000000000000000000000fae103dc9cf190ed75350761e95403b7b8afa6c0000000000000000000000000eeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeee869584cd0000000000000000000000001000000000000000000000000000000000000011000000000000000000000000000000007e2993a485fcee9d031e4a30ebc0dff6";

        vm.prank(rswWhale);
        vm.expectRevert();
        prelaunchPoints.claim(address(rswETH), 100, PrelaunchPoints.Exchange.UniswapV3, data);

    }

Tools Used

Foundry,Manually

Recommended Mitigation Steps

Assessed type

Error

[0xd4n1el]

This is indeed a problem on the test implementations, however TransformERC20 always give ETH as an outputToken and Uniswap_V3 always give WETH as outputToken so the validations in the contract are correct and not a vulnerability in the contract itself

[c4-judge]

koolexcrypto marked the issue as duplicate of #109

[c4-judge]

koolexcrypto marked the issue as unsatisfactory:
Invalid