Why Not Simply Divide the DHF Payouts by the External Market Price for HBD Whenever It Rises Above 1 USD?

avatar
(Edited)

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.

Shortly thereafter, @arcange contacted me to explain that the DHF funding for the HiveSQL proposal had been ‘unvoted’ by @blocktrades because the external market for HBD had risen way above $1.

To explain that change to the HiveDev community, @arcange published a post with the following quote from @blocktrades:

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:

  1. the proposers aren’t overpaid
  2. 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.


Posted via proofofbrain.io



0
0
0.000
15 comments
avatar

There are multiple reasons why implementing such a solution is not as simple as it looks. Here are some:

What is your source for the HBD price assessment. The price may differ from one exchange to another and from the internal market.

You also need to consider the opposite case where HBD would go lower than $1. This would mean that we would then have to pay with more HBD. Then what about the (hypothetical) case of a daily budget that is 100% used and no more HBD is available to increase the payments.

Payments are made every hour. What about a short but massive pump of the HBD price (let's say a few hours) where the proposal's payout is (massively) reduced but its beneficiary is not able to sell at that higher price? Not a big deal for small amount proposals, but it can be a game-changer for higher ones.

0
0
0.000
avatar

Yes, maybe I was a bit loose with the term simple.

In any event, all those challenges seem surmountable, and the status quo seems worse (to me, anyways).

What is your source for the HBD price assessment. The price may differ from one exchange to another

If there are multiple sources, isn't that a good thing? Then you can take the median and thus automatically exclude the outliers.

the opposite case where HBD would go lower than $1.

I was suggesting this adjustment only happen when HBD is greater than a preset threshold, such as $1.10. Between $1 and the threshold do nothing; below $1 use the current protocol.

Payments are made every hour. What about a short but massive pump of the HBD price

Couldn't you just use a moving median price? So, with multiple oracles, it would be a median (across times) of medians (across exchanges).

0
0
0.000
avatar

If there are multiple sources, isn't that a good thing?

The problem is precisely that there is not a lot of sources: Bittrex, Upbit, and the internal market.

0
0
0.000
avatar
(Edited)

I see.

Couldn't the witness each make their own assessment of the 'true' external market value of HBD, then use the median of those values?

It's not like the number has to be hugely precise. If I were the recipient of DHF funds, I would rather a system where the hourly disbursement is decreased, albeit imperfectly, whenever HBD goes well above $1, instead of having the funding completely cut off at some point, as is the current case.

With the change I proposed above, if the price of HBD goes to $2, then all previously-funded proposals get their funding cut in half (but not really, because they can cash out on the external exchange if they choose to, at their full USD amount) and the DAO gets to make a 100% profit on the other half, thus returning the full amount of HIVE back to the DHF.

With that being the case, a temporarily-inflated HBD helps everyone and hurts no one -- and a proportional amount of the DHF disbursement is fueling a feedback mechanism to help bring the price of HBD back to $1. Or am I missing something?

0
0
0.000
avatar

arcange's comments are mostly on point as to the downsides of the suggested approach. Also, it's important to understand the the use case for HBD goes far beyond just the proposal system. Other forms of commerce also need a stable value, just like proposal payments.

The solution you're suggesting requires additional coding (for example, for the HBD feed price) and it only would solve the stability issue for proposals. The planned solution is to stabilize the price of HBD itself, so it can be used as a stable currency for many types of commerce, and it is actually easier to implement and maintain.

0
0
0.000
avatar

I agree that the current system is easy to implement and maintain -- and that's great for the short-term. It seems that a long-term solution merits serious consideration (a solution that frees DHF-funded developers from the whims of external markets).

The disruption to DHF funding proposals seems not insignificant. It does not affect me directly, but it does affect my eagerness to submit a proposal.

I have a couple proposals in mind, but the uncertainty associated with the current de-funding of previously-funded proposals makes me question whether I should try to move those forward.

How long do you anticipate keeping previously-funded proposals at zero?

If the answer is "until the price stabilizes" then a more robust solution should be sought. The solution I've suggested is merely one of many possible solutions.

A solution that does not involve coding, but requires active changing of votes, would be to implement the current stabilization protocol intermittently, thus allowing the previously-funded proposals to be 'overpaid' for a time, then unpaid for a time. Maybe that's the current plan?

0
0
0.000
avatar

We're planning to implement an additional operation to allow for the stabilization of HBD price peg: https://hive.blog/hive-102930/@blocktrades/proposed-hardfork-change-to-stabilize-hive-dollar-s-tracking-of-usd-value

In the meantime, I don't expect current proposals to remain unfunded for long. The exact timing will depend on HBD price. Most of them were getting about 30% overpayment for quite some time, so I don't expect any to suffer a real loss, in terms of the amounts they were proposed for.

As I stated elsewhere, if there's any proposal that is losing funding relative to their proposed amount during this time period, I can supplement their funding and make a proposal later to recover the loan, once HBD has stabilized. In short, no dev work should suffer, and we should end up with a lot more funding for the future.

0
0
0.000
avatar

In short, no dev work should suffer, and we should end up with a lot more funding for the future.

That's good to know. Thanks for the clarification.

That should alleviate concerns from future developers.

And, actually, the temporary 'loan' option seems perhaps preferable (in terms of maximizing the effectiveness of the stabilization while also maximizing the returns back to the DHF) -- but it does lack the elegance of a decentralized solution.

Thanks for taking time to help me understand the ins and outs of the DHF a little better!

0
0
0.000
avatar

The simple reason not to do this is that if it weren't for the DHF, they wouldn't even try to stabilize HBD. If they can, then HBD becomes more useful.

0
0
0.000
avatar

I'm not sure I understand your point. Are you saying the DHF is the only reason a stable HBD is required or beneficial?

That seems contrary to what blocktrades is saying.

0
0
0.000
avatar

I wouldn't say that the DHF is the only reason. But it's the thing with the most impact. Before the DHF, people would just say "oh well" and let the debt asset do its thing. With the presence of the DHF, it is seen as a new tool to reign HBD in.

I have my doubts as to the effectiveness of this form of HBD stabilization. But it's something to try.

0
0
0.000
avatar

Thanks for the clarification.

My main concern was with the impact on current and future developers. @blocktrades explained the mechanisms by which devs will be 'protected' from the whims of the external HBD market under the current approach.

I still favor a decentralized solution (because that's a big part of why we're all here -- if we can't solve a problem in a decentralized way, are we just fooling ourselves and playing games?) -- that's one of the reasons I created this post and entered this conversation.

However, in addition to being a most-of-the-time idealist, I am also a full-time pragmatist. Yes, the two often conflict -- the pragmatist usually wins.

0
0
0.000
avatar

As far as I can tell, those of us collecting a paycheck from the DHF have not been adversely impacted. If anything, we have benefitted, so far. I have lowered my daily pay in order to avoid being dropped, but that's not the only strategy being used.

I agree, though. A decentralized solution would be much better.

0
0
0.000
avatar

I suggest front ends make payouts 50/50 by default. Maybe even give users a chance to change their mind about 100% power up with a link to my post on why its better if it is set to 100% power up. These are @ecency @peakd and @hive.blog interfaces. There is only about 9% inflation and only 65% is that of rewards of posting and curation. Now the authors get 50% of those rewards. Now only 50% of of the award can be dollars. That leaves 50% of 50% of 65% of 9%. This is about 1% of the virtual supply of Hive in newly created dollars after one year. Maybe not enough to fix the HBD price but great if you're a struggling Venezuelan and getting healthy post rewards.


Posted via proofofbrain.io

0
0
0.000
avatar

I am glad someone is on here understands this stuff!

0
0
0.000