Issue with Borrower's Incentive in using this protocol

Summary

According to the sponsor, the borrowers/traders profit from an increase in price in the hold token's value.

However, this isn't entirely true. The borrower can only make a profit from the slippage in the swap in the repay function. This profit mechanism is circumstantial and may not provide clear or substantial incentives for users to borrow.

Vulnerability Detail

Borrowers on the platform are expected to pay certain fees and a liquidation bonus. These costs seem to outweigh the primary method of profit, which is designed to be through slippage during swaps. The issue arises because:

Slippage is unpredictable and variable.
The borrowed funds are locked in a vault, restricting borrowers' flexibility.
Discrepancies between the developer's claims and actual benefits can lead to confusion and mistrust.

POC:

Let's us consider the test "repay borrowing and restore liquidity (long position WBTC zeroForSaleToken = false) will be successful" in the WagmiLeverageTest.ts file.

For simplicity, let's consider that only one loan has been borrowed:

const loans = [
            {
                liquidity: nftpos[5].liquidity,
                tokenId: nftpos[5].tokenId,
            },
        ];
params = {
            isEmergency: false,
            internalSwapPoolfee: 500,
            externalSwap: swapParams,
            borrowingKey: borrowingKey,
            swapSlippageBP1000: 990, //1%
        };
        await borrowingManager.connect(bob).repay(params, deadline);

After adding some logging, let's dissect the result:

console.log("current fees", currentFees/Constants.COLLATERAL_BALANCE_PRECISION);
current fees 1401
console.log("Borrowed Amount",borrowing.borrowedAmount);
Borrowed Amount 12111183
console.log("Liquidation bonus",liquidationBonus);
Liquidation bonus 94277

As we can see here, Bob is only making a profit if the slippage gain outweighs liquidationBonus + current fees. Now inside the _restoreLiquidity function :

console.log("Balance of holdtoken before Swap",IERC20(cache.holdToken).balanceOf(address(this)));
Balance of holdtoken before Swap 12205460
console.log("Balance of saletoken before Swap",IERC20(cache.saleToken).balanceOf(address(this)));
Balance of saletoken before Swap 0

console.log("saleTokenAmountOutbefore", (saleTokenAmountOut * params.slippageBP1000) /
                                Constants.BPS);
saleTokenAmountOutbefore before 993089349189290423
console.log("Balance of holdtoken after swap",IERC20(cache.holdToken).balanceOf(address(this)));
Balance of holdtoken after swap 5387963
console.log("Balance of saletoken after swap",IERC20(cache.saleToken).balanceOf(address(this)));
Balance of saletoken after swap 1002313303210717006

console.log("Amount0 to increaseLiquidity",amount0);
Amount0 After 5293681
console.log("Amount1 to increaseLiquidity",amount1);
Amount1 After 999997734913537898

Thanks to the slippage, the actual amount swapped is stricly bigger than the amount1 expected for liquidity increase in the pool.

The final result are then :
console.log("Balance of holdtoken after",IERC20(cache.holdToken).balanceOf(address(this)));
How much borrower win holdtoken 94281
console.log("Balance of saletoken after",IERC20(cache.saleToken).balanceOf(address(this)));
How much borrower win saletoken 2315568297179107

If we remove liquidationBonus + current fees = 95678 Hold tokens. The total P&L is : 2315568297179107 Sale tokens - 1397 hold tokens. Which is a profitable strategy only if the P&L > 0. However, this strategy is clearly dependant on the profit that can be extracted from the swap slippage. This strategy is not necessarily dependant on the increase in token value as many parameters can impact the slippage. The borrower might prefer to borrow the tokens from other protocol that offer CDP loans, use the tokens for leverage trading then repaying them with a profit.

Impact

Potential reduction in user adoption due to unclear profitability, possible erosion of trust in the platform, and potential financial risks for borrowers. I consider this vulnerability to be high because, it can stop potential borrowers from using the platform. However, I still listed it as a medium for reason that it doesn't actually block and the loss of funds for the borrowers is limited to CollateralValue transfered when the borrow was first called.

Code Snippet

repay function : https://github.com/sherlock-audit/2023-10-real-wagmi/blob/main/wagmi-leverage/contracts/LiquidityBorrowingManager.sol#L532

_restoreLiquidity: https://github.com/sherlock-audit/2023-10-real-wagmi/blob/main/wagmi-leverage/contracts/abstract/LiquidityManager.sol#L223

Tool used

Manual Review

Recommendation

Re-assess and clearly communicate the profit mechanisms for borrowers. Consider revising the fee structure and introducing additional incentive mechanisms or utilities for borrowed funds to bolster borrower appeal.

Duplicate of #109

sherlock-admin2 commented 1 year ago

1 comment(s) were left on this issue during the judging contest.

JP_Courses commented:

not a duplicate of the common slippage findings; possibly unique; due to slippage being highly unpredictable profit from slippage is not guaranteed

Maroutis commented 1 year ago

ESCALATED

This issue is different from #103 as explained in the details and the judge's comment. Profit is not a certainty even when there is a price increase because of slippage volatility, unlike what was explained during the contest.

Using the logged example before : even with a price increase, if the amount exchanged was equal to an equivalent of 1397 hold tokens or less in sale tokens (let's say the exact amount used for liquidity 999997734913537898 sale tokens) then after adding liquidity (added 999997734913537898 sale tokens). The borrower is losing a net of 1397 Hold tokens. Also, even in case of a positive P&L, trader's profit is dependent on slippage not price increase which might hinder his earnings.

sherlock-admin2 commented 1 year ago

ESCALATED

This issue is different from #103 as explained in the details and the judge's comment. Profit is not a certainty even when there is a price increase because of slippage volatility, unlike what was explained during the contest.

Using the logged example before : even with a price increase, if the amount exchanged was equal to an equivalent of 1397 hold tokens or less in sale tokens (let's say the exact amount used for liquidity 999997734913537898 sale tokens) then after adding liquidity (added 999997734913537898 sale tokens). The borrower is losing a net of 1397 Hold tokens. Also, even in case of a positive P&L, trader's profit is dependent on slippage not price increase which might hinder his earnings.

The escalation could not be created because you are not exceeding the escalation threshold.

You can view the required number of additional valid issues/judging contest payouts in your Profile page, in the Sherlock webapp.

sherlock-audit / 2023-10-real-wagmi-judging

0xMaroutis - Issue with Borrower's Incentive in using this protocol #177