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
{{ message }}
This repository has been archived by the owner on Sep 17, 2021. It is now read-only.
As I've wrote in my issue #19, for the Liquidity Providers in makes economical sense to add liquidity only if the price ratio of UniSwap contract assets' is more or less stable. For example a pair DAI <-> GUSD would make sense - the liquidity providers would not risk their funds too much, but they could still collect the fees.
Having two exchanges ETH <-> DAI and ETH <-> GUSD does not fix the price fluctuation problem for the liquidity providers, since they will still loose funds when Ether price changes.
I think this is the only alternative to implementing Oracle to update the prices - UniSwap could work very well in trading assets which relative price does not change much.
P.s. I am not sure how the Ether case should be handled in code - it must either have separate handling logic (more complexity) or it must be wrapped to WETH (extra gas).
The text was updated successfully, but these errors were encountered:
Sign up for freeto subscribe to this conversation on GitHub.
Already have an account?
Sign in.
As I've wrote in my issue #19, for the Liquidity Providers in makes economical sense to add liquidity only if the price ratio of UniSwap contract assets' is more or less stable. For example a pair DAI <-> GUSD would make sense - the liquidity providers would not risk their funds too much, but they could still collect the fees.
Having two exchanges ETH <-> DAI and ETH <-> GUSD does not fix the price fluctuation problem for the liquidity providers, since they will still loose funds when Ether price changes.
I think this is the only alternative to implementing Oracle to update the prices - UniSwap could work very well in trading assets which relative price does not change much.
P.s. I am not sure how the Ether case should be handled in code - it must either have separate handling logic (more complexity) or it must be wrapped to WETH (extra gas).
The text was updated successfully, but these errors were encountered: