That's basically what I was suggesting with the other possibility, although you've explained it more depth: "a completely random increase by really bad speculators (relatively unlikely I think)"

Oh, sorry, I misread your question the first time I think. To answer your question, yes, the work to stabilize the value of HBD will also help stabilize the value of SWAP.HBD.

The unvoting is definitely a temporary measure. I will be revoting all the proposals I unvoted as soon as it makes sense.

I'm not aware of how SWAP.HBD is being used to stabilize HBD, but in practice I don't see how it could be done by that alone, because the only effective way to fight an HBD pump is to create more HBD supply,

For the near term, we're hoping to have a hardfork every 6 months, unless devs decide to tackle something big. You should probably check out these communities: Hive Improvement HiveDevs Although maybe

Here's a couple of posts by others that have helpful info about how the stabilizer functions:

The haircut mechanism was established to mitigate the risk of an excess amount of HBD created during a bull market resulting in severe dilution. Despite it's negative impacts, I think it serves that purpose

The hdbstalizer is doing exactly that (stopping that from happening to HBD). I just published a post that goes into that in more depth. As for the internal market issue, there are traders who arbitrage

There's nothing terribly wrong in theory with what you said, other than missing the sheer magnitude of the return ratio associated with the stabilizer right now. The returns from the stabilizer will let

Lol, you could do it at scale too: create a hundred coins, generatable from one coin, then profit from random pumps by senseless speculation on crypto markets. Almost afraid to publish this idea, since

You say that an account can have 3 slots, and it can receive RC from all 3 of these slots (i.e. a single account can get RC from multiple pools). In what order is RC consumed from these three

Here's a post written for SBD, but it also mostly applies to HBD: One thing that was added later, so it is not described in the article above, is that HBD is also created from Hive that is transferred

No, that's entirely wrong. The selling of hbd by the stabilizer can only drive the price downwards. And due to the nature of the funding for the stabilizer this is a constant pressure. It never pushes

The increase in HBD price isn't caused by the stabilizer. The stabilizer actively works against the pump: it doesn't buy any HBD, it only sells it. And it sells it on a continuing basis, as long as HBD

I'm hoping we can keep to HF every six month for the near term, but it'll depend a little on the scope of the specific HF. If there's something big, could take longer. We will scope out next HF after this

I expect it will be for a few days to a week or so. But if it goes too long, I can make temporary payouts, then create a proposal later to be reimbursed.

Please enlighten over the many things that have been tried over the last 4 years. Because I don't remember many at all. I'm pretty sure you can count them all on one hand. But let's see your list. From

I'm the primary stakeholder involved in the loss of funding for proposals right now. And I do place a high value on developers, as should be obvious from how many proposals I'm normally voting for. You're

All the economics argue against that scenario. The stabilizer actually acts to increase the price of Hive, via it's buying activity. Even in the worse case, where every proposal that was paying out and

I don't use hivesigner, and apparently dpoll doesn't support hive keychain, so I won't vote on the poll itself. But I believe it should be left at 13 weeks. It reduces the impact of voting from short term