有个 TermMax 的设计很不起眼，但我翻文档时停下来看了挺久。
以前看 DeFi 安全，我第一反应基本都是审计、多签、有没有出过事故。TermMax 这里倒有个更细的东西：一些关键参数不是管理员想改，下一秒就能生效。
它的 Vault 有 Timelock。
大概流程是，Curator 先提交修改，然后进入等待期，时间到了才能正式接受。默认等待时间是 1 天，而且这个时间不是随便设的，官方给出的范围是 最短 1 天，最长 30 天。等待期间还有 Guardian 这个角色，可以检查尚未生效的修改，发现不对可以撤掉。(TS Finance Docs)
我觉得这里最有用的不是“24 小时”这个数字，而是它故意留了一段空档。
假如某个费用参数被误改，或者权限出了问题，如果修改立即执行，链上速度越快，留给别人发现问题的时间反而越少。Timelock 相当于把“提交修改”和“真正生效”硬拆成了两件事。
TermMax 连 Oracle 这种影响抵押品估值、清算判断的地方，也单独加了 Timelock 保护。(TS Finance Docs)
这种设计平时其实没什么存在感。
行情正常的时候，没人会因为一个协议“参数修改要等一天”就觉得它多厉害，甚至还可能嫌麻烦。但真遇到异常权限或者错误操作，这一天可能就是检查、发现和撤销修改的窗口。
所以我现在看协议，会多翻一页后台机制。
首页 APY 是给所有人看的，真正让我愿意多研究一会儿的，反而是出问题的时候，它给没给用户留时间。
你们看 DeFi 项目时，会专门查 Timelock 这种东西吗？
@TermMax #TermMax
以前看 DeFi 安全，我第一反应基本都是审计、多签、有没有出过事故。TermMax 这里倒有个更细的东西：一些关键参数不是管理员想改，下一秒就能生效。
它的 Vault 有 Timelock。
大概流程是，Curator 先提交修改，然后进入等待期，时间到了才能正式接受。默认等待时间是 1 天，而且这个时间不是随便设的，官方给出的范围是 最短 1 天，最长 30 天。等待期间还有 Guardian 这个角色，可以检查尚未生效的修改，发现不对可以撤掉。(TS Finance Docs)
我觉得这里最有用的不是“24 小时”这个数字，而是它故意留了一段空档。
假如某个费用参数被误改，或者权限出了问题，如果修改立即执行，链上速度越快，留给别人发现问题的时间反而越少。Timelock 相当于把“提交修改”和“真正生效”硬拆成了两件事。
TermMax 连 Oracle 这种影响抵押品估值、清算判断的地方，也单独加了 Timelock 保护。(TS Finance Docs)
这种设计平时其实没什么存在感。
行情正常的时候，没人会因为一个协议“参数修改要等一天”就觉得它多厉害，甚至还可能嫌麻烦。但真遇到异常权限或者错误操作，这一天可能就是检查、发现和撤销修改的窗口。
所以我现在看协议，会多翻一页后台机制。
首页 APY 是给所有人看的，真正让我愿意多研究一会儿的，反而是出问题的时候，它给没给用户留时间。
你们看 DeFi 项目时，会专门查 Timelock 这种东西吗？
@TermMax #TermMax