Architecture

Short-lived collection and verification jobs publish a static report. The browser reads the published snapshot; it does not collect blockchain data.

  1. Zycord P2P peersDesignated official peers provide bounded observations of headers and a common tip.
  2. GitLab CIRestore archived inputs, check overlap and source agreement, and validate header structure, IDs and continuity.
  3. Generic Package RegistryStore versioned, integrity-checked headers, manifests, reports and CSV evidence.
  4. Validated static report and CSVsCompute four observation windows and complete reward-address rankings; independently reconstruct counts and verify every CSV.
  5. GitLab PagesPublish validated JSON, HTML, JavaScript, CSS, documentation and the four complete CSV files.
Zycord P2P peers → GitLab CI → Generic Package Registry → validated static report and CSVs → GitLab Pages.

Collection and validation

Short-lived CI jobs retrieve headers from designated Zycord peers. They check header identity, contiguous links and heights, timestamps, prior overlap, source agreement and file integrity. These checks do not perform full independent consensus validation; see the five evidence levels.

Historical storage and aggregation

The Generic Package Registry keeps versioned raw evidence and manifests. The application restores the genesis-to-tip sequence and computes 7d, 30d, 90d and All History populations, address counts and complete rankings without sending the raw archive to the browser.

Compaction groups contiguous history into chunks of at most 15,000 headers (3.9 MB). Existing full content-addressed chunks can be reused. New chunks must pass decoding, checksums and readback; whole-archive byte equality and original baseline lineage must hold before committing a compacted state. Older states remain unchanged. Byte and partition bounds require capacity review as history grows.

Publication and downloads

All four CSVs and their manifest belong to the same immutable report version as data.json. Every address/count is independently checked against raw headers before publication. Registry readback and complete-artifact checks precede Pages deployment.

The dashboard fetches one report on load. Window and Top N controls operate locally; requesting a CSV fetches its pinned manifest and only that file, verifies identity and checksum, then saves it. This is a static snapshot system, not real-time monitoring.

Automation, failure and recovery

The active production schedule is configured for daily at 12:00 UTC, on protected main with its required schedule marker. Execution and publication remain conditional on GitLab availability, permissions, quotas and successful checks. Operations explains how maintainers verify actual schedule status.

One CI resource group serializes updates; time, network, storage and request budgets are bounded. Failed validation does not silently publish a new verified report. The prior validated report can remain visible and become stale under its explicit freshness policy. Divergent history stops for review; recovery uses exact prior evidence rather than inventing missing data or choosing a fork.

No continuously running personal VM, dedicated node, application server or database is required for R1.1. The architecture still depends on peers, GitLab, source availability, account permissions, finite quotas and maintainer attention. Native failure notifications complement visible staleness; they cannot prove that a schedule actually launched.

Maintainer runbook and recovery · Compaction · Inspect this report's evidence