Sequential fee charging lowers the total fees collected

[hats-bug-reporter[bot]]

Github username: @0x3b33 Twitter username: -- Submission hash (on-chain): 0xf2272eb1d86d82d16625c83af98475f043e86d1c55589a97e2b6123f852a481b Severity: low

Description: Description\ The getRedeemAssetsAndFees function charges fees sequentially, meaning the second fee is calculated on the reduced amount after the first fee is charged.

 protocolFee = protocolFeeAmount(assetsForReceiverBeforeFees, id);
 uint256 assetsForReceiverAfterprotocolFee =  assetsForReceiverBeforeFees - protocolFee;
 exitFee = exitFeeAmount(assetsForReceiverAfterprotocolFee, id);

This approach is generally problematic because the second fee will always be lower than its set value and will always depend on the first fee.

Attack Scenario

• Protocol fee is 2% and exit fee is 2%.

1. Monthly redeem volume is 1 million (can be much higher).
2. Monthly protocol fees are 1,000,000 * 2% = 20,000.
3. Monthly exit fees should also be 20,000, as the exit fee is 2%. However, since it is charged on the already reduced balance (after the protocol fee), the amount will be (1,000,000 - 20,000) * 2% = 19,600.

Although this discrepancy may seem small, it will grow significantly with higher usage, ex. 10+ mil.

Recommendations\ Charge the fee on the full amount.

        } else {
             protocolFee = protocolFeeAmount(assetsForReceiverBeforeFees, id);
+           exitFee = exitFeeAmount(assetsForReceiverBeforeFees, id);
-            uint256 assetsForReceiverAfterprotocolFee = assetsForReceiverBeforeFees - protocolFee;
-            exitFee = exitFeeAmount(assetsForReceiverAfterprotocolFee, id);
        }

        uint256 totalUserAssets = assetsForReceiverBeforeFees;
        uint256 assetsForReceiver = assetsForReceiverBeforeFees - exitFee - protocolFee;

[mihailo-maksa]

Sequential fee charging is intentional and not a bug. This design ensures fair and transparent fee calculations, aligning with our protocol's operational principles.

Therefore, this issue is invalid.