add position manager [wip] #141
Conversation
| donateRouter.donate(key, 0.2e18, 0.2e18, ZERO_BYTES); | ||
|
|
||
| // subtract 1 cause we'd rather take than pay | ||
| uint256 feesAmount = amountDonate.mulDivDown(liquidityAlice, liquidityAlice + liquidityBob) - 1; |
There was a problem hiding this comment.
doesnt the div down already handle the downward rounding for take vs settle? is it not enough?
There was a problem hiding this comment.
it didn't in this case. if i dont subtract 1 it does a pay/settle
| // transplant: burn and mint on different keys | ||
| function test_execute_transplant() public {} | ||
| // cross-coalesce: burn and increase on different keys | ||
| function test_execute_crossCoalesce() public {} |
There was a problem hiding this comment.
lmao i like the fun name ideas but i do think it would be much easier to see what was failing if you saw
test_execute_burnAndIncreaseDifferentKeys
instead of test_execute_crossCoalesce
There was a problem hiding this comment.
I am gonna keep this for now - sauce has a really great doc/table explaining all these names LOL. we can change later when we actually implement the tests if u still dont like
Co-authored-by: Alice <[email protected]>
| import {LiquidityOperations} from "./LiquidityOperations.sol"; | ||
|
|
||
| /// @notice A shared test contract that wraps the v4-core deployers contract and exposes basic liquidity operations on posm. | ||
| contract PosmTestSetup is Test, Deployers, LiquidityOperations { |
|
|
||
| contract Quoter is IQuoter, IUnlockCallback { | ||
| contract Quoter is IQuoter, SafeCallback { |
| bytes memory calls = planner.finalize(range.poolKey); | ||
| vm.prank(alice); | ||
| lpm.modifyLiquidities(calls, _deadline); | ||
| snapLastCall("PositionManager_mint_warmedPool_differentRange"); |
There was a problem hiding this comment.
maybe stupid question... what about a warmed pool is cheaper than an un-warmed pool when it doesnt share a tick? Like which slot(s) that it writes to is "warm" that decreases the cost?
There was a problem hiding this comment.
Oh I just added this because the gas costs were different when I didn't "touch" a pool before the mint. Like compare this to just PositionManager_mint.. they are different. Im not really sure why I'm guessing its because the tokens are touched, and pool key is touched? But not totally sure.
| swap(key, true, -int256(swapAmount), ZERO_BYTES); // zeroForOne is true, so zero is the input | ||
| swap(key, false, -int256(swapAmount), ZERO_BYTES); // move the price back, // zeroForOne is false, so one is the input | ||
|
|
||
| uint256 tolerance = 0.000000001 ether; |
There was a problem hiding this comment.
the tolerance stuff for auto-compounding fees has given me an idea - currently you have a command for doing either settle or take that you can call for these cases of dust in one direction or the other.
I'm wondering if itll be worth having a command thats like either settle or clear?
There was a problem hiding this comment.
yes! Although I also wonder if we could just "auto" clear if its less than some threshold.. basically abstracting away clear a bit? or at least still having some check around clearing? I dont want someone to encode a clear that wipes non negligible funds
Related Issue
Which issue does this pull request resolve?
This is the dev branch for everything related to position manager and should be reviewed in entirety before merging into main.
Closed:
Add salt to LiquidityRange(fixes _beforeTokenTransfer)[FIXED WITH SALTS ON POSITION]OUT-OF-SCOPE for base PositionManager, but tracking below:
Outstanding tests: