User Guide

Read the report as a distribution of blocks among reward addresses. It is not a ranking of identified miners.

Your first report

Open Report and check the acquisition time and freshness message.
Select an observation window. The selected button stays highlighted.
Move the Top N slider to compare the leading addresses' combined share of all eligible blocks.
Use Download full ranking (CSV) for every reward address in that window.

Use Tab to reach controls, Enter or Space to select buttons, and arrow keys to adjust the slider. The controls use the loaded snapshot; they do not query the blockchain.

Choose an observation window

7 DAYS, 30 DAYS, 90 DAYS: the selected number of complete UTC days, ending at the snapshot's complete-day cutoff. A day runs from 00:00:00 UTC to the next midnight. The start is included; the ending midnight is excluded.
ALL HISTORY: all archived non-genesis blocks through the latest checked archived tip, including that tip. This can include part of the acquisition day. It does not require the complete-day views' 1,024-successor margin; recent blocks may change.

If the blockchain is younger than the requested period, coverage starts at genesis instead. Genesis itself is not counted. This can make 30 DAYS and 90 DAYS identical: both may cover exactly the same available history. They will differ when their eligible populations differ.

An address can appear in All History but not 7 DAYS if none of its observed blocks fall in those seven complete UTC days. A block in the acquisition day's partial day may also appear only in All History.

Window & evidence shows the actual interval. Expand Advanced technical evidence to compare the requested and effective intervals and exact boundaries.

Read Top N and the ranking

Top N means the N reward addresses with the most eligible blocks. N starts at 5 and ranges from 1 to 20. Home selects 1, End selects 20; changing window retains N. The chart is capped at 20 for readability; the complete CSV has no Top 20 truncation.

Each eligible block contributes one count to its header reward address. Rows sort by block count descending, with equal counts ordered by the full address ascending. Full addresses are shown so they can be compared exactly.

Top N share = 100 × blocks assigned to the selected N addresses ÷ all eligible blocks in the window.

The denominator includes addresses outside the visible chart. Individual address percentages use that same denominator. Empty windows have no eligible-block percentage; windows with fewer than N addresses show only those available.

A high Top N share describes concentration by address. It does not establish miner ownership, controlling entities, actual hashrate distribution or network decentralization.

Download the complete ranking

Select a window on Report, then choose Download full ranking (CSV). It includes every distinct reward address found in the same verified reporting population as the dashboard, not every wallet on Zycord or every actual miner.

The columns are Rank, Reward Address, Block Count, Percentage. Open the UTF-8 CSV in standard spreadsheet software using comma-separated import if prompted. CSV percentages have six decimal places; the dashboard displays two. Both use the same exact counts and full denominator.

The filename identifies the window and immutable report version. The dashboard checks snapshot identity and SHA-256 before saving; an unavailable or inconsistent file produces an error. Verify & source supplies direct file links, checksums and provenance. Only the requested CSV is downloaded; changing windows alone downloads none.

Solo mining, pool mining and PPLNS

Solo mining

A miner works independently and may configure block production to use an address under their control. A block's reward may be attributed to that configured address, subject to protocol rules. An address in a header does not cryptographically prove the miner's or operator's real-world identity.

Pool mining

Multiple miners contribute computational work to a pool. A pool may produce blocks under a shared reward address and later pay participants at separate payout addresses. One reward address can therefore represent the work of many miners. Pool architectures and payment arrangements vary; this is not a claim that every pool works in the same way.

PPLNS is a payment method

Pay Per Last N Shares (PPLNS) is a reward-distribution method used by some pools. It allocates rewards according to accepted work in a recent share window, under that pool's rules. A share is a pool's record of submitted work; it is not necessarily a network block. PPLNS is not a synonym for all pool mining. Other payment schemes, such as Pay Per Share (PPS), exist. This share-window N is unrelated to ZBPO's Top N slider.

Reward address versus payout address

ZBPO's reward address is the address in Header.EmissionAddr, the header field used for the relevant emission/reward purpose. A pool participant's payout address is where that participant receives a payment; it may be a different address.

ZBPO does not trace subsequent payments, wallet balances or economic beneficiaries. A payout address receiving substantial funds need not appear in this ranking. Its transactions or pool information may still be publicly observable elsewhere; absence from ZBPO does not imply privacy or absence of mining activity.

Acquisition, updates and stale snapshots

This is a static report, not real-time monitoring. Acquired is when the source observation was obtained; generated is when its report was computed. Last acquisition in the banner uses that source observation time, shown to minute precision; exact seconds remain in Window & evidence. Next scheduled update is calculated in UTC from the published, verified GitLab schedule configuration. It means the planned start of the update pipeline, not report availability or a new acquisition at that instant: GitLab can start late, processing takes time, and checks or publication can fail.

The dashboard does not continuously poll the blockchain. The next scheduled time advances while the page remains open, without initiating an acquisition. An inactive, missing or unsupported schedule shows “unavailable”. The static configuration records its verification time; later schedule changes require a verified site publication and are not monitored live by the browser.

A failed or unlaunched update can leave the previous validated report visible. Production freshness expires at the acquisition date's complete-day cutoff plus two days. Fresh until is that policy deadline, not a guarantee of historical accuracy or a claim to match the live network tip.

STALE means the snapshot is no longer within its freshness interval. It remains a historical observation; expiry does not retroactively invalidate correctly measured counts. Historical evidence can still be reproduced after expiry.

Practical FAQ

Does one reward address mean one miner?

No. A pool may combine many miners under one address, while one operator may use several addresses. ZBPO does not identify them.

Why can't I find my mining pool payout address?

The pool may record a shared reward address in its blocks and pay you separately. ZBPO counts the header field, not all later payouts. See the generic pool example.

Does Top 5 represent the five largest miners?

It represents the five reward addresses with the most eligible blocks. Their share is not the share of five identified miners.

Why can 30 DAYS and 90 DAYS show the same results?

If both starts are clipped to genesis, both can cover the same complete-day history. This depends on the chain's age and the snapshot; it is not guaranteed.

What does “excluding genesis” mean?

The height-zero genesis block identifies the chain and remains in the evidence. It contributes no production count. Counting starts with eligible blocks above height zero.

Why are only 20 addresses shown when many more exist?

The visual chart is capped at 20 for readability. Every eligible block still contributes to its percentage denominator.

How do I download every observed reward address?

Select the window and use Download full ranking (CSV). It includes every reward address observed in that window, not every wallet or miner.

Why might an address appear in All History but not in 7 DAYS?

Its blocks may be older than the seven-day interval or only in the partial day included by All History.

How often is the report updated?

The banner shows the next planned start when a verified schedule is available. Reports publish only after successful checks. Read the acquisition and freshness information; the site is not a live feed.

Can ZBPO tell whether the Zycord network is decentralized?

No. Address concentration alone cannot establish independent miners, controlling entities, hashrate distribution or network decentralization.

Glossary

Block: A unit in the observed blockchain sequence. ZBPO uses its header for this report rather than analyzing all block contents.
Block header: Metadata identifying a block and its link to its parent. The supported Zycord header contains height, declared time and the emission address.
Block height: A block's position in the sequence: genesis is height zero, followed by heights one, two and so on.
Genesis block: The height-zero starting block. ZBPO keeps it as evidence but excludes it from production counts.
Genesis Anchor: The expected height-zero chain reference, including the verified genesis block identifier. It establishes the intended network identity, not full consensus validity.
Chain tip / archived tip: A sequence's latest block. ZBPO's latest checked archived tip is the last header in its validated observation, not necessarily the current live network tip. Tip inclusive means that last archived block is counted when eligible.
Reward / emission address: The exact address recorded in Header.EmissionAddr. ZBPO groups eligible blocks by this field; it does not infer miner identity or control.
Payout address: An address receiving a payment, such as a participant's pool payout. It need not be the address in the producing block's header.
Solo mining: Mining independently, with a configured block reward address, subject to protocol rules. The address does not prove a real-world identity.
Pool mining: Miners contributing work under a pool's arrangements. A shared header reward address and separate participant payouts are one possible arrangement.
PPLNS: Pay Per Last N Shares: a pool reward-distribution method based on a recent window of accepted shares. It is not all pool mining and its N is unrelated to Top N.
Observed header sequence: The contiguous headers ZBPO obtained and checked against designated peers and archived inputs. The checks are described in Methodology; this is not a claim of full independent consensus validation.
Snapshot: A fixed report and its exact input evidence, acquisition/generation instants, observation windows and provenance.
Requested interval: The nominal observation period a selected window asks to cover.
Effective interval: The covered interval after clipping the requested start to the available chain history.
Complete UTC day: A calendar day from 00:00:00 UTC up to, but not including, the next UTC midnight. UTC avoids local timezone and daylight-saving ambiguity.
Acquired: When ZBPO obtained the source observation, distinct from a header's declared time.
Generated: When ZBPO computed the report from the recorded observation.
Genesis prefix acquired: When the historical archive segment starting at genesis was retrieved, not when the blockchain was created.
Fresh until: The reporting-policy deadline for currentness; not a historical accuracy guarantee.
Fresh / stale: Within / beyond the snapshot's declared freshness interval. These labels concern currentness, not a new validation or invalidation of historical counts.
Canonical chain: The chain selected under a network's consensus and chain-selection rules. ZBPO reports an observed sequence agreed by its queried peers; it does not independently establish the canonical chain by full consensus or accumulated-work validation.
Reorganization / reorg: A change to previously observed chain history. Changed checked overlap or divergent peers stops publication for investigation; ZBPO does not silently choose a replacement fork.
SHA-256 checksum: A content digest used to compare exact bytes with recorded evidence. A matching checksum is not proof of consensus correctness or truthful header timestamps.
Independent reproduction: Rebuilding the report from pinned evidence and comparing exact outputs, including a structurally separate raw-offset/SQLite count reconstruction. It does not turn the underlying header observation into full consensus validation.

Exact mathematical and validation rules · Verify this snapshot

Background references for mining terminology

These explain general mining concepts, not ZBPO measurements or pool endorsements: Zycord's mining documentation, P2Pool's description of share-window payouts, and Braiins' description of a different pool payment scheme. They do not imply that Zycord pools use those projects' architectures.