rounding errors in the deposit and withdraw logic

Summary

The share amounts are calculated from token balances, which could lead to tiny amounts of funds being lost or locked over many transactions

Vulnerability Detail

There is potential for rounding errors in the deposit and withdraw logic due to calculating share amounts from token balances. In the deposit function, the shareAmount is calculated as: Link 1. Where cBalanceBefore and cBalanceAfter are the bToken balances before and after minting new bTokens. The actual amount of bTokens minted is: Link 2 So there could be a slight difference between the bTokens minted and the change in bToken balance, leading to rounding errors over time. Similarly, in the withdraw function, the shareAmount burnt is compared to the change in underlying token balance: Link 3 When redeeming bTokens: bToken.redeem(shareAmount) There could again be slight differences leading to rounding errors.

The issue is that token balances are uint256 and may contain minor inaccuracies due to rounding. For example: • User deposits 10.5 tokens • 10 tokens are transferred to the contract and minted into 10 bTokens • But the contract records shareAmount as 10 bTokens instead of 10.5 • 0.5 tokens worth of funds are lost

Impact

Tiny amounts of funds can be lost or locked in the contract rather than returned to users.

Code Snippet

https://github.com/sherlock-audit/2023-07-blueberry/blob/main/blueberry-core/contracts/vault/SoftVault.sol#L109 https://github.com/sherlock-audit/2023-07-blueberry/blob/main/blueberry-core/contracts/vault/SoftVault.sol#L105 https://github.com/sherlock-audit/2023-07-blueberry/blob/main/blueberry-core/contracts/vault/SoftVault.sol#L132

Tool used

Manual Review

Recommendation

the shareAmounts should be calculated from the actual amounts minted/redeemed, not the balance differences

sherlock-audit / 2023-07-blueberry-judging

feelereth - rounding errors in the deposit and withdraw logic #92