Tapioca DAO - 0xnev's results

Lines of code

https://github.com/Tapioca-DAO/tapioca-bar-audit/blob/master/contracts/markets/bigBang/BigBang.sol#L721-L739 https://github.com/Tapioca-DAO/tapioca-bar-audit/blob/master/contracts/markets/singularity/SGLLendingCommon.sol#L83-L98

Vulnerability details

Impact and Details

In _liquidateUser()/_orderBookLiquidation(), the internal _repay() function is never called, hence indicating that liquidator USDO balance is not burnt to repay borrower's CDP positions.

While it is true they only receive liquidation incentive based on current exchange rates, it essentially means that the liquidation mechanism is free of charge, since liquidator's do not risk their own CDP positions.

Depending on collateral type, this can cause the Tapioca's BigBang/Singularity markets to incur huge losses in the form of paying profits for liquidator's for free.

• Liquidator's USDO balance is not updated (burned) based on current exchange rate, allowing liquidator's to arbritrage, by choosing exchange rates that favor them to liquidate, they can drain collateral in the form of rewards paid by Tapioca protocol due to liquidation bonuses
• This allows liquidators to always keep a healthy CDP position by redepositing earned rewards and borrow more USDO
• This also opens up for malicious borrowers to liquidate their own positions to get liquidation bonus and then redeposit, allowing them to permanently prevent positions from liquidation and incur bad debt for Singularity and BigBang markets due to payment of liquidation bonuses.

Tools Used

Manual Analysis

Recommendation

Call the internal _repay() function when liquidator's liquidate borrower's CDP position under maximum LTV ratio via liquidate() function. This forces liquidators to burn their EUSD (signifying loss)

Assessed type

Context

Lines of code

https://github.com/Tapioca-DAO/tapioca-bar-audit/blob/master/contracts/markets/bigBang/BigBang.sol#L604-L606 https://github.com/Tapioca-DAO/tapioca-bar-audit/blob/master/contracts/markets/singularity/SGLLiquidation.sol#L350 https://github.com/Tapioca-DAO/tapioca-bar-audit/blob/master/contracts/markets/singularity/SGLLeverage.sol#L21 https://github.com/Tapioca-DAO/tapioca-bar-audit/blob/master/contracts/markets/singularity/SGLLeverage.sol#L58 https://github.com/Tapioca-DAO/tapioca-bar-audit/blob/master/contracts/markets/bigBang/BigBang.sol#L336 https://github.com/Tapioca-DAO/tapioca-bar-audit/blob/master/contracts/markets/bigBang/BigBang.sol#L384 https://github.com/Tapioca-DAO/tapioca-bar-audit/blob/master/contracts/markets/singularity/SGLLeverage.sol#L147 https://github.com/Tapioca-DAO/tapioca-bar-audit/blob/master/contracts/markets/singularity/SGLLeverage.sol#L97

Vulnerability details

Impact and Details

Functions lacking both slippage and deadline checks

• BigBang._liquidateUser(): Link
• Singularity._liquidateUser(): Link
• SGLLeverage.multiHopBuyCollateral(): Link
• SGLLeverage.multiHopSellCollateral(): Link

Functions lacking only deadline checks:

• BigBang.buyCollateral(): Link
• BigBang.sellCollateral(): Link
• SGLLeverage.buyCollateral(): Link
• SGLLeverage.sellCollateral(): Link

The BigBang/Singularity._liquidateUser() is called by _closedLiquidation() which is in turn called by liquidate() when liquidating CDP positions greater than maximum LTV ratios. One of the inputs is collateralToAssetSwapData calldata which allows user to input necessary swap information such as slippage.

During the liquidation process, while the data is successfully decoded, it is never checked against minimumAmount swapped out when swapping collateral to USDO, and thus liquidator slippage tolerance is never checked against amount of USDO swapped and transferred back to BigBang/Singularity.sol contract, similar to that performed in buyCollateral()/sellCollateral().

This issue also exist in LiquidationQueue.executeBids() which is called by SGLLiquidation._orderBookLiquidation(), where swapData is passed in as input but never decoded and checked.

In addition, all functions that involves a swap does not allow for the pass in of a deadline check for transaction expiration. This could mean being exposed to sandwich attacks due to being exposed to undesired slippage, and ultimately lead to lower liquidation incentives transferred to liquidators.

Tools Used

Manual Analysis

Recommendation

Ensure slippage check is performed in all functions involving a swap and consider adding an additional deadline check to prevent MEV/sandwich attacks.

Assessed type

Context

Lines of code

https://github.com/Tapioca-DAO/tapioca-bar-audit/blob/master/contracts/markets/singularity/SGLCommon.sol#L107

Vulnerability details

Impact and Details

In SGLCommon._getInterestRate(), the amount of fees that protocol accrue may be much lower than expected due to not converting feeAmount back to Asset amount.

feeAmount is in terms of USDO amount, and is multiplied by totalAsset.base / fullAssetAmount to essentially convert it back to base amount, that is the total asset to pay to protocol's fee receiver address.

However, this feeAmount should be multiplied by base borrowed positions represented by _totalBorrow.base instead of _totalAsset.base. This could potentially overestimate/underestimate protocol fees paid to protocol via Singularity.withdrawFeesEarned() since totalAssets used as collateral for lending USDO could be higher/lower than borrowed amount of USDO by lenders due to LTV ratio requirements.

SGLCommon.sol#L107

    function _getInterestRate()
        internal
        view
        returns (
            ISingularity.AccrueInfo memory _accrueInfo,
            Rebase memory _totalBorrow,
            Rebase memory _totalAsset,
            uint256 extraAmount,
            uint256 feeFraction,
            uint256 utilization,
            bool logStartingInterest
        )
    {
        ...
        ...
        extraAmount =
            (uint256(_totalBorrow.elastic) *
                _accrueInfo.interestPerSecond *
                elapsedTime) /
            1e18;
        _totalBorrow.elastic += uint128(extraAmount);

        uint256 feeAmount = (extraAmount * protocolFee) / FEE_PRECISION; // % of interest paid goes to fee
        /// @audit feeAmount should be multiplied by _totalBorrow.base
->      feeFraction = (feeAmount * _totalAsset.base) / fullAssetAmount;
        _accrueInfo.feesEarnedFraction += uint128(feeFraction);
        _totalAsset.base = _totalAsset.base + uint128(feeFraction);
        ...
        ...

Tools Used

Manual Analysis

Recommendation

    function _getInterestRate()
        internal
        view
        returns (
            ISingularity.AccrueInfo memory _accrueInfo,
            Rebase memory _totalBorrow,
            Rebase memory _totalAsset,
            uint256 extraAmount,
            uint256 feeFraction,
            uint256 utilization,
            bool logStartingInterest
        )
    {
        ...
        ...
        extraAmount =
            (uint256(_totalBorrow.elastic) *
                _accrueInfo.interestPerSecond *
                elapsedTime) /
            1e18;
        _totalBorrow.elastic += uint128(extraAmount);

        uint256 feeAmount = (extraAmount * protocolFee) / FEE_PRECISION; // % of interest paid goes to fee
        /// @audit feeAmount should be multiplied by _totalBorrow.base
--      feeFraction = (feeAmount * _totalAsset.base) / fullAssetAmount;
++      feeFraction = (feeAmount * _totalBorrow_.base) / fullAssetAmount;
        _accrueInfo.feesEarnedFraction += uint128(feeFraction);
        _totalAsset.base = _totalAsset.base + uint128(feeFraction);
        ...
        ...

Assessed type

Context