Yes. Your block is on chain.
This is the process I go through when checking each block for my pool:
- Run leadership schedule for next epoch 1 day before epoch end so I know when my blocks are due.
- After each block should have been produced, check to see if pooltool.io has the block on chain. For your pool ID this would be this page:
Cardano PoolTool - The most comprehensive staking statistics for Cardano on the web.
If the block is not on-chain according to pooltool.io then you need to find out what went wrong:
- First look in your log files for the time your block was minted and make sure that it was actually minted. IE: TraceNodeIsLeader, TraceForgedBlock, TraceAddBlockEvent, TraceAdoptedBlock, etc.
- If you block was minted but is no longer on-chain then it may be because you lost a “fork battle”. So I look in my cncli database to check for that. Just modify the sqlite3 query I used to show all the blocks around the time of your slot. For your block we have been investigating this query is:
sqlite3 /var/lib/cardano/cncli.db '.headers on' '.mode column' "select id, block_number, slot_number, pool_id, substr(hash,1,8), substr(prev_hash,1,8), substr(block_vrf_0,1,8), orphaned from chain where slot_number between 94253310 and 94253359;"
Your cncli database should already store all this information. Although your logs from your journalctl --since command above showed that there could be a problem with cncli on your machine. Note the following error message in your logs:
cnode-cncli-ptsendtip[1648572]: 'POOL_ID' and/or 'POOL_TICKER' and/or 'PT_API_KEY' not set in cncli.sh
If cncli-sync is running properly on your machine then you should have an sqlite database you can directly query. Just modify my sqlite3 command above to direct it at the location of your own cncli database. Mine is at /var/lib/cardano/cncli.db but yours is probably in your user home directory somewhere if you have followed one of the more common guides (which I don’t agree with). The substr functions in the sqlite3 command just shorten the hash and VRF values for ease of viewing.
If your block has a 1 in the orphaned column then you need to understand why it was “orphaned”. Often it is orphaned because you lost a “fork battle”. This happens when the other pool’s competing block had a lower block VRF value. That is why my query includes information about each block’s VRF value. The VRF (Verifiable random function) value is used to settle “fork battles” which are equal in length. (If forks differ in length then longest chain wins.) Most forks in Cardano don’t get longer than a single block long before they are settled. The block(s) in the losing fork get “orphaned” which means they are dropped from the chain. Furthermore, those orphaned blocks are not rewarded for staking rewards. So if your block gets “orphaned” you don’t get any staking rewards for that block. Bummer!
See also: troublshooting why my block got orphaned.