DUSKの収監クロックをもう一度テストするつもりはなかった。私は利回りを受け取るために、自分のテストネット報酬ダッシュボードを開いただけだった。そこで見たのはこれだ。最終性プロバイダーの稼働率は99.1%で、直近3か月の14回の収監リセット（jail-reset）イベント。

そのダッシュボードは何も通知しなかった。まるで履歴書が日付を引き延ばして空白を隠すように、黙ってそれらを履歴へ格納していた。リセットのたびにStartHeightが再アンカーされ、古いものが成熟する前に28時間のライブログ（liveness）ウィンドウをやり直してしまう。つまりそのプロバイダーは信頼できない。再エントリーによって不在を“取り繕う”ことで成り立っていた。

私は、めったに姿を見せないバリデータから報酬を複利で積み上げていた。というのも、不在のペナルティは、見逃したエポックよりも先に失効するからだ。私が信じていた指標――稼働率――は可用性を測っていない。測っているのは、オペレーターが自分の言い訳（アリバイ）をどれだけ更新し直せるかだ。

その夜、DUSKのボイスチャットではPhoenixやCitadelの話はされていなかった。オンチェーンの収監リセット件数をどう監査するのかを尋ねている、Maraというユーザーの話だった。誰もきれいな答えを出せなかった。データは存在する。

ただ、インターフェースには表示されない。私たちは皆、本当に起きていて活動しているのを見たことのないオペレーターに委任していた。なぜなら、重要なのは“騙されるように設計された”数値だけだったからだ。スラッシングは悪意を罰する。収監は不注意を罰するはずだった。だが実際には、収監は時計が追いつく前に再エントリーし忘れた人だけを罰する。ネットワークは、悪意あるバリデータを用意する必要すらない。

必要なのは、「不在は、正しいブロック高で戻ってくる限り無料だ」と理解しているオペレーターが十分にいることだけだ。計算は明確だ。レポートされる可用性は、明確ではない。

#dusk $DUSK @Dusk $ACE $AKE