Part 2

Summary

The bug occurs in the way the redeem fee is applied during the calculation of expected asset output for share redemption. In the VaultRouterBranch::getIndexTokenSwapRate function, when the shouldDiscountRedeemFee flag is true, the redeem fee is subtracted from the computed preview assets out. However, in the overall redeem flow, the redeem fee is later subtracted from the expected assets. This double‑discounting (or misapplication) of the fee results in an incorrect expected asset value, causing users to receive less assets than they should. The bug is compounded by the fact that if the fee should be waived (i.e. not charged), the discount logic should instead add back the fee—effectively canceling the subtraction that occurs in the redeem function—rather than subtracting it.

Vulnerability Details

Misapplied Fee Discount in VaultRouterBranch::getIndexTokenSwapRate:

The function getIndexTokenSwapRate computes a preliminary value, previewAssetsOut, based on the vault’s net credit capacity and share ratio.When shouldDiscountRedeemFee is true, the code subtracts the fee:

This logic subtracts the fee from the preview assets, which then returns a lower asset amount. However, in VaultRouterBranch::redeem, after receiving expectedAssetsX18 from VaultRouterBranch::getIndexTokenSwapRate, the redeem fee is again applied by subtracting a fraction of expectedAssetsX18:

If shouldDiscountRedeemFee is true, it indicates that the expected asset output should not be reduced by the fee at this stage (or should be adjusted such that later fee subtraction in the redeem function results in the correct net value). In other words, the fee should be added back (or not discounted) in getIndexTokenSwapRate so that the final redeem calculation subtracts the fee exactly once.

The current code subtracts the fee in getIndexTokenSwapRate, and then subtracts it again in the redeem flow, leading to an excessive fee deduction. As a consequence, users redeeming their shares receive fewer assets than expected. This miscalculation undermines user trust and can result in significant financial discrepancies, particularly in high‑volume or high‑value redemptions.

Proof Of Code (POC)

Impact

Financial Loss: Users will receive less than the expected amount of underlying assets upon redemption due to the double application of the redeem fee.
Protocol Imbalance: The overall accounting within the vault may become inconsistent if the redeem fee is applied incorrectly, potentially affecting credit capacity calculations and subsequent financial operations.

Tools Used

Manual Review, Foundry

Recommendations

Correct Fee Discount Logic in getIndexTokenSwapRate:

Modify the fee application in getIndexTokenSwapRate so that when shouldDiscountRedeemFee is true, the redeem fee is added to (or not subtracted from) previewAssetsOut. This ensures that the final redeem fee is applied only once in the redeem function.

Note: The exact arithmetic may need to be adjusted to correctly cancel the later subtraction in the redeem function.

Reevaluate the overall redeem flow to ensure that the redeem fee is applied exactly once. Consider centralizing the fee adjustment logic either in getIndexTokenSwapRate or in the redeem function to avoid duplicated adjustments. Ensure that the shouldDiscountRedeemFee flag correctly reflects whether the fee should be waived or applied, and document the intended behavior clearly.