-
Notifications
You must be signed in to change notification settings - Fork 322
Another Oracle proposal #19
Comments
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. |
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. |
I understand you point.
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. |
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:
The changes to Exchange contract:
The text was updated successfully, but these errors were encountered: