I was having a convo a few days ago with @arcange trying to get up to speed on HiveSQL. I had followed the instructions on HiveSQL.io, which said to ‘donate’ 0.01 HBD to @hivesql and I would be subscribed to HiveSQL.
However, that didn’t work.
HBD is worth more than $1 right now. [It raised over $2, close to $3].
The proposals were written with the assumption that HBD was worth $1.
So when HBD goes more than a dollar, those proposers get more than expected.
So the voters [i.e. anyone] [can] unvote them temporarily, and this serves two purposes:
- the proposers aren’t overpaid
- the additional HBD that is now available gets used to buy up Hive, to allow for more proposals to be funded in the future.
About the same time, @themarkymark published a similar post explaining why so many DHF proposals had been ‘unfunded’ and why there are multiple HBD Stabilization proposals currently receiving the bulk of the DHF funding, and how the existing DHF proposals had been receiving more than they should have for the past couple months because HBD had been hovering significantly above $1.
I may be a bit naïve here, but it seems like a really simple solution can be implemented.
Why not make the DHF payouts to successful proposals be fractional if and when the external market for HBD is above some threshold, say $1.10.
For example, HiveSQL’s current proposal calls for 100 HBD per day. Instead of cutting that proposal off completely, simply adjust the payout for that proposal to 100 / current_external_HBD_price. So, with HBD currently going for $1.86 on the open market, the HiveSQL proposal would get 100 / 1.86 = 53.76 HBD today instead of 100 HBD.
Under this scenario, the HBD Stabilizer proposals can be positioned just above the Return Proposal, thus automatically kicking in the stabilization funds whenever the price of HBD rises above $1.10 (or whatever cutoff is chosen), without cutting off funding to proposals that have already been voted worthy of DHF funding.