Park Rate Voting

[Nagalim]

. If the oldest existing block in the window has a rate less than current rate, then nothing changes.

Right. This is the case currently and will be so for another half week or so.

[mhps]

OK I see. Park rate is really for the slow components (low frequency in Fourier space) of peg balancing. Don’t expect it to come or go quickly.

Realising this, it’s wrong to mandate that T4 reserve is used before park rate. T4 and park rates should always be used together as they cover different part in frequency space. The optimum park rate could be crafted from MA5 of e.g. buy/sell ratio. As the rate constantly changes, a bot can be used to update the park rate feed. This could save a lot of T4 reserve.

[mhps]

@desrever and @willy,

It’s important to record how many NBT are parked as a functiion of park rates, so future models can be made to set the optimum park rates. Now the rates are non-zero. Can you configure your server and record them?

[Nagalim]

The optimum park rate could be crafted from MA5 of e.g. buy/sell ratio

I feel like that’s higher frequency than the standard. I really can’t think of a lower frequency smart trigger than the standard.

[masterOfDisaster]

Realising this, it’s wrong to mandate that T4 reserve is used before park rate.

Right!

Interpretation of the liquidity tiers, a waterfall model, triggers, metrics and actions

As adjusting parking rates have a delayed effect on the liquidity, because it takes time until they are adjusted, I consider a continuous and early adjustment of parking interest more effective than adjusting the parking rates in case of emergency.

But for that you need a way to replenish T4 - which would be T6 in this case.
That’s why I prefer NSR sale to park rates.

[mhps]

I really can’t think of a lower frequency smart trigger than the standard.

Probably right, except for two problems: the Standard is currently only measured once a week while MA5 is an integral. The Standard is absolute number instead of a ratio. Both problem can be solved.

Edit: I forgot the important and unsolvable part with the Standard: it is the spot ratio, not reflecting the low frequency component. MA5(Standard/circulating) might do.

Interpretation of the liquidity tiers, a waterfall model, triggers, metrics and actions

I consider a continuous and early adjustment of parking interest more effective than adjusting the parking rates in case of emergency.

Excellent. To which I replied

Interpretation of the liquidity tiers, a waterfall model, triggers, metrics and actions

From reading your summay it seems that Tier 4 and Tier 5 can be the same thing only to react to Global Liquidity Imbalance (GLI; defined as global sell side liquidity minus the buy side; edit: then the difference is divided by the buy side ) changes at different frequency – Tier 4 reacts to fast spikes and dips of GLI, while Tier5 react to slow fluctuations of GLI. For a mathmatical example Tier 5 continuously reacts to the 7-day moving average of GLI, denoted as MA(GLI,7), Tier4 continuously reacts to GLI - MA(GLI,7).

[Nagalim]

Standard/circulating

My issue with this is that park rates already account for the circulating dependency. Meaning that we don’t really get x nbt parked given a certain rate, we get x% of circulating nbt parked. As the network grows, number of parked nubits per park % will grow.

[mhps]

I agree. I imagine that the park rate will be continuously calculated based on MA5(Standard/circulating) where Standard and circulating calculations have had parked amount removed. As parked amount increases, Standard approaches 0.

Also if one is using the standard for the next week’s buyback, ideally one has to calculate the forward-looking standard, which takes into account of the to-be-freed-next-week parked amount.

[Nagalim]

If you take standard/circulating you’re double counting the circulating. Lets imagine 2 circumstances, one where there are 1mil circulating nbt and one where there are 100k. Let’s say the standard is -$5k. So if we use your calculation the park trigger is 5% in one case and 0.5% in the other. Let’s pretend we use that as the park rate. Let’s also assume that for each park rate %, that % of the network nubits gets parked. So for both cases $5000 nbt gets parked.

Lol, i think i just convinced myself that you’re right and im wrong. Ill think about it some more.

[mhps]

Let’s also assume that for each park rate %, that % of the network nubits gets parked.

I don’t assume it’s a linear function. The function should ideally determined by testing/optimizing against past data. So it doesn’t matter if it is standard/circulating or just standard, it is f(standard, circulating, tolerance, many other parameters).
The question is : what is the goal of optimization? My rough guess is we optimize to minimize peg maintenance cost in a given period.

[Nagalim]

testing/optimizing against past data

I don’t believe the parking function is fundamentally repeatable because the structure of Nu, the blockchain, and the risk associated with Nu are all changing. Finding a function for this seems like an impossible task.

[mhps]

Finding a function for this seems like an impossible task.

There are methodologies. Parameterize and fit. Monte-Carlo simulation. It can make a pretty good MAster’s degree thesis. The problem is we don’t have a lot of data.

[mhps]

The wall has been in more or less balanced state for almost two days. If the wall keeps balanced like now for another 15hr, I think shareholders can consider lowering voted park rates, knowing that it will take a few days to come down.

@willy, it’s likely that 5-day moving average gives important clue on how the park rates should be set. Could you add 5-day MA to https://alix.coinerella.com/charts/?select=48h_4h_15min_combined_ma_percent ? It doesn’t have to show by default to avoid cluttering.

[willy]

5-day moving average

Just to clarify. You want a five day moving average, not a five day window, right?

[mhps]

Right, Five day moving average. See here and here

Since 5day MA changes slowly, you can sample the 4hr MA results every hour and average the latest 120 samples to get 5day MA ,so the cost of resource is small. There will be one new data point on the plot every hour.

[mhps]

The wall has been in more or less balanced state for almost two days. If the wall keeps balanced like now for another 15hr, I think shareholders can consider lowering voted park rates, knowing that it will take a few days to come down.

There are only 2000nbt parked but the wall is balanced. We need more parked nbt to help replenish the rreserve.
I suggest the park rate set to

32% @ 11 day
16% @ 23day
8% @ 1.5 mo
4% @ 3mo
0% @ 6mo

The above base-2 exponential distribution of park rates will give the same total premium to any none-zero period. It encourage choosing the shorter periods due to less opportunity cost. Shorter periods require frequent renewal which aligns with Nu’s need to adjust the total amount of parked NBT acccording to liquidity and Standard.

With the base-2 exponential distribution Nu has only one parameter to adjust re park rates: the total premium. This will make operation and analysis easier.

[Nagalim]

This is in line with my analysis here:

A method for picking park rates

Concerning time binning of park rates, I will use integer n to represent a bin of length t days at rate R and C for total cost to the Nu network: n-1 is of length 0.5*t If you vote for R at n, there is no reason not to vote for R/2 at n+1 because C=R*t = (R/2)*(2t) The inverse (2R at n-1) cannot be extrapolated because we don't know the rate at t/2 This means there is no reason not to vote for a very small park rate at 64 years if you vote for any park rate at all. R'.n can represent R for bi…

[cryptog]

32% @ 11 day16% @ 23day8% @ 1.5 mo4% @ 3mo0% @ 6mo

that makes sense.

will modify my rates.

[Cybnate]

32% @ 11 day16% @ 23day8% @ 1.5 mo4% @ 3mo0% @ 6mo

This goes against my logic of the risks of parking and ensuring Nu gets the best deal.
With that setup, it would encourage people to park for very short amounts of time at a premium for Nu.
That is high maintenance for whoever wants to park and relative low returns. Not attractive. For Nu it means that the velocity of money parked is very high meaning that parked money is returned in shot periods. I believe that is not a good thing when we have low reserves. It encourages a yo-you effect which will cost more.

I will stick with:
3% for 23 days
6% for 1.5 months
12% for 3 months

I might add the 24% for 6 months when reserves continue to be low. This would provide an opportunity to set aside NuBits for longer, usually an attractive opportunity for investors spreading their risk profile.

[mhps]

With that setup, it would encourage people to park for very short amounts of time at a premium for Nu.That is high maintenance for whoever wants to park and relative low returns.

We have to recognize that parking is not designed to give out perks. It’s a mechanism to adjust the amount of circulating nubits. High maintenance is a direct result of high volatility of nubits demand due to high volatility of BTC prices.

The premium for Nu you refer to is a cost to have people’s fund parked. There is ZERO difference between 3% for 23 days and 6% for 11 days as far as premium is concerned, because once fund is parked, the interest rate is fixed. The difference is that the latter gives people more incentive to park due to less opportunity cost.

parked money is returned in shot periods. I believe that is not a good thing when we have low reserves.

If you don’t want the fund returns, keep offering park rate at an effective rate.

I might add the 24% for 6 months

That is a horrible idea because I don’t believe we know anything about the liquidity and reserve situation in more than a few weeks. What business are we in to offer people 24% pa for extended period of times?