Uniswap liquidity manager #12

potvik · 2024-12-01T00:20:49Z

No description provided.

polymorpher · 2024-12-02T21:17:49Z

Can you import interfaces and contracts where it is possible to do so? I think the number of duplicated files are getting difficult to manage. For example, PoolAddress, INonfungiblePositionManager and its dependencies can be installed and imported from uniswap/v3-periphery (forge)

polymorpher · 2024-12-02T21:27:36Z

contracts/LiquidityManager.sol

+    int24 private constant TICK_SPACING = 60;
+
+    address internal immutable WETH;
+    address public nonfungiblePositionManager;


INonfungiblePositionManager

polymorpher · 2024-12-02T21:27:47Z

contracts/LiquidityManager.sol

+    int24 private constant MAX_TICK = -MIN_TICK;
+    int24 private constant TICK_SPACING = 60;
+
+    address internal immutable WETH;


polymorpher · 2024-12-02T21:28:02Z

contracts/LiquidityManager.sol

+
+    address internal immutable WETH;
+    address public nonfungiblePositionManager;
+    address public uniswapV3Factory;


IUniswapV3Factory

polymorpher · 2024-12-02T21:40:37Z

contracts/LiquidityManager.sol

+        token.approve(nonfungiblePositionManager, tokenAmount);
+
+        uint256 eth = address(this).balance;
+        IWETH(WETH).deposit{value: eth}();


Should not deposit everything to WETH. Just check if approved amount is already greater than what's needed. If there is a shortage, approve and deposit that amount

polymorpher · 2024-12-02T21:54:22Z

contracts/LiquidityManager.sol

+        return pool;
+    }
+
+    function sqrt(uint256 x) internal pure returns (uint256) {


use sqrt function in UD60X18 from prb-math instead? It is already installed in foundry dependency. Same approximation method, but checks for overflow, uses better initialization value, and limit the number of approximation steps

polymorpher · 2024-12-02T22:04:27Z

contracts/LiquidityManager.sol

+        IWETH(WETH).deposit{value: eth}();
+        IWETH(WETH).approve(nonfungiblePositionManager, eth);
+
+        uint160 sqrtPriceX96 = uint160(sqrt((ethAmount * 2 ** 192) / tokenAmount));


This will overflow easily, since 1e18 ~= 2^60, so any amount of native token greater than 2^(256-192-60) = 2^14 = 16384 would make ethAmount * 2 ** 192 overflow. I suggest scaling it by 96 bits only (which gives 2^96 more "space" to prevent overflow) before taking the division and sqrt, then scaling it by another 48 bits afterwards

polymorpher · 2024-12-02T22:15:01Z

contracts/LiquidityManager.sol

+        IWETH(WETH).approve(nonfungiblePositionManager, eth);
+
+        uint160 sqrtPriceX96 = uint160(sqrt((ethAmount * 2 ** 192) / tokenAmount));
+        _nonfungiblePositionManager.createAndInitializePoolIfNecessary(tokenAddress, WETH, UNISWAP_FEE, sqrtPriceX96);


Method does not exist. Just call initialize with sqrtPriceX96? Pool should be already created

polymorpher · 2024-12-02T22:19:20Z

contracts/LiquidityManager.sol

+        uint160 sqrtPriceX96 = uint160(sqrt((ethAmount * 2 ** 192) / tokenAmount));
+        _nonfungiblePositionManager.createAndInitializePoolIfNecessary(tokenAddress, WETH, UNISWAP_FEE, sqrtPriceX96);
+
+        INonfungiblePositionManager.MintParams memory params = INonfungiblePositionManager.MintParams({


The convention (used in Uniswap code) is to order [token0,token1] addresses based on their hexadecimal value, and to have the lower valued address as token0. The pool does it automatically upon creation, so the parameters here should follow the same convention as well

polymorpher · 2024-12-02T22:20:49Z

contracts/LiquidityManager.sol

+            tickUpper: (MAX_TICK / TICK_SPACING) * TICK_SPACING,
+            amount0Desired: tokenAmount,
+            amount1Desired: ethAmount,
+            amount0Min: 0,


Should be close to tokenAmount and ethAmount, as sanity check

polymorpher · 2024-12-02T22:39:16Z

contracts/LiquidityManager.sol

+            token0: tokenAddress,
+            token1: WETH,
+            fee: UNISWAP_FEE,
+            tickLower: (MIN_TICK / TICK_SPACING) * TICK_SPACING,


The initial liquidity added shouldn't concentrated at around the tick for initial price. It should spread out (from MIN to MAX, or some reasonable price range) so everyone can trade the token regardless of its current price

polymorpher · 2024-12-02T22:50:59Z

contracts/TokenFactory.sol

-            block.timestamp
-        );
+        if(winnerToken == tokenAddress) {
+            address pool = _createLiquilityPool(tokenAddress);


should check that a pool was not created before, and revert if it was

polymorpher · 2024-12-02T23:04:34Z

contracts/TokenFactory.sol

+            uint256 creatorBalance = token.balanceOf(creator);
+
+            // burned all creator tokens    
+            token.burn(creator, creatorBalance);


Token creator's tokens shouldn't be burned and seized. Otherwise there is no incentive for them to create tokens and market that

polymorpher · 2024-12-02T23:07:10Z

contracts/TokenFactory.sol

-            mintedAmount,
-            block.timestamp
-        );
+        if(winnerToken == tokenAddress) {


Use a different function for "graduating to Uniswap"? Since the logic is completely different from burning losing tokens

polymorpher · 2024-12-02T23:21:20Z

For a new pool, the initial native token deposit (during liquidity provisioning) should be the total collateral for the competition round, which includes collateral for all tokens in that round, not just that particular token. The initial price of the pool should be the current price, as calculated based on bonding curve (I will add a new function for that). To have that price, the pool has to be deposited with some winning token at the same time. Since the pool itself has no winning token, it needs to mint some new winning tokens to be able to make that deposit. The amount of winning token minted for that purpose should be initial native token deposit / price

polymorpher · 2024-12-02T23:32:58Z

Correction: I shouldn't need to make a new function on bonding curve. Just query for k using p=1e18 as the input parameter, to get the current number of tokens that can be minted with 1.0 ONE. The inverse of that value in decimal (divide by 1e18) would be the number of ONEs needed for 1.0 (1e18) token

For a new pool, the initial native token deposit (during liquidity provisioning) should be the total collateral for the competition round, which includes collateral for all tokens in that round, not just that particular token. The initial price of the pool should be the current price, as calculated based on bonding curve (I will add a new function for that). To have that price, the pool has to be deposited with some winning token at the same time. Since the pool itself has no winning token, it needs to mint some new winning tokens to be able to make that deposit. The amount of winning token minted for that purpose should be initial native token deposit / price

potvik · 2024-12-03T21:19:17Z

Can you import interfaces and contracts where it is possible to do so? I think the number of duplicated files are getting difficult to manage. For example, PoolAddress, INonfungiblePositionManager and its dependencies can be installed and imported from uniswap/v3-periphery (forge)

we can't do this: Error HH404: File @openzeppelin/contracts/token/ERC721/IERC721Metadata.sol, imported from @uniswap/v3-periphery/contracts/interfaces/INonfungiblePositionManager.sol, not found

uniswap/v3-periphery use lower version of openzeppelin/contracts 3.4.2

Uniswap/v3-periphery#335

v1.3.0

polymorpher · 2024-12-03T21:35:07Z

try add a remapping in foundry.toml (and remappings.txt)? Not sure if single file remapping works now
foundry-rs/foundry#6706. This thread says the new compiler fixed it foundry-rs/foundry#7527

'@openzeppelin/contracts/token/ERC721/IERC721Metadata.sol=lib/openzeppelin-contracts/contracts/token/ERC721/extensions/IERC721Metadata.sol'

potvik · 2024-12-04T00:27:40Z

Correction: I shouldn't need to make a new function on bonding curve. Just query for k using p=1e18 as the input parameter, to get the current number of tokens that can be minted with 1.0 ONE. The inverse of that value in decimal (divide by 1e18) would be the number of ONEs needed for 1.0 (1e18) token

For a new pool, the initial native token deposit (during liquidity provisioning) should be the total collateral for the competition round, which includes collateral for all tokens in that round, not just that particular token. The initial price of the pool should be the current price, as calculated based on bonding curve (I will add a new function for that). To have that price, the pool has to be deposited with some winning token at the same time. Since the pool itself has no winning token, it needs to mint some new winning tokens to be able to make that deposit. The amount of winning token minted for that purpose should be initial native token deposit / price

polymorpher · 2024-12-06T01:01:35Z

contracts/LiquidityManager.sol

+            token0: token0,
+            token1: token1,
+            fee: UNISWAP_FEE,
+            tickLower: (MIN_TICK / TICK_SPACING) * TICK_SPACING,


MIN_TICK and MAX_TICK are actually not divisible by TICK_SPACING. Rounding is needed

polymorpher · 2024-12-06T01:38:05Z

contracts/TokenFactory.sol

-        if (contributionWithoutFee > remainingEthNeeded) {
-            contributionWithoutFee = remainingEthNeeded;
-        }
+


There are several issues with the code below in this function.

Let r% be fee percentage, and p be the amount the user paid. Currently fee is calculated as p / (1+r) * r where, and contributionWithoutFee (the collateral increment, i.e. ∆b) is calculated as p / (1+r). The two sums to p, since ∆b + fee = p / (1+r) + p / (1+r) * r = p. However, the fee charged is not really r%. In reality it is 1 - 1 / (1+r) = r / (1+r), which is less than r%.

Rather than pass in valueToBuy, the parameter passed in should be amountPaid (which is consistent with how it is currently used). The calculation of contributionWithoutFee should then be amountPaid - fee, where fee should be simply to be calculateFee(amountPaid, feePercent)

We should remove valueToReturn if it is not used

The public function buy(address tokenAddress) should also return the amount minted (so the client can accurately tell the user ahead of time via simulation-write)

There is no need to check availableSupply since we do not cap supply

polymorpher · 2024-12-06T01:38:55Z

contracts/TokenFactory.sol

+        address tokenAddress,
+        uint256 valueToBuy
+    ) public view returns (uint256) {
+        uint256 contributionWithoutFee = (valueToBuy * FEE_DENOMINATOR) /


same issue here, and valueToBuy

polymorpher · 2024-12-06T01:41:55Z

contracts/TokenFactory.sol

+        WETH.deposit{value: totalCollateral}();
+
+        // calulate winner token amount
+        uint256 contributionWithoutFee = (totalCollateral * FEE_DENOMINATOR) /


fee was already assessed before being added into collateral. It should not be deducted again here

polymorpher · 2024-12-06T01:46:31Z

contracts/TokenFactory.sol

+        uint256 winnerTokenAmount = bondingCurve.computeMintingAmountFromPrice(
+            totalCollateral,
+            Token(tokenAddress).totalSupply(),
+            contributionWithoutFee


What we want to know here is the per-token (1e18) unit price of the token, so this parameter should be 1.0 (1e18). After getting the per-unit price, we can then calculate the amount of tokens to be minted by totalCollateral / unitPrice (in decimal space), which would give us the number of units, i.e. unwrap(div(ud(totalCollateral), ud(unitPrice)))

polymorpher · 2024-12-06T01:48:05Z

contracts/TokenFactory.sol

+            uint256 amount0, 
+            uint256 amount1
+        ) = tokenAddress < address(WETH) ? 
+            _addLiquidity(tokenAddress, winnerTokenAmount, address(WETH), totalCollateral, tokensCreators[tokenAddress]):


This liquidity does not belong to tokensCreators[tokenAddress]. It belongs to the factory itself. Let's also make sure it has fee withdraw / WETH unwrap / token burning functions for admin

and token withdrawal - since the pool will earn fees in both WETH and the new token

polymorpher · 2024-12-06T01:49:26Z

We should have some tests for creating uniswap pools and trading on it, making sure price and liquidity are as expected

…uidity_manager

v1.0.0

polymorpher · 2024-12-07T18:49:43Z

contracts/TokenFactory.sol

+            uint256 amount1
+        ) = tokenAddress < address(WETH) ? 
+            _addLiquidity(tokenAddress, winnerTokenAmount, address(WETH), totalCollateral, tokensCreators[tokenAddress]):
+            _addLiquidity(address(WETH), totalCollateral, tokenAddress, winnerTokenAmount, tokensCreators[tokenAddress]);


I also got a stack too deep compilation error here. I will do some local refactoring

…okenState; Initialize currentCompetitionId at 1. Use competitionIds for existence check

…plify parameters for _getCollateralAmountAndFee

…_manager Fix issues with liquidity calculation for publishing to uniswap, fees issue with buy and sell, and simplify contracts

…/e2e-test

polymorpher · 2024-12-09T07:48:53Z

Let's merge this

…_manager Fix an issue in liquidity calculation which results in unexpected revert when collateral is less than 1.0 native asset

Some basic test for publishing to Uniswap end-to-end. More verification logic needed

potvik added 2 commits November 29, 2024 02:22

added _mintFullRange feature

800617a

Added liquidity manager

9305079

polymorpher reviewed Dec 2, 2024

View reviewed changes

polymorpher added 2 commits December 3, 2024 16:23

forge install: v3-periphery

f7f508f

v1.3.0

gitignore

bf3af98

potvik closed this Dec 4, 2024

potvik reopened this Dec 4, 2024

potvik added 2 commits December 4, 2024 04:28

review fixes

999d043

added _buyReceivedAmount and _sellReceivedAmount

08426af

polymorpher reviewed Dec 6, 2024

View reviewed changes

polymorpher added 2 commits December 6, 2024 12:24

Merge branch 'uniswap_liquidity_manager' into polymorpher/uniswap_liq…

c666cbf

…uidity_manager

forge install: v3-core

6f1166a

v1.0.0

polymorpher reviewed Dec 7, 2024

View reviewed changes

polymorpher and others added 13 commits December 7, 2024 14:23

fix compile issues and add v3 remapping

521b6b2

simplify and fix fee calculation, _buy logic

c617cb1

Fix fee issues in _sell. Fix event emission fee field error. Remove T…

8649efe

…okenState; Initialize currentCompetitionId at 1. Use competitionIds for existence check

prettier

41e735f

fix getCollateralByCompetitionId to account for fees for selling. Sim…

68fb318

…plify parameters for _getCollateralAmountAndFee

fix liquidity computation issues with publishToUniswap; fix compile bug

d5a1c10

prettier

2ba6a57

add fee withdrawing

a3ac50d

createToken returns Token instead of address

4c330e6

Merge pull request #13 from polymorpher/polymorpher/uniswap_liquidity…

da4fe0a

…_manager Fix issues with liquidity calculation for publishing to uniswap, fees issue with buy and sell, and simplify contracts

fix revert

e3b8e2e

Merge branch 'polymorpher/uniswap_liquidity_manager' into polymorpher…

498e279

…/e2e-test

test skeleton

0c0f7e4

potvik added 2 commits December 9, 2024 11:33

Merge pull request #14 from polymorpher/polymorpher/uniswap_liquidity…

32cf346

…_manager Fix an issue in liquidity calculation which results in unexpected revert when collateral is less than 1.0 native asset

Merge pull request #15 from polymorpher/polymorpher/e2e-test

07ae327

Some basic test for publishing to Uniswap end-to-end. More verification logic needed

potvik merged commit 1f53843 into main Dec 9, 2024

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uniswap liquidity manager #12

Uniswap liquidity manager #12

potvik commented Dec 1, 2024

polymorpher commented Dec 2, 2024 •

edited

Loading

polymorpher Dec 2, 2024

polymorpher Dec 2, 2024

polymorpher Dec 2, 2024

polymorpher Dec 2, 2024 •

edited

Loading

polymorpher Dec 2, 2024

polymorpher Dec 2, 2024

polymorpher Dec 2, 2024

polymorpher Dec 2, 2024 •

edited

Loading

polymorpher Dec 6, 2024

polymorpher Dec 2, 2024

polymorpher Dec 6, 2024

polymorpher Dec 2, 2024

polymorpher Dec 6, 2024

polymorpher Dec 2, 2024 •

edited

Loading

polymorpher Dec 2, 2024

polymorpher Dec 2, 2024

polymorpher commented Dec 2, 2024

polymorpher commented Dec 2, 2024

potvik commented Dec 3, 2024

polymorpher commented Dec 3, 2024

potvik commented Dec 4, 2024

polymorpher Dec 6, 2024

polymorpher Dec 6, 2024

polymorpher Dec 6, 2024

polymorpher Dec 6, 2024

polymorpher Dec 6, 2024

polymorpher Dec 6, 2024

polymorpher Dec 6, 2024

polymorpher commented Dec 6, 2024

polymorpher Dec 7, 2024

polymorpher commented Dec 9, 2024

Uniswap liquidity manager #12

Uniswap liquidity manager #12

Conversation

potvik commented Dec 1, 2024

polymorpher commented Dec 2, 2024 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

polymorpher Dec 2, 2024 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

polymorpher Dec 2, 2024 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

polymorpher Dec 2, 2024 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

polymorpher commented Dec 2, 2024

polymorpher commented Dec 2, 2024

potvik commented Dec 3, 2024

polymorpher commented Dec 3, 2024

potvik commented Dec 4, 2024

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

polymorpher commented Dec 6, 2024

Choose a reason for hiding this comment

polymorpher commented Dec 9, 2024

polymorpher commented Dec 2, 2024 •

edited

Loading

polymorpher Dec 2, 2024 •

edited

Loading

polymorpher Dec 2, 2024 •

edited

Loading

polymorpher Dec 2, 2024 •

edited

Loading