Skip to content
This repository has been archived by the owner on Sep 17, 2021. It is now read-only.

Another Oracle proposal #19

Closed
gundas opened this issue Jan 10, 2019 · 3 comments
Closed

Another Oracle proposal #19

gundas opened this issue Jan 10, 2019 · 3 comments

Comments

@gundas
Copy link

gundas commented Jan 10, 2019

Hello,

This is a proposal for a radical change, so feel free to close this issue if Oracle solution is not acceptable from the project's standpoint of view.
Also, there are many ways to integrate Oracle, described below is just one of them.

I really liked the idea of UniSwap, but I also came to the conclusion that the UniSwap's price discovery model is just too expensive. Liquidity providers will be getting "punished" by arbitrage traders for every exchange rate shift.
For the liquidity providers not to loose funds there must be enough "end user" trading so that the collected 0.3% fee covers for the losses caused by price movements. However, the bigger the liquidity fund is, the more losses it will suffer from arbitrage.

For example:
We have created Uniswap 1.000 Ether and 100.000 DAI, when Ether price was $100. If Ether price moves to $150, the arbitrage trader will take away $5.000 (around 33 Ether) from the contract's liquidity to bring the price close to the correct one. To compensate for this move, the UniSwap contract needs to trade around $1.700.000, which is almost 10x the contract's total liquidity.

I think using an Oracle would be much cheaper than that.

I have the following proposal:

Create an Oracle contract which would have the following functionality:

  • external updatePrice() function could be called by anyone (we need to figure out what to do with the gas payments, maybe refund the gas to the caller, but then there is a risk of grief attack). This function would initiate an Oraclize call to get the price.
  • the Oracle contract could add/remove Ether balance to/from the Exchange contract to adjust the price ratio of the assets. We need to figure out the initial funding to Oracle contract.
  • Oracle contract would allow Exchange Contract to add/remove Ether funds

The changes to Exchange contract:

  • it would allow Oracle Contract to add/remove Ether
  • when removing liquidity, it would also remove a proportional part of Ether from the Oracle Contract
  • when adding liquidity, it would also add a certain proportional part of Ether to the Oracle Contract. It could use Oracle Contract price to set the correct rate.
  • add a voting mechanism to for the liquidity providers to change the Oracle contract
  • maybe add a voting mechanism to change the trading fee
@BlinkyStitt
Copy link

As @haydenadams said on #13, "Custom pools - exchange contracts that integrate the same interface but are not deployed from the factory - are the best place to experiment on this. Custom pools are able to trade against the public pools using the tokenToExchange functions."

I think you can experiment with what you want with a custom pool instead of needing to change the existing Exchange contract.

You said "[updatePrice()] would initiate an Oraclize call to get the price." Where is this price coming from though? Who has control over this price? I see "Oracle" used a lot with cryptocurrencies, but haven't yet seen a decentralized one that is fast enough updating the price to work with something like you are proposing.

@haydenadams
Copy link
Contributor

Put another way, Uniswap w/ large pools is the best decentralized oracle I know.

I'm assuming you mean centralized oracle - ie creating a Kyber-like system but maybe with more efficient code.

@gundas
Copy link
Author

gundas commented Jan 11, 2019

I think you can experiment with what you want with a custom pool instead of needing to change the existing Exchange contract.

I understand you point.

You said "[updatePrice()] would initiate an Oraclize call to get the price." Where is this price coming from though? Who has control over this price? I see "Oracle" used a lot with cryptocurrencies, but haven't yet seen a decentralized one that is fast enough updating the price to work with something like you are proposing.

The price would come from whatever is coded in the Oracle Contract (e.g. some URL & Oraclize). So, yes the Oracle would not be decentralized, but the decision if to use Oracle, what Oracle to use (and when to change) and would be decentralized.

I am closing this issue, since the proposal is clearly not in line with the project direction.

@gundas gundas closed this as completed Jan 11, 2019
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants