🇯🇵 日本語版は準備中。 EN version below is the source-of-truth until the JA translation pass is reviewed.

Methodology

This document describes exactly what data the Cardano Delegation Observatory collects, how the values shown on the site are computed, what is deliberately not included, and how anyone can reproduce the published results from public data.

This page is the legitimacy core of the project. Every operational decision is documented here. If you find an inconsistency between this page and what the site shows, this page is the authoritative description; please open an issue.

1. What this site does

The Cardano Delegation Observatory takes a daily snapshot of voting weight delegated to active Cardano DReps and publishes:

• The 30 DReps with the highest current voting weight.
• For each, the current voting weight in ADA, 7-day and 30-day change, delegator count, last vote epoch, and 90-day voting weight history.
• Governance action submissions as time-anchored overlay markers on the historical chart.

All data is derived from the Cardano blockchain via the Koios API. No private data sources are used.

2. What this site does not do

The site does not compute or display:

• Trust scores or composite ratings of any kind.
• Alignment scores between stated positions and votes.
• "Good DRep" / "bad DRep" classifications.
• Predictions of voting behavior, delegation flow, or election outcomes.
• Real names of DReps unless those names are provided by the DRep themselves in their on-chain metadata.
• Wallet-level information about delegators (no whale identification, no clustering, no deanonymization, no inference of identity).
• Alerts, push notifications, RSS-of-changes, or any form of real-time feed.
• User comments, ratings, tags, or any form of social layer.
• Featured, highlighted, recommended, or curated DReps.
• Concentration warnings, framing language, or any other text that implies a value judgment about an individual DRep.

If a future version of the site is considered for any of these, this document and the project's changelog (§11) will be updated before the feature is shipped, and a comment period will be provided.

3. Data sources

Primary: Koios API — a community-run REST interface over Cardano db-sync. Free tier is sufficient for the daily snapshot pattern this site uses.

Endpoints used (reproducible from the source at etl/snapshot.py):

• GET /tip — current epoch and block height for run metadata.
• GET /drep_list — registered DReps, paginated.
• POST /drep_info — registration status, voting weight, metadata URL+hash (batched, ≤50 IDs per call).
• GET /drep_delegators (Content-Range header) — delegator count per DRep, fetched only for top-60 candidates.
• POST /drep_metadata — Koios-parsed metadata content with is_valid flag.
• GET /proposal_list — governance actions (paginated).
• GET /vote_list — every recorded vote (paginated), filtered to voter_role == 'DRep'.

DRep metadata content is consumed via Koios's drep_metadata endpoint and its is_valid flag; see §8 for the full handling chain and the v0.2 plan for independent fetch + verification.

4. Update cadence

The observatory has two cadences. The daily layer is canonical for everything reported as "Data through {date}"; the live telemetry layer (described in §14) is supplemental and refreshes more often but writes a narrower set of data.

The daily ETL runs once a day at 02:00 UTC.

Each daily run captures live DRep state at the moment of the run. The site displays the daily snapshot under the label "Data through {YYYY-MM-DD}". Daily updates happen at most once per day, so lag from any on-chain event to its appearance in the daily layer is at most approximately 24 hours.

If the daily ETL run fails, the prior daily snapshot remains displayed unchanged. No partial or potentially inconsistent daily data is ever published. The site's "Last successful update" timestamp signals staleness if the daily data is older than 36 hours.

The live telemetry layer runs every 10 minutes via a separate cron entry; its cadence, scope, and limitations are defined in §14.

5. Selection criteria

The 30 DReps shown on the main page are selected by:

• Active registration status — Koios drep_info.active = true for the current epoch. This excludes DReps whose registration has expired or been deregistered.
• Exclusion of default-delegation targets — the special identifiers drep_always_abstain and drep_always_no_confidence are never displayed. These are protocol-level default delegation options, not individual DReps; including them would dominate the ranking and mislead readers.
• Voting weight, descending, computed from the most recent daily snapshot. The voting weight value is the amount field from Koios drep_info, in lovelace, displayed as ADA (lovelace ÷ 1,000,000).
• Ties broken by drep_id ascending, deterministic across runs.

This selection is fully deterministic and reproducible from public data. There is no manual curation, no featured selection, and no operator-influenced ranking. The ranking criteria above are the only criteria; changes to them will be documented in §11 with rationale.

6. Fields displayed per DRep

• DRep ID — the bech32 drep1... identifier from the on-chain registration certificate.
• Name — the value of the givenName field in the DRep's on-chain metadata, if present and verified. If the metadata fails hash verification, contains no givenName field, or no metadata URL was registered, this field is empty.
• Voting weight (ADA) — the most recent daily snapshot of the DRep's total delegated voting power, in ADA.
• Δ 7d — voting weight today minus voting weight 7 daily snapshots ago, in ADA. Signed; no color coding.
• Δ 30d — voting weight today minus voting weight 30 daily snapshots ago, in ADA. Signed; no color coding.
• Delegators — count of distinct stake credentials currently delegated to this DRep.
• Last vote (epoch) — the most recent epoch in which the DRep cast a recorded vote on any governance action. When a DRep has revoted on the same proposal, only the chronologically latest vote is stored (DReps may change their vote on an open proposal; the latest cast vote is the one that counts at tally time).
• 90-day chart (per-DRep expand) — the daily series of voting weight for the last 90 snapshots, with epoch boundaries shown as light vertical markers and governance action submission dates shown as labeled vertical markers.

7. Fields not displayed

This list is exhaustive for v0.1. Any addition requires a §11 changelog entry written before the change ships:

• Off-chain identity not provided by the DRep.
• Delegator wallet addresses, balances, or any per-delegator detail.
• Inferred relationships between DReps, between delegators, or between DReps and delegators.
• Inferred motivations for any delegation movement.
• Any composite score, percentile rank, badge, tier, or rating.
• Any "highlights," "alerts," or "of note" framing.

8. Metadata handling

DRep metadata URLs may return arbitrary content. In v0.1, metadata content is consumed via the Koios drep_metadata endpoint, which fetches the off-chain JSON, hashes it, and applies CIP-100/CIP-119 validation. The observatory uses Koios's is_valid flag as the validation gate.

• Validation gate — metadata flagged is_valid = false by Koios is ignored entirely. No name is extracted; the DRep entry shows the bech32 DRep ID only.
• No HTML rendering — only the givenName field is read from the parsed JSON. No raw metadata content is ever rendered as HTML on the site.
• Sanitization — extracted givenName is treated as plain text: control characters are stripped, the value is truncated to 200 characters, and the result is displayed only if non-empty after stripping.
• No fallback identification — if metadata is missing, invalid, or contains no givenName, the entry shows the bech32 DRep ID only. No alternative naming source is consulted.

In v0.2, the observatory may move to fetching metadata directly from the on-chain URL with independent SHA-256 verification, removing Koios from the trust path for metadata content. This is a v0.2 candidate, not a v0.1 commitment.

9. Right of reply

A DRep who wants to add context to their entry on this site should update their on-chain metadata. The observatory fetches the latest metadata each day and the new content will appear on the next snapshot.

There is no operator-mediated channel for adding text, links, badges, or commentary to any DRep's entry. This is deliberate: the moment the operator can edit per-DRep content, the site has an editorial dimension.

If a DRep believes a published number is computationally incorrect, please open an issue on the GitHub repository with the snapshot date, the field in question, and the value you expect. Computational corrections will be made publicly, with the changelog noting the affected dates.

10. Operator

This observatory is operated by cryptoleo79, an independent Cardano stake pool operator and DRep.

Conflicts of interest disclosure:

• The operator is a registered DRep. The operator's DRep entry, if it appears in the top 30 by voting weight, is shown in the data with no special treatment, no exclusion, and no editorial flag.
• The operator runs a Cardano stake pool. Stake pool data is not displayed on this site; this observatory is concerned only with DReps and delegation to DReps.
• The operator authored the Connected Treasury Framework. That project advocates for treasury yield distribution that includes performance-gated DRep participation incentives. The observatory does not promote, link to, or favor the CTF proposal in its data presentation.

The source code, deployment configuration, and data schema are all public in the GitHub repository under Apache 2.0. The published data is CC0. Anyone can independently reproduce all results from the cited public endpoints.

11. Changelog

For the canonical record, see METHODOLOGY.md in the repository. The summary below is mirrored from there:

13. Pages and public exports

The observatory comprises four pages:

• Observatory (/) — top-30 DReps by current voting weight, with Δ7d, Δ30d, delegator count, last vote epoch. Daily snapshot. Click any row to expand inline detail, or follow the "open full page" link to the per-DRep permalink page.
• Governance actions (/actions.html) — every governance action recorded on-chain with type (TreasuryWithdrawals, InfoAction, ParameterChange, NewConstitution, NewCommittee, HardForkInitiation), outcome (enacted, ratified, dropped, expired, active — derivation per §6), expiration epoch, and per-action DRep vote tally. Sortable; filterable by type and outcome.
• Per-DRep page (/drep.html?id=drep1...) — permalinkable page for any DRep currently in the snapshot. Shows current voting weight, last vote epoch, full vote history (paginated), 90-day voting weight chart, and on-chain metadata source.
• Methodology (/methodology.html) — this page.

Public data exports (all CC0, regenerated by the daily ETL at 02:00 UTC):

• GET /data/snapshots/top30.json — current snapshot in JSON
• GET /data/snapshots/top30.csv — same in CSV (header + 30 rows; lovelace and ADA columns both included for verification)
• GET /data/snapshots/actions.json — governance actions index with per-action vote tallies
• GET /data/snapshots/meta.json — ETL run metadata
• GET /data/snapshots/dreps/{drep_id}.json — per-DRep history + vote record (top 30 only)

The format is stable within a major version. Any field additions or removals are recorded in the §11 changelog before the change ships.

Vote tally semantics (in actions.json): the counts drep_yes_count, drep_no_count, drep_abstain_count for each action represent the most recent vote each DRep has cast on that action. When a DRep has revoted on the same action, only their chronologically latest vote is counted (see §6 for the revote-ordering rule). The counts are facts, not interpretations; they do not constitute approval or rejection signals.

14. Live telemetry layer

In addition to the daily snapshot, the observatory runs a live telemetry ETL every 10 minutes to surface near-real-time governance pulse. This layer is deliberately narrow.

What the live layer fetches each run:

• GET /tip — current epoch and block height (1 call).
• GET /vote_list?block_height=gt.{last_seen} — only DRep votes recorded since the previous live run (typically 0–1 pages).
• GET /proposal_list — full action list, but only every 6th run (≈ hourly).

What the live layer does NOT fetch or change:

• It does not refresh voting weight, delegator counts, or DRep ranking. Those remain pinned to the daily snapshot and to the epoch-boundary stake snapshots the Cardano protocol itself uses.
• It does not refresh DRep metadata.
• It does not modify any row written by the daily ETL.

What the live layer writes:

• New votes rows into the shared SQLite table (with INSERT OR REPLACE on (action_id, drep_id); the revote-ordering rule from §6 applies identically).
• Conditionally new or updated governance_actions rows (hourly).
• JSON files under /data/snapshots/live/ (see §17).

The daily ETL at 02:00 UTC is the source of truth and reconciles any divergence on its next run.

15. Eventual consistency

Because two ETL processes share the same SQLite database, brief inconsistencies are possible:

• A vote captured by the live layer at 10:07 UTC may appear on the site at 10:08, before the next daily ETL run codifies it into the daily snapshot.
• A new governance action submitted between two live runs is captured at the next live run (max ~10 min lag) or the next daily run.
• If a live run fails partway through, no live JSON files are written for that cycle. The prior live files remain in place. The freshness timestamp in live/meta.json makes the staleness visible to the UI.

Reconciliation rule: the daily layer is canonical. If a discrepancy is observed between live and daily reports of the same fact, the daily value is the one to cite. The live layer exists to shorten the visibility lag, not to replace the daily layer.

The site UI labels live-layer-sourced fields with an explicit "Live" indicator. Daily-layer fields have no such indicator; absence of label = canonical daily data.

16. Koios rate-limit discipline

The observatory is a polite consumer of the Koios free tier. Estimated combined load with the live layer at 10-minute cadence:

• Daily ETL: ~136 calls/day
• Live ETL: ~316 calls/day (144 tip + 144 vote_list + ~24 proposal_list + ~4 occasional drep_info refreshes)
• Combined: ~452 calls/day

This is well under typical free-tier limits. If Koios returns a 429 or persistent 5xx error, individual call retries use exponential backoff up to 2 retries (same as the daily layer). If retries fail, the run aborts cleanly, writes a failure record to etl_runs, and leaves all existing files in place. The next 10-minute cron tick is independent and will retry. There is no behavior that polls more aggressively under failure.

17. Live-only data exports

All paths below are under /data/snapshots/live/, are CC0 licensed, and are regenerated by each successful live ETL run (every ~10 minutes). Format is stable within a major version.

• GET /data/snapshots/live/tip.json — current epoch, block height, block time, last-fetched timestamp.
• GET /data/snapshots/live/recent_votes.json — most recent DRep votes (sorted by block_time descending), with DRep name and action title joined in. Bounded to the most recent 20 votes within the last 24 hours.
• GET /data/snapshots/live/meta.json — last live-run start/complete timestamps, success flag, count of new votes in last run, and the cadence in minutes. This is the file the UI reads to compute the "Live · N min" freshness indicator.

The live exports do not duplicate any field that the daily layer publishes. They complement, never replace.

12. v0.1 scope limitations

The site is deliberately narrow at v0.1. The following are out of scope for this version and disclosed here transparently rather than masked with synthetic or interpolated values:

• Delegator counts are fetched only for the top 60 candidates per daily run (to support top-30 ranking with headroom), not all active DReps. The remaining active DReps are visible via the underlying Koios API for anyone who needs them.
• Historical backfill is not yet implemented. The Δ7d and Δ30d fields will appear as — until daily snapshots have accumulated for 7 and 30 days respectively from first deployment. The 90-day chart will populate forward from launch.
• Vote outcomes are not editorialized. The votes table stores facts only — (action_id, drep_id, vote ∈ {yes, no, abstain}, vote_epoch). No alignment scoring, no "voted with consensus" / "voted against consensus" framing, no per-vote interpretation. Governance action outcomes (enacted, ratified, dropped, expired, active) are derived deterministically from Koios fields and likewise carry no value judgment.
• Japanese methodology page is being translated; this English page is currently the source-of-truth.

These limitations resolve over time. They are not concealed and are not approximated.