Open ceilican opened 8 months ago
@ceilican Why do we need min and max price here? From my understanding, the 2-price oracle would provide us with the current spot price and current moving average price and the algorithm selects the worst price among the two for pricing assets and calculating reserve state. So, do we need min and max price to calculate the moving average price as there can be cheaper alternatives to it.
Ref to these is from the zephyr protocol whitepaper
So, the Shu version of djed uses an oracle that provides 2 prices, and it doesn't matter what these 2 prices are. But Djed Shu needs to know which one is the higher price and which one is the lower price.
Zephyr is a special case of Shu, where the two prices are the latest price and a moving average.
Here I am proposing that, for the solidity implementation of Djed Shu, we take the 24h max price and the 24h min price as the two prices.
Okay, one more thing why do we need to store prices in an array then. Can't we just store the minimum and maximum price and update them every 24 hours? For example, every 24 hours, the oracle checks if the new price is less than minimum or greater than maximum, if it is, the maximum and minimum is updated accordingly.
Also, in the zephyr version of shu, the worst price (maximum price) among current spot price and current moving average price was taken into consideration but here the worst price would always be the maximum price, so what would be the use of minimum price in this implementation.
For example, every 24 hours, the oracle checks if the new price is less than minimum or greater than maximum, if it is, the maximum and minimum is updated accordingly.
Suppose that the currently recorded maximum and minimum prices are 10 and 9, respectively. Suppose that we have the following sequence of prices, taken every hour:
10, 11, 9, 8, 7, 9, 10, 12, 13, 14, 15, 13, 12, 11, 10, 10, 10, 9, 11, 12, 13, 7, 9, 10
If we did what you suggest, we would ignore all these intermediary prices. we would look only at price taken at 24h (10) and since it is neither higher nor lower than the maximum and minimum prices currently stored, the max and min prices would not be updated. This is incorrect behaviour. The max price should have been updated to 15 and the min price should have been updated to 7.
Also, as time passes, the max and min price may have to be updated even if the latest seen price is neither higher nor lower than the currently recorded max and min price. For, example, suppose that the sequence above continues with the following prices: 10, 10, 10, 10, 10, 10, ... Then, eventually, the min price will have to be updated from 7 to 9, because 7 will have occurred more than 24h ago and the next lowest price is 9. Likewise, the max price will eventually have to be updated from 15 to 13, because 15 will have occurred more than 24h ago and the next highest price is 13.
but here the worst price would always be the maximum price, so what would be the use of minimum price in this implementation.
This is not the case, actually. The worst price depends on the operation. For example, for "Buy stablecoin", the worst price is the max price. But, for "sell stablecoin", the worst price is the min price.
See #20 and #21 for context.
Djed Shu requires oracles that provide two prices, but most blockchain oracles (e.g. Chainlink, API3, HebeSwap) provide just one price: the latest price.
Therefore, the question is: how do we convert a 1-price oracle to a 2-price oracle?
The answer is: we implement a converter that implements the IOracleShu interface and reads data from an oracle that implements the IOracle interface.
This converter should, as it reads data from the IOracle, memorize the data that it reads in something like an array and then provide the provide the maximum and minimum values from this array in the last, let's say 24h, as the maximum and minimum prices.
Care should be taken not to include too many data points in the array, otherwise it can become too expensive to traverse the array. This is not trivial. Whoever takes this task should like to work with data structures and have a good practical understanding of complexity theory.