sakshamguruji - Not The Entire Token Amounts Provided To AMM Might Get Consumed Leading To Incorrect Accounting Of LV Tokens

[sherlock-admin2]

sakshamguruji

Medium

Not The Entire Token Amounts Provided To AMM Might Get Consumed Leading To Incorrect Accounting Of LV Tokens

Summary

When RA is deposited into the Vault then a part of that RA is used to to mint CT (and DS) and then RA + CT are added as liquidity in the AMM , this is done by first calculating the ratio and then providing assets in that ratio , but it is possible that assets are not provided in the exact ratio which means not all of the assets will be used by UniV2 to be added as liquidity , therefore there will be some left out assets . But these left out assets are not accounted.

Vulnerability Detail

1.) When RA is deposited in the vault , liquidity is added to the AMM in the calculated ratio ->

https://github.com/sherlock-audit/2024-08-cork-protocol/blob/main/Depeg-swap/contracts/libraries/VaultLib.sol#L204

function __provideLiquidityWithRatio(
        State storage self,
        uint256 amount,
        IDsFlashSwapCore flashSwapRouter,
        address ctAddress,
        IUniswapV2Router02 ammRouter
    ) internal returns (uint256 ra, uint256 ct) {
        uint256 dsId = self.globalAssetIdx;

        uint256 ctRatio = __getAmmCtPriceRatio(self, flashSwapRouter, dsId);

        (ra, ct) = MathHelper.calculateProvideLiquidityAmountBasedOnCtPrice(amount, ctRatio);

        __provideLiquidity(self, ra, ct, flashSwapRouter, ctAddress, ammRouter, dsId);
    }

And inside calculateProvideLiquidityAmountBasedOnCtPrice ->

function calculateProvideLiquidityAmountBasedOnCtPrice(uint256 amountra, uint256 priceRatio)
        external
        pure
        returns (uint256 ra, uint256 ct)
    {
        ct = (amountra * 1e18) / (priceRatio + 1e18);
        ra = (amountra - ct);

        assert((ct + ra) == amountra);
    }

Therefore if amountRa = 33333333333333333333 and ratio was 50e18 , there will be some rounding in the calculated amounts of CT and RA , also the (+ 1e18) in the denominator can will cause some results which will be not necessarily follow the ratio(that's because we must convert the RA to CT, imagine if it would be 50 RA 50 CT but we only had 50 RA, and it's costs us 50 RA to make 50 CT in the PSM. so that's why we add 1 to the equation)

2.) Therefore when adding liquidity to the AMM ->

https://github.com/sherlock-audit/2024-08-cork-protocol/blob/main/Depeg-swap/contracts/libraries/VaultLib.sol#L74

Due to above mentioned reasons there will be some unutilised amount of RA/CT since the amounts were not provided in the actual ratio , and by time these amounts will grow larger .

3. These are unaccounted since we assume all of the RA/CT got consumed and mint LV ->

https://github.com/sherlock-audit/2024-08-cork-protocol/blob/main/Depeg-swap/contracts/libraries/VaultLib.sol#L205

The amount of LV minted is the amount of tokens provided to AMM but as discussed not all of the token amounts will be added as liquidity therefore the LV minted will always be a bit higher.

Impact

Not The Entire Token Amounts Provided To AMM Might Get Consumed Leading To Incorrect Accounting Of Ra/Ct and LV Tokens

Code Snippet

https://github.com/sherlock-audit/2024-08-cork-protocol/blob/main/Depeg-swap/contracts/libraries/VaultLib.sol#L74

Tool used

Manual Review

Recommendation

Only account for the tokens actually added as liquidity in the AMM.

Duplicate of #240

[SakshamGuruji3]

Escalate

This should be a dupe of #240 , not #155

[sherlock-admin3]

Escalate

This should be a dupe of #240 , not #155

You've created a valid escalation!

To remove the escalation from consideration: Delete your comment.

You may delete or edit your escalation comment anytime before the 48-hour escalation window closes. After that, the escalation becomes final.

[cvetanovv]

I agree it is dupe of #240.

[WangSecurity]

Planning to accept the escalation and duplicate with #240

[WangSecurity]

Result:
Medium
Duplicate of #240

[sherlock-admin4]

Escalations have been resolved successfully!

Escalation status:

• SakshamGuruji3: accepted