Open code423n4 opened 2 years ago
This is correct, though I believe un needed. If the user wants to create a vault for a deflationary token they need only account for said transfer fee when calculating their initialLiquidityNew
value.
Not sure how you can account for transfer fee in initialLiquidityNew
since it's the same amount used for approval and deposit: IBathToken(newOne).deposit(initialLiquidityNew, msg.sender);
It simply means that deflationary / FoT tokens arent supported at all, which isn't necessarily a bad thing. There isn't a loss of assets, though function of the protocol or its availability could be impacted
. Keeping it at medium severity, although could've potentially lowered to QA too.
Lines of code
https://github.com/code-423n4/2022-05-rubicon/blob/8c312a63a91193c6a192a9aab44ff980fbfd7741/contracts/rubiconPools/BathHouse.sol#L136-L203
Vulnerability details
Impact
Function
openBathTokenSpawnAndSignal
will alway revert whennewBathTokenUnderlying
ordesiredPairedAsset
is deflationary tokenProof of Concept
There are ERC20 tokens that may make certain customizations to their ERC20 contracts. One type of these tokens is deflationary tokens that charge a certain fee for every
transfer()
ortransferFrom()
For example, I will assume thatnewBathTokenUnderlying
is deflationary token. After line 163, the actual amount ofnewBathTokenUnderlying
that BathHouse gained will be smaller thaninitialLiquidityNew
. It will make the deposit call reverted because there are not enough fund to transfer.Tools Used
Manual review
Recommended Mitigation Steps
set
initialLiquidityNew = newBathTokenUnderlying.balanceOf(address(this))
after line 163 andinitialLiquidityExistingBathToken = desiredPairedAsset.balanceOf(address(this))
after line 178