Since last point of 25th update of 2021 on BlockTrades work on Hive software gained a lot of attention, I thought it would be nice to sum up current state of the code, that is, how the mechanism in question works at the moment.
There are three semi-independent limits related to HBD. First two constitute SOFT LIMIT and mainly control HBD print rate. These are dynamic_global_property_object::hbd_start_percent and dynamic_global_property_object::hbd_stop_percent. Despite being variable members of dynamic properties these values can only change during hardforks. Up to HF20 their values were 200 and 500 respectively (value in basis points => 2% and 5%), after HF20 the values changed to 900 and 1000 (9% and 10%). As the total amount of HBD in existence(x) in relation to virtual supply grows (aka debt ratio), it affects the value of dynamic_global_property_object::hbd_print_rate. When it is below hbd_start_percent, the value is 10000 (100%), meaning that portion of comment rewards that is due to be paid in HBD will not be limited. When the ratio grows above hbd_start_percent but remains below hbd_stop_percent, the hbd_print_rate is reduced proportionally which in turn reduces comment rewards paid in HBD - they are paid in HIVE instead. Finally, when there is so much total HBD that the ratio reaches hbd_stop_percent, hbd_print_rate is set to 0 which means comment rewards will not contain any portion that is paid in HBD.
hbd_stop_percent limit has one more use. If execution of collateralized_convert_operation (conversion of HIVE to HBD) was to push debt ratio above that limit, the operation will fail. It means that upper soft limit not only stops (some) automatic HBD printing but also stops users from printing new HBD.
Ok, but what is virtual supply and how is the debt ratio calculated? Virtual supply is essentially the total amount of HIVE: liquid, in savings, as well as VESTed, but also including all HIVE that would be issued if all HBD was to be converted into HIVE. The value is stored in dynamic_global_property_object::virtual_supply and updated (along with hbd_print_rate) twice every block - once after transactions are processed and potentially new internal price is established, second time after some automatic operations are finalized, including conversion processing and comment rewards (but not proposal payouts) - see calls to database::update_virtual_supply.
(x)While virtual_supply is calculated like I described, when calculating debt ratio, all the HBD stored in treasury account (hive.fund) is subtracted as if it didn't exist. It was done so since treasury holds large amount of HBD from Steem->Hive airdrop and the funds are governed by the code, not by users, so it makes no sense to treat it the same way as HBD on the market. When HBD held by treasury was still calculated into debt ratio, the limits were reached pretty much all the time. If you are interested in details of debt ratio calculations, look for database::calculate_HBD_percent.
Because treasury balance is not taken into account, when HBD is transfered out of it as proposal pay, it is functionally equivalent of issuing new HBD, therefore even if upper soft limit is reached, new HBD can still show up on the market, hence "soft" limit. It also does not stop interest on HBD savings.
Since calculation of virtual_supply involves adding values of HIVE and HBD, which are different assets, there needs to be the price to put them on common ground. That price is held in feed_history_object::current_median_history and updated once every hour from what witnesses propose as correct price - see database::update_median_feed. It is possible, especially during decline of HIVE price, that the amount of HBD on the market that was below debt limit, after the price is updated it becomes well above limit. If that happened, there was theoretical scenario where one user holding large portion of HBD would then be able to use convert_operation (HBD to HIVE conversion) to turn all his HBD into large amount of HIVE, power it up and consequently gain massive voting power, possibly taking over the blockchain governance. Note that if he tried to collect the same amount of HIVE on the market, it would move the price upwards, but since conversion happens on chain, no such immediate effect would take place.
Here is where last limit takes effect - the HARD LIMIT. It is currently hardcoded into process of price update and it changes the witness established price in such a way to guarantee, that even if all the HBD was converted into HIVE, the conversion would only create no more than hard limit amount of total HIVE. The hardcoded limit is at 10%, the same value as upper soft limit, and it only makes sense to have upper soft limit at or below hard limit, because since debt ratio calculations use internal price and that is affected by hard limit, soft limit could never be reached if it was above hard limit.
When hard limit is reached, the internal price of HIVE becomes artificially high, meaning that on chain conversion and other calculations will cause code to give out less HIVE than one would expect (so f.e. the user trying to convert HBD to HIVE on chain will be at a loss compared to the market, but the chain as a whole will be safe). Now, why would we want to reduce such strong protection? Nowadays we have more tools to use if the attack scenario takes place, including delayed voting - extra 30 days to react in case of attempt to hostile takeover. As long as "the good guys" have more voting power than attacker could gain there should be no problem.
Yup a huge risk for panic and i totally against increase the debt limit. Im sure we will see sooner or later a panic run for the 10% Stablecoin interest farmers.
If the plan is to increase it anyway, i would watch first what happens with 10%. Im sure we will see a 0,5$-0,6$ price per HBD. Special because HBD conversing makes the movements more extreme in both directions.
True, but with for example 50% ( to make it a bit extreme) we will hit the panic at some time too. Only later.
With the difference, hive could pump to 7$ in that timeframe to print a shit ton of HBD.
With the 10%, it's like a government that can't pay its bills. The haircut would destroy at this point way more "money".
And it could also if the conversion is unlucky destroy the tokenomics from Hive.
7$ Hive = 2,8B MC
30% print = 900M possible HBD (also 10% APR is more then 90M a year)
Price drops to 3$ and panic hits + mass conversions. Price drops more and more conversions.
Sure Haircut can be in place, but it would not be stable at all.
I don't know. I like collateral stables more with lockups. They have problems too but don't affect inflation and they are not debt.
Yeah, I don't know, I'm in favor to hold it as low as possible :) IMO it makes it riskier to hold larger amounts powered up in extreme market movements.
The N idea is good. Let's see what happens.
I think the premise of someone converting a lot of HBD being an "attack" is kind of wrong. It assumes that existing stakeholders don't value HIVE and have abandoned holding it to an extent that has caused the price to crash. In that case, maybe it's fair they just pass the baton.
The way I see it, if someone is willing to hold a lot of HBD while the price of HIVE is collapsing (risking losses, potentially total loss, with probably limited upside), and then convert their HBD, power it up, wait out the voting delay, and then vote, I think they earned their votes. Way back in the early Steem days, @abit did this, and he certainly earned his votes.
Someone trying to buy a lot of HBD quickly to pull this off, as opposed to being a long-term holder, would drive up the price of HBD, just as someone trying to buy a lot of HIVE would, maybe more so. We've seen how this plays out.
Someone buying HBD over time while others were dumping it could instead be buying HIVE while others were dumping it (i.e. able to accumulate a lot without driving the price up). Don't see much difference.
You should definitely write such posts more often :-)
Nah, it takes too much time. I should be doing stuff, not writing about it :o) But let's play a bit.
Even the simplest changes are not as straightforward as one would think. F.e. in order to make hard limit more flexible we first have to change hardcoded part into generalized formula.
Let's define
h = HBD supply(corrected for treasury balance),v = HIVE supply. Current code sets minimal price as9*h HBD per v HIVE. Check:virtual supply = h*price + v = (1/9)*v + v = (10/9)*v; the HBD part(1/9)*vin relation to virtual supply(10/9)*vis((1/9)*v) / ((10/9)*v) = 1/10 = 10%exactly as we wanted.Generalized price formula could look like this:
(10000/limit - 1) * h HBD per v HIVE. Forlimit = 1000(10%) we get exactly the same price as before. It also looks nice for 20% (4*h HBD per v HIVE), but for 30% we get2*h HBD per v HIVE- exactly the same as for 33%. Not good.Alternative price formula would look like this:
(10000-limit) * h HBD per limit*v HIVE. It has the advantage of pushing the inevitable truncation during integer division to the very end (when price is multiplied by asset). However it means that we're expressing price using much larger values. It is true that in general price expressed asa per bis equivalent to price expressed as10000*a per 10000*b, that is, as long as we can fit bigger numbers in 64bit variables. We are using total supply numbers inside price definition. Current HIVE supply is ~350 million, so let's triple that number to account for future inflation and safety margin. Amount of HBD is much smaller. We also have to consider that it is expressed with 3 digit precision and another 4 places to account for 10000 basis points (100%) of potential limit value. We get 10(9+3+4) = 1016. Signed 64bit integer can hold up to 9*1018, so there is still some space left... at least as long as we are not doing another similar price percentage scaling somewhere. The only place that I currently remember where scaling happens is during calculation of modified price forcollateralized_convert_operation, however we are not actually scaling price itself, we are doing the scaling along with multiplication with asset (multiply_with_fee) and that calculation happens on 128bit integers, so we are safe there. But to make sure we are not going to run into trouble, all the places where price is constructed need to be found and verified (cheers for someone who thought constructing price with use ofoperator /is going to be a good idea - that needs to be eliminated first). On top of that it might be a good idea to also assume (static_assert) that limit is at least in whole percentages, so instead of(10000-limit) * h HBD per limit*v HIVEwe can use(100-limit/100) * h HBD per (limit/100)*v HIVEwhich would give us two more levels of magnitude of margin.The above is an example of a lot of work required to change couple of lines of code :o) And it doesn't even touch the unit tests, that tend to go belly-up whenever you sneeze near the code, especially when they are designed to test the edge cases.
Is there anything wrong with using 20% or 25% or 33 1/3% and keeping the "couple of lines" of code change minimal? The number seems mostly arbitrarily picked, I don't see the value in fretting over getting right to 30% vs 25% or 33 1/3%?
Congratulations @andablackwidow! You have completed the following achievement on the Hive blockchain and have been rewarded with new badge(s) :
Your next target is to reach 200 upvotes.
You can view your badges on your board and compare yourself to others in the Ranking
If you no longer want to receive notifications, reply to this comment with the word
STOPCheck out the last post from @hivebuzz:
Hive (as Steem getting more complicated with every update. I think we should always have in our minds the average non technical user.
It's a job for user interfaces to deal with this problem. Otherwise we would be bunch of savages chasing each other with poop sticks. Average user of a car have no idea how the engine works, and that's fine if all they are looking for is drive from A to B.
I think the statistics speak for themselves. There are many ways to go from A to B.
Since I am non-technical for the most part, my favorite bit was this being the thumbnail:
:)
I'm glad I used toonified version in my profile picture, but it looks like it would be a good idea to always use some other picture inside the post, so it is picked for thumbnail instead of me :o)
I don't know - this could be your thing now.
When @gtg said you should post more, maybe he wasn't talking about your content ;P
Its too technical to understand me the HBD and Hive Hard Limit but what i simply understand if Debt ratio is higher then We don't receive HBD from reward pool . I think its well balanced financial ecosystem in hive blockchain which strictly control the inflationary printing of tokens . Thats why HBD is more useful and profitable if someone go for savings where 10% APR is not a bad deal .HBD is partially pegged with US dollar and that is another beneficial point to hold HBD ..Who knows when korean pumps the price value of HBD till 10X in value in near future..
That's a great explanation. Thank you.
I'm very glad to see you posting on Hive.
I might be late for the game but I might have something in response to people who are still against increasing the haircut ratio after reading the post.
Just remember, that limit wasn't always 10%. It's an arbitrary number. Even if you set it to 5%, it can cause a downward spiral for the price of Hive in a price crash.
You don't know what is the good number for the hard limit. 2, 5, 10, 20, or maybe 50?
There is no science or formula to calculate it. That doesn't mean we have to go out of our minds and make huge changes. That's why the proposed change is so tiny compared to the current situation and the demand for HBD.
Anyway, I'm not here to argue with anyone. The decision is up to the top 20 witnesses.
Yeah I agree, which is why I think we ought to stick with something that is easily to implement. With the way the code works, this seems to be 20%, 25% or 33 1/3%.
Could you answer me a simple question?
I had around HBD and I convert that to hive when the hive was at 1$, but I got only 1Hive on the wallet? I should have got more than that according to the three day median price of hive.