Goal: Hive Dollar = one dollar worth of Hive
Hive dollars (HBD) rarely go very far below the value of a dollar for long, because HBD can normally be converted to the value of 1 USD worth of Hive in the space of 3 days. So if HBD starts to trade for less than a dollar, knowledgeable traders can buy up any HBD that is trading for less than a dollar and convert it profitably with a reasonable risk level.
Hive’s haircut rule: when there too much HBD, HBD < one dollar worth of Hive
There is a protective mechanism built-in to the blockchain rules called the haircut rule that breaks this lower side peg when the supply of HBD exceeds 10% of the marketcap of Hive itself, and in this case the value of HBD does tend drop below the value of one dollar.
But most of the larger holders of HBD are aware of this mechanism, and they will often start converting their HBD to Hive when the supply of HBD begins to approach the haircut ratio, reducing the supply of HBD so as to keep the HBD supply out of the haircut range. And the blockchain will also reduce and even stop printing HBD entirely once the haircut limit is reached. So the haircut rule mostly only becomes a problem when the price of Hive drops very rapidly and there’s simultaneously a large existing supply of HBD.
What about converting Hive to HBD?
So, the ability to convert HBD to one dollar worth of Hive enables HBD to maintain a value of about one dollar, without most people ever needing to do an actual conversion to Hive.
But there’s no corresponding mechanism for a user to convert one dollar worth of Hive to HBD, so there’s currently no built-in mechanism to prevent HBD price from going above one dollar. For example, at the time of this post, HBD is trading for around $1.20 USD.
If there was a safe mechanism for converting one dollar worth of Hive to HBD, then whenever HBD began to be traded for more than one dollar, Hive holders would be incentivized to convert their Hive to HBD, and then sell it for more than one dollar, use that to buy more Hive, and keep repeating the process until the price of HBD was forced down to one dollar.
Why propose this change now?
Note that this isn’t a particularly new idea: using a Hive → HBD conversion as a means of stabilizing the HBD peg has been discussed many times in the past.
There’s been two issues that have stopped it from being implemented: 1) concerns about potential unintended consequences of such a conversion mechanism and 2) some devs willing and available to invest effort into implementing a Hive to HBD conversion operation.
Over the past year, I’ve read several posts with proposed mechanisms for stabilizing the peg for Hive dollars. While many of them had good ideas, most mechanisms would require a lot of coding effort, and I believe that an implementation of a relatively safe form of Hive → HBD conversion is the simplest mechanism for stabilizing the peg.
I’m not even saying that some of the other proposals shouldn’t be implemented in the future, since some of the proposed ideas (such as using collateral to create HBD) could allow for more HBD to be safely created than is possible with a simple conversion mechanism. But as a first step, I think none of the proposed ideas matches the simplicity of a Hive to HBD conversion operation.
Proposed rules for HBD → Hive conversion operation
Similar to the current convert_hbd(hbd quantity) operation, I’m proposing a new operation:
convert_hive(hive quantity)
Pricing Hive → HBD conversions
This function would immediately convert the specified amount of Hive to HBD in the transacting account, using the following formula:
min(3 day price average, worst case price in last hour) + a 5% fee.
The motivation for this operation to maintain the HBD peg at around $1USD against price pump attempts. If the price of HBD begins to exceed $1.05 USD, it becomes profitable to convert Hive to HBD, and then sell the HBD for Hive on the market where HBD's price has exceeded $1.05 (assuming that the 3 day median price of Hive hasn't been dropping, but in practice we rarely see HBD price increasing while Hive price is actively dropping).
The 5% fee on this operation is to encourage the use of normal HBD market trading. Normal market trading is in fact needed by this mechanism, in order to have the price discovery it requires. So there needs to be an inherent bias towards use of the internal exchange built into Hive (or Hive markets on external exchanges) versus using the conversion operation.
The 3 day price average term is included in the pricing formula to prevent a whale trader from temporarily manipulating the price of Hive to get an unfair amount of HBD via the Hive conversion operation.
The worst case price in the last hour term is included in the price formula to prevent someone from benefiting from using the average price rather than the current price.
Preventing oversupply of HBD
To prevent a risky increase in HBD supply to the point where it could create a price death spiral, the proposed conversion operation would be programmed to fail whenever a user attempts to create an amount of HBD that would violate the global haircut limit. This means that users won’t be able to use this conversion operation whenever the haircut rule is in effect.
Looking for feedback
After evaluating our current workload, I believe we could implement and test the above mechanism in time to include it the upcoming hardfork (hardfork 25).
But first we need to establish if the majority of stakeholders support adding this mechanism and address any possible economic concerns related to the proposed implementation. So if you have an opinion on the subject, please make a comment below.
I think it's better to stick with the 3.5-days-in-the-future model that used for the existing HBD->HIVE conversion. This can be implemented using effectively the exact same code as the existing HBD->HIVE conversions, except at the end of the 3.5 day period, instead of dividing the quantity of HBD converted by the median price to calculate the quantity of HIVE delivered, multiply the quantity of HIVE converted by the median price to determine the amount of HBD delivered.
This prevents gaming after a big price change, as well as manipulation, since (setting aside manipulation) no one knows what the price is going to do over the next 3 days. The best estimate is simply the current price.
As proposed, there will be situations when the backward looking average higher than the current price. In fact, if it is >5% higher, then it will make sense to generate new HBD even when HBD is >$1.05. That's not desired.
The 3.5 day forward process like the converting HBD to HIVE, with the 5% spread, is pretty safe and sound IMO.
Also, I think the haircut threshold should be increased, but I guess that is a separate issue.
I added the worst case price in the last hour term in the formula to prevent just this issue.
Even that will fail if the price moves quickly before the hourly feed updates. Moving more than 5% within an hour is hardly unprecedented or even unusual. It's also simply not desired to create more HBD just because the price of HIVE happened to be different over a backward looking period, say from 1-2 days ago. If we had a feed of HBD, then indeed looking at an average price might be helpful, since this would indicate whether the peg had been held and if not, in which direction, but if basing it on the HIVE price, this sort of backward averaging makes no sense.
3.5 days in the future is just a more economically sound method, and the code to implement it already exists. The justification for it is the same in either direction.
I guess the issue is I was assuming that witnesses will publish any adverse price move during the last hour (including at the current time). In such as case, I don't believe it can be gamed.
If they aren't doing that (ie. if they were only posting on some time basis without publishing faster when there is price change of say more than a few percent), using the worst case price in an hour would fail (since we wouldn't really have the worst case price). However, I still don't see how it would be gamed if we are correctly getting the worst case price during the past hour. But if your argument is that we can't count on that happening, that's a different situation.
I think there's a tradeoff here: having the conversion take 3.5 days means it's won't be possible to stop short price rallys in HBD. But instant conversions do increase the possibility of gaming, if witnesses aren't able to provide fast enough price change data.
Another option is to compromise at some intermediate point, for example setting the conversion delay to something like a couple of hours, and keeping the worst case price check during the hour prior to the operation plus some additional small period of time after the conversion to ensure the current price would likely be included in the "worst price during hour" calculation. EDIT: after thinking about it, I guess we can't reasonably use any pricing after the operation is requested, because then that could potentially be used to attack converters.
The 3.5 day method has been proven pretty effective in handling price drops whenever we haven't been close to the haircut being hit.
I don't believe you need the conversion mechanism itself to handle every short term price swing, and if you do, then why are short term increases above the peg more important than decreases below the peg? Short term trading and market making can handle short term swings as long as there isn't a persistent imbalance.
Also, in proposing the 5% spread (which I agree with), you are implicitly designing this to NOT handle short term swings, but instead of address large persistent imbalances. In that case, 3.5 days should work just fine to get the supply moving in the right direction (even if not instantly), as it does on the down side.
Likewise the minimum function in your formula which will penalize (discourage) conversions if the price was lower in the past. This has to be seen as a longer term measure to adjust supply.
This would be a significant change in the existing practice for price feeds and would significantly increase the number of updates required (every time a new low is reached).
Also, no matter how often witnesses update, currently the median is only updates once per hour. That would either need to be changed, or you would need to use individual witness updates rather than the median, which increases vulnerability to deliberate or accidental bad feeds from a witness.
I wasn't aware that the median was only updated once per hour. I definitely don't think we should rely on one witness price. So maybe it is too difficult with the current price feed to reasonably get the worst price in the last hour.
I'm still a little worried about effectively fighting pumps though with a 3.5 day delay in the conversion time. I could easily see converters getting their HBD right about the time the price pump ends.
Maybe we could reduce the delay to something like 8 hours. It's probably sufficient to prevent price gaming, and it would still allow for effective deterrence of the typical price pump.
I don't think it's that big a problem. People who already hold HBD can sell it immediately and initiate a conversion to get it back (with an expected profit) in three days. If there were a lending market, you could even borrow HBD, sell it, and then use the conversion proceeds to pay back the loan (with some risk). If this happens regularly it makes holding even more HBD and waiting for such a pump to be more profitable, meaning more people will do it.
We could also just reduce the 3.5 days in both directions to say 24 hours, or even as you say 8 hours. It's basically the same argument that was made when reducing it from 7 days to 3.5 days: reduced defense against manipulation (which maybe is currently overkill still even at 3.5 days) in exchange for more responsiveness.
But we haven't really had a problem with HBD price dumps (that aren't so large as to involve the haircut) taking 3.5 days to correct. People are pretty willing to tie up capital and take a bit of price risk for 3.5 days. I don't think we necessarily need to go from having no HIVE->HBD conversion mechanism at all to assuming that a slow one won't work. It can only make matters better even if not perfect, and if it turns out not to be sufficient we can do more.
Also, this is undesirable if the HIVE price was lower in the past, but has risen say in the past day or so, which will regularly happen due to typical price fluctuations. It will discourage creating new HBD even if HBD is overvalued and more is needed, since the minimum will take the lower price, not the current price, and the converter is penalized.
Now in this case, is is clearly no worse than simply not having the function at all (which is where we are now) so in that sense it can't be seen as an objection to the proposal.
But I see see no gain to using this proposed method over inverting the existing conversion mechanism, which has proven to be quite effective (apart from situations where the haircut is hit, which of course is a different issue).
Everything you've said here I generally agree with, but I think you wrote this prior to my last comment, so just to note as per my last comment, the reason I favored this over the 3.5 day delay method is ability to respond quicker to a price pump. But there is definitely the tradeoff that you mention in your first paragraph with the worst-case price in last hour term.
Yeah, I think rather than wondering about different tradeoffs, we should just start with the inverted 3.5 day mechanism. That addresses the fundamental supply imbalance issue. If it then turns out we need something faster to provide more stabilization against short term moves than what people doing short term trading and market making provide, then we can add something else.
Let's start with the proven mechanism and see if it is enough. It think it might be.
(Yes I wrote the above before your last comment.)
Reverse Conversions. Hooray!
Very happy to see this idea finally getting a real chance of being implemented.
That's right @buggedout for the first time the path seems to be much clearer and thanks to the @blocktrades team will soon crystallize this option that from my perspective will make exchanges more attractive.
I think this is worth trying.
Will the fee get burned?
Effectively, yes: all the Hive that's getting converted is being burned, so more Hive is being burned than the equivalent amount of HBD that is being created.
I think it's a great idea and it's worth trying. But I do worry about the haircut rule. Like in steem days when steem dropped from +$7, the haircut was in place for a very long time.
Especially with introducing higher interest rates on HBD, the demand will rise and the price of HBD might go up but with the new HIVE to HBD conversion, people might convert HIVE to HBD and try to take profit but what if we can't keep the price under 1.05 with all the possible HIVE to HBD conversions and reach the haircut limit? I think we can maybe take HBD from DAO and convert it to HIVE but that's very limited.
TL;DR; the haircut is easy to reach and if that happens we don't have many options.
Yes, but once the haircut rule is reached, there's an additional reason why HBD value should drop: it's no longer pegged to at least one dollar worth of Hive.
Then peg fails downward and what can we do next?
This proposal isn't meant to address downward failure of peg, but that hasn't been much of problem, since HBD holders tend to increase conversions to Hive as haircut is approached.
But if the concern is that this mechanism would get us to the haircut ratio too quickly, another option I've thought of is to stop allowing conversions at some point before the haircut ratio even. I'm just not sure that it's necessary. I don't think it would be advantageous for a Hive->HBD converter to approach the haircut limit, because it increases the chance that the HBD they are creating for themself would lose value due to the haircut taking effect.
If it gets to the haircut ratio too quickly on a regular basis I think that just tells us we should increase the haircut ratio (within reason). This means there is more demand for HBD, which can be transmitted into demand for HIVE, and we shouldn't be arbitrarily capping that at 10%. This is the value of yield farmers in capitalizing a token. If it turns out that the demand mix is such that people want to invest in Hive more for yield than for speculative appreciation, we should let them.
Yes, I agree.
stop conversion before haircut ratio is reached,
stop conversion if result of 3 day average results in a loss for the trader (protecting noobs). Maybe start activation at 1.07$ for the last 3 days average.
Yeah, it's not very likely but I had worries about it mainly because of seeing under $1 SBD for too long. Thanks for the explanation.
As a side note, one way to prevent downward failure of the peg would be to implement an additional mechanism for creating HBD via Hive collateral. But that's a much more complicated mechanism, and I think it's better to make the simple change now, and see if anything more complicated is really needed later.
I would like to have the option to create HBD from HIVE as a collateral :)
The most important issue is not to allow an oversupply of HBD which can be terrible in a bear market.
I think we should find a way of lowering the haircut ratio in a bull market to limit HBD printing, and then elevate the ratio in a bear market to prevent the death spiral.
5% going down to 1% if hive goes above $10 this year for the haircut ratio.
30% haircut ratio when the price is low and consolidating in the bear market.
At $10 HIVE the marketcap would be around 4 Billion USD. That means a 1% haircut ratio will limit printing when the supply of HBD reaches 40 million HBD. This feels like a lot if we get another big crash.
If there is a way to limit HBD printing without using the haircut ratio that is fine too.
I like this idea but it may be complex enough that it would take a fair bit of time to implement.
I think it would be good if witnesses managed the haircut ratio in a way similar to other median-based feed values. However - I don't think witnesses taking an active role can be relied upon (SBD/HBD interest sat at 0 for far longer than it had any right to, due to disinterest).
The haircut ratio isn't really about limiting printing currently. Printing is actually limited before that point. The haircut ratio is really about trying to avoid a deathspiral. It's almost certainly set too conservatively at 10%, but I just don't want to mess with it in this HF.
I see. How do we limit printing then. Is it using the witness price feed?
If it is, I believe witnesses should consider what is the max supply of HBD we want to reach by estimating what will be the hive low in the next bear market. Obviously it's impossible to guess, but it's easy to take a guess being extremely conservative.
Then using that low, caluclate the hive marketcap, which should be able to support the HBD supply. Doesn't have to be 10 times larger, as you said.
Wouldn’t it be the easiest way to use the DHF. It anyway holds HBD and the Hive gets slowly converted to HBD.
When the DHF always sell HBD when its above 1.05$, it would be an additional income for the DHF and this goes vice versa when you always buy HBD below 0,95$.
One could define a minimum HBD stock to hold (and the mechanism would end there).
In the long run I would prefer a collateral system.
I agree with ya. I honestly haven’t been following much until past few weeks. I gotta get up on all this but from what I know u made a good point
I thinking doing anything with the DHF would require far more work.
As much as it would be awesome to have a stable on Hive, sometimes I wonder if all the energy spent over the years on trying to stabilize it, could be better spent.
I'm sure that's likely the case, that's why I'm proposing something very simple to do.
Out of my own naïve curiosity, is it possible to have a native DeFi platform that utilizes the savings wallet as an asset like Metamask? I think it would be valuable to offer a sink for liquid HIVE where it can earn, without trapping it into the 13 week PD cycle whilst still offering Hive features, including decentralization, security and feeless transactions.
Are you suggesting an interest bearing account for Hive (similar to what has been previously proposed for HBD)? It's certainly possible to implement, although it's non-trivial and would be a new source of inflation, of course.
But on a macroeconomic level, I'm not sure what the justification would be though, unless it's just a way to get Hive out of circulation in order to increase scarcity. Generally, I'm not in favor of such mechanisms.
At the moment, almost 2/3rds of the Hive is liquid, but even though it can't be used for much out there, it seems that powering up isn't attractive enough. I suspect that it is likely that a fair bit of it is being sold in order to get into the trading pools on eth and BSC etc, since the ROI is so high. Wouldn't it make sense to add capabilities for HIVE to be used, to give more reason for people to buy off exchanges?
I don't really know what the real interest level in such things are. Yield chasing definitely does seem to be a thing right now, but it's not something I'm keen to work on, I'd rather work on other things that I think can provide more real world utility. But I'm not opposed to having such functionality on the chain, if someone wants to implement it (it's probably not that hard to do).
Yeah, I understand that. I am hoping there are some more use case coming. It might be an interesting way to back SMTs in some way though. I think that the Leo Finance team might be working on something for it on CUB, but I think that it would be useful to have more native functionality and gateways.
You seem to be proposing an alternate staking period. Possibly useful, but seems a bit of diminishing returns. I mean 13 weeks isn't THAT long (6.5 weeks average). There was probably a better case for this when power up was two years. At this point let's say we had an alternate shorter staking of 1 or 2 weeks. Is that really enough value add relative to 6.5 weeks?
What I was thinking (in my limited head on these things) was more along the lines of a holding pool, that could have contracts placed upon it for a portion of the tokens, so they would be able to be used for staking purposes, whilst still being held behind owner keys in some way. kind of like an escrow?
I have no idea if this is useful or even possible.
I was also wondering if it could be used to stabilize HBD directly in some way using its value. But I can't get my head around that one.
Or, what if the savings wallet was used as a pseudo-stake wallet, that had voting capabilities with a three day powerdown, but it couldn't vote on governance and a portion of what it earned was burned?
It's perfectly reasonable but I'm still wondering whether the value add is enough to be making that kind of change. I'm just not sure that people need dial-a-staking-period to this degree. The 13 weeks (6.5 avg) isn't that bad unless you are completely a drive-by.
You'd think. But I am one of the fools that is powering up :)
The problem is that it is important to have compelling reasons to buy and hopefully stake Hive, in an environment where the 15%ish on curation isn't competitive. There are heaps of positives to being staked on Hive, but as you know, many people still act on maximization of wealth, regardless of whether they enjoy it or not.
After reading the whole discussion between smooth and you, I agree with him that mirroring the other convert operation is best, so 3.5 days which is then reduced if we feel like it at a later hard fork.
HIVE!D
I believe this will also keep the HBD from flying into crazy territories like the ol SBD is doing rn...
High regards!
Congratulations @blocktrades! You have completed the following achievement on the Hive blockchain and have been rewarded with new badge(s) :
Your next payout target is 1065000 HP.
The unit is Hive Power equivalent because your rewards can be split into HP and HBD
You can view your badges on your board and compare yourself to others in the Ranking
If you no longer want to receive notifications, reply to this comment with the word
STOPI think that is a good idea, the ability to go both ways in trading the two, I mean at least the option therein and let people make those choices freely.
Like @smooth said I think making the conversion roughly parallel to the HBD->HIVE conversion makes more sense. The last-hour worst case price overriding the median is open to manipulation. And in this post you mention 3 days and an average. Are you accurate with those terms or are we talking about a 3.5 day median already?
It's not really open to manipualtion except as a denial of service. Making the price lower just makes the conversions less attractive. But yes, someone looking to pump HBD for some reason (not sure why, but we could imagine it) might want to discourage conversions in this manner.
If someone with a large enough bankroll wanted more HBD for their HIVE conversion, they could conceivably make the market take a dip for a couple hours. Exploits like this should be avoided in consensus code.
Making the market dip means they would get less HBD. That's not a gain, but it could discourage others from initiating HIVE->HBD conversions. That's why I say it is only a denial of service (but that's not desirable either)
Ah, right. I was still thinking about HBD->HIVE conversions. It still doesn't make sense to allow the median to be overridden but it seems like Dan N has come around to that conclusion in a reply to you.
Not exactly: I think the median should absolutely be overridden in the case where it provides better than the current price: the whole point of that mechanism is to avoid gaming by the converter.
But practically speaking, it seems we don't have a price feed that can allow us to do that.
It sounds like an okay plan, but to include it in HF25 I feel is a bit risky at this time of growth in Hive. HF 25 has been about solidifying the foundation, and by not futzing with the economics over necessarily, presenting it as an economically sound platform.
I think this and other economic proposed changes are best reserved for HF 26. That of course is just an opinion from a non tech/finance type ordinary user.
This is one of those type of changes that we really can't judge the impacts of with certainty until we make it and release it into the real world. So practically speaking, I don't think there will be any change in the effect if we do it in this HF or the next, except for delaying its occurrence. The technical implementation is relatively straightforward (I don't think that will change if we add in some delay in the conversion time too, although I'll need to check on that part).
I just think as a person looking in from the outside, that HF 24 was foundation repair and fixing and had very little to do with the economics of Hive. It seems to me that all the other items and work for HF 25 were also sans any real economic changes.
I feel for changes to the economy on Hive that they should be contained in their own HF. For one year now Hive, while slightly slower in growth than some other tokens, has been a pretty steady slow rise. Is there any real dire reason to execute the change on HF 25? If not then lets make HF 26 all about the economy of Hive, and take the time to ensure there will be no issues with making an economy change interfere with some of the long waited social and foundation changes.
I guess I just saw to many HF approaching lets hurry and add this change in also scenarios over on steem, and well it was those mostly thrown in at the last minute changes that caused issues.
Way above my pay grade but I trust you, you awesome dude
3.5 days plus 5% fee? isnt that much? converting is quite a risky thing since the price can move in those 3.5 days and since everyone does it it usually means that suddenly a large supply of the other would appear on the market changing the price by demand supply. hence i dont always convert the moment it seems profitable
the median price is also moving much more now in hive since we dont have any sockpuppets giving wrong median price. back in steem it was much more profitable to convert.
having a hive to hbd conversion could lower inflation of hive, so it can be beneficial to hoddlers
The 3.5 days isn't so risky, because it cuts both ways: it can work to your advantage as well as to your disavantage. Savvy traders have long recognized this, and realize that on average they can rely on the mechanism working reasonable over time.
During the time before the launch of Hive, I'm not aware of anyone successfully manipulating the median price of SBD on Steem used for conversions. I have no idea about how the mechanism has fared since that time, as I don't really monitor it any more.
There haven't been any issues with the price feed since the fork either. Not sure what the other comment was talking about.
Do you think that this will incentivize the internal market toward market trading in general or less? There is really only one usable 3rd party market exchange of HBD for most people bittrex and it's liquidity is extremely low but traditionally hive internal market has been pretty bad for depth... though I admit I have not looked since the proposal from @smooth to see if it impacted that.
It's gotten better since the @hbdstabilizer started and I also restarted the my @teamsmooth-mm bot around the same time (both likely contributing to some degree). But it still is not great by any means if you want to make large trades.
I believe it will incentivize trading, because it will be easier for someone to obtain HBD to trade when someone is trying to pump the price of HBD beyond a dollar. Whether that happens on the internal exchange or on an external exchange will likely be determined by where the price pump is happening (generally in the past they've happened on external exchanges).
So my guess is it won't change the situation much for internal trading, except to the extent that it makes it easier for someone to create more HBD when the supply goes low, without having to wait till the reward mechanism creates more.
This idea was discussed more than a year ago, I'm in favor of this, although I doubt it will help the peg. Any coin or token traded on the exchanges is subject to pumps and dumps, and no matter what mechanisms we have, their response time is too slow to counteract the whales and momentum on the exchanges.
I like the idea. Sure I like more the collateral to create HBD :). For many reasons like "I want to buy a car" or something more expensive, it would more work as a currency. But I think you already know.
24h would be IMO better for conversion. Because of 5% I don't see something crazy happens. Maybe if HBD goes to 3$ or more.
Besides that, what if we build something like a Blackbox / return mechanic.
Send Hive to the Blackbox -----> auto conversion ----> get more hive back -----> send a return to the user. And the other way. It would generate some passive income streams and make HDB more stable. Like the DAO does. Hive to HDB to more Hive back to DAO.
Would be something like DEFI and I can imagine it should be doable.
It would be working the same as the proposal @smooth already does.
Would be maybe worth thinking about.
And after something expand to loans and collaterals on Blockchain level :)
Here's another method which addresses your concern about not getting the HBD right away and still prevents gaming or undesirable disincentives to convert by using a future price, by combining the conversion mechanism with a short term collateralized loan.
I'll describe it by example (for simplicity of description, the 5% fee is omitted here).
You request to convert 1000 HIVE. The most recent median price is 0.25. This is further divided by the overcollateralization ratio, say 2 (could be 3 or even higher without causing major problems, but I think 2 might be sufficient, especially if the window is reduced to 24 hours). You then receive 125 HBD immediately, as a loan. In addition, a request is made to convert your HIVE into 125 HBD, which will pay back the loan. At the end of the median window (currently 3.5 days, but maybe changed to 24 hours), let's say the median price is now 0.20. Your 125 HBD conversion requires 625 HIVE at that future price, which is kept by the blockchain and the remaining 375 HIVE collateral is returned to you.
There is some risk that if the price of HIVE falls by more than the collateralization ratio (below 0.125 in the above example with a collateralization ratio of 2), there won't be enough HIVE to repay the loan, and the blockchain could suffer a loss. However, I think short duration of the loan combined with the 5% fee is probably enough to make this an acceptable risk.
I like the idea, and it would work well in combination with a 24 hour delay. And, importantly, the mechanics still look fairly simple to implement.
After considering this a bit more, the initial price should use either your method of the minimum of the most recent and median price, or perhaps even better, the minimum of all the prices in the feed history (currently 3.5 days or 24 hours if this were changed).
While temporarily pumping the price doesn't affect the conversion rate in this model, it does reduce the collateral required, increasing the risk of the blockchain taking a loss (which would be a benefit to the converter), so we should defend against that. Using the minimum of the entire feed increases the collateral required when recent price volatility has been higher, which is probably desired.
The converter's "collateral price" in this case is already a 3.5 day median. So it's presumably a reasonable price, unless you're concerned about the price of Hive being persistently pumped over a 3.5 day interval.
At 2x collateral, the converter already has to deal with being exposed to a price 2x his "expected" price (i.e. the median price at the time of the transfer), so it kind of feels like enough risk to me.
And a minimum over a 3.5 day period, or even a 24 hour period could potentially be very low, especially if there was one malicious witness feeding a low price. A single witness could effectively negate use of the conversion mechanism in this case.
My proposal above was the use the most recent price. Using the 3.5 day median isn't great because it may be a lot higher than the current price at the time the conversion is initiated just due to market fluctuations, which may result in very low collateral, even without any manipulation. (This was the motivation for your use of minimum with a recent price; the same logic applies here.)
I meant minimum of the hourly medians, so any individual witness with a bad price would be filtered out. This is already the current mechanism in the code.
If the price has really risen a lot over 1-3.5 days (say 2-3x), then I would say there is enough volatility to be "suspicious" (not suspicious in the sense of manipulation, necessarily, just that it may not last), and not give credit for that new, higher price right away, in terms of collateral required.
Overall I'm not very concerned with requiring more collateral. Locking up HIVE for a short time (1-3.5 days) is a very small cost if there is direct profit to be made from the conversion itself (particularly if the profit is large). Arguably, giving people a reason to hold and lock up more HIVE could even be good, but that's not my primary motivation for suggesting a more conservative collateral calculation in this case.
With a 2x collateral requirement, the risk for too low collateral would require the 3.5 day price to be more than 2x the current price (and the likely price at the time of the conversion). But admittedly crypto prices can be quite volatile.
Ok, minimum of the hourly medians sounds more reasonable, since it shouldn't be subject to manipulation by a single price oracle. Since I've never reviewed this code, I didn't know these were calculated.
I'm still a little concerned about using a single data point over the entire period though, since flash crashes do happen. What about using the min (total period median price, most recent median price)?
Now, this doesn't protect against a trade performed right after the current price has dropped below that value, but neither does using the worst case during the period. There is a fundamental issue because we just don't have the current price to reason about due to the rate at which oracles are feeding in the price. So if we accept that limitation, the only way to mitigate it would be to further increase the collateral ratio (e.g 3x collateral).
Using the minimum of all the history of median prices provides the maximum degree of protection. The most recent median would be included in that history, so if that happened to be the lowest price, it would set the minimum and the collateral required. If another earlier price were lower, collateral required would be higher.
I'm not worried about this resulting in "too much collateral". Let's say the price doubles or even tripled. That multipled by an 2-3x overcollaterallization ratio would require collateral of 4x-9x. I don't see why people wouldn't post that for a short 1-3.5 day conversion period in order to make even a 1-2% profit, and certainly for a larger profit. The cost of posting collateral for a short time which you then get back just isn't that high. For ease of calculation let's say 1% profit, 10x collateral and 1 day of conversion delay. That's 0.1% per day profit on the posted collateral which is 36% per year not even compounded (compounded would be much higher). This is easily enough to motivate people to do it, and is somewhat of a worst case calculation.
You are correct since we don't know the real time price there is still a risk of undercollateralization. We need to set the overcollateralization ratio high enough to provide reasonable protection as you say, and also just accept some risk of loss in exchange for all the fees collected along the way (not necessarily just from that one conversion request; overall the fees may be quite profitable if overvaluation happens regularly).
Also
Not exactly. That would be the risk of the collateral being insufficient to cover the conversion from the start (obviously very bad), but you definitely want some extra collateral, not just barely enough to cover the conversion. The latter still gives the blockchain a good chance of a loss and the converter a good chance of a corresponding gain (if the HIVE price were to drop still more during the conversion process).
One interesting aspect to the delayed mechanism is it sort of gives a useful application for temporary lockup of Hive as per @tarakzp request: it's useful for Hive holders that want to make a profit by participating in support of the HBD peg.
Again, collateral as a staking opportunity isn't a new idea, BitShares had some of this same idea as well, although the implementation here is a bit different (and considerably simpler to implement from a blockchain and UI perspective).
I think this is probably a good idea but I was enjoying higher HBD prices. If this is one idea for stabilizing HBD, what is the method by which we get Hive over $1 ? If users are constantly selling HBD for HIVE it keeps the exchange low. What does HBD look like when it is the lesser value ($1) versus a $10 Hive for example? I saw that other proposal to burn HBD, does this account for those measure already being taken? Thank you for your time, I will support this proposal but I would like to understand the dynamic between HIVE:HBD. Is $1 HBD $100 HIVE an unreasonable hope? Or $1 HBD:$10 HIVE ? @blocktrades
There's no strong economic relationship that links the price of HBD and Hive right now.
There's actually a reasonable argument that if we can stabilize the peg for HBD, that Hive will gain in value, as the Hive network will have a new useful service: a trustless stablecoin.
Thank you for your response. May I read this proposal on my next @hivecoffee live stream, and discuss this response with the community? I am also going to talk about a hive.stats proposal, so I would be happy to discuss this one also.
Sure, feel free.
Hive already has mechanisms for returning HBD to $1 from below that price, and historically they have been more effective than the mechanism of bringing the price down to $1 from above.
Why not add the 5% fee for both conversions HIVE -> HBD and HBD -> HIVE and burn the fee?
Preventing oversupply of HBD is important because HBD is like debt and could cause a death spiral of HIVE price in a bear market as we have seen with SBD/STEEM conversions.
I support the idea of adding the conversion in the same 3.5 day manner in both directions HIVE <-> HBD.
The fee is effectively burned in all the proposed forms of the operation.
While it "might" make sense to add 5% to the normal conversion (HBD -> Hive), it would require more work/testing, and I don't think there's a pressing need for it. And HBD -> Hive conversion is kind of critical to holding of HBD, because traditionally exchanges have had much less liquidity for HBD than for Hive (hopefully we can change that, of course).
Ultimately I think the fee should apply on both sides. With the fee only on the high end, HBD will tend to trade in a range of $1-$1.05, which isn't really desired. Better with the same total fee would be for it to trade in a range of 0.975-1.025, which hopefully would tend toward stabilizing around $1 (vs. $1.025 with the 1-1.05 range).
I agree with your point that this isn't critical so we can ignore it for now in order to simplify implementation. If we end up with stability in a range of $1-1.05 that would be a short term great outcome we could then refine later.
And yet I would like to reintroduce a more complicated method of Hive to HBD conversion.
It would certainly require more coding efforts but in my opinion also provide more benefits.
First it requires the implementation of HBD staking in the same form as Hive power up we have now with the same benefits considering participation in the reward distribution process.
Then the Hive to staked HBD conversion should be implemented with no denial of service ever needed at that case.
The partial denial of service should be implemented only for unstaking HBD, meaning that instead of liquid HBD the corresponding amount of liquid Hive would be unstaked in case of haircut rule being active.
The only reason why I would go for a collateralized #Hbd is to add value to Hive.
Problem - how much Hive would we need to deposit in terms of overcollateralization? 100? 😂😆
Over a short period of time, I think 2x should be sufficient. And even occasional losses aren't really a problem, given the mechanism being proposed.
I have been watching the movements of the HBD all this time and what you say I have thought. It should be like that. Greetings!
I agree it is a problem when HBD drops too far below one USD, but it is also equally a problem when it rises too far above one dollar, such as when SBD went up to 5 dollars. I think you also need checks and balances to prevent the value from going too high, so that it is always within 10 cents of one dollar.
@blocktrades, let the market decides what the price of HBD is, in my view.
In my view, trying to regulate something/ peg something to fiat, etc. is simply an intervention against the principles of the free market that may damage the ecosystem.
Also, I would like to say that most of the people on the HIVE blockchain live outside the U.S. It means that most of us don't care about the value of the U.S. dollar. For me, it is not important what 1 HBD in U.S. dollar terms is. In my part of the world, we don't use USD and don't pay attention to it. That's why for me it will be irrelevant if HBD is pegged to 1 USD. Even, I will consider it as something negative. Also, I want to say that most of the HIVE-rs from my small city I communicate with either price their crypto in HIVE or BTC/ETH. That's why it would be much better if the price of HBD is backed/pegged to Bitcoin.
HBD was designed to be pegged to the dollar: it is supposed to be a stablecoin. And this has a very valuable purpose : a relatively stable price versus commodities makes it more suitable for commerce. And having a working stablecoin will make Hive itself more valuable.
If you're interested in price appreciation, you can hold Hive instead of HBD.
Here is a man from the citadel!
That it is pegged to the USD is mostly irrelevant. The main purpose, as @blocktrades noted in the other reply, is to maintain relatively stable purchasing power. For example, it is used by the DHF to set hourly payments for funded proposals which go on for an extended period of time. We don't want someone being paid to work for Hive to see their pay increase or decrease by 10x or even 100x just because the price changes. That's highly disruptive and damaging.
If, for some reason, USD itself were to go haywire and stop maintaining relatively stable purchasing power, we could decide to start pegging to something else like a different currency or a basket of commodities. Either way, the mechanism for having a stablecoin that maintains a peg still needs to work.
@blocktrades am I able to send steem over from steemit to convert to hive? I looked on your site, and I guess the answer is no.
Yes, we don't support Steem any more.
The problem with this is the boom bust scenario; in boom years it wont take a lot of Hive to convert into HBD. But we will be printing a huge amount of them (as the haircut wont be near its limit). Then all of a sudden the bear kicks in; you then have collapsing price of HIVE. The haircut is about to kick in but it comes too late; and now all those HBD that were printed at 1/10th of a hive at 10$ hive, are now being converted at 5 hive to 1 HBD (lets assume we drop back to 20 cents). This essentially creates a hive hyper inflation zone when all that HBD comes converting back to Hive (in the 10$ to 20 cent example below your minting 50 times the hive it took to create the HBD when you convert it back). So essentially you reduce inflation in boom years and multiply it out in bear years; meaning the Hive price whiplashes around. We saw this with steem.
The real question is why do we need a HBD? Why cant we just use cross chain (existing asset backed) stable coins via Hive Smart Chain or some other 2nd layer solution? To me HBD adds no value and poses an existential risk to Hive. And for what benefit ?
I think you've made too many assumptions about how HBD has affected the price of Hive (or SBD has affected the price of Steem). IMO the creation of SBD has had little real impact on the price of Steem at any given point in time (and the same of Hive and HBD). Further, I don't believe that HBD poses an existential risk to Hive in it's current form, or with the planned changes.
Crosschain solutions aren't great because they rely on trust. I've seen these go very badly wrong. Not saying they aren't better than nothing, but an onchain stable coin is much better, IMO.
HBD does provide a useful value even now, as a semi-stable coin that gets used for commerce, and it could supply a lot more as a stable coin (which would make it more suitable as a trading intermediary). With the right tuning, I think we can make HBD into possibly the first trustless stablecoin that works well.
Thanks for taking the time to respond. Do you have any verified data on steem inflation in 2018 after the crash and what % was SBD conversion related that we can review? I don't have access to any reliable data; but quick google found found the post below (which I have no affinity with and have not checked the data) and they imply that inflation in 4th quarter when things were at its worst was a massive 2.5 times the set inflation level due to multipliers on SBD conversions happening at lower steem price compared to when they were issued
Also most of the 'new' SBD induced inflation was dumped straight onto the markets not powered up (as people converted their stable coin); compared to the post reward inflation which is under haircut circumstances mostly illiquid (as SP). So you had massive increase in market supply of steem putting downward pressure on the steem price which in turn further increases inflation as the price goes down and the SBD conversion ratio goes up. Aka death spiral of extra supply dumping on markets, just when you don't need it and people race to convert before the haircut kicks in or gets worse. IMO this put steem into a magnified downward spiral well beyond what a lot of other cryptos experienced as people rush to convert their SBD and dump them before the haircut gets worse.
Hive/HBD has the same mechanics; so I expect the same to happen again. Allowing people to produce even more HBD just means a larger debt hangover when its converted; and negative feedback inflation boom just at peak of the main token price collapse will be much worse.
@buggedout always had a view on this ; not sure if he is still active.
Thanks for the shout out. I am active, just working a bit more in the background these days.
I'll have to have a good read of whats being proposed but I just don't have time just now.
I think your opinion would be valued here; but whenever you get the chance.
I was a long term investor in Steem. I saw no indications that it was the SBD conversions that caused the drop in price, when it dropped. IMO most crypto prices are driven by hype and FUD more than anything else, these tend to dominate over normal economic factors of the level created by SBD conversions.
Congratulations @blocktrades! You received a personal badge!
You can view your badges on your board and compare yourself to others in the Ranking
Check out the last post from @hivebuzz:
Que información tan importante, buen post, cada día aprendemos cosas nuevas
Congratulations @blocktrades! You received a personal badge!
You can view your badges on your board and compare yourself to others in the Ranking
Check out the last post from @hivebuzz:
Sure I like more the collateral to create HBD