Hello,
As you're probably aware, hbd is way above it's peg, (trading at 2.3$ atm, from about 1.5$ most of the month) while on the short term it can seem like a good thing because that's more value that can flow into hive stakeholders (post, get hbd, buy hive ??? profit) a stable coin is what we need for funding a lot of the development on hive via the dhf.
So as @smooth mentioned on @arcange's post
In the case of severe undervaluation/underpayment beyond a few cents (which would only happen with the haircut, as @blocktrades stated), it is my opinion that a lot of proposals would absorb it for a limited period, but would then either request additional funding or cut service/spending in some manner. I could be wrong, but that's how I see it, and I think the current situation is pretty similar. Proposals have been overpaid for a month or so, and it was overlooked/absorbed as a market fluctuation, but at some point it does become too significant to ignore.
Which is something I completely agree with. So now that HBD has been above the peg for quite a bit, even with @hbdstabilizer's help it's not unreasonable to think that until hf25 comes along to fix it, it will stay above the peg. (blocktrades and his team are introducing a new change which should solve it)
So now we have a problem where proposals are paid more than what they asked for for too long, and the community and stakeholders came up with a lot of different solutions that I'll outline here:
@good-karma (ecency/hivesigner): Introduced a bot to automatically send the overpaid HBD to @hbdstabilizer every hour (so if you're paid 1 hbd and the price is 2$, it sends back 0.5) basically this means the cost of the proposal is reduced to 0 if the hbd price is 2$ or even < 0 if it goes above.
@inertia documentation proposal: He used a change introduced in hf24 to reduce the amount of hbd paid to him every day to match the hbd price, the problem is once hbd goes back closer to 1$ he won't be able to increase it again, so he'll then be underpaid, and then he'll probably have to make a new proposal to get the full amount again, which is a lot of time "lost" campaigning
@blocktrades (not running a proposal): As an alternative solution to inertia, unvoted all the proposals paying out, in his own words:
From what I can see the option to reduce the pay is worse for proposals. As it is, they temporarily lose funding, but will be able to go back to full funding after they are voted back in.
If they lower their funding, and HBD went back to $1, I don't think they can raise the funding level back and would need to create and campaign for entirely new proposals to reach the same funding level. So I don't think that mechanism is that useful for the situation of fluctuating HBD. I believe it was mainly added as a method for bargaining between proposers and voters.
Another potential option would be for proposers to just temporarily redirect their funds to the hdbstabilizer, but some might not feel comfortable doing so, because they might feel they were overstepping the guidelines of their original proposal, unless they had put in such a clause when they originally made their proposal.
From the available options, it looked to me like a temporary unvote was the most reasonable choice.
My take:
The key difference between a lot of those proposals that are "objective based" where it's "I need 20k to do x/y" my proposal is based on man hours, and in my initial proposal I put a clause regarding the HBD fluctuations:
I am asking for 275 HBD a day for a year. I calculated the price to be about 100$ an hour. So I will be spending between 15 and 20 hours a week on it
So my take on it is simple and has been for the past year: When hbd dips below 1$ I spend less time on it, when hbd rises above a dollar I spend more time on it proportionate to how much it rises. And this is what I've been doing for the past month.
Obviously I'm just a single man and I can't work 25 hours a day if HBD were to rise to 10$. So then we'll see other solutions like hiring someone to match the hours or sending some HBD back, but hopefully we won't see this anytime soon.
I think this is a better approach than the "the proposal costs 0" solution. We have a lot of HBD/Hive (soon to be converted) to spare thanks to the ninja mine (not even taking into account all the new money coming in from @smooth and hbdstabilizer). We should be taking this opportunity to double the development speed for the same cost instead of making it "free" and save hbd.
Thoughts ?