BlockScout coin balances view seem like a great way to track POA rewards coming into payout wallet. Is this view available via BlockScout’s JSON-RPC REST API or alternative a SQL / ES query to pull from AnyBlock? My understanding is that I need to query for internal transactions as these don’t show up as regular blockchain ledger txs.
Also, I see that sometimes instead of 1 POA / minute payout wallet gets 2 POA / 2 minutes. How is this possible?
Best, MM
You can get historical balances via our (Anyblock Analytics) ElasticSearch API like this:
{
"query": {
"bool": {
"filter": [
{
"term": {
"address.raw": "0xF977814e90dA44bFA03b6295A0616a897441aceC"
}
}
]
}
},
"sort": {
"timestamp": "desc"
},
"_source": ["timestamp", "blockHash", "blockNumber.num", "balance.eth", "balance.raw"],
"size": 1000
}
This covers all balance movements though. If you only want to look at the mining rewards, you should check the internal transactions / traces like this:
{
"query": {
"bool": {
"filter": [
{
"term": {
"type": "reward"
}
},
{
"nested": {
"path": "action",
"query": {
"bool": {
"filter": [
{
"term": {
"action.author.raw": "0x1985293823D122F11AbFbB82fB245e345A0AC60d"
}
}
]
}
}
}
}
]
}
},
"sort": {
"timestamp": "desc"
},
"_source": ["timestamp", "blockHash", "blockNumber", "action.value.raw", "action.value.num"],
"size": 10
}
@Micwebnet Such is possible if you see balance history of recent blocks. This view just shows the balance deltas between blocks in which balance has changed from the Blockscout DB. But new blocks processing is not ordered in Blockscout: first block processed -> first imported to DB. It means, that this is possible at some point of time when blocks #1 and #3 processed and #2 not yet processed. Thus, you will see coin balance delta between blocks #1 and #3. When block #2 will be processed, the view should change, as we can see for the same account, as you posted, missing blocks appeared in the coin balance history view:
BlockScout coin balances view seem like a great way to track POA rewards coming into payout wallet. Is this view available via BlockScout’s JSON-RPC REST API
There is no JSON-RPC API method in Blockscout which returns exactly such balance deltas in the response, but Blockscout provides eth_get_balance which hash absolutely the same interface, that is for eth_get_balance of Ethereum JSON RPC which returns the balance of address at any block:
curl -X GET "https://blockscout.com/poa/core/api?module=account&action=eth_get_balance&address=0xC57fE00C51aB00a4d6f270DEDbe5e7965dc6ADd5&block=16316421" -H "accept: application/json" {"jsonrpc":"2.0","result":"0xd9c2a908e4c249c00","id":0}
@viktorbaranov thanks for confirming this was an out-of-order block processing UX race condition and historical balance data wasn’t affected. Not sure if it makes sense to have UX process serialize on block ID to avoid this race condition, given underlying data layer isn’t offering sequential guarantee on processing completion, but at least maybe highlight that intra-blocks haven’t been processed yet when this happens?
@saschagoebel, thanks for the sample queries! I’ll be sure to play with ES some more. For now aggressive pre-filtering together with query folding made PostgreSQL a viable source for Power BI. My refresh times have reduced from hours to minutes, so I’m unblocked. 
I’m interested in all incoming POA coins, so need to track both reward emissions as well as tx/uncle fees. Looks like the latter are represented in trace table via trace_type=call so one table has them both! Is there a way to distinguish between tx vs. uncle fees?
Best, MM
@saschagoebel, so I’ve done some analytics, and seeing interesting results for pre-5,761,157 blocks. Back then POA used to transfer mined block rewards + tx/uncle fees every hour to payout wallet. I see quite a few 33.999979, which doesn’t makes sense since 34 POA were mined and the minimum should be 34. Any ideas why AnyBlocks SQL is returning a smaller number (I see the same when 35 POA were mined in an hour, shows up as 34.999979)? Would that be accounting for the gas to make the transfer?
Also any way to track tx/uncle fees separately for pre-5,761,157 blocks directly from the AnyBlock SQL DB, other than having to count and subtract block rewards for every hour?
Best, MM
Hi @Micwebnet,
regarding the 33.999 vs 34 transfers, I’d also guess that’s the gas being used already subtracted, but @igorbarinov can probably give a more confident answer 
As for the uncles … I’m not aware there are special fees that are delegated to the uncles. Ultimately an uncled block has no transactions, so there’s nothing to participate in.
Uncle rewards are tracked in the trace table as trace_type reward
SELECT *
FROM trace
WHERE trace_type = 'reward'
AND reward_type = 'block'
-- AND reward_type = 'uncle'
LIMIT 10
Hi @saschagoebel, I’m getting zero hits on reward_type = “uncle” in trace table. Can you show an example of what you are seeing for it?
I do see:
This matches the initial reward to mining address with 1h transfers, followed by direct on-chain reward to payout address starting from block 5761157. I always thought uncle rewards + tx fees validator income were both captured in the trace_type = “call”. Post-5761157 it’s all they are, but pre-5761157 it includes block rewards, minus the tx gas fee. Shouldn’t this have actual gas paid for the call (value transfer)?
In the trace table, gas=gas_used=0 for trace_type = “call”.
Here are examples (value column adjusted by 1 buterin for readability)
Best, MM
Hi Michael,
sorry, I was testing this on mainet. POA runs on AuRa which assigns the validators round-robin, so there are no uncles at all.
As POA Core doesn’t have that many transactions, blocks can be empty and have therefore no gas cost.
Also, AuRa sometimes sends transactions to report benign validators. These transactions are send from the validator itself and should therefore be free.
Anyhow, if you want to do analytics on gas usage, you should look at the transaction table, as the traces reflect only small parts of the complete transaction.
Cheers!
