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.