Account creation token claims ARE much more expensive
Not true - they are exactly as expensive as on mainnet down to 5th digit. But there is a catch. RC costs on fakenet are influenced by situation on fakenet, and as close as it is to mainnet, there are still differences (after all it was made so people can try doing things they didn't do on mainnet).
curl --request POST --url https://api.fake.openhive.network/ --header 'Content-Type: application/json' --data '{"jsonrpc": "2.0", "method": "rc_api.get_resource_pool", "params": {}, "id": 1}'
Replace api.fake.openhive.network with api.hive.blog for values from mainnet.
When I'm writing this, resource_new_accounts pool on fakenet is 10729483 while it is 11952076 on mainnet. Since each token is 10000 units, it means that fakenet has 122 less tokens available. For the pool that is exhausted so much such difference in fill level means big difference in RC cost, and big relative difference in RC cost for the most expensive resource means huge difference in absolute value of that cost.
In conclusion, you can't really compare RC costs in this particular case. When comparing apples to apples, for your @brianoflondon account, the average cost of claim_account_operation changed from 9'372'413'894'817 with old rules to 9'372'452'227'838 with new rules (data collected from up to block 66.3M). It means that after claiming a token, now you need to wait 0.12s longer for RC mana to recover in full (new - old = 38'333'021; max mana of 136'853'962'413'867 - value from block 66.3M - means you recover that much over 5 days = 432000 seconds, meaning 316'791'579.66 every second).
Refer to this article for more details on how RC costs changed between old and new version and what are the factors that influence them.
Thanks for this, I can't say I'm finding it very easy to figure out what the RCs actually used for a transaction are or will be. Are these available after the fact for a given transaction?
Right now I'm making a kind of watcher that looks that the resource credits across a group of apps and hands them out if they need more.
There is no easy way to predict RC cost, but you can somewhat get to know what you've already paid. It is the easiest if you have your own node. Having your own node means you can write your own plugin or even add notifications/logs directly to the place that charges your account(s). It is also easy to differentiate between "present" (state from the blocks which can be treated as solid) and "future" (pending state). If you don't have your own node, then you can only use something like
rc_api.find_rc_accountsto monitor your accounts. However, if you wanted to use that to see exactly how much you've paid for each transaction, it gets tricky. Typically you only see the "future" when using API, so you'd need to make sure that "future" and "present" are the same, that is, first wait until your transaction gets into block usingtransaction_status_api.find_transaction, then look for your account's RC and compare it with what it had before transaction. The tricky part is that if you make another transaction in the meantime, you won't be able to tell the cost properly. Also if you are using some service that can f.e. vote in your name, then it can make you the RC payer, not just for your own vote, but for all the votes in the transaction it sent. In normal situation there is little difference between "present" and "future", but during high traffic "future" can be distorted, and in case of highly contested resources, like new account tokens, it can happen that you've claimed your token and "future" shows you've paid 9T RC, but before it becomes "present" some whale claimed 100 tokens and now your token costs 12T RC (it might even happen that you'll no longer be able to afford it and your transaction that was accepted as pending will never make it to the block - these are the dangers of looking into the "future").BTW can you point me in the direction of where the data for this panel comes from and how it is calculated? Especially the recharge rate.
I'm guessing here, but everything tells me that the values with
HPandMas units use the same procedure for recalculation. The value is calculated from raw RC using current price of VESTs.Calculating on raw RC values is simplier. Since your RC regenerates from 0 to 100% during 5 days, just take
max_manaand divide it by whatever period you want to calculate, that is, 5 for daily recharge rate, 120 for hourly recharge rate, 7200 for minute recharge rate etc. The result is going to be expressed in raw RC values as well. Only now you can treat it as amount of VESTs (which have 6 fractional digits) and using current price recalculate it to HP/M presented in the panel.