我把 @TermMax の安全ページ、監査リポジトリ、そして権限の説明を一緒に見てみたところ、「監査済み」というのは実はいちばん外側の層にすぎません。本当にトラブルが起きたときにシステムがどう反応するかを決めているのは、どのコントラクトが変更可能か、誰が停止（停止/一時停止）できるのか、そして重要な権限がどのように共同で管理されているかです。#TermMax

公開リポジトリには現在、ABDKの段階的レポート、TMXのレポート、Cantinaのコンペティションレポートが挙げられており、Immunefiにも稼働中の脆弱性報奨金があります。ドキュメントには、24時間のオンチェーン監視と自動停止の仕組みについても書かれています。これらの情報は、プロジェクトが多層防御を施していることを示していますが、それは「問題が起きることが今後一切ない」という意味ではなく、「問題の発見」と「対応時間の短縮」を目的としている、ということです。

権限層までさらに分解すると、TermMaxは重要な管理アクションを4-of-6のマルチシグに委ね、市場間には隔離が設けられています。VaultのパラメータにはtimelockとGuardianによる抑制（相互牽制）もあります。さらに、公式としても緊急停止能力を明確に保持しており、一部コンポーネントにはアップグレード可能な手当ても採用されています。言い換えれば、このシステムの安全性は「誰も管理できない」という発想ではなく、隔離・遅延・複数者の共同承認・緊急時のアクションによって、単一障害点のリスクを制限することで担保しているのです。

市場の隔離については、これは別途きちんとメモしておきます。ある市場が独立してデプロイされているからといって損失が絶対に起きないわけではありませんが、それが表しているのは、故障の境界をできるだけ他の市場へ拡散させないことです。安全設計は、しばしば「リスクを消し去る」よりも先に、「一度の誤りが波及する範囲を狭める」ことを重視します。

私はむしろ、「コードは法律」という一文よりも、こっちのほうがよほど見ておく価値があると思います。なぜならDeFiで例外が起きたときは、結局次の2つの具体的な問いへの回答が必要になるからです。権限は十分に素早く発動できるのか、そして境界は十分に狭いのか。遅すぎれば止める前に手遅れになる可能性があり、広すぎればガバナンスそのものがリスク源になってしまいます。

なので今後も、マルチシグのメンバーが変化したかどうか、アップグレード可能なコンポーネントの範囲、停止（停止/一時停止）イベント、そして監査後の修復記録を引き続き追っていきます。監査レポートは「有人が真剣に問題を探した」ことを示してくれますし、権限の軌跡は「現実の場面でシステムが問題にどう対処しているか」を教えてくれるからです。