私はDusk公式の監査インデックスの12行を並べ替え直し、まずコンポーネントごとに分類してから、日付を横に貼りました。表が完成したあと、もともととても言い回しが自然だった「Duskはすでに監査済み」という一文が、そのまま書けなくなってしまいました。各レポートにはそれぞれ対象と時期があり、どの行も「現在の全コードスタックの総合証明書」という名前ではないのです。

いちばん後ろの2項目は2026年4月のERC20およびBEP20のセキュリティ評価です。中核プロトコル、コンセンサス、ノード、Phoenixなどのレポートは主に2023〜2024年に集中しています。ここで重要なのは、新旧のどちらが上かではなく、レポートは実際に確認したコンポーネントのことしか語れない、という点です。後から追加されたモジュールや大きく変更されたバージョンは、プロジェクト名が同じだからといって、旧レポートの結論をそのまま引き継げません。

この表は、私の核となる検証アクションを本当に変えました。今後セキュリティの宣伝を見ても、「監査に意味があるのか」を最初に議論せず、まず次の4点を確認します。レポート名、対象の被監査コンポーネント、監査日、対応するバージョン。この4つが揃って初めて、調査結果の指摘事項や修正の提出（フィックスのレシート）を読み進めます。プロジェクトのロゴや監査機関のロゴだけが提示されていても、情報は宣伝のレベルで止まってしまいます。

$DUSK にとって、このような限定は、わざと反対意見を唱えることではありません。監査リポジトリが公開され、レポートが追跡できること自体が良いことです。範囲を正しく言い切ってこそ、どこに既存の証拠があるのか、どこはバージョン変更のために追加で裏取りが必要なのかが見えてきます。旧レポートを「無効」と雑に判定する必要もありません。ただし、それは未カバーの対象を自動的に保証してくれるわけではない、というだけです。

さらに、残り2つのことはこの12行からは導けません。今回、各レポートの品質を評価していませんし、問題がすべて修復済みかどうかも項目ごとに検証していません。公開インデックスに載っていない材料があるとしても、それが他の場所に絶対に存在しないことを証明できるわけではありません。@Dusk が提示しているインデックスは入口としては適切ですが、結論の到達点ではありません。

「監査済み」という一言は多くの文字を省いてくれる一方で、最も重要な境界も省いてしまいます。12行をばらして見たことで、セキュリティ判断には追跡可能な主語・時間・バージョンがようやく備わりました。次に誰かがプロジェクト全体の口径で結論を述べるときは、まず「いったいどの行なのか」を指摘してもらいます。#dusk