Mining and payment totals

How far collection has got. ready means it reached the last checked chain tip. catching-up and recovering mean replay or reorg work is still running, stale means the last successful check is too old, and unavailable means collection failed. On disabled or loading the numbers are not evidence that the period was quiet.

Whether history survives a client restart.

When the last replay cycle started, in Unix milliseconds. Absent until the first check after a restart.

Last processed height, or the starting anchor if nothing has been collected yet.

The block id at sourceHeight.

Last checked chain height. Collection can lag behind it.

First retained height. Higher than sourceHeight means the history is empty.

Timestamp of the first retained block, in Unix milliseconds. Absent when there are no block records.

Exact sums and counts for the period, as decimal strings. A missing key means nothing was collected for it, which is not evidence that nothing happened outside the coverage. Amounts ending in NanoErg are nanoERG and LIT amounts are base units. New keys get added over time, so ignore ones you do not recognise.

Payout families hold outputs, grossNanoErg, rewardNanoErg, bondNanoErg, surplusNanoErg, rewardLit and receivedLit. Gross ERG is reward plus refunded bond plus any surplus. rewardLit is what the protocol owes; receivedLit is what the outputs actually carried. Network totals already contain the local ones — never add the two together.

Batching families hold orders, grossNanoErg, transactionFeeNanoErg and afterTransactionFeesNanoErg, counting recognised execution layouts only, not all pool activity. Gross is newly earned executor fees and excludes takings carried in from earlier. Liquidity-provider fees are a different thing and live on the DEX API. pool.batching pays no transaction fee, so it holds only orders and grossNanoErg. It and local.batching never count the same execution.

Rollup families hold count, miners, claimedScore, bondNanoErg and valueNanoErg, plus localCount, localValueNanoErg, localBondNanoErg and localClaimedScore where the local miner is identifiable — the submitting miner for submissions, the prover input for fraud proofs. So rollup.submission.localBondNanoErg is the bond this client posted, and rollup.fraudProof.localValueNanoErg is the slashed bonds it was paid for proving fraud. miners counts entries at that transition, not unique people. valueNanoErg means a different thing per kind: added holding value for a top-up, zero for a submission, the full box value at evaluation, the slashed bond for a fraud proof, and distributable ERG excluding bonds at payout readiness. These are stages of the same funds, so summing them is not income.

transaction.<kind> covers genesis, the rollup kinds above, payout, registration, ergodex, lithosdex, ergodexOtherPoolSpend and lithosdexOtherPoolSpend. Those fees overlap the block fee totals.

Priority fees. lithos.priorityFeeNanoErg / lithos.blocks is the mean fee across every Lithos block; divide by lithos.blocksWithPriorityFee instead for the mean across the blocks that carried one. The amount is the WHOLE fee the lender posted, not the share the block's finder keeps out of it. The pool's share went into the holding box and is already inside holding.genesisNanoErg, so there is deliberately no separate key for it.

Divide a sum by its matching count for an average. claimedScore is protocol accounting, not measured hashrate. A transaction fee is a transaction's cost and not automatically this client's expense, holding top-ups and executor fees can describe the same proceeds, and no key here is a net-income figure.