The HBD limits explained (technical)

avatar

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.



0
0
0.000
25 comments
avatar

You should definitely write such posts more often :-)

0
0
0.000
avatar

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 as 9*h HBD per v HIVE. Check: virtual supply = h*price + v = (1/9)*v + v = (10/9)*v; the HBD part (1/9)*v in relation to virtual supply (10/9)*v is ((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. For limit = 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 get 2*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 as a per b is equivalent to price expressed as 10000*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 for collateralized_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 of operator / 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 HIVE we can use (100-limit/100) * h HBD per (limit/100)*v HIVE which 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.

0
0
0.000
avatar

Cool, there will be people requesting their right to argue if 32% is better than 31% for placing the haircut. I think they are missing the point.

To me, changing that "9" into 4 (too conservative), 3 (reasonably conservative), 2 (reasonably aggresive) or 1 (too agressive for starters but a good goal to reach after a couple of i:=i-1 hardforks at least for a while until people feel 50% is too low) is enough of a choice for politics.

The side message (this number is not intended for frequent changes) is even cooler.

0
0
0.000
avatar

It also looks nice for 20% (4h HBD per v HIVE), but for 30% we get 2h HBD per v HIVE - exactly the same as for 33%.

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%?

0
0
0.000
avatar

Congratulations @andablackwidow! You have completed the following achievement on the Hive blockchain and have been rewarded with new badge(s) :

You received more than 100 upvotes.
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 STOP

Check out the last post from @hivebuzz:

Feedback from the October 1st Hive Power Up Day
0
0
0.000
avatar

Hive (as Steem getting more complicated with every update. I think we should always have in our minds the average non technical user.

0
0
0.000
avatar

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.

0
0
0.000
avatar

In this case, the first step for UIs is to include a haircut warning in the convert HBD->Hive section. Preferably along with an estimate of the current debt ratio.

IIUC, the real issue is that few people understand they can get rekt when they seemingly start HBD conversion in time but then the debt ratio goes over the limit and their rate gets calculated from inflated internal price over the next 3.5 days.

0
0
0.000
avatar

I think the statistics speak for themselves. There are many ways to go from A to B.

0
0
0.000
avatar

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

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.

0
0
0.000
avatar

Yup a huge risk for panic and i totally against increase the debt limit.

I fully agree with your premise, I just arrived to the opposite conclusion - keeping the debt limit low at 10% means the panic situation is way more likely to trigger compared to the situation where the debt limit is increased.

Also, it is a huge argument for blocktrades' proposition to reduce automatic HBD printing long before getting close to the actual debt limit.

0
0
0.000
avatar

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.

0
0
0.000
avatar

I follow you.

People offer their opinion that N% is the last healthy level of debt. Different people have different N's.

The only problem I can see is they conclude the haircut should kick in at N+1% debt ratio.

They should ask for like 3*N%.

That way, they will see significant HBD burn pressure at N%.

0
0
0.000
avatar

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.

0
0
0.000
avatar

Since I am non-technical for the most part, my favorite bit was this being the thumbnail:

Screenshot_20211009_142401.jpg

:)

0
0
0.000
avatar

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)

0
0
0.000
avatar

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

0
0
0.000
avatar
(Edited)

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..

0
0
0.000
avatar

what i simply understand if Debt ratio is higher then We don't receive HBD from reward pool

That is true but that is not the risk part. We risk getting bad rate during HBD->Hive conversion that might make it more profitable to sell HBD well below $1 on external exchanges (or buy fewer Hive on internal market than we would get for the same amount of USDT externally).

0
0
0.000
avatar

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.

0
0
0.000
avatar

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.

0
0
0.000
avatar

You don't know what is the good number for the hard limit. 2, 5, 10, 20, or maybe 50?

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%.

0
0
0.000
avatar

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.

0
0
0.000
avatar

Are you referring to your last conversion that was based on 1 Hive = $0.923 giving you 1.08 Hive for each HBD? That median price looks right to me for that timeframe (starting shortly after the Hive peak).

0
0
0.000