Park Rate Voting

With the buy wall at 11,000 and the sell wall at 61,000 I’m quite surprised to see rates being dropped over the last 24 hours. It is clear to me the costs and risks of lowering rates are at least 100 times greater than the risks and costs of raising rates right now. I can’t see why there is any controversy in the matter.

I have around 50,000 in funds besides NuBits, and that is just enough to meet my obligations to contributors over the next month. So I won’t be offering any of that for liquidity.

The NuLagoon has some buy side liquidity that does not display in the client, but my guess is that it isn’t very much. @KTm may also have some, but again I don’t think it is much.

When the percent of buy side liquidity drops below some threshold, which could be argued to be between 25% and 40%, shareholders should always vote for higher rates, in the absence of any clear indication that the liquidity figures are wrong.

If rates remain being offered for any significant period of time, it is a sign that NSR should be sold and NuBits burned.

Edit: right now, rates are only being offered for 3 months. A protocol flaw that is on our roadmap to fix makes it so that when rates are offered for a single duration rates will only be offered for that exact block duration. So right now, our rates are 2.5% for 131072 blocks, but 0% for all other block durations. The parking UI doesn’t allow for a precise block duration selection, so shareholders should never vote for a single duration. You must vote for at least two adjacent durations to offer interest rates that are functionally above 0%.

3 Likes

Is there a data feed or can you or someone suggest a set of rates?

As you can see here I have been voting for 10% up to 3 months since yesterday in my feeds.

Thanks. I didn’t realize park rates are also set in data feed.

2 Likes

buy side at 10.8k. Decreasing.
Please increase your parking rates.

1 Like

I multiplied all my rates by 10. Currently we should rather start from a too large rate and decrease them then the other way around I think.

I have increased my votes rates as well.

@assistant park rates

Hi @cryptog

The current park rates in the Nu network are:

32768 blocks: 0.000810% APR
65536 blocks: 0.001670% APR
131072 blocks: 0.008722% APR

Even if park rates have been raised to 1.3% for 10 and 20 days, 2.3% for 1.5m and 4.5% for 3m, it seems the totally parked quantity has not increased yet, over the last 24 days.
I feel shareholders should vote for higher short term rates in order to incentivize nubits holders to park immediately.

1 Like

I think that park rates should reach at least a range of 8 - 10 % for the 3months period to start to see more parked NBT
We saw that happening not long ago.

1 Like

I see. I am voting in my feeds for 15% regarding all periods btw.

Note that voting for much higher rates doesn’t make the rates increase faster. The reason is we use median and not average. So voting for your target rate is enough to make the rates grow at its maximum speed.

Also note that there’s a maximum increase of 1% per day on each duration. For example on 3 months the current rate is 4.5% but the current result of the vote is actually 8%. So if if everybody keeps his vote as is, the rate will be at least 8% in 4 days.

2 Likes

Any easy way to get this info?

Not sure it’s easy, but you can use the (very verbose) getparkvotes RPC on the NBT wallet. It will display the details of the votes on each duration. The median rate is the first rate for which the accumulated age percentage is above 50.

tks for the info. getparkvotes with no arguments crashes the client…any typical values to input for block height and block quantity?

The default values are fine because they match the protocol rules.

I don’t know why it crashes. The function may need a significant amount of memory. Are you running the daemon on a low memory system?

I do not think so. It crashes on 2 machines btw:

  • 4gb machine 2 gb left when Nu client is on
  • 8gb machine: 2 gb left when Nu client is on

We’ll investigate the problem.

1 Like

Assistant hasn;t been correctly reporting the APR for park rates. The figures returned by the getparkrates rpc call are the raw rates. There is an extra calculation to convert to APR (thanks for the information @sigmike).
I’ve just made the changes to Assistant and tested locally. I’ve moved the code to the server where assistant lives and (hopefully) this next call should give the correct park rates.

@assistant park rates