-
Notifications
You must be signed in to change notification settings - Fork 9
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Feat/delta params #19
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good to me!
@@ -89,27 +91,24 @@ contract ConstantSum is IStrategy { | |||
ConstantSumParams memory params = | |||
abi.decode(getPoolParams(poolId), (ConstantSumParams)); | |||
|
|||
(uint256 startRx, uint256 startRy, uint256 startL) = | |||
IDFMM(dfmm).getReservesAndLiquidity(poolId); | |||
|
|||
(nextRx, nextRy, nextL) = abi.decode(data, (uint256, uint256, uint256)); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
These are really deltaRx
, deltaRy
and deltaL
right?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It seems like these are still returned to DFMM
as next reserves and liquidity
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@kinrezC is right, in this case the parameters are still the reserves, I think it's easier because we don't have to think about if the swap is x for y or vice versa.
@Autoparallel I think this is why you were talking about using int256
yesterday? I understand how they could be useful here but I still think they are annoying to deal with.
Anyway, ff we want to use delta we can add a isXForY
parameter.
fees = amountIn.mulWadUp(params.swapFee); | ||
minLiquidityDelta += fees.divWadUp(params.price); | ||
} else { | ||
revert("invalid swap: inputs x and y have the same sign!"); | ||
} | ||
|
||
liquidityDelta = int256(nextL) - int256(startL); | ||
liquidityDelta = int256(nextL) - int256(pool.totalLiquidity); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Wait, if we're passing deltas into this method then why are we getting the liquidityDelta
here?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We're still passing the reserves (see my reply above).
) | ||
{ | ||
(reserveX, reserveY, totalLiquidity) = | ||
(deltaX, deltaY, deltaLiquidity) = |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Oh I see. Only the allocations have the deltas. Perhaps we could also do this with swaps?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, it would be better to have all the functions expecting the same kind of parameters.
@@ -41,6 +41,7 @@ contract ConstantSum is IStrategy { | |||
function init( | |||
address, | |||
uint256 poolId, | |||
IDFMM.Pool calldata pool, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What is this for?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
yeah, it's not entirely clear to me why we're passing the pool in init
, I checked the implementations in all of the strategies and none of them seem to use this argument.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I explained this on Discord or during a standup, there are two main reasons:
- Most of the other functions in
IStrategy
are receiving thepool
parameter, so I added it for the sake of conformity - This extends the possibilities of the strategies, for example restricting the pool creation to stable tokens only, etc...
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM, only nit is that it doesn't seem like we need the pool
arg in IDFMM.init
@@ -41,6 +41,7 @@ contract ConstantSum is IStrategy { | |||
function init( | |||
address, | |||
uint256 poolId, | |||
IDFMM.Pool calldata pool, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
yeah, it's not entirely clear to me why we're passing the pool in init
, I checked the implementations in all of the strategies and none of them seem to use this argument.
@@ -89,27 +91,24 @@ contract ConstantSum is IStrategy { | |||
ConstantSumParams memory params = | |||
abi.decode(getPoolParams(poolId), (ConstantSumParams)); | |||
|
|||
(uint256 startRx, uint256 startRy, uint256 startL) = | |||
IDFMM(dfmm).getReservesAndLiquidity(poolId); | |||
|
|||
(nextRx, nextRy, nextL) = abi.decode(data, (uint256, uint256, uint256)); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It seems like these are still returned to DFMM
as next reserves and liquidity
Only comment is that keeping solver function signatures similar across strategies would be nice dev ex for the kit. |
This PR brings a major change in the DFMM contract: when allocating or deallocating liquidity, strategies are no longer expecting the adjusted reserves as parameters but a
deltaLiquidity
amount along with maximum or minimumdeltaX
anddeltaY
amounts that the liquidity provider is willing to pay or expecting to receive.This change allows multiple liquidity providers to interact with the protocol at the "same time", without having their transactions being invalidated. Also a swap happening before a liquidity change will no longer revert it.
Other changes:
Closes:
allocate
&deallocate
parameters to deltas instead of pool reserves #13