Minimum liquidity pool share may become infeasible for small liquidity providers to provide any liquidity

[code423n4]

Lines of code

https://github.com/code-423n4/2022-12-caviar/blob/d42a53b569ee06254ec3b5fd17ca2e527592dfe4/src/Pair.sol#L426

Vulnerability details

Impact

Pair.addQuote calculates the amount of LP tokens received for adding a given amount of base tokens and fractional tokens. If there are no existing deposits, then initializes to Math.sqrt(baseTokenAmount * fractionalTokenAmount). The problem arises when the value of a liquidity pool share grows over time, either by accumulating trading fees or through “donations” to the liquidity pool. In theory, this could result in a situation where the value of the minimum quantity of liquidity pool shares (1e-18 pool shares) is worth so much that it becomes infeasible for small liquidity providers to provide any liquidity. (See here on Uniswap v2 whitepaper). Creating MINIMUM_LIQUIDITY tokens and sending them to address zero to lock them also makes sure that they can never be redeemed, which means the pool will never be emptied completely, and this saves us from division by zero in some places (See Ethereum.org contract walkthrough).

Proof of Concept

With time, the worth of the minimum quantity of liquidity pool share (i.e. 1**-18), becomes high. High enough that the small liquidity providers will be unable to provide liquidity.

Tools Used

Manual inspection

Recommended Mitigation Steps

To mitigate this issue, Uniswap v2 burns the first 1e-15 (0.000000000000001) pool shares that are minted (1000 times the minimum quantity of pool shares), sending them to the zero address instead of to the minter. This should be a negligible cost for almost any token pair. But it dramatically increases the cost of the above attack. In order to raise the value of a liquidity pool share to 100 USD, the attacker would need to donate 100,000 USD to the pool, which would be permanently locked up as liquidity.

diff --git a/src/Pair.sol b/src/Pair.sol
index 185d25c..73bb3ff 100644
--- a/src/Pair.sol
+++ b/src/Pair.sol
@@ -19,6 +19,7 @@ contract Pair is ERC20, ERC721TokenReceiver {
 
     uint256 public constant ONE = 1e18;
     uint256 public constant CLOSE_GRACE_PERIOD = 7 days;
+    uint256 public constant MINIMUM_LIQUIDITY = 1000;
 
     address public immutable nft;
     address public immutable baseToken; // address(0) for ETH
@@ -86,6 +87,9 @@ contract Pair is ERC20, ERC721TokenReceiver {
 
         // *** Interactions *** //
 
+        if(lpToken.totalSupply() == 0) {
+            lpToken.mint(address(0), MINIMUM_LIQUIDITY); // permanently lock the first MINIMUM_LIQUIDITY tokens
+        }
         // mint lp tokens to sender
         lpToken.mint(msg.sender, lpTokenAmount);
 
@@ -423,7 +427,7 @@ contract Pair is ERC20, ERC721TokenReceiver {
             return Math.min(baseTokenShare, fractionalTokenShare);
         } else {
             // if there is no liquidity then init
-            return Math.sqrt(baseTokenAmount * fractionalTokenAmount);
+            return Math.sqrt(baseTokenAmount * fractionalTokenAmount) - MINIMUM_LIQUIDITY;
         }
     }
 

[c4-judge]

berndartmueller marked the issue as duplicate of #442

[c4-judge]

berndartmueller changed the severity to 3 (High Risk)

[c4-judge]

berndartmueller marked the issue as satisfactory