Uniswap V2 LP tokens are ERC4626 tokens that are comprised of 2 assets. ERC4626 tokens maintain a consistent asset/share ratio upon deposits and withdrawals. Rewards can be distributed to shareholders by increasing assets without increasing the number of shares. In Uniswap V2, the L = sqrt( token0 * token1) "invariant" is followed for liquidity deposits, withdrawals and swaps. "Invariant" is in quotes because this isn't a true invariant - the token amounts can increase due to donations or fee accrual. The token reserves are tracked with internal accounting variables but inflating these variables is easy because the sync() function makes the reserve accounting variables equal to the token balances. Most inflation attacks that apply to ERC4626 vaults also apply to Uniswap V2 LP tokens. For example, there have been many instances of hacks which occurred when LP tokens were included as a borrow asset. The lending pool becomes vulnerable to attacks that donate to inflate the value of the LP token. Many other AMM LP tokens are vulnerable to inflation attacks in the same way. The first-deposit inflation attack doesn't work on Uniswap v2 because Uniswap v2 mints dead shares that don't belong to any user during the first deposit. The same mitigation is used in some ERC4626 vaults.
@banditx0x This is super important. A lot of projects don’t realize how easy it is to mess with Uniswap V2 reserves because of sync(). If you’re using LP tokens, treat their value as something that can be manipulated.
@banditx0x what do you think about having virtual shares like in the yieldbox model instead of burning some initial shares?
