If it was up to me I'd do the following:
There is also problem of return proposal. Was there even one time when return proposal was not funded? Because I'm under impression that we keep accumulating funds to spend later for years, and that "later" never comes. It is somewhat connected to the third problem that bothers me more than it should - a great portion of development was never funded by DHF, so it is not really serving its purpose.
Now to the main topic.
If Hive’s own protocol is already suppressing HBD printing because of debt stress, then DHF proposal payouts should not continue at full speed. The suppression should apply for everyone.
DHF is not printing HBD. It pays out of HBD it already has on balance. Printing of HBD happens every block when portion of inflation is added to DHF balance. If you wanted for hbd_print_rate to affect that part, I could agree, but the effects would only be visible years later (or maybe never given the return proposal).
If HBD printing is being suppressed, DHF proposal payouts should be suppressed too.
There is already mechanism for that - return proposal. If people actually wanted to cut spending from DHF, they'd unvote funded proposals or push up return proposal (or maybe some new "burn" proposal to avoid accumulation of funds).
By voting for proposals, Hive users agree to pay for some work to be done for the sake of whole ecosystem. Recipients of proposals already face challenges - proposals can lose funding every payout schedule (every hour), so they might commit to work only to not be paid later. At the time like currently they also face possibility of having their funds slashed by haircut rule. Your proposal would cut their funds much earlier (at higher HIVE price) and completely. How is that fair?
It only says that discretionary DHF outflows should be tied to the same HBD stress signal the protocol already uses elsewhere to everyone else.
hbd_print_rate does not affect how much funds authors get for their posts - it only changes asset type. All the rewards they earned are just paid in HIVE instead of HBD. You on the other hand want DHF to stop funding proposals completely. By the way there was an idea to pay proposals in HIVE instead of HBD when hbd_print_rate goes to zero, but the effect would be that recipients would have easier time to sell received HIVE (now they have to first convert HBD to HIVE before selling, since external markets for HBD are nonexistent).
Someone with a large enough stake on the governance token may not care for the value of the governance token because they can still have financial gains on the other token.
It is completely false. HBD does not give any gains over HP. Even the raw APR is comparable (passive HP increases from inflation plus curation that can be fully automated vs interest on HBD), but stake gets you a lot more influence.
That is deeply unfair. If the stablecoin emission is halted for the second class citizens it should be halted or scaled similarly for the first class citizens.
As stated before - the purpose of getting funds from DHF is to pay for work. Since you can't pay for groceries/gas/rent/taxes with HBD (hopefully just yet - one can dream :o) ), those funds need to be converted and sold for fiat money. There might be projects that choose to save received HBD, but that means they are spending their own money to fund the work, so it is effectively as if they were buying HBD but without all the intermediate steps.
I have an impression that you are implying the following scenario: people with high stake can make fake proposals, where they don't do any work, but vote themselves for those proposals to get HBD. Only then it could be viewed as some sort of "backdoor". But such scenario is completely unrealistic on Hive. I'd even doubt it is possible on legacy chain, but I have not looked there for a long time.
By the way. Your so called "second class citizens" benefit from HBD "emissions" from DHF through hbdstabilizer proposal - even if they can't get new HBD from direct conversions nor author rewards, they can buy them on internal market from HIVE they receive instead. That way is realisticly available only for small accounts because you can't buy HBD on internal market at volume.
I am not a protocol developer.
No no, stop, don't comment...
I myself do not have the computing resources to test it on a local devnet
Hive runs on pretty much everything, as exemplified by team on last HiveFest. Sure, running and testing full stack might be challenging, but core development only requires proper unit tests. The hardware is not a problem whatsoever, the challenge is that even if you know exactly what you are doing, unit tests can still lead you to frustrating traps - there is no way around this, everyone wanting to do work in core code has to get through that themselves. AI helps a lot, but not fully :o)
They should explain why the burden of debt stress should fall on holders, buyers and HBD users, but not on proposal receivers.
HBD holders or buyers are not affected by hbd_print_rate. Even authors are not really affected since they still receive the same rewards, just in HIVE. The "debt stress" should not fall on proposal receivers, because for them it is payment for work, not investment. You can see it as stock holders vs subcontractors - the former are affected by debt of the company they hold, but why would the workers be affected?
They should explain why the chain can be close to the haircut and still treat treasury outflows like public financing as usual
Because it is financing as usual. And DHF recipients are actually more affected by haircut than any other user holding HBD, because by principle investors has to accept that risk and also more likely can hold until situation improves, while DHF recipients have bills to pay from the devalued HBD they receive.
RE: I opened a protocol PR: scale DHF payouts when HBD printing is suppressed