What this report measures

Eligible blocks and addresses

R1.1 reads Header.EmissionAddr and groups its exact 32 address bytes. Each eligible non-genesis block contributes one count to that address. It does not group by a miner name, pool, payment recipient or wallet balance.

The height-zero genesis block remains in the evidence as the Genesis Anchor but contributes no production count. Historical coverage must be contiguous from genesis through the archived tip. Gaps, duplicates or changed checked history do not become eligible data silently.

Exact observation windows

For 7d, 30d and 90d, the complete-day cutoff is the acquisition date's UTC midnight. Requested start = cutoff minus the selected number of calendar days. Effective start = the later of requested start and genesis time. Selection uses declared header time in the interval [effective start, cutoff): start inclusive, cutoff exclusive.

Generation must remain on the same UTC date as acquisition. The archive must cover the required midnight; the release cannot fall back to an older cutoff. Complete-day windows require at least 1,024 successor headers after the last header strictly before the cutoff. This is an observational safety margin, not irreversible finality or a full consensus confirmation guarantee.

All History counts heights 1 through the latest checked archived tip, inclusive. It can include part of the acquisition day and has no successor-margin requirement. Its block total equals archived tip height; archived header count equals tip height plus one. Recent blocks may change.

A young chain clips long requested intervals to genesis. Two complete-day windows with the same effective interval have identical populations; this does not imply that 30d and 90d always match.

Counts, percentages and ordering

Address share = 100 × eligible blocks with that address ÷ all eligible blocks in the selected window.

Top N share = 100 × sum of the selected N address counts ÷ the same complete eligible block total.

All address counts sum to the complete population before any visual truncation. Rankings sort by count descending, then exact address ascending for ties. The canonical lowercase hexadecimal address encoding preserves this byte order. The dashboard displays at most 20 addresses, initially five; the CSV includes the entire ranking.

Dashboard percentages round to two decimal places. CSV percentages use exact integer counts and decimal half-even rounding to six decimal places. Rounding can prevent displayed percentages summing to exactly 100%. Empty windows contain no percentage-bearing rows, and the dashboard states there are no eligible blocks.

Declared times and observation times

Header.Time is miner-declared Unix seconds interpreted in UTC, not the instant ZBPO observed a block or an independently measured mining time. The pinned source's B37 rule requires strictly increasing header times. ZBPO checks that rule but does not thereby establish truthful wall-clock mining times.

Acquired records the source observation time; generated records computation time. Genesis prefix acquired records retrieval of the archived segment starting at genesis, not the blockchain's creation time.

Production freshness ends at the acquisition date's cutoff plus two days. It describes currentness rather than a historical accuracy guarantee. Expired reports remain reproducible. Reproduction uses the recorded generation instant and freshness policy, never today's clock as a replacement.

Five distinct evidence levels

1. Header parsing and structural checks

   The official-source adapter decodes the supported 260-byte layout. Checks cover admitted versions, fields, heights, timestamps and interval/overlap rules.

2. Block IDs and parent-link continuity

   The pinned official ID algorithm recomputes header IDs. Parent links, contiguous heights, the Genesis Anchor and exact archive partition hashes bind the recorded sequence. A SHA-256 file checksum checks bytes; it is distinct from a protocol block identifier.

3. Agreement between designated official peers

   Byte-for-byte header agreement, a common observed tip and checked overlap are required from the two queried official seeds. They may share ownership or operation. Matching them does not establish two independently controlled sources.

4. Independent report-count reconstruction

   A structurally separate raw-offset reader and SQLite aggregation reconstruct all four complete populations and rankings. Every CSV address and count, including rows beyond the Top 20, is compared with those raw-header results; percentages and endpoints are checked too.

5. Full independent consensus validation — not performed

   ZBPO does not establish RandomX proof-of-work validity, difficulty correctness, accumulated-work chain selection, transaction validity or state transitions. Levels 1–4 do not add up to this fifth level. The report is an observation of the queried sequence, not a fully consensus-verified canonical-chain claim.

A reorganization changes previously observed history. Divergent peers or changed checked overlap stop publication for investigation. ZBPO does not silently select a fork or fill missing history.

The reader admits legacy version 1 and the reviewed U1 version-bit form from mainnet height 77,760, preserving the 260-byte proof-of-work codec. Wider ramp or stake layouts stop collection for review. See the exact source's header version policy.

Provenance, complete CSVs and reproduction

Versioned manifests identify every raw partition, the historical genesis prefix and the exact report input state with byte sizes and SHA-256. The report records its source revision, generation instant, boundaries and totals. A separate CSV manifest binds all four complete files to that report's SHA-256 and immutable version.

The release checks independent counts before report publication, reads new Registry files back before committing the report, and deploys only a complete static artifact. Historical versions remain available in the Registry. Immutability relies on create-only client checks and serialized CI, not server enforcement against another authorized writer.

Reproduction regenerates byte-identical JSON, CSV manifest and complete CSVs, then runs the independent raw-header/SQLite comparison. Checksums protect comparison against recorded content; they are not consensus proofs.

Retrieve the exact evidence and reproduce it · Detailed report and CSV contracts