Why is median_history_price no longer the median of feed price? My investigation.

in #witness-category6 years ago

According to my previous understanding, witnesses feed prices for steem blockchain, as shown in the figure below.


(From: https://www.eztk.net/witnesses.php)

And about per hour(STEEM_FEED_INTERVAL_BLOCKS), STEEM read the feeds from the 21 witnesses(current_shuffled_witnesses) in current round, and sort the feeds value, get the median value of it.

Then STEEM push_back the median feed value got in above step to the globe feed history object(get_feed_history/price_history), and then remove the oldest feed by pop_front(). The price_history looks like the picture below.

The price_history length keeps 84, is defined as follows:

#define STEEM_FEED_HISTORY_WINDOW (12*7) // 3.5 days

Then sort the price_history and return the median value as the current_median_history.

But now I found two questions,

  • The price of STEEM has been under $0.35 for a long time, Why is the current_median_history still higher than $0.4?

  • In the past, we always get the feed price in the form of {'base': '0.308 SBD', 'quote': '1.000 STEEM'}, Why now become such a form of {'base': '117738879.462 SBD', 'quote': '285479893.989 STEEM'}? This problem also leads to the Estimated Account Value of the wallet shows abnormal.

To find the answers to these two questions, I went to learn the code STEEM, then the following code was found:
https://github.com/steemit/steem/blob/master/libraries/chain/database.cpp#L3258

The intent of the code has been written in the comments, so I will not repeat them. This code perfectly explains two of my questions.

In the current market conditions(min_price > fho.current_median_history),median_history_price is no longer calculated by witnesses feeds and history feeds(price_history), it's determined by the supply of STEEM and SBD.

.

Why hasn't this happened before? I guess it's because we modified STEEM_SBD_START_PERCENT and STEEM_SBD_STOP_PERCENT in HF20. Before HF20 there are 2% & 5%, in HF20 they are 9% & 10%.

New question

But the new question comes:
The sbd_print_rate is calculated from the supply of STEEM & SBD and the median_history_price and will be zero when STEEM_SBD_STOP_PERCEN(10%) reached.

But the median_history_price always be checked to force SBD to remain at or below 10% of the combined market cap of STEEM and SBD.

It seems that we will never get a SBD percentage greater than 10%, So sbd_print_rate will never be zero? If my calculation is correct, it's really an interesting thing😀.

Related links:


Vote For Me As Witness
https://steemit.com/~witnesses type in oflyhigh and click VOTE

Vote @oflyhigh via Steemconnect
Thank you!

Sort:  

Thank you for this great write-up. It will take me a while to process this fully.

So this price feed is calculated like this right now?


285,502,123 STEEM / 13,077,523 SBD

9 x 13,077,523 = 117,697,707 SBD (STEEM SBD value MAX).

117,697,707 SBD / 285,502,123 STEEM = $0,413 = Price feed.


To get the feed price, the better way is call get_feed_history(), For example:

curl --data '{"jsonrpc": "2.0", "method": "call", "params": ["database_api", "get_feed_history", []], "id": 1}' https://api.steemit.com

The result:

The we just get feed price (median_history_price) by
base / quote in current_median_history

So it should be:
117695452.311 / 285504114.958 = 0.41223732389396

Use the value from get_dynamic_global_properties and the formula in https://github.com/steemit/steem/blob/master/libraries/chain/database.cpp#L3258 will got the same result, but get_feed_history handles all situations.

Another thing to remember is median_history_price updated every hours, So the real-time results calculated by get_dynamic_global_properties may be slightly different

brilliant, I was looking for a great explanation of this. Resteeming.

On your last point however I am left baffled. unless there is the use if int or round somewhere in the code????

Thank you for resteemd.

You are right, the code of percent_sbd:

auto percent_sbd = uint16_t( ( ( fc::uint128_t( ( dgp.current_sbd_supply * get_feed_history().current_median_history ).amount.value ) * STEEM_100_PERCENT ) / dgp.virtual_supply.amount.value ).to_uint64() );

So although percent_sbd is actually 999.99, but it return 999, and sbd_print_rate return 100(1%) instead of 0.26(0.0026%).

Cool, Great find. Code scares me, there is no way I would have been able to read the code to find that, but math is my thing :-)

Thanks for the investigation and sharing the analysis.

I think for the last question, the answer is in your own paragraphs:
“But the new question comes: The sbd_print_rate is calculated from the supply of STEEM & SBD and the median_history_price and will be zero when STEEM_SBD_STOP_PERCEN(10%) reached.”

when STEEM_SBD_STOP_PERCEN(10%) reached so it only needs to be equal to 10%

“But the median_history_price always be checked to force SBD to remain at or below 10% of the combined market cap of STEEM and SBD.”

remain at...10% So SBD can reach that 10% level which would trigger the zeroed of the print rate and would stay at 0 while the debt remains at 10%

The code only prevents it to go higher than 10% it does not prevent it from reaching 10%

Posted using Partiko iOS

But it seems the percent_sbd is calculated with the virtual STEEM supply, while the debt ratio calculation fixes the SBD market cap with the actual STEEM supply - as a result, the 10% SBD debt can be reached, but the 10% SBD_STOP_PERCENT cannot. (However, I'm still not 100% sure I understood it correctly?!)
edit: I was wrong and I think you are right

It is because forced type conversion is used in the code.
When percent_sbd is 999.9973478070555, it return 999, so we got sbd_print_rate return 100(1%) .

Right...

Posted using Partiko iOS

Can anyone comment on if this effects the old convert​ sbd to steem function?(which was taken out of the gui, but is till an active feature?)

Or is the price feed still pointing to an actual dollar rather than SBD? I understood that the feature burned SBD in cases like now where SBD id less than $1

Posted using Partiko Android

Convert function use the median_history_price, currently very close to internal market prices.

Ok thanks. I'm surprised, I thought this mechanism was there to reduce the sbd supply if it was slipping it's peg, but you're telling me that it is just pegged to the market prices of steem. No wonder sbd is losing right now.

Posted using Partiko Android

It is. But by design, if STEEM market cap is too low, SBD will jump off the 1$ peg. See https://steem.com/wp-content/uploads/2018/10/steem-whitepaper.pdf . quoting in section about sustainable debt ratios:

A rapid change in the value of STEEM can dramatically change the debt-to-ownership ratio. The blockchain
prevents the debt-to-ownership ratio from getting too high by reducing the amount of STEEM awarded
through SBD conversions if the debt level were to exceed 10%. If the amount of SBD debt ever exceeds
10% of the total STEEM market cap, the blockchain will automatically reduce the amount of STEEM
generated through conversions to a maximum of 10% of the market cap. This ensures that the blockchain
will never have higher than a 10% debt-to-ownership ratio.

Note that conversions still reduce the SBD supply, which in turn affect the debt ratio.

感谢o哥!学习了!HF20的时候没有考虑到这个因素吗?

我估计没考虑吧,不然设置成9%到9.9%也好啊。
反正强迫症表示受不了有个零头SBD发出来......

o哥怎么这么牛,晚上来个啤酒🍺烧烤

Posted using Partiko Android

Time to say Bumingjueli... I'm only Qiangtieliuming...
请问有下一步吗
P.S. 刚看到Steemit老板新帖里讲到Steemit Inc.的情况

我还以为你说的哪国语言.....

Great summary!

It seems that we will never get a SBD percentage greater than 10%, So sbd_print_rate will never be zero?

Interestingly, the sbd_print_rate seems to be calculated from the virtual supply here, while the median price is defined from the "actual" STEEM supply as you linked. With the SBD debt at 10% at most and the virtual supply always greater than the "actual" supply I think you're right that a 0% print rate can never be reached. Is this intended, or am I missing something?!

edit: Even though the median price is calculated with the actual supply, the arithmetic is chosen in a way to fix the SBD debt wrt to the virtual supply.

I'm not sure. 😂

Ok... Two questions than: what is the new equilibrium value?
And why anyone who screwed up the macroeconomy has done that?!

Someone thought it was a bad thing that posters no longer would get sbd in rewards, so they decided to change the algorithm to keep on printing unsustainable amounts of sbd.

There were plenty of warnings that this was a Bad Idea.

I actually thought they would want to phase out SBD... but apparently not?

Perhaps someone wanted to phase out SBD, but lost the discussion ... and then wanted to covertly incite a phaseout? :-)

You might have a theory brewing there....

Posted using Partiko iOS