I opened a small protocol-level PR for Hive.
PR: https://github.com/openhive-network/hive/pull/48
Proposal: https://peakd.com/me/proposals/381
The idea is simple:
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.
Hive already has a consensus field called hbd_print_rate. When the chain gets closer to HBD debt stress, this field suppresses HBD printing. My PR applies that same signal to DHF proposal payouts.
If hbd_print_rate is 100%, DHF proposal payouts behave normally.
If hbd_print_rate is 50%, DHF proposal payouts are 50%.
If hbd_print_rate is 0%, DHF proposal payouts are 0%.
Unpaid HBD stays in the treasury.
It does not fix Hive. It does not pretend to fix Hive. It does not redesign governance. It does not punish named accounts. It does not touch user balances. It does not claw back money. It does not freeze anyone's wallet.
It only says that discretionary DHF outflows should be tied to the same HBD stress signal the protocol already uses elsewhere to everyone else.
If HBD printing is being suppressed, DHF proposal payouts should be suppressed too.
First, having two tokens minted separately add a vulnerability in the DPoS. Technically whoever has the most stake is incentivized to maintain the value of the stake. This is the basis of trust in and PoS chain and should be the same on a DPoS chain.
Because Hive has HBD those incentives are warped. 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.
The DHF introduces first and second class citizens. The first class citizens have contacts and large enough power to mint their own stablecoin. The second class citizens do not.
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.
This effectively reduces, but does not mitigate, the flaw in our dual currency economy. Now users with a large stake in the governance token do not have a back door to print a stablecoin while everyone else has their stablecoin yields halted.
This PR does not abolish the DHF. It simply makes the DHF beneficiaries adhere to the rules everyone else adheres to.
hbd_print_rate?Because it already exists.
When Hive says HBD printing should be suppressed, with this change DHF proposal payouts are suppressed by the same factor.
I am not a protocol developer. This PR is missing tests.
I aimed for the smallest code change possible to make the intent clear. The code change is small, direct and simple, but it misses testing.
Testing is valuable and probably the most difficult and important part of Hive core development. I myself do not have the computing resources to test it on a local devnet and apply it under stress and I am not a C++ dev, I could use AI to write tests but the code diff would be huge and the tests would possibly be flawed and/or redundant.
Still with tests written I would not have the resources to run and actually test because the software is heavy and running multiple machines and testing the consensus is computationally expensive.
This is a PR, a PR is a code proposal, if it is rejected I expect at least an explanation. I am posting about it to gauge public opinion and raise awareness.
They should explain why discretionary DHF proposal payouts deserve to continue normally while the protocol is suppressing HBD printing. Why we should have two different class of citizens and why one of them deserves printing rights.
They should explain why the burden of debt stress should fall on holders, buyers and HBD users, but not on proposal receivers.
They should explain why the chain can be close to the haircut and still treat treasury outflows like public financing as usual, like a tax on the buyers distributing to the receivers.
That is already a useful discussion.
Hive already has an HBD stress signal.
I am asking whether DHF payouts should obey it.
If the answer is no, then say no publicly and explain why.
If the answer is yes, then review the PR and contribute to it, since I know it lacks testing.
But do not pretend there is no protocol-level action possible.
There is.
I opened one.
