You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
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
, themint
function is incorrect as it assumes any amount ofbase
is what the user deposits, but for non-tv pools, there'll be base already, so thebaseIn
return 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?:
Strategy
contracts).Liquidity
event.The text was updated successfully, but these errors were encountered: