I guess we're stating facts.
Like how your proposal has been around since 2020-11-12. During that time, your proposal was exposed to the risk of under payment, if the peg fell below the target. Proposals were also subject to small underpayments due to a bug.
It is unlikely that these two risks would have been compensated, and they are (mostly) understood when a proposal is created. It's just the way proposals are.
It's too bad there's a double-standard.
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.
There's reasonable protection against the price of HBD going too low: the HBD->Hive conversion mechanism. It only fails in the case of the haircut. There is currently no mechanism to protect against HBD going too high (with the possible exception recently of the hdbstabilizer, which is being employed now). So the opportunities for each possibility are not the same.
And in such a case, any proposer who feels he is not getting enough can, in fact, create a second proposal to get paid more.
That's definitely an opinion, not a fact, and one I disagree with.
I get it. But proposals also now have an option to reduce pay. If there was some direction given, perhaps on a weekly basis, "Reduce pay by n % or risk being unfunded," that might help.
Is that out of the question?
Is there a mechanism in the blockchain for that or would they have to send it back, and then stakeholders make sure that it is being sent back? The latter seems possible and fair to me, but a bit of a pain.
While we're waiting for clear direction, I'll just drop mine from 130 HBD to 45 HBD.
Again, how is that done? I was asking because I want to learn.
It's a new feature for HF24:
https://gitlab.syncad.com/hive/hive/-/releases/v1.24.2
Seems potentially problematic in that if you reduce funding you can't increase it again if the price of HBD goes down. But it's a tool in the toolbox, might make sense in some instances.
There's been a discussion in DHF forum in mattermost for weeks about potentially temporarily unvoting proposals due to high price of HBD. But it wasn't until today that HBD jumped suddenly. A weekly advisory basis isn't really possible as long as HBD price is so volatile. I certainly had no idea it would spike to $3 today.
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.