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 ?
There is no way to confirm/verify, "over-working when above and under-working when below the peg". And proposals are made with consideration that hbd will be $1 and costs were estimated accordingly. 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. Beside in script we can add threshold parameter for downside risk and stop returning HBD when it is 20% or 10% close to peg.
This is by far the best solution imo. 100% fair and extra hbd earns money for the dao.
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.
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$
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.
Neat !
you are right and we have 6 guys working in all 3 proposals combined, it is all or nothing in current state, but with this approach, there is some compromise on both sides and we can continue focusing development, improving, innovating.
Drops fill the ocean 😅 I hope DHF funds will serve chain at least 20+ years
Yeah that's totally fair, If it's "not funded or half goes to stabilizer" then 100% go to stabilizer
Haha the 10% inflation is a more reliable/ bigger source than 2 months of "above the peg" I think
Similar point that I made above. There is no guarantee that the market will absorb the 10% of inflation without just hurting the price. Maybe it will, maybe it won't. But when the market does give us a way to suck in some value on very favorable terms, we should take it. The amount here is pretty significant, I think we've pulled in several hundred thousand USD worth at this point, and still going. In a month or two it could be at least a million or two.
Fair point, I guess we'll have to see.
The hbdstabilizer yes because it's funding is 850 hbd per hour, but the "normal" proposals that are getting paid 10-20 hbd an hour don't have that big of an impact if half of it went to stabilizer instead of funding more development imho
Once again I would say we agree on these points.
i don't really see these at the same thing. If we wanted we could print a 100 billion HIVE into the DHF but that wouldn't necessarily mean there is a market for it. At some point we end up back where Steem was when Steemit was (arguably) dumping more than the market could absorb for their own funding and it was self-defeating in a way, because the more they sold, the more the price went down, hurting the funding.
I believe it is quite plausible that the 74 million will end up in much the same situation when we try to spend it (no guarantees ever when it comes to future market conditions of course). However, funds that come from taking HIVE off the market now seem less of a risk of flooding the market later. It's a bit like borrowing from the market (on very favorable terms given the prices today) rather than just selling what are effectively new coins in a way.
I guess my comment is going to be the same as the one to you above regarding the low impact of "regular" proposals on the hbdstabilizer in terms of contributions.
So this is where I argue that funding development is how we create that need from the market that can then absorb it, but I agree that it's definitely not a given and the hbdstabilizer is a much more straightforward and "safe" way (in the sense of how risky it is to have benefits compared to the funds) to bring benefits to hive.
I think we agree almost entirely.
This is the "correct" thing to do, in my opinion. Each proposal is just a small business really, they have funding, resources, and goals to achieve. When a small business receives additional funding they don't start thinking of how best to return it, they use it and they grow.
The fact that there is so much discussion and work around how best to return extra funds means that most people are thinking about this the wrong way (again, in my opinion). If funding increases and you have a proposal to do development work - use it to get more development work done. If you have a proposal to do marketing - do more marketing.
One of the most important jobs of the CEO of a business is capital allocation. Hive doesn't have a CEO, so we have to all work together to allocate the capital available in the DHF in the best possible manner to grow the platform, and returning it to sit in the fund unused doesn't seem like the best way to do that to me.
I would agree with you if that were true. But they're not "unused" they are doubling their value every day! (with HBD at $2)
In case you have not checked, the return proposal is receiving 0 because @hbdstabilizer is selling all HBD for hive.
However, I think each person with a proposal should decide what to do with the funds and every voter has the right to keep or remove his vote. There is no right or wrong here, just preferences.
Thanks !
Exactly, as my old boss told me when I asked him why we were spending so much and raising capital every year instead of having a longer runway "we don't want to leave any growth on the table, so we spend as much as possible to gain as much growth as possible"
The only caveat to this is some proposals don't adapt well to increased funding like hivesql who's purely infra costs (which don't adapt well to a 2x increase) and then there are people who may just not want to produce more work which is totally understandable imo.
To be fair it's not exactly "returning it" it's sending it to hbdstabilizer which makes a direct profit for the dhf. Which as some stakeholders argue, brings more value than any proposal. Because it's much more straightforward (double the value that you get from the dhf)
If proposals all have an About clause would that not solve the issue. If the proposal is based on 275 HBD equaling $2000.00 dollars a week, 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.
What do you mean ?
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.
The about clause was a conversion to dollar amount, example 100 HBD or the equivalent of $100.00 dollars in HBD.
Yeah it does nothing to fix the HBD peg I guess, but it would make it easier on people doing proposals to determine how many HBD a week they would need to meet their funding needs.
With the price sometimes rapid up and down of HBD, I guess it would be difficult to code something like that and to track it. One week 20 HBD needed the next 200 HBD needed.
Maybe a couple more months of the @hbdstabilize program will see a change.
Well assuming a working peg, people can just use 1$ = 1hbd.
I very much doubt it will last more than a few months, hf25 should quash the upward peg with the new hive -> hbd conversion change and we should be back at normal :)
Most proposal don't account for hours of work. Works in your case I suppose.
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.
Yes I think I'm along with keychain and peakd one of the only proposals that can work like this
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.
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.
My preference at this point will be to vote for proposals that use the @good-karma script (or equivalent). I don't really see it as "proposal costs 0", although it might happen to be that at a particular HBD price. It is more like 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).
@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.
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)
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.
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.
Yeah I don't think your approach is wrong either.
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.
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?
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 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.
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.
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 :)
The liquidity is always low on the internal dex .... thats why the token is volitile ... if we have a lot of orders (millions) around the 1$ it will be much more stable ... but we need incetives for people to put their fokens on bids ... having some incetives will do a lot ... thats how all the defi liquidity works ... if we can manage to give out incetives for orders like example in the range of 0.95 to 1.05 that will be great ... the conversions will just help in this direction
the internal dex is not the only place where you trade HBD though, the 24h volume is 2.1m on upbit, and any arbitrage opportunity on the internal market is already automated so the dex cannot go up unless the whole market follows it, and then you need to move a lot of liquidity (tens of thousands) to make it move.
The tough part is posts haven’t started paying out liquid hive yet like they were doing on Steem. I don’t know if that’s intentional and permanent but I know I’m glad to have HBD over 1$ since I’m constantly getting paid in it for posts. I think it would stabilize if that would change but I’m guessing there is a mathematical calculation coming into play with that, hive price below 1$? Don’t know but I and others can use the liquid hive even if it’s not more than what is supposed to be paid out. I’m powering up all mine, which I know a lot are just selling so it’s not like I’m looking to send hive off and cash out.
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.
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.
You offering no objectives to be held accountable against is now in favor of your overfunding. 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.
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.
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).I think we need a stable coin. How about a hive based frank pegged to the relatively stable CHF thats trading for USD 0.90 ! It could be used for other future economies build on hive as well? I know we are a specialised blockchain but have a number of potential use cases that haven't been explored yet? I'd love to see one with transaction fees that go to the dapps that use them?
Posted using Dapplr
We want a stable coin that is algorithmically pegged and not pegged by a collateral like theter / usdt. So that's why we are not using anything like this.
Tx fees going to dapps that uses them could be done via an L2 and custom tokens like hive engine :)
That makes so much sense. Thank you for clarifying this.
Tx fees at a stable HDB rate would also make more sense on L2 for dapps now?
Well any dapp is free from taking a txfee, it can be as simple as "if you send 1 hive, I will take 0.001 hive".
But imho there are more values with things like beneficiaries than inhibit your users with a txfee
It's not about what currency the HBD is pegged to, but the effectiveness of the peg. With the hbdstabilizer rapidly gaining in available capital - the ability to enforce the peg should gradually improve.
To get it fast and stable to 1$ we simple need the same mechanic from the stabilizer open in a pool, everyone can invest in.
So it would be staying at 1$. I have made a post about it.
At this point, we can simply use DAO again for development.
Everything else is trust base and it's uncool in a blockchain space :)
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.
Sure,
IMO we don't need it on-chain level. More a fund open for everyone. Because then it will become stable at 1$ + nice return for investors.
I don't think most people will do this, and most proposals are grossly over priced even at $1 HBD.
Another idea is just have the DHF print the appropriate amount of HBD based on current price.
If they don't feel like doing it they can just use good-karma's script though. There is no "one solution fits all"
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)
The internal market price can be used as a second price feed, but it isn't all that great because unless my market maker bot is running (which it wasn't until a month or so ago), the spread can be enormous, making the price quite ambiguous. It is also a small enough market that it could easily be manipulated, although the same sort of 3.5 day window would help prevent that.
I agree this isn't a good way to go.
That's a neat solution ! I didn't think of that, but yes has it's limitations.
I will share my point of view/ observations on this topic.
So, fellow Hivers, I would like to hear your point of view on my observations?
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.
'We' should stop voting folks that just dump rewards, imo.
Thanks for mentioning Ecency. 🙏 Learn more about Ecency, what our team is building follow @ecency!
Support Ecency, in our mission
Forgive and restore funding to the unvoted proposals and ask them to do more or return overpay to DHF from future payments (whichever fits better to their books and strategy) until HF25 hopefully mostly fixes the peg
Bagus sekali