For those of you who haven't seen the project before, HeyStack is a Hive-orientated crypto portfolio tracker. I created it for the STEMGeeks Hackathon last year.
You can use it to look at all your Hive data. And do pretty charts! Or you can track your whole crypto portfolio by combining this Hive data with imported exchange data.
As a quick example of the Hive side of things, since a picture is worth a thousand words, here are some charts for the @leofinance account:
- the account's monthly author and curation rewards since the launch of Hive (both in USD):
Note that these are only the level 1 Hive/HBD/HP rewards - not those from Leo tokens!
- the @leofinance daily account balances over time (coin amounts on the upper chart, USD on the lower chart):
To the moon!
HF25 updates
There was a hard fork. So the new transactions types needed to be added. And other things broke.
An example of broken things
Heystack uses the account_history API to obtain the past financial transactions for an account. These transactions are stored on the user's computer. They can then can be rolled-up into account balances, organised into charts, or exported into spreadsheets.
For Hive (but not for Steem) the transaction types to be obtained can be filtered as part of the account_history API call. For example it isn't necessary to obtain vote transactions or even posts and comments to reproduce the account balances. Author and curation reward operations provide the relevant financial data.
This filtering relies on a list of Hive transaction types, in order. The positions of the desired transaction types in the list are aggregated into two parameters for the account_history call. These parameters produce the filtering.
HF25 introduced a number of new blockchain transaction types. So the list changed. And so all the wrong transactions were being pulled. Still, easy to fix once I'd worked out what was wrong!
For info, these are the financial transactions HeyStack now uses:
Transactions:
'transfer', // 3
'transfer_to_vesting', // 4
'account_create', // 10
'claim_account', // 23
'claim_reward_balance', // 40
'account_create_with_delegation', // 42
'create_proposal', // 45
'collateralized_convert', // 49
Virtual operations:
'fill_convert_request', // 51
'author_reward', // 52
'curation_reward', // 53
'interest', // 56
'fill_vesting_withdraw', // 57
'fill_order', // 58
'comment_benefactor_reward', // 64
'producer_reward', // 65
'proposal_pay', // 67
'fill_collateralized_convert_request', // 82
'fill_recurrent_transfer', // 84
New transaction type: Recurrent transfers
Recurrent transfers were introduced as part of HF25. There are a few new transaction types related to these transfers:
- recurrent_transfer: which is the creation of the stream of transfers,
- fill_recurrent_transfer: which is a virtual operation produced when an individual transfer of the stream of payments is made, and
- failed_recurrent_transfer: for when you are broke.
HeyStack only needs to handle the second of these transaction types. The first has more detail of what will happen in the future but an account roll-up only needs to know the transfers that have actually taken place.
In theory this should have been very similar to handling the existing transfer transaction. In practice, although the data required is almost exactly the same, the format of the transaction is different, with the amounts using the nai code rather than saying HIVE or HBD.
I assume the new format is what we're moving towards?
Anyway, an example. The recurrent transfers made by an account, in Hive and USD. There are a couple of overlapping payment series here.
Looks good.
New transaction type: Collateralized conversion
All the rage these days! And an absolute pain to handle!
Collateralized conversions from Hive to HBD were also introduced as part of HF25. There are two transaction types that need to be handled:
- collateralized_convert, and
- fill_collateralized_convert_request.
The former initiates the conversion and looks like this:
The latter completes the conversion three days later and looks like this:
Anyone who has undertaken a collateralized convert operation will know that the HBD is received immediately. And they will also realise that this amount is missing from the first transaction.
Fortunately there is an API to list all outstanding collateralized conversion requests and this can be used to plug the missing data on a temporary basis until the 3.5 days have passed.
It's a bit clunky. Adding the HBD amount to the first transaction would be helpful!
An example: Collateralized convertions made by the @mika account, in Hive/HBD (upper) and USD (lower).
There's a cool million being flipped around here. I assume they are making lots of money. Maybe I will work out how much at some point.
Implementation
The work is done and tested. I just need to tidy it and then work out the commits to add to github (my own local version has lots of things bolted on).
Should be done in a couple of days!
Support my projects!
That's it for today! My project is free and open-source. If you like it, please upvote to support it!