Explained About HBD limits

since the last point of The 25th update of 2021 on BlockTrades running on Hive software has received a lot of attention. I thought it would be nice to summarize the current state of the code. That's how the mechanism in question works at the moment.

There are three quasi-independent constraints associated with HBD. The first two consist of SOFT LIMIT and primarily control the HBD print rate. These are dynamic_global_property_object::hbd_start_percent and ::hbd_stop_percent.dynamic_global_property_object despite being a variable member of a dynamic property These values can only be changed between hard forks. Up to HF20 their values are 200 and 500 respectively (values in the base point => 2% and 5%). After HF20 the values change to 900 and 1000 ( 9% and 10%). As the total amount of HBD in existence(x) in relation to the growing virtual supply (aka debt ratio), it affects the value of the states ::hbd_print_rate.dynamic_global_property_object when lower hbd_start_percent Avalue of 10000 (100%) means that comment rewards due in HBD are unlimited when the above growth rate. hbd_start_percent but still lower hbd_stop_percent, will decrease proportionally, thereby reducing the opinion that the winnings paid in hbd_print_rate HBD - they will be paid in the nest instead. Finally when there is HBD to include that much hbd_stop_percentThe upstream ratio, hbd_print_rate is set to 0, which means the return comment will not have any portion of the cost in the HBD.

The hbd_stop_percent limit is applied one more time. If the action collateralized_convert_operation (HIVE to HBD conversion) pushes the debt ratio above that limit. The operation will fail. It means that the soft upper limit not only stops (part of) automatic HBD printing, but also stops the user from reprinting HBD. OK, but what is virtual supply and how is the debt ratio calculated? The virtual supply is basically the total quantity of HIVE: liquid, in the form of savings. Like VESTed, but also the total HIVE that will be issued if all HBD is converted to HIVE. ::virtual_supply and updated (along with dynamic_global_property_objecthbd_print_rate) twice every block - when the transaction is processed and a new internal price may be set. The second time after some automation has finished. Includes conversion processing and comment rewards (but not paying offers) - :: update_virtual_supplySee calls to database (x)while virtual_supply calculated as I described. When calculating the HBD debt ratio, all held in the Treasury account (hive.fund) is deducted as if it did not exist. This happens because many HBD repositories from Steem->Hive airdrop and funds are regulated by code. not by user Therefore, it does not make sense to treat HBD the same way as HBD in the market. When HBD held by the Treasury is still calculated as a debt ratio, the limit is almost always reached ::calculate_HBD_percentIf you are interested in the details of debt ratio calculations, look for its database.

Because the treasury balance is not taken into account when transferring HBD out of the proposed payment. HBD is equivalent to issuing a new, so although the limit can also be expressed HBD new to the market, so "soft" limit also does not stop interest savings HBD
because the calculation. virtual_supply It involves increasing the value of HIVE and HBD, which are different assets. Therefore, there must be a price to bring them together. price to be held in feed_history_object :: current_median_history and updated every hour from what witnesses bid valid - :: update_median_feedView the database is possible. Especially during the downturn in HIVE prices, where the volume of HBD in the market is below the debt limit. After the price is updated will be higher than the limit if so There is a theoretical situation that one user with most HBD would be able to use. convert_operationHBDsHIVEs, powering (HBD to HIVE conversion) to turn all of hisinto manythem up and gaining massive voting power. May take over blockchain governance Please note that if he tries to collect the same amount of HIVE in the market, price will move up But because the conversion takes place on the network Therefore, there is no such immediate effect.

Once the hard limit is reached, the internal price of HIVE will be inflated. This means that in chain conversions and other calculations Will make the code to HIVE less than expected (so users trying to convert HBD to HIVE on the chain will be at a loss compared to the market but the chain as a whole is safe). Why would we want to reduce this strong protection? Today, we have more and more tools to use if an attack scenario occurs. Including late voting - There is an additional 30 days to react in the event of an attempt to capture an enemy. As long as the "good guy" has more voting power than the attacker can get, there shouldn't be a problem.

This is where the final limit will come into effect - HARD LIMIT. It is now hardcoded in the process of updating prices and changing the price set by the witness to guarantee that even if all HBD is converted to HIVE, the conversion will not generate all HIVE. Exceeding the hard limit only The hardcoded limit is 10% which is the same as the upper soft limit. and it is only appropriate to have the soft limit above or below the hard limit. This is because the debt ratio calculation uses internal prices and is affected by hard limits. Soft limit It cannot be accessed if the hard limit is exceeded.

Explained About HBD limits | Ecency