Summary

UnripeFacet is responsible for allowing users who hold Unripe Tokens to effectively exchange them for Ripe Tokens.

This is done by calling chop, passing in the address of the unripeToken, the amount of unripeTokens to be exchanged, and the address of the user who is exchanging them, and both the toMode and fromMode.

Once the totalSupply is fetched, the LibChop.chop function is called, passing in the amount of unripeTokens to be exchanged, the totalSupply of unripeTokens, and the address of the unripeToken.

However, the vulnerability arises from the way Solidity truncates division.

Vulnerability Details

When converting unripe tokens into their ripe counterparts, the conversion rate and subsequent calculations can result in the final amount of ripe tokens being less than the ideally expected amount.

This scenario unfolds across two critical steps:

Calculation of sharesBeingRedeemed:

This step involves adjusting the amount of unripe tokens based on the recapitalization percentages (fertilized_index and unfertilized_index). Due to rounding down, the effective shares to be redeemed might be less than the proportional share based on the input amount.

Determination of redeem Amount:

This step calculates the amount of ripe tokens corresponding to the sharesBeingRedeemed. Again, due to rounding down, the final redeemable amount may be less than what could be expected from a precise calculation.

POC:

Lets play with these figures below for argument sake.

unfertilized_index = 1200
fertilized_index = 1000 (considering unfertilizedIndex will always be >= fertilizedIndex.)
amount_unripe_tokens = 10
totalSupply = 1000
balance_of_underlyingTokens = 800

Here, the number of shares to be redeemed is determined based on the fertilized and unfertilized indexes,
with the formula (fertilized_index * amount_unripe_tokens) / unfertilized_index.

This results in (1000 * 10) / 1200 = 8.33.

Due to the division operation, rounding down can occur, resulting in fewer sharesBeingRedeemed than mathematically accurate.

Calculation of Redeemable Amount (redeem):

The redeemable ripe token amount is calculated by (balance_of_underlying * sharesBeingRedeemed) / supply

This results in (800 * 8.33) / 1000 = 6.66.

Again, the division operation can lead to rounding down, further exacerbating the loss from the initial calculation.

Impact

The primary impact of this vulnerability is the potential for users to receive fewer ripe tokens
than expected when converting from unripe tokens.

Tools Used

Manual Review

Recommendations

Considering that the remaining tokens will be present in the contract, utilize a method todistribute the remaining tokens to the users.