Judge has assessed an item in Issue #179 as 3 risk. The relevant finding follows:
There’s also a reentrancy in uniswapV3MintCallback() with ERC777 tokens (the project supports them). When Alice calls mintTokenizedPosition() the following will happen:
She’ll receive SFPM tokens from _mint();
_createLegInAMM() calculates and updates the liquidity held by Alice;
_mintLiquidity() calls UniswapV3Pool.mint();
Uniswap calls back to uniswapV3MintCallback();
The callback calls the token to transfer funds from Alice to Uniswap;
And if the token is ERC777, it’ll call Alice before the transfer. At this point, Alice has both SFPM tokens and liquidity to use in external systems before actually paying any money. Even if these external systems rely on non-standard liquidity counters inside SFPM (s_accountLiquidity mapping) instead of the standard ERC1155 to determine the liquidity held by Alice, they will still be vulnerable to this reentrancy. Solution here is to update the liquidity after the payment.
Judge has assessed an item in Issue #179 as 3 risk. The relevant finding follows:
There’s also a reentrancy in uniswapV3MintCallback() with ERC777 tokens (the project supports them). When Alice calls mintTokenizedPosition() the following will happen: She’ll receive SFPM tokens from _mint(); _createLegInAMM() calculates and updates the liquidity held by Alice; _mintLiquidity() calls UniswapV3Pool.mint(); Uniswap calls back to uniswapV3MintCallback(); The callback calls the token to transfer funds from Alice to Uniswap; And if the token is ERC777, it’ll call Alice before the transfer. At this point, Alice has both SFPM tokens and liquidity to use in external systems before actually paying any money. Even if these external systems rely on non-standard liquidity counters inside SFPM (s_accountLiquidity mapping) instead of the standard ERC1155 to determine the liquidity held by Alice, they will still be vulnerable to this reentrancy. Solution here is to update the liquidity after the payment.