Small bug to report, I don't think it's a security risk, but may have some effects on any strategy/code that deals with minting LP tokens on a pool.
For PoolNonTV, the mint function is incorrect as it assumes any amount of base is what the user deposits, but for non-tv pools, there'll be base already, so the baseIn return param is wrong, it misleads the caller saying a bigger amount of base was used for minting the LP tokens
The value is only used for return and for the event, so it shouldn't have a negative effect on the mint logic
IMO, an easy fix is to change this line (baseIn = baseToken.balanceOf(address(this));) to also subtract the cached base tokens.
Where this bug could be problematic?:
Integrations that rely on the return values to verify the minting process (like newer Strategy contracts).
Event based indexers like TheGraph/Dune that may use the values reported by the Liquidity event.
Small bug to report, I don't think it's a security risk, but may have some effects on any strategy/code that deals with minting LP tokens on a pool.
For
PoolNonTV, themintfunction is incorrect as it assumes any amount ofbaseis what the user deposits, but for non-tv pools, there'll be base already, so thebaseInreturn param is wrong, it misleads the caller saying a bigger amount of base was used for minting the LP tokensThe value is only used for return and for the event, so it shouldn't have a negative effect on the mint logic
IMO, an easy fix is to change this line (
baseIn = baseToken.balanceOf(address(this));) to also subtract the cached base tokens.Where this bug could be problematic?:
Strategycontracts).Liquidityevent.