Estimating DAI/USD from the eth2dai order book instead of dex trades

Throughout the history of DAI the vast majority of the volume has been through the oasis/eth2dai contract. This poses a problem when it comes to estimating the DAI/USD price using trades because it takes a few blocks to cancel a limit order. If ETH/USD moves against the maker, an arbitrager/market maker/metamask meatball will take it. In terms of DAI/USD, this trade looks like it occurred at an outlier price of +1.02/0.98 when compared to a centralized ETH/USD feed. This adds unnecessary noise to our DAI/USD error signal if DAI/USD was close to 1 the rest of the day.

The second problem with calculating the DAI/USD price by trades is liquidity. Occasionally, uniswap or tap contract pure revenue bots will chew through offers on eth2dai +2% away from the spread. If the market makers on eth2dai put their offers right back where they were (with respect to 1), then these trades also add noise to our DAI/USD error signal.

The third problem - how do we calculate DAI/USD if very few trades occurred during that hour/day? This hasn’t been an issue lately, but some days during 2018 it was. Calculating the DAI/USD price from the order book reduces these three sources of unnecessary error.

Here is eth2dai order book over around 1000 blocks.

My primary goal is to get a cleaner, more accurate, DAI/USD error signal into my PID controller for repeatable off chain SF estimation. (updated post on PID coming soon) Sites that calculate DAI/USD from trades like http://dai.descipher.io/ or https://dai.stablecoin.science/ are excellent for getting a quick look at what is going on in DeFi, but they are too noisy to make repeatable estimations possible using a PID for the reasons I listed above. Lets compare a volatile period where DAI was too low in April 2019.

Calculating the DAI/USD error signal by trades: https://gfycat.com/frighteningselfreliantadder
Calculating the DAI/USD error signal by eth2dai order book: https://gfycat.com/mintybriefamericanredsquirrel
Comparing the two on the same plot:


(plot notes: 1. I omitted a few trades that happened at extremely low or high values. 2. The hourly order book depth is calculated by the median amount of DAI available from eth2dai over a 1 hour period. 3. All error bands signify 1 standard deviation)

The benefit is marginal for when DAI is off the peg. The standard deviation bands for the order book method are slightly tighter than using trades, but overall the signals look about the same. Now, lets take a look at a less volatile (in terms of DAI/USD) period a few weeks ago.

Calculating the DAI/USD error signal by trades: https://gfycat.com/deadlygroundedblowfish
Calculating the DAI/USD error signal by eth2dai order book: https://gfycat.com/waryopenafricanporcupine
Comparing the two on the same plot:

This is where the order book method really shines. If there are asks above 1, and bids below 1, the SF is in its happy place. There is no reason to change it, so the error signal can =0 when this is the case. If you were calculating the error using trades it would be much harder to say what was going on due to all the noise.

Let me know if you have any questions/comments as the feedback I’ve gotten so far has been spectacular.

data sources:
trades - dai.stablecoin.science
ETH/USD (gemini minute) - http://www.cryptodatadownload.com/data/northamerican/
order book - eth2dai/oasis contract

source code:
1000 block order book plot - https://github.com/lixwhi/order_book_plot
get the order book data - https://github.com/lixwhi/get_oasis_book
plot the book histogram and make gif https://github.com/lixwhi/oasis_hourly_histogram
dex trades histogram and compare plots- https://github.com/lixwhi/dex_trades_histogram

8 Likes

Comment about why noise in the prices is also an important data-point

It is important to consider the gas cost of the oracle. Uniswap V1 has pretty thick liquidity rn, and it requires very little gas to check its price (compared to reading an orderbook) because you only have to check its ETH balance and its DAI balance, both of which you can do without calling into the contract.

Of course you can do a weighted volume averages or devise other ways of defining the “market price” However to call any free market trade data “noise” or “error”, is dangerous. It shouldn’t matter if a trade is made by man/machine, market/limit, arbitrage/momentum automated/manual marginal/central central/otc and so on … More market data, increases accuracy of “price”. no? This maybe just a philosophical bias on my part, but this is what I was thought.

1 Like

Sorry guys, I should have been more clear. I was attempting to show that there are some trade-offs to consider when calculating DAI/USD for a PID controller.

I’m not suggesting we should bring the DSR or SF calculations on chain yet. One day, that might be achievable. It would help out with voter fatigue to make the rate calculations automatic. However, at this stage in the project, I think the price is too easy to manipulate to have on chain rate calculation.

I agree with this, and should have been more clear in what I was going for. By “error” and “noise” I mean signal error and signal noise in the context of an off chain PID controller. The controller’s purpose is to make the error=0. So, if DAI is 1.01 then the error is 0.01. The transient trades that occur definitely mean something. However, from the controller’s point of view, these “out of spec” trades induce unnecessary instability into the error signal. The DAI/USD ratio moves slowly. That’s why the controller doesn’t need to consider every trade to provide a rate estimation - it only needs the big picture.

Thanks for the feedback. I haven’t written anything on the PID controller recently because I’ve had second thoughts on if it can work. I think it would require voting more frequently than once per week, and that is not possible due to governance fatigue. The controller might suggest better values in MCD if we only change the DSR to keep the peg. We’ll have to wait and see.

It may be worth noting here that Oasis team keeps track of the Order Book midpoint price for each block, we can set up API for easy access if that would be useful

2 Likes

Well as a controls guy familiar with feed back or feed forward PID loops.

In the context of frequency of voting vs. something more finely grained one could simply vote a range available for such a PID loop and then enable the PID loop to operate to make automatic adjustments on finer timescales.

The question would be what range, and time slice of the PID. Careful consideration of the data sources and system response characteristics would be imporant. The real question is what levers to allow the PID to pull and how success is measured.

2 Likes

I think having a contract make automatic adjustments to the SF would be challenging in today’s DAI market. Wouldn’t it be fairly cheap to manipulate the DAI/USD price and induce wild rate swings from the PID regardless of the response characteristics we give it? I suppose an on chain solution could work if we had authority to shut it down quickly in case it was being attacked.

PID design is tricky for reasons cited above (signal noise, systemic or random). Also note that I pointed out in the first post that the PID allowed range to operate would be limited. Lets say +/- 5% of the current SF for example. Right now that would be 4.75-5.25%. It is a nice way to have a PID do fine grained and somewhat limited changes in scope on a more frequent basis (say once/hr or once/day). In fact it would be the best way to test such a PID is to just limit how much it can change the voted target fee (or whatever is being used). Doing a % of the SF fee means that if the SF voted target was 1% the PID given the +/-5% range example above would go from .95-1.05. If it was 20% this would give a working range of 19-21%.

Over time one if we found that the PID worked reasonably well we could open the range to 10 or 20% of the voted target range.

EDIT ADD: Note I’m not saying TO DO a PID just as a guy who deals with this for a living that there are good ways. What to try to regulate on and how is always the tricky part of PID design. I come back to something I’ll say a lot.

What is the goal?
How do we measure success or failure?

BTW: In reply to the OP and using eth2dai orderbook as a DAI/USD oracle. Given that orders require fees this may be interesting but I see a lot of bots that will move orders instantly as I trade on eth2dai a lot. Most people consider that using the orderbook for anything to not be a great idea generally as the liquidity is virtual not actual because orders can appear and disappear quickly (whether there are fees or not).

1 Like