One month os $HBD interest payments,; what does it tell us?

in #hbdlast month

In this post, that should be the first of three posts, I want to look at the whopping 20% APR that $HIVE boasts, and what that means concretely. In this post I am going to look at the month January of this year. I hope to do the same post with less context again for february, and then again for march to get an image seen over time.

Before we look into HBD interest payments on HIVE, we take a short look at the chart for HIVE on coingecko.

If we trust the graph on coingecko, HIVE ad an average market cap of 124 million USD over the mont of january. This number will become important later on when we look at what the current HBD APR means for inflation.

aiohivebot and virtual operations

I was really curious about HBD and its 20% APR, but I had no idea how it worked because for some silly reason, while I've been coding for HIVE since I few months after I joined the platform in 2017, virtual opps untill now never entered my view in any of my projects, at least not directly.

If you've been following my blog, I've started work on a new async python library for HIVE some time ago, partially to be able to write some bots for personal use and general benefit, and partial in order to be able to experiment and demonstrate my slow moving work on my CoinZdenze project, a project aiming to provide quantum resistance and least authority subkey management for Web-3.0 blockchains, including HIVE.

Untill the current release, aiohivebot still doesn't have support for virtual operations, but my uncommited code on my home PC does, its not production grade yet, so the below code will not work yet if you try it.

import asyncio
from aiohivebot import BaseBot

class MyBot(BaseBot):
    """Example of an aiohivebot python bot without real utility"""
    def __init__(self):
        super().__init__(82316952, use_virtual=True)

    async def interest_operation(self, body, timestamp):
        if body["interest"]["nai"] == "@@000000013":
            print(body["owner"] + ";" + body["interest"]["amount"] + ";" + timestamp.isoformat())

pncset = MyBot()
loop = asyncio.get_event_loop()
loop.run_until_complete(pncset.run())

Note the 'use_virtual=True' in the call to the super constructor. This enables some crude code for supporting vitrual operations, including the interest_ioeration that generates a tiny piece of CSV output here.

The output looks something like this:

mangowambo;99218;2024-01-01T00:12:33
justclickgorving;7244;2024-01-01T00:21:48
verdaguer;459;2024-01-01T00:55:54
python13;21954;2024-01-01T01:09:21
charcoalbuffet;1897;2024-01-01T01:09:33
yraimadiaz;1255;2024-01-01T01:20:39
hive-102879;285;2024-01-01T01:21:03
digi-me;8274;2024-01-01T01:21:03
ssiena;679;2024-01-01T01:33:03
abitcoinskeptic;3;2024-01-01T01:38:21
...

HIVE API node rate limiting?

There is a reason why I'm not making a single post now over three months of data. And a reason why I'm not pushing my use_virtual aiohivebot code yet. When I started running this little piece of code starting at January 1st, hoping to make one big CSV to do an analasys on, I started noticing hickups in my peakd experience. Peakd kept giving errors and prompting me to switch nodes. And keychain also started giving errors. But only when on my home IP.

It is quite likely that I triggered some type of API node rate limiting, so after getting most of January, I thought I had enough to to a first analysis of the output CSV, and I should investigate what it is I'm running into with my script right now.

The problem is likely related to multiple facts:

  • In non-life mode the aiohivebot load balancing isn't active
  • In non-life mode, aiohivebot , as @felixxx noted, should use get_blockrange rather than get_block
  • The account history API that we need to use to get virtual operations using get_ops_in_block is probably more likely to result in API node load, and thus may need rate limiting,
  • The API nodes might be using standard HTTP rate limiting headers. The aiohivebot code currently doesn't look at these, and even they don't, non-life mode should probably rate-limit itself.

Some January results.

For now, the script has run for all blocks of the month of january, resulting in a CSV file with 3321 lines linked to a total of 3284 HIVE accounts.

The total amount of interest payments on HBS in January 2024 has been 115,789.214 $HBD.

It is important to put this number against the 124 million USD market cap in the same month. Why? Because ultimately the 20% APR is funded through inflation. This comes down to 0,093% in 31 days, what is equivalent to 1.1% of HIVE inflation to fund 20% APR on HBD savings.

In an other post I'll write about my oppinion on this, but not on just one month of data, I need to analyze february and march as well to get a more structural view on the numbers.

But let's zoom in a bit on the data.

Of the 3321 interest payments in January:

fromtopaymentstotal amounttotal percentage
0116563690.3%
1109203,2232.8%
1010057919,74817%
1001,00014439,96834.5%
100010,0002132,17127.8%
10,000100,000120,30917.5%

20% APR: Not a fan, but need more data

I make it no secret that I think the 20% APR on HBD savings is not a good idea. The info from this post somewhat quentisizes it, but its only one month, the 1.1% anual inflation for January might not be representative.

I think $HBD is really valuable on this platform. I've contracted artists using $HBD, and recently the talented @marylucy did an amazing logo for the new business site and social media pressence of an important person in my life through such a sontract. I think having a stable coin through what comunity members can contract other community members makes $HBD an incredibly valuable asset to the community.

As savings though, $HBD is locked down as an investment rather than a coin that makes the community economy blossom. This makes the community utility of the coin less, as it leaves less $HBD to actively circulate in the community economy. I feel strongly that using $HBD as a means of payment for in-community contracting is what should be stimulated, not locking it down in savings, bleeding the main coin, the active community coin with something like 1.1% of additional inflation.

Most of the witnesses seem to think otherwise. Some witnesses like @abit, @anyx and @dpoll.witness have the APR set to 7% what seems reasonable, and @isnochys has it at as low as 0%, what I feel sends a clear signal worthy of reward (so ignore the dead price feed and aprove @isnochys's witness if you agree with my point of view on this subject), but most of the witnesses have it at 10% or higher, most top witnesses at the 20%. I really wish that more witnesses had the sense to set it to 7% or lower.

I know one month of data is not convincing in any way, and I may shift my own view if things turn out to be significantly less than that 1,1% anual inflation.

Sort:  

I use block_range and also alternate nodes, so it doesn't happen.
I can replay rather quickly that way... I'd share the code, but you won't like it as it isn't as heavily OO as yours :P

btw you can reward helpful comments by clicking 'vote' :P

aiohivebot isn't actually designed to run in non-life mode right now. It's designed to stream events from brand new blocks. For that, in life mode it will run 13 async tasks, one for every public API node, each doing a get_dynamic_global_properties to see if the node has any new blocks that have not and are not being processed yet, and then fetches exactly one block that is processed within its task, so the next block will likely be picked up by another node it's async task. Hence the load balancing in life mode. It also keeps track of errors and latency, so if from within the block handling other API calls are done, these will only be done to low error-rate low latency nodes. This strategy makes perfect sense in life mode, and it even works for non-life mode in terms of blocks only bots, but it doesn't really in non-life mode when I'm doing additional JSON-RPC calls (like get_ops_in_block), so I need to see how I can refactor it with the least complecity for combining both modes.

It would be cool if get_ops_in_block had a multi block too, so get_blockrange will only be part of the solution. I probably still need rate limiting when I enable virtual operations.

I have built something similar, I also checked out your bot (a while ago)... but I found it too abstract.
You probably know this, but you can get_global_properties and then (with connection still open) query the block (or the range). this results in faster times and you are less likely to be banned for too many queries within too small of an interval.
whether my bot is 1 block or 10000 blocks behind, it just uses the same function (block_range). so if for some reason, the thing isn't 'live' (yet) it just sleeps(3) and queries more.
hope that makes sense.
as for virtual ops... yeah those are kinda annoying, but for all my cases I don't need those (phew)

A little add on: live or not, block range is always superior imo.
If you query blocks out of range, nothing bad happens. you just need to count yourself, as for some stupid reason, the reply does not include the block_number.
for extra safety I use blockhash and 'previous' to serialize 100% failproof

The reason it makes sense to fetch one block at a time in aiohivebot is that I'm using async tasks, one for every public API node. So if one task is processing one block, and processing takes longer than it takes for the next block to arive, another task is going to pick up the next task even if the other task is still bussy.

since it's only 1 block every 3 secs, I don't need to use async for anything.
It complicates things, as different nodes sometimes are on a different head_block.
The call time for range is about the same as for single blocks, so I use the one call for all cases. (range = 0 queries a single block, just without the explicit block num in the reply, which I think is ridiculous)

Thank you for your witness vote!
Have a !BEER on me!
To Opt-Out of my witness beer program just comment STOP below


Hey @pibara, here is a little bit of BEER from @isnochys for you. Enjoy it!

Learn how to earn FREE BEER each day by staking your BEER.


Hey @pibara, here is a little bit of BEER from @isnochys for you. Enjoy it!

We love your support by voting @detlev.witness on HIVE .

Thank you for your witness vote!
Have a !BEER on me!
To Opt-Out of my witness beer program just comment STOP below

It's one of those things now I think; getting too entrenched, too much stake gaining from it at 20% for it to change easily. Too much resistance. Seems like it would be wise for it to go down though to encourage more use of HBD for trade like you say. I'm sure there's some people out there doing just that with their HBD interest earnings too, though maybe not that many.

Its interest rate within the bear market has helped people a lot and people have met their daily expenses with this profit so we will see that continue in the near future.