In a move to automate the activities of the Liquidity team, this post will show up to date values of the Daily move to Equilibrium previously calculated here.
The data for the calculation is collected from various sources and stored for display and calculation on https://grafana.crypto-daio.co.uk.
The Full Calculation link in the OP will lead to the full data Dashboard where the Equilibrium calculations are made so the figures can be scrutinised there. I have changed the visibility of https://grafana.crypto-daio.co.uk so that it is open and viewable without an account. Feel free to browse the dashboards there.
The plan for the data shown here is to automate the NuShare Buybacks or Sales (dependent on the Daily move to Equilibrium figure).
The website adds a datapoint every 10 min, yet there is no 10 min refresh window (though there is 5 min and 15 min). It would be natural to just make the website update every time a new datapoint is added, maybe give people a check box to stop it from refreshing if they want.
The y-axis on your charts is an issue. When there are a lot of lines on the chart itâs not so big a deal because there is no real right answer. When there is only one line on the chart, however, it does not make sense to have every chart start from 0. It makes it very difficult to see changes on any time scale. The UI for y-axis scaling can get confusing, so maybe something simple like just a check box to apply autoscaling or not, or the user ability to change the scale manually by entering numbers.
Iâve added a 10 min refresh window so you can apply that from the UI. Any other time period can be specified with the refresh= parameter in the url.
New data points are added every 5 minutes. Data is collected by a series of Lambda functions running on AWS. As they are connecting to exchange APIs, currency APIs, CoinMarket Cap and other external data sources there is a very high chance that one or other will fail in any given 5 minute period. For that reason I have applied a 10 minute âsmart summarizeâ average to try and mitigate the effect of bad or missing data.
The Platform I am using for these charts is an âoff the shelfâ solution called Grafana. This allows a much faster turn around than the self built charts I was producing previously but at the expense of a little flexibility. The y-axis issue is a case in point. The scaling is left up to Grafana to fit the series contained by the chart. If you click on any of the series in the legend the chart will re-scale to best fit that one serie.
For reference, the data store that most of this data comes from is called Carbon with a preprocessor called Graphite over the top. Itâs designed for time series data and exposes all these functions to Grafana http://graphite.readthedocs.io/en/latest/functions.html
If you or anyone else feels that a different function or set of functions should be used on some of the charts, Iâd be happy to experiment with them. Iâm eager to get these charts right so that they can be trusted and the data they contain be used as a basis of lots of other projects.
Does the minimum reserve not update live? Right now, for instance, there are $11.6M in circulation but the reserve amount is stated as $6.015M, which is ~52% instead of 40%.
All figures should automatically update.
Iâve looked in to this and Iâm afraid I had made a mistake. I had previously played about with using a 24 hour moving average on all calculated series but had abandoned the idea when the figures hadnât looked right. It appears though that I still had the moving average enabled on the Minimum Reserve calculated series. Iâve removed that now and checked the series in the charts and the summary boxes.
Thanks for reporting this @Nagalim. Please do continue to poke holes in the charts on Grafana (goes for everyone else too). Over the coming weeks Iâll be deploying code that uses the figures generated in Grafana for placing orders and carrying out other liquidity operations. Before such code goes live I will perform sanity checks of the figures but more eyes are always better. It is paramount that these charts and figures can stand up to scrutiny and are correct.
CMC Calculates the price as an average of all markets. The price on the Grafana chart you linked to is simply the USD value of the top Bid or Ask âNu placed orderâ on the book at that time. The only calculation in the display of those prices is to multiply the figure coming from the exchange (in BTC) by the BTC usd_price coming from CoinMarketCap.
A quick note on the Daily Move to Equilibrium figure above.
The calculations werenât taking into account the CNNBT funds held by Nu, awarded in the recent Grants. There is a manual step to notify the system that a certain address is ânetwork ownedâ and that itâs balance should be discarded from the âCirculatingâ Calculation. I have updated the charts to automatically pick up such addresses (at the expense of labeling such addresses with a friendly name rather than the address string itself).
In the future I will endeavour to mark ânetwork ownedâ addresses as such before they appear on the charts in such a way as to artificially skew the results.
Thatâs correct, @Nagalim, there are intermittent problems with these new calculations. @woolly_sammoth has identified a problem with the price stream server and plans to fix it in the next day.
I really do appreciate having eyes on these public network calculations to discover bugs. Thank you @Nagalim for helping us improve what we are doing.
Esko will be posting correct figures shortly. Currently, Liquidity Operations is conducting daily NSR sales in the amount of $558.
As we develop the liquidity model of Nu, one factor that needs to be taken into account is the relative cost of using park rates and NSR sales to support the peg. If only a little peg support is needed, only the cheapest of the two methods should be used. When very strong peg support is needed, added value can be had by using both the cheaper and the more expensive method, because overall peg support is enhanced. The Liquidity Operations team is currently working to hash out the details of this new part of the model, and that work is not complete yet. The need to include this factor in the calculations is great, because the difference in cost of using NSR sales and park rates for peg support is currently very great. Therefore, in the coming days Liquidity Operations will use an estimated figure for the multiplier figure in the DMTE calculation, which is currently set to a static 0.007. Very soon this figure will be calculated and variable.
I estimate the new methodology would indicate a DMTE multiplier of 0.002, so we will use this until we can finalize the new rules for calculating DMTE.
@woolly_sammoth grafana is reporting equilibrium reserve at ~20% instead of 40% of circulating nubits. This is after it did some weird spiking yesterday.
Thanks for the heads up. I will check what Iâd going on and verify the data today.
Edit: It seems there were some network issues between the block explorer and the AWS Lambda function which collects the data about Nu owned funds and feeds it into Grafana. That caused the Total Circulating NuBits figure to appear much larger than it really is and caused the other calculations to get out of sync too.
I will look at how to mitigate future network issues so that the affect automated sales or buybacks as little as possible.
The figures are looking correct now, without any intervention from me.