Skip to content

Latest commit

 

History

History
63 lines (44 loc) · 1.93 KB

File metadata and controls

63 lines (44 loc) · 1.93 KB

Fast Khaki Raccoon

Medium

Incorrect application of fees results in admin receiving more than supposed to

Summary

Incorrect application of fees results in admin receiving more than supposed to

Root Cause

Upon calling TokenRewards::depositFromPairedLpToken(), we have the following code:

uint256 _adminAmt = _getAdminFeeFromAmount(_amountTkn);
        _amountTkn -= _adminAmt;

        if (LEAVE_AS_PAIRED_LP_TOKEN) {
            (, uint256 _yieldBurnFee) = _getYieldFees();
            uint256 _burnAmount = (_amountTkn * _yieldBurnFee) / PROTOCOL_FEE_ROUTER.protocolFees().DEN();
            _adminAmt += _burnAmount;
            _amountTkn -= _burnAmount;
            if (_adminAmt > 0) {
                _processAdminFee(_adminAmt);
            }
            _depositRewards(PAIRED_LP_TOKEN, _amountTkn);
            return;
        }

The function applies an admin fee to the token amount and then if LEAVE_AS_PAIRED_LP_TOKEN is true, we apply a burn fee as well. The issue is that the burn amount is applied to the admin amount and is then simply transferred to him:

    function _processAdminFee(uint256 _amount) internal {
        IERC20(PAIRED_LP_TOKEN).safeTransfer(OwnableUpgradeable(address(V3_TWAP_UTILS)).owner(), _amount);
    }

This results in the admin receiving more than supposed to.

Internal Pre-conditions

No response

External Pre-conditions

No response

Attack Path

  1. TokenRewards::depositFromPairedLpToken() is called and LEAVE_AS_PAIRED_LP_TOKEN is true
  2. We apply a 10% admin fee to 100 tokens, resulting in 90 tokens leftover and admin amount being 10
  3. We then apply a 10% burn fee to the 90 tokens, resulting in 81 tokens leftover and admin amount going to 19
  4. Admin unfairly receives 19 tokens

Impact

Unfair distribution of the amount, users receive less rewards and admin receives more

PoC

No response

Mitigation

Do not give a burn fee to the admin