TermMax の設計はわりと地味ですが、ドキュメントを読み返しているときに思わず立ち止まって、かなり長い時間見入ってしまいました。

以前 DeFi のセキュリティを見るときは、私の最初の反応はだいたい「監査」「マルチシグ」「事故が起きたことがあるか」でした。TermMax にはそれとは別に、もう少し細かい仕組みがあります。つまり、いくつかの重要なパラメータは管理者がすぐには変更できず、次の瞬間には反映されないということです。

TermMax の Vault には Timelock があります。

だいたいの流れは、Curator がまず変更を提出し、その後待機期間に入って、時間が来てから正式に受け付けられる、というものです。デフォルトの待機時間は 1 日で、この時間は適当に設定できるわけではありません。公式が示している範囲は、最短 1 日、最長 30 日です。待機期間中は Guardian という役割もいて、まだ有効になっていない変更を確認できます。おかしければ撤回できます。（TS Finance Docs）

ここで最も有用なのは「24 時間」という数字そのものではなく、意図的に“空白の時間”を作っている点だと思います。

たとえば、ある手数料パラメータが誤って変更されたり、権限に問題が起きたりした場合に、変更が即時実行されるなら、オンチェーンの反映が速いほど、問題に気づいてもらえる時間はむしろ短くなります。Timelock は「変更を提出すること」と「本当に有効になること」を、きっちり二つに分けているのです。

TermMax は Oracle のように、担保の評価や清算判断に影響する領域にも、別途 Timelock による保護を加えています。（TS Finance Docs）

こうした設計は、普段は正直あまり存在感がありません。

相場が正常なときは、あるプロトコルが「パラメータ変更には 1 日待つ必要がある」といっても、大したことだとは思われないし、面倒だと感じられることすらあります。しかし、異常な権限や誤操作に直面したとき、この 1 日こそが「確認」「発見」「変更の撤回」を行うための窓になる可能性があります。

だから私は今、プロトコルを見るときは、裏側のメカニズムをもう 1 ページ多めにめくるようになりました。

フロントページの APY は誰にでも見せるものです。私がもう少し研究する気になるのは、むしろ問題が起きたときに、ユーザーに時間を残してくれているかどうかです。

皆さんは DeFi プロジェクトを見るとき、Timelock のようなものを特に調べますか？

@TermMax #TermMax