HBD stabilizer algorithm

in #hbd3 years ago (edited)

Although the code is not open source, I have made the exact algorithm used by the stabilizer open source as pseudocode here: https://github.com/iamsmooth/hbdstabilizer

My intent is to update the pseudocode any time the algorithm changes.

Contributions of improvements to the algorithm are welcome, but will be accepted only if I decide to implement them in the running code.

Contributions of working code that implements the documented algorithm are also welcome, although in this case, if you don't continue to maintain and submit updates to the code as the algorithm changes, the code will be archived.

100% beneficiary to @hbdstabilizer

Sort:  

Thanks for sharing the code. This probably doesn't matter since a 30s cycle is short, but the top-level chain of if-else-ifs look like they should be independent ifs rather than an else-if chain.

As implemented there's a lol-attack here where a malicious actor could spam post every >30s, set the stabilzer_account as beneficiary and upvote their spam posts. After a week, the pseudocode above then gets into a loop claiming rewards instead of later actions (stabilising the price). The counter-measures are simple too: either make the else-if chain into independent ifs, or identify the spam accounts and downvote their posts to zero just before payout.

Also, with an else-if chain the exchange price fetch is wasted resources if a reward claim occurs first.

The else-if chain does introduce a bit more randomness in the timing of market actions, but if this was going to be exploited by a market bot then the amount of randomness is probably not significant enough to matter. IE.. after each stabilizer_account market action, assume there's 30s to get in whatever the other bot wants to do.

If API node traffic is a concern, then using a finer timer and a step counter with each if clause checked on a different step might be a reasonable solution.

Assuming that API calls are not realtime and are synchronous (at least how the code is written) the cycle isn't going to be 30s. But, I'm aware you know that already and probably it isn't a big enough issue to make the code more complex to fix.

Good feedback. I'll incorporate some of these suggestions in the next update.

The else if chain is intentional, to throttle work done per interval.

The minimum thresholds on things like claims are intended to reduce lol attacks. Someone could do that, but they would have to incur a significant cost each time or it would be ignored (until aggregate threshold is reached).

Correct, I don't care about the exact interval, in fact it should probably be made random. It's just to throttle workload, and also avoid a tight loop in some odd situation where progress isn't made (but 1s would be okay for that too).

I would like suggest a small change/correction to make the algorithm even better.

Change this line:
dao_account = “hive.fund”
To:
dao_account = “geekgirl”

And it should work flawlessly.

Nice posting. Like it

Good morning a beautiful day @smooth nice posting like it

why stabilise something that puts a demand strain onto Hive?

It only puts a demand strain on hive when the price of HBD goes below one dollar. The defective part of HBD is that when the opposite occurs there is no mechanism in the other direction to offset the negative effects.

The way this proposal is setup effectively creates demand for Hive on the internal market and also opportunities for savy traders to arbitrage the price of HBD between the internal market and the exchanges (when it is overvalued).

In order for traders to profit Hive will need to be purshased on the exchanges and then traded for cheap HBD on the internal market. Since the hive obtained by the hbd stabilizer account is sent immediately back to the DAO the cost for the stakeholders is practically zero with the added benefit that it reduces the supply of Hive on the market.

Algorithm is nice as it makes things more real and engaging, thanks for sharing such idea and code

Excellent work!!!!