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.本書は、Cardano Delegation Observatory が収集するデータ、サイト上に表示される値の算出方法、意図的に含めない項目、そして公開データから第三者が結果を再現する手順を、すべて記述する。

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.本ページはプロジェクトの正統性の核である。運用上の決定はすべてここに記録される。本ページとサイトの表示に齟齬があれば、本ページが正準の記述である。Issue で報告してほしい。

1. What this site does1. 本サイトが行うこと

The Cardano Delegation Observatory takes a daily snapshot of voting weight delegated to active Cardano DReps and publishes:Cardano Delegation Observatory は、現役の Cardano DRep に委任された投票権を日次でスナップショットとして取得し、以下を公開する。

• 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.

• 現時点の投票権が上位30位の DRep。
• 各 DRep について、ADA 建ての現在の投票権、7日間および30日間の差分、委任者数、最終投票エポック、過去90日分の投票権推移。
• ガバナンスアクションの提出を、時刻起点のオーバーレイマーカーとして履歴チャートに重ねる。

All data is derived from the Cardano blockchain via the Koios API. No private data sources are used.すべてのデータは Koios API 経由で Cardano ブロックチェーンから取得する。非公開のデータソースは一切使用しない。

2. What this site does not do2. 本サイトが行わないこと

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.

• 信頼スコアや、いかなる種類の総合評価も。
• 表明された立場と投票との整合性スコア。
• 「良い DRep」「悪い DRep」といった分類。
• 投票行動・委任の流れ・選挙結果の予測。
• DRep がオンチェーン・メタデータで自ら提供した名称以外の、現実世界の氏名。
• 委任者のウォレット単位の情報(クジラ判定・クラスタリング・匿名化解除・身元推定を一切行わない)。
• アラート、プッシュ通知、RSS による変更通知、その他あらゆるリアルタイム配信。
• ユーザーコメント・評価・タグ等の、いかなるソーシャル層も。
• 特集・ハイライト・推薦・キュレーションされた DRep。
• 集中度の警告、価値判断を含意するフレーミング、その他特定の 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.将来これらのいずれかを本サイトに追加することが検討された場合は、リリースに先立って本書および §11 の変更履歴を更新し、意見表明期間を設ける。

3. Data sources3. データソース

Primary: Koios API — a community-run REST interface over Cardano db-sync. Free tier is sufficient for the daily snapshot pattern this site uses.主要ソース: Koios API — Cardano db-sync 上に構築された、コミュニティ運営の REST インターフェイスである。本サイトが用いる日次スナップショット方式は、無料枠の範囲内で十分に賄える。

Endpoints used (reproducible from the source at etl/snapshot.py):使用するエンドポイント(ソースコード 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'.

• GET /tip — 現在のエポックとブロック高(実行メタデータ用)。
• GET /drep_list — 登録済み DRep の一覧(ページング)。
• POST /drep_info — 登録ステータス、投票権、メタデータ URL とハッシュ(1リクエストあたり最大50 ID のバッチ)。
• GET /drep_delegators(Content-Range ヘッダー) — DRep ごとの委任者数。上位60候補のみ取得する。
• POST /drep_metadata — Koios が解析したメタデータ本体と is_valid フラグ。
• GET /proposal_list — ガバナンスアクション(ページング)。
• GET /vote_list — 記録された投票すべて(ページング)。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.DRep メタデータ本体は、Koios の drep_metadata エンドポイントとその is_valid フラグを介して取得する。処理経路の全容および v0.2 での独立取得 + 検証計画は §8 を参照。

4. Update cadence4. 更新頻度

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.本オブザバトリーは二層の更新頻度を持つ。日次層は「データ対象日 {日付}」と表記されるすべてのデータについて正準である。ライブテレメトリー層(§14)は補助であり、より高頻度で更新されるが、書き込むデータの範囲は狭い。

The daily ETL runs once a day at 02:00 UTC.日次 ETL は毎日 02:00 UTC に1回実行される。

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.日次実行は、実行時点の DRep の状態を取得する。サイトは日次スナップショットを 「データ対象日 {YYYY-MM-DD}」 として表示する。日次更新は1日1回までであるため、オンチェーンの任意のイベントが日次層に反映されるまでの遅延は 最大で約24時間 である。

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.日次 ETL 実行が失敗した場合、直前の日次スナップショットが変更されずに表示され続ける。部分的・整合性の不確かな日次データを公開することはない。日次データが36時間以上経過した場合は、サイトの 「最終更新成功」 タイムスタンプにより古さが示される。

The live telemetry layer runs every 10 minutes via a separate cron entry; its cadence, scope, and limitations are defined in §14.ライブテレメトリー層は別の cron エントリにより10分ごとに実行される。その頻度・対象範囲・制限は §14 で定義する。

5. Selection criteria5. 選定基準

The 30 DReps shown on the main page are selected by:トップページに表示される30 DRep は以下の基準で選定される。

• 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.

• 現役の登録ステータス — 現エポックにおいて Koios drep_info.active = true。登録が失効済み、もしくは登録解除済みの DRep を除外する。
• 既定委任先の除外 — 特殊識別子 drep_always_abstain および drep_always_no_confidence は一切表示しない。これらはプロトコル層の既定委任オプションであり、個別の DRep ではない。含めれば順位を支配し読者を誤誘導するためである。
• 投票権の降順 — 直近の日次スナップショットから算出する。投票権の値は Koios drep_info の amount フィールド(lovelace 単位)であり、ADA(lovelace ÷ 1,000,000)として表示する。
• 同順位は drep_id の昇順でタイブレーク。実行をまたいで決定的である。

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.本選定は完全に決定的であり、公開データから再現可能である。手動のキュレーション、特集の選定、運営者の影響による順位付けは一切存在しない。上記の基準のみが順位を決定する。変更は §11 に理由とともに記録する。

6. Fields displayed per DRep6. 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.

• DRep ID — オンチェーンの登録証明書から得た bech32 形式の drep1... 識別子。
• 名称 — DRep のオンチェーン・メタデータにおける givenName フィールドの値(存在し検証を通過した場合)。メタデータがハッシュ検証に失敗した場合、givenName が存在しない場合、メタデータ URL が未登録の場合のいずれかでは空欄とする。
• 投票権(ADA) — 当該 DRep に委任された投票権総量の直近日次スナップショット。ADA 単位。
• Δ 7日間 — 本日の投票権から、7日次スナップショット前の投票権を差し引いた値(ADA)。符号付き。色分けはしない。
• Δ 30日間 — 本日の投票権から、30日次スナップショット前の投票権を差し引いた値(ADA)。符号付き。色分けはしない。
• 委任者数 — 当該 DRep に現在委任している、相異なるステーククレデンシャル (stake credential) の数。
• 最終投票(エポック) — 当該 DRep がいずれかのガバナンスアクションに対して投票記録を残した直近のエポック。同一提案に再投票した場合は、時系列上で最新の票のみを保持する(DRep は開放中の提案に対して投票を変更でき、集計時には最後に投じた票が有効である)。
• 90日間チャート(DRep 行の展開) — 直近90スナップショット分の投票権の日次系列。エポック境界を淡い縦マーカーで、ガバナンスアクションの提出日を見出し付きの縦マーカーで重ねて描画する。

7. Fields not displayed7. 表示しないフィールド

This list is exhaustive for v0.1. Any addition requires a §11 changelog entry written before the change ships:本一覧は v0.1 において網羅的である。いかなる追加も、リリースに先立って §11 の変更履歴への記載を必要とする。

• 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.

• DRep 自身が提供していないオフチェーン上の身元情報。
• 委任者のウォレットアドレス、残高、その他委任者単位の詳細。
• DRep 間、委任者間、もしくは DRep と委任者の間の推定関係。
• 委任の動きについて推定された動機。
• 総合スコア、パーセンタイル順位、バッジ、ティア、評価のいずれも。
• 「ハイライト」「アラート」「注目」といったフレーミング。

8. Metadata handling8. メタデータの取り扱い

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.DRep のメタデータ URL は任意の内容を返し得る。v0.1 では、メタデータ本体を Koios の drep_metadata エンドポイント経由で取得する。当該エンドポイントはオフチェーン JSON を取得し、ハッシュを計算し、CIP-100/CIP-119 の検証を適用する。本オブザバトリーは Koios の is_valid フラグを検証ゲートとして用いる。

• 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.

• 検証ゲート — Koios により is_valid = false と判定されたメタデータは完全に無視する。名称は抽出せず、DRep エントリには bech32 形式の DRep ID のみを表示する。
• HTML として描画しない — 解析済み JSON からは givenName フィールドのみを読み取る。生のメタデータ本体をサイト上で HTML として描画することは一切ない。
• サニタイズ — 抽出した givenName はプレーンテキストとして扱う。制御文字を除去し、200文字に切り詰め、除去後に非空である場合のみ表示する。
• 代替の識別なし — メタデータが欠落、無効、または givenName を含まない場合、エントリには bech32 形式の DRep ID のみを表示する。代替の命名ソースを参照することはない。

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.v0.2 では、オンチェーン URL から直接メタデータを取得し、独立した SHA-256 検証を行う方式へ移行する可能性がある。これにより、メタデータ本体の信頼経路から Koios を外す。v0.2 の候補であり、v0.1 での約束ではない。

9. Right of reply9. 反論の機会

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.本サイト上の自エントリに文脈を追加したい DRep は、オンチェーン・メタデータを更新すればよい。本オブザバトリーは毎日最新のメタデータを取得し、次回のスナップショットに新しい内容を反映する。

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.DRep のエントリに対し、テキスト・リンク・バッジ・コメントを追加する運営者を介した経路は存在しない。これは意図的である。運営者が DRep 単位の内容を編集できる瞬間から、サイトは編集的な次元を持ってしまう。

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.公開されている数値が計算上誤っていると判断した DRep は、GitHub リポジトリで Issue を開いてほしい。スナップショット日、該当フィールド、期待される値を併記する。計算上の訂正は公開の場で行い、影響を受けた日付を変更履歴に記す。

10. Operator10. 運営者

This observatory is operated by cryptoleo79, an independent Cardano stake pool operator and DRep.本オブザバトリーは、独立した Cardano ステークプール運営者かつ DRep である cryptoleo79 によって運営されている。

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.

• 運営者は登録済みの DRep である。投票権が上位30位に入る場合、運営者の DRep エントリは、特別扱い・除外・編集的フラグを一切なしにデータ中に表示される。
• 運営者は Cardano ステークプールを運営している。ステークプールのデータは本サイトでは表示しない。本オブザバトリーが扱うのは DRep と DRep への委任のみである。
• 運営者は Connected Treasury Framework の起案者である。同プロジェクトは、業績連動の DRep 参加インセンティブを含むトレジャリー利回りの分配を提唱している。本オブザバトリーは、そのデータ表示において CTF 提案を宣伝・リンク・優遇することはない。

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.ソースコード、デプロイ設定、データスキーマはすべて GitHub リポジトリに Apache 2.0 ライセンスで公開されている。公開データは CC0 である。第三者は、引用された公開エンドポイントからすべての結果を独立に再現できる。

11. Changelog11. 変更履歴

For the canonical record, see METHODOLOGY.md in the repository. The summary below is mirrored from there:正準の記録はリポジトリ内の METHODOLOGY.md を参照。以下はそこからの抜粋である。

13. Pages and public exports13. ページと公開エクスポート

The observatory comprises four pages:本オブザバトリーは4ページから成る。

• 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.

• Observatory(/) — 現在の投票権による上位30 DRep を、Δ7日間、Δ30日間、委任者数、最終投票エポックとともに表示する。日次スナップショット。行をクリックすればインラインで詳細が展開する。「個別ページを開く」リンクから DRep のパーマリンクページに遷移できる。
• ガバナンスアクション(/actions.html) — オンチェーンに記録されたすべてのガバナンスアクションを、種別(トレジャリー引き出し、情報アクション、パラメータ変更、新規憲法、新規委員会、ハードフォーク起動)、結果(施行、批准、廃案、失効、進行中 — 導出は §6 に従う)、期限エポック、アクション単位の DRep 投票集計とともに表示する。並び替え可、種別および結果でフィルタ可。
• DRep 個別ページ(/drep.html?id=drep1...) — 現スナップショット内のいずれかの DRep に対してパーマリンクとして開けるページ。現在の投票権、最終投票エポック、完全な投票履歴(ページング)、90日間の投票権チャート、オンチェーン・メタデータのソースを表示する。
• 方法論(/methodology.html) — 本ページ。

Public data exports (all CC0, regenerated by the daily ETL at 02:00 UTC):公開データのエクスポート(すべて CC0、02:00 UTC の日次 ETL により再生成):

• 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)

• GET /data/snapshots/top30.json — 現スナップショットの JSON
• GET /data/snapshots/top30.csv — 同 CSV(ヘッダ + 30行。検証用に lovelace と ADA の両列を含める)
• GET /data/snapshots/actions.json — アクション単位の投票集計付きガバナンスアクション一覧
• GET /data/snapshots/meta.json — ETL 実行メタデータ
• GET /data/snapshots/dreps/{drep_id}.json — DRep ごとの履歴 + 投票記録(上位30のみ)

The format is stable within a major version. Any field additions or removals are recorded in the §11 changelog before the change ships.形式はメジャーバージョン内で安定である。フィールドの追加・削除はリリース前に §11 の変更履歴に記録する。

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.投票集計の意味(actions.json 内): 各アクションの drep_yes_count、drep_no_count、drep_abstain_count は、各 DRep が当該アクションに対して最後に投じた票を表す。同一アクションに DRep が再投票した場合は、時系列上で最新の票のみを集計する(再投票順序のルールは §6 を参照)。集計は事実であり解釈ではない。承認や否決のシグナルを構成するものではない。

14. Live telemetry layer14. ライブテレメトリー層

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.日次スナップショットに加え、本オブザバトリーはライブテレメトリー ETL を 10分ごとに実行し、準リアルタイムのガバナンス動向を可視化する。この層は意図的に狭い範囲に絞っている。

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).

• GET /tip — 現在のエポックとブロック高(1回)。
• GET /vote_list?block_height=gt.{last_seen} — 前回のライブ実行以降に記録された DRep の投票のみ(通常0〜1ページ)。
• GET /proposal_list — アクションの全リスト(ただし6回ごとに1回、約1時間ごとに取得)。

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.

• 投票権、委任者数、DRep の順位は更新しない。これらは日次スナップショット、および Cardano プロトコル自身が用いるエポック境界のステークスナップショットに固定される。
• DRep メタデータは更新しない。
• 日次 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).

• 共有 SQLite テーブルに新規 votes 行((action_id, drep_id) に対する INSERT OR REPLACE。§6 の再投票順序ルールが同一に適用される)。
• 条件付きで新規または更新された governance_actions 行(時間ごと)。
• /data/snapshots/live/ 配下の JSON ファイル(§17 を参照)。

The daily ETL at 02:00 UTC is the source of truth and reconciles any divergence on its next run.02:00 UTC の日次 ETL が信頼の源であり、次回実行時にあらゆる乖離を突合する。

15. Eventual consistency15. 結果整合性

Because two ETL processes share the same SQLite database, brief inconsistencies are possible:2つの ETL プロセスが同一の SQLite データベースを共有するため、短時間の不整合が生じ得る。

• 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.

• 10:07 UTC にライブ層が捕捉した票は、次回の日次 ETL 実行が日次スナップショットに固定する前の 10:08 にサイト上に現れ得る。
• 2回のライブ実行の間に提出された新規ガバナンスアクションは、次回のライブ実行(最大約10分の遅延)または次回の日次実行で捕捉される。
• ライブ実行が途中で失敗した場合、当該サイクルではライブ JSON ファイルは一切書き込まれない。直前のライブファイルがそのまま残る。live/meta.json 内の鮮度タイムスタンプにより、古さが 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.サイト UI は、ライブ層に由来するフィールドに明示的な「Live」インジケータを付ける。日次層のフィールドにはこのインジケータを付けない。ラベルがないことが、正準である日次データを意味する。

16. Koios rate-limit discipline16. Koios レート制限の節度

The observatory is a polite consumer of the Koios free tier. Estimated combined load with the live layer at 10-minute cadence:本オブザバトリーは Koios 無料枠の節度ある利用者である。ライブ層を10分間隔で動作させたときの合算負荷の見積もりは以下の通りである。

• 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

• 日次 ETL: 約136コール/日
• ライブ ETL: 約316コール/日(tip 144 + vote_list 144 + proposal_list 約24 + drep_info の不定期更新 約4)
• 合算: 約452コール/日

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.これは通常の無料枠の制限を十分に下回る。Koios が 429 または持続的な 5xx エラーを返した場合、個別コールの再試行は指数バックオフを用いて最大2回まで行う(日次層と同一の方針)。再試行が失敗した場合、当該実行は整然と中止され、etl_runs に失敗記録を書き込み、既存ファイルはすべてそのまま残す。次の10分 cron tick は独立しており再試行を行う。失敗時にポーリング頻度を上げる挙動は存在しない。

17. Live-only data exports17. ライブ専用データのエクスポート

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.以下のパスはすべて /data/snapshots/live/ 配下にあり、CC0 ライセンスで、各ライブ ETL 実行の成功時(約10分ごと)に再生成される。形式はメジャーバージョン内で安定である。

• 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.

• GET /data/snapshots/live/tip.json — 現エポック、ブロック高、ブロック時刻、最終取得タイムスタンプ。
• GET /data/snapshots/live/recent_votes.json — 直近の DRep 投票(block_time の降順)。DRep 名およびアクションタイトルを結合する。直近24時間以内の最新20件に限定する。
• GET /data/snapshots/live/meta.json — 最後のライブ実行の開始・完了タイムスタンプ、成功フラグ、直近実行での新規投票数、分単位の更新頻度。UI が「Live · N 分」鮮度表示を計算するために読むファイルである。

The live exports do not duplicate any field that the daily layer publishes. They complement, never replace.ライブのエクスポートは、日次層が公開するフィールドを重複させない。補完するのであって、置き換えることはない。

18. Delegation flow (FLOW-1)18. 委任フロー (FLOW-1)

This section defines exactly what "delegation movement" means within the observatory. The boundary is sharp: the observatory measures what changed between two snapshots; it does not infer why the change happened. Every flow metric below is computed directly from the daily snapshot record (§5) and carries no editorial dimension.本節は、本オブザバトリーにおける「委任の動き」の定義を明確に規定する。境界は明瞭である。本オブザバトリーは2つのスナップショット間で何が変わったかを計測するのであって、変化がなぜ起きたかを推定するのではない。以下のすべてのフロー指標は、日次スナップショット記録(§5)から直接算出され、編集的な次元を一切含まない。

18.1 Quantities measured18.1 計測する数量

Two independent quantities are tracked for each DRep:DRep ごとに2つの独立した数量を追跡する。

• Voting weight (lovelace). The amount field from Koios drep_info at snapshot time, in lovelace.
• Delegator count. The number of distinct stake credentials currently delegated to the DRep.

• 投票権(lovelace)。スナップショット時点の Koios drep_info の amount フィールド(lovelace 単位)。
• 委任者数。当該 DRep に現在委任している、相異なるステーククレデンシャル (stake credential) の数。

These quantities are tracked separately. They can move in opposite directions in the same interval. The observatory reports both, never reconciles them into a single "movement" number.これらの数量は別個に追跡する。同一期間内に逆方向に動くこともある。本オブザバトリーは両者を報告するのであって、両者を単一の「動き」値に集約することはない。

18.2 Net movement18.2 純変動

For a DRep D and interval length n days, net movement is:DRep D と期間長 n 日について、純変動は次の通り。

  net_voting_weight_delta(D, t, n)  = voting_weight(D, t) − voting_weight(D, t')
  net_delegator_count_delta(D, t, n) = delegator_count(D, t) − delegator_count(D, t')

where t is the most recent snapshot date and t' is the most recent snapshot at or before t − n days. If no such reference snapshot exists, the flow is reported as null (never zero, never interpolated).ここで t は直近のスナップショット日、t' は t − n 日以前で最も新しいスナップショット日である。該当する基準スナップショットが存在しない場合、フローは null として報告する(ゼロや補間値は用いない)。

18.3 Net movement is not migration18.3 純変動は移行 (migration) ではない

Net movement values are independent per DRep. The observatory makes no claim that a positive net movement at DRep A and a negative net movement at DRep B during the same interval represent the same delegators having moved from A to B. Even when the magnitudes match exactly, this is not evidence of migration.純変動値は DRep ごとに独立である。本オブザバトリーは、ある期間において DRep A に正の純変動、DRep B に負の純変動が同時に観測されたとしても、それが「同一の委任者が A から B へ移った」ことを意味するという主張を一切行わない。大きさが完全に一致したとしても、それは移行 (migration) の証拠ではない。

Example: in a given week, DRep A shows +100M ADA and DRep B shows −100M ADA. The observatory reports both values. It does not report "ADA moved from B to A." Such a migration claim would require per-delegator event tracking, which FLOW-1 does not provide. The two movements may have been driven by completely independent delegators making unrelated decisions.例: ある週に DRep A が +100M ADA、DRep B が −100M ADA を示したとする。本オブザバトリーは両者の値を報告する。「B から A へ ADA が移った」とは報告しない。そのような移行の主張は委任者単位のイベント追跡を必要とし、FLOW-1 はそれを提供しない。2つの動きは、完全に独立した委任者がそれぞれ無関係な意思決定を行った結果である可能性がある。

Migration tracking, if added in a future phase, will be documented in its own methodology section before any "A → B" claim appears anywhere on the site.移行追跡が将来の段階で追加される場合は、サイトのどこかに「A → B」の主張が現れる前に、独立した方法論セクションで規定する。

18.4 What is not measured by FLOW-118.4 FLOW-1 が計測しないもの

The observatory does not measure, and the published data does not support claims about:本オブザバトリーは以下を計測せず、公開データは以下に関する主張を裏付けない。

• Gross inflow (total ADA newly delegated to a DRep during an interval, ignoring departures).
• Gross outflow (total ADA un-delegated from a DRep, ignoring arrivals).
• Migration ("ADA moved from DRep A to DRep B"), per §18.3.

• 総流入(ある期間に DRep へ新規に委任された ADA の合計。離脱は無視)。
• 総流出(DRep から委任解除された ADA の合計。新規流入は無視)。
• 移行 (migration)(「DRep A から B へ ADA が移った」)。§18.3 を参照。

Each requires per-delegator event tracking, which FLOW-1 does not provide. All flow values published are net only.いずれも委任者単位のイベント追跡を必要とし、FLOW-1 はそれを提供しない。公開するフロー値はすべて純変動 (net) のみである。

18.5 Canonical comparison interval18.5 正準の比較期間

Two intervals are exposed in the top-30 view: 7 days (Δ7d) and 30 days (Δ30d), both snapshot-to-snapshot diffs in calendar days.上位30表示には2つの期間を露出させる: 7日間 (Δ7d) および 30日間 (Δ30d)。いずれもスナップショット間の暦日差分である。

A third interval, 1 day (Δ1d), is computed and exposed in per-DRep JSON exports and on the per-DRep page only. It is intentionally not surfaced on the main table because day-over-day voting-weight changes within an epoch are often not governance-meaningful and would crowd the table visually.3つ目の期間 1日 (Δ1d) は計算し、DRep ごとの JSON エクスポートおよび DRep 個別ページにのみ露出させる。主テーブルには意図的に表示しない。エポック内の日次投票権変化はガバナンス上の意味を持たないことが多く、テーブルを視覚的に圧迫するためである。

Each published flow value carries an explicit flow_reference_date field naming the snapshot date used as the prior reference. Anyone who downloads the daily snapshots can recompute the published flow value.公開する各フロー値は、前回基準として用いたスナップショット日を明示する flow_reference_date フィールドを併記する。日次スナップショットをダウンロードした者は誰でも公開フロー値を再計算できる。

18.6 Missing-data handling18.6 欠損データの取り扱い

The observatory does not interpolate. If the prior snapshot at or before t − n days is missing, the flow value is null. A DRep that entered the top-30 within the last n days has null flows for n-day intervals until enough snapshots have accumulated. For dates before the first deployment of the observatory, no value is ever reported.本オブザバトリーは補間を行わない。t − n 日以前の基準スナップショットが存在しない場合、フロー値は null とする。直近 n 日以内に上位30に入った DRep は、十分なスナップショットが蓄積するまで n 日期間のフローが null である。本オブザバトリーの初回デプロイ前の日付については、いかなる値も報告しない。

18.7 Edge cases that cannot be resolved from snapshot data18.7 スナップショットデータからは解決できないエッジケース

These conditions produce snapshot-level flow values that are not directly attributable. The observatory reports raw numbers anyway, without editorial framing:以下の状況では、スナップショットレベルのフロー値が直接的に帰属できない。本オブザバトリーは編集的なフレーミングを加えず、生の数値をそのまま報告する。

18.8 What flow data does NOT mean18.8 フローデータが意味しないこと

Flow data is a record of what changed, not why. The observatory cannot resolve motive from snapshot deltas. In particular:フローデータは何が変わったかの記録であって、なぜ変わったかではない。本オブザバトリーはスナップショット差分から動機を解き明かすことはできない。具体的には以下の通り。

• A DRep gaining ADA does not imply approval, trust, endorsement, or agreement.
• A DRep losing ADA does not imply rejection, disagreement, failure, or decline.
• Large movements may originate from wallet software defaults, custodial infrastructure, exchange operations, stake-key changes, or delegation decisions. The observatory records the movement itself and does not attribute motive. The mechanism behind a delegation change is invisible from snapshot data.
• Coordinated-looking movement is not evidence of coordination.
• Movement near a governance event is not evidence of voting motive.
• The largest movers are not "winners" or "losers." Magnitude reflects the scale of delegation activity, not its quality or normative direction.

• DRep が ADA を獲得しても、それは承認、信頼、推薦、賛同を意味しない。
• DRep が ADA を失っても、それは拒絶、不同意、失敗、衰退を意味しない。
• 大きな動きはウォレット既定設定、カストディアン基盤、取引所運用、ステーク鍵の変更、委任の意思決定のいずれからも生じ得る。本オブザバトリーは動きそのものを記録するのみであり、動機を帰属させない。委任変更の背後にある機構は、スナップショットデータからは見えない。
• 協調しているように見える動きは、協調の証拠ではない。
• ガバナンスイベント近傍の動きは、投票動機の証拠ではない。
• 最も大きく動いた者は「勝者」でも「敗者」でもない。大きさは委任活動の規模を反映するのみで、その質や規範的方向を反映しない。

Readers — researchers, journalists, DReps themselves — interpret what they see. The site does not.読者 — 研究者、ジャーナリスト、DRep 自身 — が観測したものを解釈する。サイトは解釈しない。

19. Governance event overlays (FLOW-2)19. ガバナンスイベント・オーバーレイ (FLOW-2)

This section defines how governance actions are displayed in time alongside delegation movement on the per-DRep voting weight chart. The boundary is sharp: the observatory shows temporal proximity between delegation movement and governance events; it makes no claim about causation.本節は、DRep ごとの投票権チャート上で、ガバナンスアクションを委任の動きと時系列上どのように並置するかを規定する。境界は明瞭である。本オブザバトリーは委任の動きとガバナンスイベントの時間的近接性を示すのみであり、因果関係に関するいかなる主張も行わない。

19.1 Event types overlaid19.1 重ねるイベントの種別

For each governance action, up to five events may be drawn on the chart, depending on which fields are populated:各ガバナンスアクションについて、対応するフィールドが埋まっている場合、最大5種類のイベントをチャートに描画する。

• Submission — UTC date of block_time from Koios /proposal_list.
• Ratification — start date of ratified_epoch.
• Enactment — start date of enacted_epoch.
• Expiration — start date of expires_epoch.
• Drop — start date of dropped_epoch.

• 提出 — Koios /proposal_list の block_time の UTC 日。
• 批准 — ratified_epoch の開始日。
• 施行 — enacted_epoch の開始日。
• 失効 — expires_epoch の開始日。
• 廃案 — dropped_epoch の開始日。

19.2 Time alignment between epochs and snapshot dates19.2 エポックとスナップショット日付の時刻整合

Submission events use the exact UTC date of submission. State-transition events use the UTC date the relevant epoch began, sourced from Koios /epoch_info (canonical). When no source is available, the overlay is omitted rather than approximated.提出イベントは正確な提出 UTC 日を用いる。状態遷移イベントは該当エポックの開始 UTC 日を用い、正準ソースとして Koios /epoch_info から取得する。ソースが取得できない場合は、近似せず、オーバーレイ自体を省く。

19.3 What an overlay marker means — and does not mean19.3 オーバーレイマーカーが意味すること、そして意味しないこと

An overlay marker at date D for event E concerning action A means exactly: Event E for action A occurred on date D (approximately, at epoch granularity for state transitions).アクション A に関するイベント E を日付 D に置いたオーバーレイマーカーが意味するのは厳密に次のみである:アクション A のイベント E は日付 D に発生した(状態遷移についてはエポック粒度での近似)。

The marker does not mean that any delegation movement on or near D was caused by A, that movement was a reaction to A, that voters coordinated, that A is more or less important than other actions, or that any DRep voted on A in any particular way.マーカーは以下を意味しない。D 近傍の委任の動きが A によって引き起こされたこと、当該動きが A への反応であったこと、投票者が協調したこと、A が他のアクションより重要または重要でないこと、いずれかの DRep が A に対し特定の投票をしたこと。

Multiple governance events may occur within the same visual window without any observable delegation response. The observatory records both the events and the delegation state independently. Proximity on the same time axis does not imply influence in either direction.同一の視覚的ウィンドウ内に複数のガバナンスイベントが、観測可能な委任応答を伴わずに発生し得る。本オブザバトリーはイベントと委任状態をそれぞれ独立に記録する。同一時間軸上の近接は、いずれの方向の影響も含意しない。

19.4 Visual conventions19.4 視覚的慣習

Overlays appear as subtle vertical markers on the chart, in a single calm neutral color, with no outcome-based color coding (enacted is the same color as dropped; ratified is the same color as expired).オーバーレイはチャート上に控えめな縦マーカーとして、単一の落ち着いた中立色で表示する。結果に基づく色分けは行わない(施行は廃案と同色、批准は失効と同色)。

Overlay markers are rendered behind the delegation series and never obscure the underlying governance data. The delegation line and its data points are always drawn on top of the marker layer.オーバーレイマーカーは委任系列の背後に描画し、基礎となるガバナンスデータを覆い隠さない。委任ラインとそのデータ点は常にマーカー層の上に描画する。

Hovering or tapping a marker reveals plain text: action ID, action type, event type, event date. Markers for the same action at different events are not connected by lines or arrows.マーカーへのホバーまたはタップでプレーンテキストを表示する: アクション ID、種別、イベント種別、イベント日付。同一アクションの異なるイベントに対するマーカーは、線や矢印で接続しない。

19.5 Scope of which actions appear on which charts19.5 どのアクションをどのチャートに表示するか

The observatory overlays all governance actions whose any event date falls within the chart's visible 90-day window. It does not pre-filter by whether the DRep voted on the action. Pre-filtering would implicitly editorialize relevance; showing all events presents the governance environment the DRep was operating in.本オブザバトリーは、いずれかのイベント日がチャートの可視90日ウィンドウに入るガバナンスアクションをすべて重ねる。当該 DRep が当該アクションに投票したかどうかで事前フィルタすることはない。事前フィルタは関連性を暗黙に編集することになる。すべてのイベントを表示することで、当該 DRep が活動していたガバナンス環境を提示する。

19.6 What FLOW-2 does NOT do19.6 FLOW-2 が行わないこと

• No causal claims; no correlation computations.
• No highlighting of actions near large delegation movements.
• No ranking of actions by proximity.
• No color signaling by outcome on the chart.
• No forecasts.
• No per-DRep filtering of which actions appear.

• 因果の主張も相関の計算も行わない。
• 大きな委任の動きの近傍にあるアクションを強調しない。
• 近接性によるアクションの順位付けを行わない。
• 結果による色シグナルをチャート上に置かない。
• 予測は行わない。
• 表示するアクションを DRep ごとにフィルタしない。

19.7 Edge cases19.7 エッジケース

• Action submitted before deployment: overlay placed at the submission date with no chart context to its left. Honest, not hidden.
• Multiple events on same date for same action: drawn as separate markers with small horizontal offset; tooltip lists all events.
• Still-active action: only submission marker is drawn.
• Epoch boundary on day with no successful ETL run: boundary date from Koios /epoch_info directly.
• Action in window but DRep not yet in top-30: marker still appears; voting weight series may be null for earlier dates.
• Fewer than 90 days of snapshots: overlay window matches actual snapshot range, not synthetic 90 days.

• デプロイ前に提出されたアクション: オーバーレイは提出日に置く。左側にはチャート文脈がない。隠さず誠実に表示する。
• 同一アクションの同一日に複数イベント: 小さな水平オフセットを伴う独立マーカーとして描画する。ツールチップに全イベントを列挙する。
• 進行中のアクション: 提出マーカーのみを描画する。
• ETL 実行が成功しなかった日のエポック境界: 境界日付は Koios /epoch_info から直接取得する。
• ウィンドウ内にアクションがあるが DRep がまだ上位30に入っていない場合: マーカーは表示する。投票権系列はその時点より前の日付では null になり得る。
• スナップショットが90日未満しかない場合: オーバーレイのウィンドウは実際のスナップショット範囲に一致する。架空の90日に合わせない。

19.8 Reproducibility commitment19.8 再現性のコミットメント

Every overlay marker is derivable from governance_actions (action_id + epoch fields), proposal_list.block_time, and the epoch_info mapping. All three are CC0; FLOW-2 adds the export at /data/snapshots/epoch_info.json.すべてのオーバーレイマーカーは、governance_actions(action_id + エポックフィールド)、proposal_list.block_time、epoch_info マッピングから導出可能である。三者すべて CC0 である。FLOW-2 は /data/snapshots/epoch_info.json にエクスポートを追加する。

20. Governance history layer (FLOW-3)20. ガバナンス履歴層 (FLOW-3)

This section defines how the observatory retains, organizes, and presents historical governance data. The boundary is sharp: the observatory records what happened (actions, votes, dates, state transitions) without claiming what was important, significant, successful, or popular.本節は、本オブザバトリーが履歴上のガバナンスデータをどう保持し、整理し、提示するかを規定する。境界は明瞭である。本オブザバトリーは何が起きたか(アクション、投票、日付、状態遷移)を記録するのみであり、何が重要で、有意で、成功で、人気だったかについては主張しない。

20.1 Scope20.1 対象範囲

• Every governance action observed on chain, indexed by canonical action_id (bech32 gov_action1...).
• Every DRep vote on every action (yes / no / abstain), with chronologically-latest semantics from §6.
• Every state transition observed: submission, ratification, enactment, expiration, drop.
• Every epoch boundary referenced by an action.

• オンチェーンで観測されたすべてのガバナンスアクションを、正準 action_id(bech32 gov_action1...)で索引付けする。
• すべてのアクションに対するすべての DRep 投票(賛成 / 反対 / 棄権)を、§6 の「時系列上最新」セマンティクスのもとで保持する。
• 観測されたすべての状態遷移: 提出、批准、施行、失効、廃案。
• いずれかのアクションが参照するすべてのエポック境界。

20.2 The action record20.2 アクションレコード

Keyed on action_id. Contains action_type, title, submission_block_time, submitted_epoch, state-transition epochs (expires, expired, ratified, enacted, dropped), deterministic outcome, and joined vote rows.主キーは action_id。action_type、title、submission_block_time、submitted_epoch、状態遷移エポック(expires、expired、ratified、enacted、dropped)、決定的に導出された outcome、結合された投票行を含む。

20.3 Action timeline20.3 アクションのタイムライン

Chronologically-ordered events per action: submission → voting period → terminal state. Active actions have no terminal state until observed. The timeline shows protocol-observed facts; no "importance" annotations, no "successful" / "failed" framings.アクション単位の時系列順イベント: 提出 → 投票期間 → 終局状態。進行中のアクションは観測されるまで終局状態を持たない。タイムラインはプロトコルが観測した事実のみを示す。「重要性」の注釈は行わず、「成功」「失敗」のフレーミングも行わない。

20.4 Retention20.4 保持

Permanent: action_id, submission_block_time, each state-transition epoch, vote rows (except revote replacement per §6).永続: action_id、submission_block_time、各状態遷移エポック、投票行(§6 の再投票置換を除く)。

Mutable across ETL runs: title (off-chain metadata), outcome derivation (only on forward progress when a new state transition is observed). No previously-captured row is ever deleted or replaced by a less-complete row.可変(ETL 実行をまたぐ): title(オフチェーン・メタデータ)、結果の導出(新規状態遷移が観測された前進時のみ)。以前に取得した行が削除されたり、より不完全な行で置換されることは一切ない。

20.5 Canonical sources20.5 正準ソース

Identity, state transitions, submission timestamp, vote facts, and epoch start dates all derive from Koios endpoints (/proposal_list, /vote_list, /epoch_info). An independent observatory would produce identical records.識別子、状態遷移、提出タイムスタンプ、投票事実、エポック開始日はすべて Koios のエンドポイント(/proposal_list、/vote_list、/epoch_info)に由来する。独立に運営される別のオブザバトリーが同一の記録を生成するはずである。

20.6 Representation20.6 表現形式

Two places: aggregate actions.json (v0.2) and per-action /data/snapshots/actions/{action_id}.json (FLOW-3). The action detail page at /action.html?id=gov_action1... reads the per-action file.2 箇所に表現する: 集約 actions.json(v0.2)とアクション単位の /data/snapshots/actions/{action_id}.json(FLOW-3)。/action.html?id=gov_action1... のアクション詳細ページは、アクション単位のファイルを読む。

20.7 What is not inferred20.7 推定しない事柄

The history layer surfaces only protocol-observed facts. It does not generate:履歴層はプロトコルが観測した事実のみを露出させる。以下は生成しない。

• "Importance," "significance," "major," or "watched" classifications.
• "Successful" / "failed" / "rejected" framings — only protocol terms.
• "Support" / "opposition" labels on DRep votes — only yes / no / abstain.
• Participation-rate framings as "high" or "low."
• Outcome leaderboards or rank-by-anything.
• Retrospective scoring of actions or DReps.
• Causal links between an action and any other action's outcome.
• "Trending" or "popular" derivations.

• 「重要」「有意」「主要」「注目」といった分類。
• 「成功」「失敗」「拒絶」といったフレーミング — プロトコル用語のみを用いる。
• DRep 投票に対する「支持」「反対」のラベル — yes / no / abstain のみ。
• 参加率を「高い」「低い」と表現するフレーミング。
• 結果のリーダーボードや、何らかの基準による順位付け。
• アクションや DRep への遡及的スコアリング。
• あるアクションと他のアクションの結果との因果関係。
• 「トレンド」「人気」といった導出。

Actions are presented in historical order. The observatory does not distinguish between "major" and "minor" governance actions. Vote tallies and submission dates determine order; nothing else.アクションは履歴順に提示する。本オブザバトリーは「主要」と「従属」のガバナンスアクションを区別しない。投票集計と提出日が順序を決める。それ以外の基準は用いない。

The canonical action identity is action_id. Titles and types are display conveniences derived from on-chain metadata and protocol fields; they do not change the identity of an action. Action detail pages display the canonical action_id prominently near the top of the page — never as an afterthought.アクションの正準の同一性は action_id である。タイトルと種別はオンチェーン・メタデータとプロトコルフィールドから導かれる表示の便宜であり、アクションの同一性を変更しない。アクション詳細ページは正準 action_id をページ上部に目立つ位置で表示する。後付けの位置に置かない。

20.8 Revisions and reconciliation20.8 改訂と突合

State-transition epochs are immutable on chain. Metadata titles may change between ETL runs; the current value is shown and prior titles are not retained in v0.5. Vote rows can be replaced per the revote rule (§6).状態遷移エポックはオンチェーン上で不変である。メタデータのタイトルは ETL 実行間で変わり得る。現在値を表示し、v0.5 では以前のタイトルは保持しない。投票行は §6 の再投票ルールに従って置換され得る。

20.9 What FLOW-3 does NOT do20.9 FLOW-3 が行わないこと

• No "top N actions" or "most-engaged actions" rankings.
• No action similarity, sentiment, or alignment computations.
• No outcome prediction.
• No highlighting of actions for which delegation moved.
• No clustering of actions by topic, era, or derived category.
• No commentary on action content.
• No comparison of DRep voting patterns across actions.

• 「トップ N アクション」「最も関心を集めたアクション」などの順位付けは行わない。
• アクションの類似度、感情、整合性の計算は行わない。
• 結果の予測は行わない。
• 委任が動いたアクションを強調することはしない。
• トピック、時代、導出カテゴリーによるアクションのクラスタリングは行わない。
• アクション内容に対する論評は行わない。
• アクションを横断した DRep 投票パターンの比較は行わない。

20.10 Edge cases20.10 エッジケース

• Action with no metadata title: displayed as truncated action_id with action_type. No fallback name fabricated.
• Action with invalid title: same — only action_id and action_type.
• Active action with no state transitions: timeline shows submission only; terminal state displays as active.
• Vote from a DRep outside top-60 candidates: vote appears in the action's vote list; DRep shown by truncated drep_id only. No fabricated names.

• メタデータタイトルがないアクション: 切り詰めた action_id と action_type を表示する。代替の名称を捏造しない。
• タイトルが無効なアクション: 同様に action_id と action_type のみを表示する。
• 状態遷移のない進行中アクション: タイムラインは提出のみを表示する。終局状態は active として表示する。
• 上位60候補外の DRep からの投票: 投票はアクションの投票一覧に現れる。DRep は切り詰めた drep_id のみで表示する。名称を捏造しない。

20.11 Reproducibility commitment20.11 再現性のコミットメント

Every action detail page is derivable from actions.json plus the votes records. For voters outside the top-30, names are not shown; this constraint applies equally to anyone running an independent observatory (the operator has no special data access).すべてのアクション詳細ページは、actions.json と votes 記録から導出可能である。上位30外の投票者については名称を表示しない。この制約は、独立に別のオブザバトリーを運営する者にも同等に適用される(運営者は特別なデータアクセスを持たない)。

21. Historical snapshot browser (FLOW-4)21. 履歴スナップショットブラウザ (FLOW-4)

This section defines how the observatory exposes its accumulated daily snapshots as a navigable historical record. The boundary is sharp: the browser surfaces the state that existed at a given date or epoch; it does not interpret, narrate, or contextualize that state.本節は、本オブザバトリーが蓄積した日次スナップショットを、ナビゲート可能な履歴記録として露出させる方法を規定する。境界は明瞭である。ブラウザは特定の日付またはエポック時点に存在していた状態を表示するのみで、その状態を解釈、語り、文脈化することはしない。

21.1 What a historical state is21.1 履歴状態とは何か

The published snapshot record for a specific UTC date: snapshots rows with snapshot_date = D; dreps, governance_actions, votes, and epoch_info as they stood when that snapshot was written. The browser does not invent or interpolate fields that were absent at the time.特定の UTC 日について公開されたスナップショット記録のこと。snapshot_date = D の snapshots 行、ならびにそのスナップショット書き込み時点での dreps、governance_actions、votes、epoch_info。ブラウザは当時欠落していたフィールドを捏造も補間もしない。

21.2 What a snapshot is21.2 スナップショットとは何か

The canonical published output of a single daily ETL run. For date D: top30.json, actions.json, dreps/{drep_id}.json, actions/{action_id}.json, epoch_info.json, and meta.json. Snapshots are immutable once published.単一の日次 ETL 実行による、正準の公開アウトプットのこと。日付 D について: top30.json、actions.json、dreps/{drep_id}.json、actions/{action_id}.json、epoch_info.json、meta.json。スナップショットは公開された時点で不変である。

21.3 Snapshot persistence and addressing21.3 スナップショットの永続化と参照

The daily ETL writes outputs in two parallel locations: Current (overwritten each run, current behavior) and Dated archive at /data/snapshots/by-date/{YYYY-MM-DD}/.日次 ETL はアウトプットを2つの並行する場所に書き込む: 現行(各実行で上書き、現状の挙動)、ならびに 日付付きアーカイブ として /data/snapshots/by-date/{YYYY-MM-DD}/。

URLs: /?date=YYYY-MM-DD, /drep.html?id=...&date=YYYY-MM-DD, /action.html?id=...&date=YYYY-MM-DD, /actions.html?date=YYYY-MM-DD. Without the date parameter, the URL serves the current snapshot.URL: /?date=YYYY-MM-DD、/drep.html?id=...&date=YYYY-MM-DD、/action.html?id=...&date=YYYY-MM-DD、/actions.html?date=YYYY-MM-DD。date パラメータがない場合、URL は現行スナップショットを返す。

21.4 Missing periods21.4 欠損期間

If a daily ETL failed, no archive entry exists. The browser does not interpolate. A request for a missing date returns an explicit gap notice and a pointer to the nearest prior published date. The list of available and missing dates is published at /data/snapshots/by-date/index.json.日次 ETL が失敗した場合、アーカイブエントリは存在しない。ブラウザは補間しない。欠損日へのリクエストには明示的な欠損通知と、直前に公開された日付へのポインタを返す。利用可能な日付と欠損日付の一覧は /data/snapshots/by-date/index.json に公開する。

21.5 Historical ranking derivation21.5 履歴順位の導出

The top-30 ranking for date D is the ranking that was published on date D. It is not retroactively recomputed and is not adjusted for DReps who deregistered later.日付 D の上位30順位は、日付 D に公開された順位そのものである。遡及的に再計算することはなく、後に登録解除した DRep に対する調整も行わない。

Historical rankings are preserved exactly as published on the snapshot date, even if later governance developments would change how a reader interprets them. The observatory's role is to retain what was; readers reason about what it meant.履歴上の順位は、後のガバナンスの展開が読者の解釈を変え得るとしても、スナップショット日に公開されたままの形で保持する。本オブザバトリーの役割は、起きたことを保持することにある。それが何を意味したかは読者が論じる。

21.6 What the browser refuses to infer21.6 ブラウザが推定を拒む事項

• Trends between historical states.
• Comparison framings ("more delegators than before").
• Significance annotations on past events.
• Synthetic "state at epoch X" for epochs the observatory did not snapshot.
• Backfill of fields that were null at the time.
• Retrospective re-ranking using current data.
• "Notable moments" or "key dates" curation.

• 履歴状態間のトレンド。
• 比較フレーミング(「以前より委任者が多い」など)。
• 過去のイベントに対する有意性の注釈。
• 本オブザバトリーがスナップショットを取得していないエポックに対する合成「エポック X 時点の状態」。
• 当時 null だったフィールドのバックフィル。
• 現在のデータを用いた遡及的な再順位付け。
• 「注目すべき瞬間」「重要な日付」のキュレーション。

21.7 What is immutable21.7 不変であるもの

Once a date has passed and its snapshot was published, all artifacts at by-date/{date}/ are immutable, enforced by file path. The ETL never overwrites a past date. methodology_version and schema_version stamps are preserved with the historical snapshot regardless of subsequent updates.日付が過ぎ、そのスナップショットが公開されたあと、by-date/{date}/ 配下のすべての成果物は不変である。これはファイルパスによって強制される。ETL は過去の日付を上書きしない。methodology_version と schema_version の刻印は、その後の更新にかかわらず、当該履歴スナップショットとともに保持される。

21.8 Historical navigation21.8 履歴ナビゲーション

Simple chronological list of dates (latest first, paginated) — not a calendar widget (which would imply continuous coverage). Adjacent navigation (previous/next snapshot date) skips missing dates explicitly.日付の単純な時系列リスト(新しい順、ページング) — カレンダーウィジェット(連続的なカバレッジを含意してしまう)は用いない。隣接ナビゲーション(前/次のスナップショット日)は欠損日を明示的にスキップする。

21.9 Snapshot provenance21.9 スナップショットの来歴

Every historical view displays a small provenance strip containing:すべての履歴ビューには、以下を含む小さな来歴ストリップを表示する。

• Snapshot date
• Snapshot archive path — the canonical filesystem path under /data/snapshots/by-date/{YYYY-MM-DD}/, shown in monospace as a citable identifier for research references
• ETL run completion timestamp from that date's meta.json
• Methodology version active when the snapshot was published
• Schema version active when the snapshot was published
• Direct download link to the canonical archive path

• スナップショット日
• スナップショットアーカイブパス — /data/snapshots/by-date/{YYYY-MM-DD}/ 配下の正準ファイルシステムパス。等幅で表示し、研究引用のための引用可能な識別子として機能させる
• 当該日の meta.json から得る ETL 実行完了タイムスタンプ
• スナップショット公開時に有効だった方法論バージョン
• スナップショット公開時に有効だったスキーマバージョン
• 正準アーカイブパスへの直接ダウンロードリンク

21.10 Scope of historical coverage21.10 履歴カバレッジの範囲

Only snapshots published by this observatory. No pre-deployment backfill, even if Koios would support reconstruction. §15's pre-launch rule applies.本オブザバトリーが公開したスナップショットのみが対象である。Koios で再構成可能だとしても、デプロイ前のバックフィルは行わない。§15 のローンチ前ルールが適用される。

21.11 What FLOW-4 does NOT do21.11 FLOW-4 が行わないこと

• No "evolution charts" over time beyond the existing per-DRep 90-day current view.
• No "rank on every past date" derived series — that is FLOW-8 territory.
• No labeling of past dates as "milestones" or "key events."
• No side-by-side historical comparison.
• No ranking-of-dates.

• 既存の DRep ごとの90日現行ビュー以外の「進化チャート」は行わない。
• 「過去の各日付における順位」の派生系列は提供しない — これは FLOW-8 の領域である。
• 過去の日付を「マイルストーン」や「重要イベント」とラベル付けしない。
• 履歴の並列比較は行わない。
• 日付の順位付けは行わない。

21.12 Reproducibility21.12 再現性

The JSON returned for a historical date matches the file in the dated archive byte-for-byte (subject only to nginx compression negotiation). Any third party who archived the original snapshots when they were current can reproduce every historical view.履歴日付に対して返される JSON は、日付付きアーカイブ内のファイルとバイト単位で一致する(nginx の圧縮ネゴシエーションの影響のみを除く)。当時現行だったスナップショットをアーカイブした第三者は、すべての履歴ビューを再現できる。

21.13 Archive integrity hashing21.13 アーカイブ完全性のハッシュ

Each dated snapshot archive includes a sha256.json file at /data/snapshots/by-date/{YYYY-MM-DD}/sha256.json listing the SHA-256 hash of every other file in that archive. Written last, after all other archive files are in place.日付付きスナップショットアーカイブには、/data/snapshots/by-date/{YYYY-MM-DD}/sha256.json として sha256.json ファイルを同梱する。同ファイルは、当該アーカイブ内の他のすべてのファイルの SHA-256 ハッシュを列挙する。他のアーカイブファイルがすべて揃った後、最後に書き込む。

Shape:構造:

{
  "schema_version": 1,
  "methodology_version": "0.7",
  "snapshot_date": "2026-05-30",
  "algorithm": "sha256",
  "files": {
    "top30.json": "a1b2c3…",
    "actions.json": "d4e5f6…",
    "meta.json": "…",
    "dreps/drep1…json": "…",
    "actions/gov_action1…json": "…"
  }
}

The hashed files include every file in the dated archive except sha256.json itself. The hash digest covers raw file bytes as written, before any HTTP-layer compression negotiation.ハッシュ対象のファイルは、日付付きアーカイブ内のすべてのファイルである。ただし sha256.json 自身は除く。ハッシュは書き込まれた生のファイルバイトを対象とし、HTTP 層の圧縮ネゴシエーションを経る前の値である。

Verification protocol. Any third party can: (1) compute SHA-256 of each file in a downloaded archive (excluding sha256.json); (2) compare against the corresponding entry in sha256.json; (3) treat any mismatch as evidence that one of the files has been modified after the snapshot was sealed.検証プロトコル。第三者は次の手順を踏める: (1) ダウンロードしたアーカイブ内の各ファイル(sha256.json を除く)の SHA-256 を計算する; (2) sha256.json の対応エントリと比較する; (3) 不一致があれば、当該ファイルがスナップショット封印後に改変された証拠と扱う。

Hashes are not cryptographically signed in v0.7. Signing is a v0.8+ candidate.v0.7 ではハッシュに暗号署名を付けない。署名は v0.8 以降の候補である。

22. Treasury observability (FLOW-5)22. トレジャリー観測性 (FLOW-5)

FLOW-5 extends the observatory to the Cardano treasury. It records the on-chain treasury balance at every epoch boundary and the governance-action-driven withdrawals from that treasury, joined to the governance actions and DRep votes the observatory already captures. It does not score, rank, judge, or recommend any recipient or any withdrawal.FLOW-5 は本オブザバトリーを Cardano トレジャリーに拡張する。各エポック境界におけるオンチェーン上のトレジャリー残高、およびトレジャリーからのガバナンスアクション駆動の引き出しを記録し、本オブザバトリーが既に取得しているガバナンスアクションおよび DRep 投票と結合する。受取人や引き出しの評価・順位付け・判断・推薦は一切行わない。

22.1 Scope22.1 対象範囲

A treasury flow, for the purposes of this section, is the movement of lovelace out of the Cardano on-chain treasury account that is enacted by a governance action of type TreasuryWithdrawals under CIP-1694. The observatory records:本節において、トレジャリーフローとは、CIP-1694 に基づく TreasuryWithdrawals 種別のガバナンスアクションによって施行された、Cardano のオンチェーン・トレジャリー口座からの lovelace の移動を指す。本オブザバトリーは以下を記録する。

• The treasury balance at each epoch boundary (per Koios /totals), back to the earliest epoch the endpoint exposes.
• Every governance action of type TreasuryWithdrawals recorded on chain — the same record already indexed under §20, with its withdrawal-recipient details normalized.
• The relationship between an enacted withdrawal and the observed treasury balance change at the epoch in which it took effect.

• 各エポック境界におけるトレジャリー残高(Koios /totals による)。エンドポイントが露出する最古エポックまで遡る。
• オンチェーンに記録された TreasuryWithdrawals 種別のすべてのガバナンスアクション — §20 で既に索引化されたレコードと同一のもの。引き出し受取人の詳細を正規化する。
• 施行された引き出しと、当該エポックで観測されたトレジャリー残高変動との関係。

What this section does not include:本節の対象に含めないもの。

• Reserves balance and reserves withdrawals. The reserves account is a distinct on-chain entity; pre-Conway reserve movement was MIR-certificate-driven. Reserves are reported by /totals and may be added to a later FLOW-5 expansion; v0.8 scope is treasury only.
• Stake-credential reward withdrawals returned by Koios /treasury_withdrawals. That endpoint, despite its name, returns ITN-era and stake-reward withdrawal events with no governance linkage (no action_id, no proposal_id, no gov_action_* field of any kind). FLOW-5 explicitly excludes it from the governance-driven treasury layer. The naming collision is acknowledged here so future readers can distinguish the two.

• リザーブ残高およびリザーブからの引き出し。リザーブ口座はオンチェーン上の別個の存在である。Conway 以前のリザーブの動きは MIR 証明書によって駆動されていた。リザーブも /totals で報告されており、将来の FLOW-5 拡張で追加され得るが、v0.8 の対象範囲はトレジャリーのみである。
• Koios /treasury_withdrawals が返すステーククレデンシャル (stake credential) の報酬引き出し。当該エンドポイントは名称に反して、ITN 期およびステーク報酬の引き出しイベントを返すが、ガバナンスとの紐付けは一切持たない(action_id、proposal_id、gov_action_* いずれのフィールドも存在しない)。FLOW-5 はガバナンス駆動のトレジャリー層から本エンドポイントを明示的に除外する。名称の衝突は将来の読者が両者を区別できるよう本書で言明する。

22.2 Canonical source model22.2 正準ソース・モデル

The corrected source model, validated by direct probe against the Koios mainnet API on 2026-05-30:2026-05-30 に Koios メインネット API に対する直接プローブで検証した、訂正後のソース・モデルは以下の通り。

There is exactly one source of truth for governance-driven treasury withdrawals: the withdrawal array attached to a proposal_type = TreasuryWithdrawals row in /proposal_list. No other endpoint or join produces this information.ガバナンス駆動のトレジャリー引き出しに関する信頼の源はただ一つ — /proposal_list の proposal_type = TreasuryWithdrawals 行に添付された withdrawal 配列である。他のエンドポイントや結合からこの情報は得られない。

22.3 Schema additions22.3 スキーマ追加

Two tables are added. Both are forward-only migrations under §13's general rule (existing schema unchanged, columns added via ALTER TABLE ADD COLUMN; new tables created idempotently via CREATE TABLE IF NOT EXISTS).2つのテーブルを追加する。いずれも §13 の一般ルールに従う前進専用のマイグレーションである(既存スキーマは変更せず、列追加は ALTER TABLE ADD COLUMN で、新規テーブルは CREATE TABLE IF NOT EXISTS で冪等に作成する)。

treasury_snapshot — one row per Cardano epoch, with columns for circulation, treasury, reward, supply, reserves, fees, deposits (stake / DRep / proposal), treasury donation, treasury withdrawal epoch total, reserves withdrawal epoch total, and fetched_at timestamp. epoch_no is the primary key. The treasury_withdrawal_epoch_total field is the published epoch-level net withdrawal as reported by Koios — see §22.14 for the field-availability addendum.treasury_snapshot — Cardano エポックごとに1行。流通量、トレジャリー、報酬、供給量、リザーブ、手数料、デポジット(ステーク / DRep / 提案)、トレジャリー寄付、エポック内トレジャリー引き出し総額、エポック内リザーブ引き出し総額、取得時刻の列を持つ。主キーは epoch_no。treasury_withdrawal_epoch_total は Koios が報告するエポック単位の純引き出し額である — フィールド可用性の付則は §22.14 を参照。

treasury_withdrawals — one row per (action_id, withdrawal_index) pair, with columns for action_id (FK to governance_actions), withdrawal_index (0-indexed position preserving stated order), recipient_stake_address (bech32), amount_lovelace, and the denormalized enacted_epoch. The denormalization is for query efficiency only; the canonical value lives on governance_actions. ETL idempotently re-syncs enacted_epoch on every run.treasury_withdrawals — (action_id, withdrawal_index) の組ごとに1行。列は、action_id(governance_actions への外部キー)、withdrawal_index(記載順を保持する 0 始まり位置)、recipient_stake_address(bech32)、amount_lovelace、および非正規化された enacted_epoch。非正規化はクエリ効率のみが目的であり、正準値は governance_actions 側にある。ETL は実行ごとに enacted_epoch を冪等に再同期する。

No other tables are added in FLOW-5. The existing governance_actions and votes tables already carry every treasury action and every DRep vote on it.FLOW-5 はこれ以上のテーブルを追加しない。既存の governance_actions と votes テーブルが、すべてのトレジャリーアクションと、それに対するすべての DRep 投票を既に保持している。

22.4 What a treasury action record contains22.4 トレジャリーアクションレコードの内容

Every record exposed by FLOW-5 inherits the full governance action record from §20 (action_id, action_type, title, submission_block_time, submitted_epoch, state-transition epochs, outcome, vote tally, individual DRep votes). FLOW-5 adds, per action:FLOW-5 が露出するすべてのレコードは、§20 の完全なガバナンスアクションレコードを継承する(action_id、種別、タイトル、submission_block_time、submitted_epoch、状態遷移エポック、結果、投票集計、個別 DRep 投票)。FLOW-5 はアクションごとに以下を追加する。

• The list of (recipient_stake_address, amount_lovelace) tuples — the withdrawal beneficiaries and the lovelace each is to receive if the action is enacted.
• The denormalized enacted_epoch for fast filtering by "what was paid out in epoch E".

• (recipient_stake_address, amount_lovelace) のタプル一覧 — アクションが施行された場合に支払われる、引き出し受取人と各人に対する lovelace 額。
• 「エポック E で支払われたもの」での高速フィルタを可能にするための、非正規化された enacted_epoch。

FLOW-5 does not add: recipient name, recipient category, recipient project, recipient evaluation, "justification" field, "impact" estimate, or any prose interpretation of what a withdrawal funds. Recipient addresses are bech32 stake addresses, as recorded on chain, full string.FLOW-5 は以下を追加しない。受取人の名称、カテゴリー、プロジェクト、評価、「正当化」フィールド、「影響度」の見積もり、引き出しが何の資金になるかについての散文的な解釈。受取人アドレスは、オンチェーンに記録されたままの完全な bech32 ステークアドレス文字列である。

22.5 The reconciliation rule (observed vs governance-attributed)22.5 突合ルール(観測値 vs ガバナンス帰属)

For any epoch E in which one or more treasury actions have enacted_epoch = E, two quantities exist:1つ以上のトレジャリーアクションが enacted_epoch = E を持つ任意のエポック E について、2つの量が存在する。

• observed_delta(E) = treasury_snapshot.treasury_lovelace[E] − treasury_snapshot.treasury_lovelace[E−1]
• governance_attributed(E) = sum over all treasury_withdrawals rows where enacted_epoch = E of amount_lovelace, sign-flipped (withdrawals reduce treasury)

• observed_delta(E) = treasury_snapshot.treasury_lovelace[E] − treasury_snapshot.treasury_lovelace[E−1]
• governance_attributed(E) = enacted_epoch = E となるすべての treasury_withdrawals 行の amount_lovelace の合計に符号反転を加えたもの(引き出しはトレジャリーを減らすため)

The reconciliation residual is observed_delta(E) − governance_attributed(E). This residual is not an error term. Treasury balance changes for reasons that are not governance-action-driven, including but not limited to: refunds of unrefunded governance proposal deposits, refunds of DRep registration deposits on deregistration, refunds of stake-credential deposits, block-production reward flows in and out per epoch protocol mechanics, and protocol-level adjustments that are not exposed through any /proposal_list row.突合残差は observed_delta(E) − governance_attributed(E) である。この残差は誤差項ではない。トレジャリー残高は、ガバナンスアクション以外の理由でも変動する。これには次が含まれる(これに限らない): 未返還だったガバナンス提案デポジットの返還、登録解除時の DRep 登録デポジットの返還、ステーククレデンシャル・デポジットの返還、エポックのプロトコル仕様に基づくブロック生成報酬の出入り、いずれの /proposal_list 行にも露出しないプロトコル層の調整。

The observatory publishes both numbers and the residual. It does not interpret the residual as anomalous, suspicious, or fraudulent. A non-zero residual is the expected state of a complex ledger; reporting it transparently is the point.本オブザバトリーは両方の数値と残差を公開する。残差を異常、不審、不正と解釈することはない。非ゼロの残差は複雑な台帳の期待される状態である。透明に報告すること自体が目的である。

22.6 Pre-Conway treasury22.6 Conway 以前のトレジャリー

The Cardano treasury account predates Conway (it existed in Shelley, populated via protocol parameters and block production). Treasury movement before epoch 432 (the Conway-era cutover) was driven by Move Instantaneous Reward (MIR) certificates, not by CIP-1694 governance actions. MIR was a protocol mechanism, not a community-governed flow.Cardano のトレジャリー口座は Conway より前から存在していた(Shelley 時代に存在し、プロトコルパラメータとブロック生成によって積み立てられた)。エポック 432(Conway 時代への移行)より前のトレジャリー移動は、Move Instantaneous Reward (MIR) 証明書によって駆動されたものであり、CIP-1694 のガバナンスアクションによるものではない。MIR はプロトコルの仕組みであって、コミュニティにより統治されるフローではない。

FLOW-5 ingests the full /totals history available (back to the earliest epoch the endpoint exposes — currently observed to be around epoch 209). For epochs < 432, the treasury_lovelace field is reported as-is; treasury_withdrawals has no rows (no governance actions existed); the reconciliation residual is, by construction, the entire observed delta. Pre-Conway treasury changes are recorded but are not attributed to governance.FLOW-5 は /totals の取得可能な全履歴を取り込む(エンドポイントが露出する最古エポックまで — 現時点ではおおむねエポック 209 までと観測される)。エポック < 432 については、treasury_lovelace をそのまま報告する。treasury_withdrawals には行が存在しない(当該ガバナンスアクションが存在しなかった)。突合残差は構造上、観測された差分の全体に一致する。Conway 以前のトレジャリー変動は記録するが、ガバナンスには帰属させない。

22.7 What FLOW-5 explicitly does NOT do22.7 FLOW-5 が明示的に行わないこと

• It does not rank or score recipients. Stake addresses are presented in the order the chain recorded them.
• It does not categorize withdrawals by purpose. The chain does not record purpose; assigning one would be editorial.
• It does not derive "net treasury health," "burn rate," "runway months," or any forward projection. Such derivations require assumptions the observatory does not make.
• It does not flag "anomalous" withdrawals. An unusual withdrawal pattern is still on-chain fact; surfacing it as anomaly would be interpretation.
• It does not link withdrawals to off-chain identities (proposal author, funded project, Catalyst fund, organization). Such linkage requires external data sources the observatory does not maintain.
• It does not modify or extend governance_actions semantics. The action record stays exactly as §20 defines it.
• It does not retroactively alter past treasury_snapshot rows. Per /totals semantics, epoch rows are stable once published; if Koios revises a value, the observatory upserts the new value and the change is visible in the git history of the deployed snapshots.

• 受取人の順位付けやスコアリングは行わない。ステークアドレスはチェーンが記録した順序で提示する。
• 引き出しを目的別にカテゴライズしない。チェーンは目的を記録していない。目的を付与することは編集行為になる。
• 「トレジャリーの健全性」「燃焼速度」「持続月数」その他の予測を導かない。そうした導出はオブザバトリーが置かない前提を必要とする。
• 「異常な」引き出しのフラグ付けは行わない。異常に見える引き出しパターンであっても、オンチェーン上の事実であることに変わりはない。異常として浮かび上がらせれば解釈になる。
• 引き出しをオフチェーンの身元(提案者、被資金プロジェクト、Catalyst のファンド、組織)に紐付けない。そのような紐付けには、本オブザバトリーが維持しない外部データソースを必要とする。
• governance_actions の意味論を変更も拡張もしない。アクションレコードは §20 が定める形のままである。
• 過去の treasury_snapshot 行を遡及的に改変しない。/totals の意味論に従い、エポック行は公開後に安定である。Koios が値を改訂した場合、本オブザバトリーは新値を upsert し、変更はデプロイされたスナップショットの git 履歴に可視である。

22.8 Edge cases22.8 エッジケース

• Action enacted but withdrawal partially observed. A TreasuryWithdrawals action with enacted_epoch = E is expected to apply at the start of epoch E. If the published treasury_snapshot[E].treasury_lovelace reflects only part of the action's amount_lovelace, the observatory reports both numbers and the residual. It does not split, fabricate, or annotate. Interpretation is left to the reader.
• Action ratified but not yet enacted. A ratified action with enacted_epoch = null does not appear in any epoch's governance_attributed sum. Its expected effect is documented on the per-action page as a pending withdrawal; no projection is made about when it will enact.
• Action with multiple recipients of equal amount. Each (action_id, withdrawal_index) pair is its own row. Order is preserved per the chain's recorded withdrawal array; no deduplication on (recipient, amount) is performed (recipients may legitimately appear multiple times in one action).
• Recipient stake address reuse across actions. A stake address may receive funds from multiple distinct governance actions. Each is its own treasury_withdrawals row; no implicit aggregation is performed at storage. Aggregations are computable at query time; the observatory's published exports stay at the (action, recipient) grain.
• Koios revises a past /totals row. Treated as a normal upsert. If a revision changes a historical treasury_lovelace, the new value is written and fetched_at updated. The dated archive at by-date/{D}/ contains the value as known on date D; the live current snapshot reflects the latest known value. Researchers tracking revisions diff successive dated archives.
• A new TreasuryWithdrawals action appears that was not present in the prior ETL run. Normal idempotent insert; vote rows accrete as DReps cast votes over subsequent epochs.

• アクションは施行されたが引き出しは一部しか観測されない場合。enacted_epoch = E の TreasuryWithdrawals アクションは、エポック E の開始時に適用されることが期待される。公開された treasury_snapshot[E].treasury_lovelace がアクションの amount_lovelace の一部しか反映していない場合、本オブザバトリーは両方の数値と残差を報告する。分割・捏造・注釈は行わない。解釈は読者に委ねる。
• 批准されたがまだ施行されていないアクション。enacted_epoch = null の批准済みアクションは、いずれのエポックの governance_attributed 合計にも現れない。期待される効果は、アクション個別ページに「保留中の引き出し」として記載する。施行時期の予測は行わない。
• 同額の受取人を複数持つアクション。各 (action_id, withdrawal_index) の組がそれぞれ独立の行となる。順序はチェーンが記録した withdrawal 配列に従って保持する。(受取人, 金額) による重複排除は行わない(同一アクション内で受取人が複数回現れることは正当に起こり得る)。
• 受取人ステークアドレスのアクション間再利用。あるステークアドレスは、複数の異なるガバナンスアクションから資金を受け取り得る。各々は独立の treasury_withdrawals 行となる。保管段階での暗黙的集計は行わない。集計はクエリ時に計算可能であり、公開エクスポートは(アクション, 受取人)の粒度を保つ。
• Koios が過去の /totals 行を改訂した場合。通常の upsert として扱う。改訂が履歴上の treasury_lovelace を変更すれば、新値を書き込み fetched_at を更新する。by-date/{D}/ の日付付きアーカイブには、日付 D 時点で既知の値が保存される。ライブの現行スナップショットには最新の既知値が反映される。改訂を追跡する研究者は、連続する日付付きアーカイブを差分検査する。
• 前回 ETL 実行に存在しなかった新規 TreasuryWithdrawals アクションが現れた場合。通常の冪等挿入。投票行は後続エポックで DRep が投票するに従って蓄積する。

22.9 Cross-link to existing layers22.9 既存層とのクロスリンク

FLOW-5 inherits, not re-implements, every cross-link the observatory already provides:FLOW-5 は、本オブザバトリーが既に提供するすべてのクロスリンクを継承し、再実装はしない。

• The DRep vote tally on each treasury action is the same vote data §6 defines.
• The action timeline (submission → ratification → enactment | expiration | drop) is the same timeline §20.3 defines.
• The per-action JSON export at /data/snapshots/actions/{action_id}.json (§13) is extended with the withdrawal array and the enacted_epoch for that action, when those fields apply.
• The historical archive at by-date/{YYYY-MM-DD}/ (§21) includes treasury_snapshot.json and treasury fields under each affected action's per-action JSON.

• 各トレジャリーアクションに対する DRep 投票集計は、§6 が定義する投票データと同一である。
• アクションのタイムライン(提出 → 批准 → 施行 | 失効 | 廃案)は、§20.3 が定義するタイムラインと同一である。
• /data/snapshots/actions/{action_id}.json のアクション単位 JSON エクスポート(§13)は、該当する場合に withdrawal 配列と当該アクションの enacted_epoch を追加して拡張する。
• by-date/{YYYY-MM-DD}/ の履歴アーカイブ(§21)は、treasury_snapshot.json と、影響を受ける各アクションのアクション単位 JSON 内のトレジャリーフィールドを含む。

The frontend rendering and JSON export structure for treasury actions follows §13 and §20's existing patterns. No new top-level page is required by methodology; whether a standalone treasury index page is added is a separate frontend decision documented under §13 when implemented.トレジャリーアクションのフロントエンド描画および JSON エクスポート構造は、§13 と §20 の既存パターンに従う。方法論として新規のトップレベルページは要求しない。独立したトレジャリー索引ページを追加するかは別個のフロントエンド判断であり、実装時に §13 に記載する。

22.10 Published exports22.10 公開エクスポート

FLOW-5 adds the following CC0 published exports:FLOW-5 は以下の CC0 公開エクスポートを追加する。

• /data/snapshots/treasury_snapshot.json — the full treasury_snapshot table as of the current ETL run, one entry per epoch.
• /data/snapshots/treasury_withdrawals.json — the full treasury_withdrawals table, one entry per (action_id, withdrawal_index) row.
• Extension of /data/snapshots/actions/{action_id}.json (§20.6): for action_type = TreasuryWithdrawals, a withdrawal array is added with the recipient list.
• Extension of /data/snapshots/by-date/{YYYY-MM-DD}/ (§21.3, §21.13): the dated archive includes treasury_snapshot.json and treasury_withdrawals.json. Both are covered by sha256.json per §21.13.

• /data/snapshots/treasury_snapshot.json — 現 ETL 実行時点の完全な treasury_snapshot テーブル。エポックごとに1エントリ。
• /data/snapshots/treasury_withdrawals.json — 完全な treasury_withdrawals テーブル。(action_id, withdrawal_index) 行ごとに1エントリ。
• /data/snapshots/actions/{action_id}.json(§20.6)の拡張: action_type = TreasuryWithdrawals の場合、受取人一覧を含む withdrawal 配列を追加する。
• /data/snapshots/by-date/{YYYY-MM-DD}/(§21.3, §21.13)の拡張: 日付付きアーカイブに treasury_snapshot.json と treasury_withdrawals.json を含める。§21.13 に従い両者とも sha256.json の対象となる。

Each export carries schema_version and methodology_version per §13.各エクスポートは §13 に従い schema_version と methodology_version を含む。

22.11 Reproducibility commitment22.11 再現性のコミットメント

A third party can reproduce every FLOW-5 number from the same Koios endpoints the observatory uses:第三者は、本オブザバトリーが用いるのと同一の Koios エンドポイントから、FLOW-5 のあらゆる数値を再現できる。

• GET /totals returns the per-epoch series; compare to treasury_snapshot.json.
• GET /proposal_list?proposal_type=eq.TreasuryWithdrawals returns the action set; the withdrawal array on each row equals the (action_id, withdrawal_index → recipient + amount) rows in treasury_withdrawals.json.
• The dated archive at by-date/{D}/ is byte-equal to what was served on date D (§21.12), and sha256.json covers both treasury files (§21.13).

• GET /totals はエポックごとの系列を返す。treasury_snapshot.json と比較すればよい。
• GET /proposal_list?proposal_type=eq.TreasuryWithdrawals はアクション集合を返す。各行の withdrawal 配列は、treasury_withdrawals.json 内の (action_id, withdrawal_index → 受取人 + 金額) 行と一致する。
• by-date/{D}/ の日付付きアーカイブは、日付 D に提供されたものとバイト単位で一致し(§21.12)、sha256.json は両方のトレジャリーファイルを対象とする(§21.13)。

The reconciliation residual (§22.5) is itself computable from the published exports alone, without re-querying Koios. A researcher can audit any past epoch's residual entirely from the dated archive.突合残差(§22.5)それ自体は、Koios への再問い合わせなしに、公開エクスポートのみから計算可能である。研究者は過去の任意のエポックの残差を、日付付きアーカイブから完全に監査できる。

22.12 Versioning22.12 バージョニング

This section ships with methodology_version = "0.8". The version bump reflects the schema additions in §22.3 and the new exports in §22.10. The schema_version increments to 2 to reflect the table additions. Existing v0.7 consumers continue to receive every field they already had; FLOW-5 fields are additive.本節は methodology_version = "0.8" として出荷する。バージョンアップは §22.3 のスキーマ追加と §22.10 の新規エクスポートを反映するものである。テーブル追加を反映して schema_version は 2 にインクリメントする。v0.7 の既存利用者は、これまで受け取っていたフィールドをすべて引き続き受け取る。FLOW-5 のフィールドは追加のみである。

22.13 Verification protocol22.13 検証プロトコル

FLOW-5 inherits the five-layer verification structure used for earlier FLOWs (ETL, Data, Frontend, Semantics, Researcher Reproducibility) but with treasury-specific checks. Verification runs against the snapshot produced by the daily ETL after FLOW-5 code is deployed; each layer is independently passable, and a failure at any layer blocks promotion of that day's archive from "candidate" to "verified."FLOW-5 は先行する FLOW で用いた五層検証構造(ETL、データ、フロントエンド、意味論、研究者による再現性)を継承するが、トレジャリー固有のチェックを伴う。検証は FLOW-5 コードがデプロイされた後の日次 ETL が生成するスナップショットに対して実行する。各層は独立に合格可能であり、いずれかの層で不合格があれば、その日のアーカイブを「候補」から「検証済み」へ昇格させない。

The full check list lives in METHODOLOGY.md §22.13 in the repository. The summary: Layer 1 verifies ETL correctness (tip alignment, pagination exhaustiveness, idempotency); Layer 2 verifies data integrity (no duplicate keys, no FK orphans, all amounts positive, mainnet stake1 prefix); Layer 3 verifies the frontend (recipient list and total displayed for TreasuryWithdrawals only; no withdrawal section for other action types; no editorial styling); Layer 4 verifies semantics (reconciliation residual computable from archive alone; pre-Conway epochs have null withdrawals; no editorial fields present); Layer 5 verifies researcher reproducibility (third-party can fetch and reconstruct from Koios; sha256.json covers both treasury files; archive immutability holds).完全なチェック一覧はリポジトリの METHODOLOGY.md §22.13 に置く。要約: 第1層は ETL の正しさ(チップとの整合、ページネーションの網羅性、冪等性)、第2層はデータ完全性(キー重複なし、FK 孤児なし、金額は正、メインネットの stake1 接頭辞)、第3層はフロントエンド(TreasuryWithdrawals に対してのみ受取人一覧と合計を表示。他のアクション種別には引き出しセクションを表示しない。編集的なスタイルを置かない)、第4層は意味論(突合残差はアーカイブのみから計算可能。Conway 以前のエポックでは引き出しが null である。編集的なフィールドが存在しない)、第5層は研究者による再現性(第三者が Koios から取得し再構成できる。sha256.json が両方のトレジャリーファイルをカバーする。アーカイブの不変性が保たれる)。

A FLOW-5 run that fails any check at any layer is flagged in the daily verification log. Failure does not silently degrade — the affected file stays in the archive in its existing state and the next successful run reconciles forward.いずれかの層のいずれかのチェックに失敗した FLOW-5 実行は、日次検証ログに記録される。失敗時に静かに劣化することはない。影響を受けるファイルはアーカイブ内の既存状態のまま残り、次の成功実行が前進方向で突合する。

22.14 Koios field availability addendum22.14 Koios フィールド可用性の付則

This addendum records a finding from the FLOW-5 verification run on 2026-06-01 and clarifies the reconciliation basis given the actual shape of the data Koios publishes today. No schema or code changes follow from it — only methodology language is adjusted.本付則は、2026-06-01 の FLOW-5 検証実行で得られた所見を記録し、Koios が現在公開しているデータの実形状に即して突合の基準を明確化する。スキーマ・コードの変更は伴わず、方法論の言語のみを調整する。

Finding. Three fields in the Koios /totals response — treasury_withdrawal, treasury_donation, and reserves_withdrawal — are present in the response schema but were observed as null for every one of the 426 epochs in the chain history at the time of verification (Cardano epochs 209–634, probed 2026-06-01). The fields are documented in the upstream API as per-epoch totals, but Koios does not currently populate them.所見。Koios /totals レスポンスの3つのフィールド — treasury_withdrawal、treasury_donation、reserves_withdrawal — はレスポンス・スキーマには存在するが、検証時(2026-06-01 にプローブした Cardano エポック 209–634 の全 426 エポック)においていずれも null と観測された。これらのフィールドは上流 API ドキュメント上はエポック単位の合計値として記載されているが、Koios は現在これらを埋めていない。

Implication for §22.5 reconciliation. The observed treasury movement for an epoch N is observed_Δ(N) = treasury_lovelace(N) − treasury_lovelace(N−1), computed from successive rows of treasury_snapshot. It is not derived from the always-null treasury_withdrawal_epoch_total. The governance-attributed sum is SUM(treasury_withdrawals.amount_lovelace WHERE enacted_epoch = N). The residual is the difference, adjusted for protocol inflows (fees into treasury, reserves-to-treasury transfers, deposit refunds). Per §22.5 the residual is not interpreted as error.§22.5 の突合への含意。エポック N における観測されたトレジャリー変動は observed_Δ(N) = treasury_lovelace(N) − treasury_lovelace(N−1) であり、treasury_snapshot の連続行から計算する。常時 null である treasury_withdrawal_epoch_total から導出するのではない。ガバナンス帰属の合計は SUM(treasury_withdrawals.amount_lovelace WHERE enacted_epoch = N) である。残差は両者の差から、プロトコル流入(トレジャリーへの手数料、リザーブからトレジャリーへの移動、デポジット返還)を調整したものとなる。§22.5 に従い、残差を誤差として解釈することはない。

Why the three fields remain in the schema. The defensive capture is intentional. If Koios begins populating any of these fields in a future release, the next daily ETL run captures them automatically with no code change, no schema migration, and no risk of silent omission. Honest reporting of current Koios behavior in the methodology is sufficient — the schema does not need to mirror Koios's current sparsity.3 フィールドをスキーマに残す理由。防御的取り込みは意図したものである。Koios が将来これらいずれかのフィールドを埋め始めれば、次の日次 ETL がコード変更・スキーマ移行・暗黙的欠落のリスクを伴わずに自動で取り込む。Koios の現挙動を方法論で誠実に報告すれば十分であり、スキーマが Koios の現在の希薄性を映す必要はない。

methodology_version remains 0.8. This addendum is a clarification of the existing §22.5 and §22.13 language, not a new methodological commitment, so no version bump is warranted. schema_version remains 2.methodology_version は 0.8 のままとする。本付則は既存の §22.5 および §22.13 の言語の明確化であって、新たな方法論的コミットメントではない。バージョンアップは行わない。schema_version は 2 のままである。

12. v0.1 scope limitations12. v0.1 における対象範囲の制限

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:v0.1 では本サイトを意図的に狭く保つ。以下は本バージョンの対象範囲外であり、合成値や補間値で覆い隠すことなく、ここに透明性をもって開示する。

• 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.

• 委任者数は、日次実行ごとに上位60候補に対してのみ取得する(余裕を持って上位30順位を支えるため)。すべての現役 DRep については取得しない。残りの現役 DRep は、必要な者が下層の Koios API 経由で参照できる。
• 履歴のバックフィルはまだ実装していない。Δ7日間 と Δ30日間 の各フィールドは、初回デプロイから7日分・30日分の日次スナップショットが蓄積するまで — として表示される。90日チャートはローンチ以降の前進累積で値が入る。
• 投票結果は編集的に解釈しない。votes テーブルは事実のみを保持する — (action_id, drep_id, vote ∈ {yes, no, abstain}, vote_epoch)。整合性スコアリングも、「コンセンサスとともに投票」「コンセンサスに反して投票」のフレーミングも、投票ごとの解釈も行わない。ガバナンスアクションの結果(enacted、ratified、dropped、expired、active)は Koios フィールドから決定的に導出され、同様に価値判断を含まない。

These limitations resolve over time. They are not concealed and are not approximated.これらの制限は時間とともに解消される。隠蔽もしないし、近似値で覆うこともしない。