DeFiHardhat
21,000 USDC
View results
Submission Details
Severity: medium
Invalid

`addUnderlying` incorrectly assumes that BarnRaiseToken is not a fee on transfer token

Summary

The way the addUnderlying function handles the underlying token doesn't account for the barnRaiseToken or underlying token being a FOT token.

Vulnerability Details

When the addUnderlying function is queried, the needed calculations are executed, then the barnRaiseWell and barnRaiseToken are gotten from LibBarnRaise.sol
From the library, it can be inferred that the barnRaiseToken can either be WETH representing ETH from the BEAN_ETH_WELL, or the underlying token which could be any ERC20 token supported by the protocol, as well as can be switched.

function addUnderlying(uint256 tokenAmountIn, uint256 usdAmount, uint256 minAmountOut) internal {
...
// Mint the LP Beans and add liquidity to the well.
address barnRaiseWell = LibBarnRaise.getBarnRaiseWell();
address barnRaiseToken = LibBarnRaise.getBarnRaiseToken();
...
IERC20(barnRaiseToken).transferFrom(
msg.sender,
address(this),
uint256(tokenAmountIn)
);
...
uint256 newLP = IWell(barnRaiseWell).addLiquidity(
tokenAmountsIn,
minAmountOut,
address(this),
type(uint256).max
);
...
}

Impact

The use of basic transferFrom and addLiquidity will lead to loss of positive slippage and unexpected reversions, when upon swaps (and fees from the transfer), the returned amount becomes less than the minimum amount out.

Tools Used

Manual review

Updates

Lead Judging Commences

giovannidisiena Lead Judge about 1 year ago
Submission Judgement Published
Invalidated
Reason: Known issue

Support

FAQs

Can't find an answer? Chat with us on Discord, Twitter or Linkedin.