> If proposals all have an About clause would that not solve the issue

What do you mean ? 

> then why not a system to peg the requested HBD to a Weekly dollar amount. If the price of HBD goes to up to where they are receiving $2200.00 then simply reduce the amount of HBD for that week by 10% to the individual. Likewise if the price declines and they are only receiving $1800.00 then simply increase the amount of HBD to the requested dollar value. They still receive the amount they needed in dollar value of HBD.

I mean yes that would work but it's treating the symptoms (proposals get paid too much or too little) not the source (hbd not being pegged). And it's a pretty complex system that would require a new price feed for HBD which is kind of an aberration considering we expect HBD to be pegged.

> You offering no objectives to be held accountable against is now in favor of your overfunding

I wouldn't argue that there is no accountability on my end, everything that I do is open (since it's open source), I talk about what I'm doing on a bi-weekly manner (via the core dev meeting) + semi regular posts and everyone is free to criticize what I'm doing if they think it's moving too slow/not working on the right things.

> Whereas it should be counted against other proposal's commitment to accountability? I would wager a guess that your fellow receivers of funding are also able to adequately tailor their time commitments to funding levels.

That's a fair point I guess I didn't explain myself clearly sorry about that. I talk about it in my other comment to @good-karma, basically I would like to see others take my approach and as I told him `hivesigner/ecency and hive in general would benefit so much more from you hiring a contractor with the extra funds to work on some new features imho`. What I'm ment is that my proposal can more easily expand to use more funding than something like hivesql/hivewatcher/banjo that has a set amount for supporting the infrastructure (and it makes no sense to get more funding to get a bigger infra if in 2 months hbd gets back to 1$ and you need to cancel your servers). 

The liquid hive part only happens if the haircut rule hits (too much hbd per hive because of a low price) and so far the hive price has sustained high enough for it to not happen. 

> hive price below 1$

It's more complex than that but yes it's a calculation of ratio between the total hive marketcap and the total hbd marketcap. Double check this (google hbd haircut) but I remember it being something like 20%, so if the hbd marketcap is at 20% of hive's then there will be no HBD printed anymore.

Well I would argue "good riddance" People posting just to earn, power down and sell all the hive they get don't contribute to the network much, they basically just add sell pressure. Ideally we want content creators that care about the platform and have stake and be incentivized to promote it.

> If devs can double their efforts to match the payouts thats amazing and I am 100% with that ... just not sure how this will be measured properly. 

I mean it's up to the devs to hold their promises and to not fool themselves that they can work twice as much, I can do 30 to 40 hours a week is very much doable. And then it's up to the stakeholders to check it and unvote if they feel like it's not up to what was promised. 

> Btw on the dhf topic ... any plans for the next hf to clean up the dhf from the steem.dao account name even it is used only for virtual ops?

No, this was already done for hf24 actually, everything uses hive.fund, steem.dao is still used by the return proposal and some people/bots do so we will always have a vop sending money from steem.dao back to hive.fund

We could have a different return proposal but I feel like it's not worth the hassle.

> On the HBD peg side ... will be interesting to explore the possibility for incetives for providing liquidity (share of inflation?) on the internal dex around the 1$ peg.

I think the incentive will be there with the hive -> HBD conversion for instance if hf25 hit today you could change 1$ worth of hive to get 1 hbd which sells for 2$, by some more hive with it and repeat, this builds up a ton of sell pressure for HBD (and buy pressure for hive :p) which will bring it down or moon hive if it doesn't. But realistically I don't see how hbd would hold above the peg against that mechanism. And if we over do it and hbd goes below 1$ then you can convert hbd to hive and do it the other way :)  

> There is no way to confirm/verify, "over-working when above and under-working when below the peg".

There is also no way to confirm/verify I'm "working" I could spend 20 hours scrambling to fix a bug testing tons of different stuff and end up committing 15 lines of code for the week (which has happened to me before) unless I livestream all my coding sessions.

> costs were estimated accordingly

But the "cost" to the chain is the same ultimately if the proposal asks for 100 hbd, it costs the chain 100 hbd if hbd is at 1$ or 100$

>  So anything DHF over paying could be returned to stabilizer, that’s basically what we started to do So you are still covered for development and also helping to decrease supply/increase future funding by sending back to stabilizer.

Which is a totally valid approach imho, I think it's up to each proposals to be like "I can either reduce the cost to 0 for the chain or alternatively make it so that the chain gets double the work from the proposal (if the proposal applies)" 

Also regarding reducing the supply/increase future funding, while true I think it's a drop in the bucket, the hivesigner prop pays out 70 hbd per day, so half of it goes back to stabilizer, meaning 114 extra hive per day it's nothing compared to the 76 million hive from the ninja mine waiting to be converted.

hivesigner/ecency and hive in general would benefit so much more from you hiring a contractor with the extra funds to work on some new features imho. 

> Beside in script we can add threshold parameter for downside risk and stop returning HBD when it is 20% or 10% close to peg

Neat !

This is by far the best solution imo. 100% fair and extra hbd earns money for the dao. 

> Most proposal don't account for hours of work. Works in your case I suppose.

Yes I think I'm along with keychain and peakd one of the only proposals that can work like this 

> Although I would prefer you choose what to do with the money and not burn out working extra hours. If you choose to keep it I'm okay with it, and since your proposal remains funded despite blocktrades removing his vote I guess hive as a whole agrees too.

Oh don't worry worst comes to worst if I can't support the load I would just send back what I can't work.

Plus me working more right now is great news because I can go into overwork mode to ship RC delegations.

> If you choose to keep it I'm okay with it, and since your proposal remains funded despite blocktrades removing his vote I guess hive as a whole agrees too.

It's tricky to say if hives "agrees" a lot of people vote and forget, the real test is my next proposal I think, we'll see in two weeks I guess.

> I don't see the point to making your hours essentially random. If you want to work more, make another or a bigger proposal.

I don't necessarily "want" to work more, I think 15-20 hours is a sweet spot that I've liked for the past year for my work/life balance. I feel like it's only fair for stakeholders that I work more if the dhf pays me more in usd value. Also this comes at the right time as I'm spending far more than my usual 15-20 working to get rc delegation ready in time. (I would have worked those hours anyways to get it shipped in time but it feels good to not work for free)

> just a way of sending back the any funding above what is needed to complete the proposal, and doing so precisely at the times (higher HBD price) when stakeholders and HBD can most benefit from that funding going to @hbdstabilizer (or the equivalent).

While I agree I also feel like stakeholders benefit more in the long run from increased worker output (if that applies to the specific proposal) than from some extra money being used to buy hive and then locked.

> @blocktrades has elsewhere stated his views that the benefits of buying HIVE and channeling that into the DHF fund are too great at high HBD prices to forgo, but the script normalizes this a lot by sending back in those times when the price is higher.

Which is totally fair imho. I don't think the other approaches are wrong in any  way, and for a lot of proposals, it's the best one. But for some proposals that can "extend" to have more output like peakd, keychain or mine, we may get equal or greater value by getting more work done.

> I don't think most people will do this, and most proposals are grossly over priced even at $1 HBD.

If they don't feel like doing it they can just use good-karma's script though. There is no "one solution fits all" 

> Another idea is just have the DHF print the appropriate amount of HBD based on current price.

As I mentioned in some other comments this would require a second price feed for hbd which is kind of an aberration because it would mean that we agree that we failed to peg hbd for good. This is more about treating the symptoms (dhf paying too much) than the cause (hbd not pegged)

That idea has been discussed (hbdstabilizer but at the chain level) but it was too complex to execute on, and we think hf25's changes will fix the upward peg via the hive -> hbd conversion.