You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The LogNormal strategy uses an incorrect fee calculation for the increase in L that will result in fees that are dependent on the current price of the pool.
Details
The fee calculation roughly looks like
fees = amountIn * swapFee;
deltaL = fees * L / R
where R is either one of the two reserves, and specifically is the reserve that is being tendered in for a swap.
In the case where the pool is priced such that R is much less than L``, can see that we then require a substantial growth in L` for the swap to be accepted. This can lead to worse execution prices and could lead to a pool becoming stale/bricked if the reported price falls too far from the "strike" price of the pool (also depends on the sigma parameter).
Fix
To fix the issue, we just calculate the fees and deltaL slightly differently.
If X is being tendered:
deltaL = amountIn * swapFee
else if Y is being tendered:
deltaL = amountIn * swapFee / params.strikePrice
Testing in Mathematica notebooks seems to show this change fixes the fee problem and as the pool depth increases, this choice of fee calculation leads to what we expect to see from a ConstantSum CFMM.
The text was updated successfully, but these errors were encountered:
Description
The
LogNormal
strategy uses an incorrect fee calculation for the increase inL
that will result in fees that are dependent on the current price of the pool.Details
The fee calculation roughly looks like
where
R
is either one of the two reserves, and specifically is the reserve that is being tendered in for a swap.In the case where the pool is priced such that
R
is much less thanL``, can see that we then require a substantial growth in
L` for the swap to be accepted. This can lead to worse execution prices and could lead to a pool becoming stale/bricked if the reported price falls too far from the "strike" price of the pool (also depends on the sigma parameter).Fix
To fix the issue, we just calculate the
fees
anddeltaL
slightly differently.If
X
is being tendered:else if
Y
is being tendered:Testing in Mathematica notebooks seems to show this change fixes the fee problem and as the pool depth increases, this choice of fee calculation leads to what we expect to see from a
ConstantSum
CFMM.The text was updated successfully, but these errors were encountered: