There’s a TermMax design that’s pretty unremarkable at first glance, but when I was browsing the documentation, I stopped to look at it for quite a while.
When I used to look into DeFi security, my first instinct was basically to check audits, multisigs, and whether there had been any incidents. But TermMax has something more subtle here: some key parameters aren’t something an admin can just change—then they take effect instantly.
Its Vault has a Timelock.
Roughly, the process is: the Curator first submits the change, then it enters a waiting period. Only after the time is up can it be formally accepted. The default waiting time is 1 day, and this isn’t something you can set arbitrarily—the official range is a minimum of 1 day and a maximum of 30 days. During the waiting period, there’s also a role called the Guardian, who can review modifications that haven’t taken effect yet. If something looks wrong, they can remove/cancel it. (TS Finance Docs)
I think the most useful part here isn’t the number “24 hours” itself—it’s that it intentionally leaves a gap.
If, for example, a fee parameter is changed by mistake, or there’s a permissions problem, and the change executes immediately, the faster the chain processes it, the less time there is for others to notice the issue. A Timelock effectively splits “submitting the change” and “the change actually taking effect” into two separate things.
TermMax even adds Timelock protection separately to places like the Oracle—areas that affect collateral valuation and liquidation decisions. (TS Finance Docs)
This kind of design usually doesn’t make much of a splash.
When the market is normal, nobody is going to think it’s that impressive just because a protocol parameter change has to wait a day. People might even find it annoying or inconvenient. But if something abnormal happens—like a permission failure or an incorrect action—then that day may be exactly the window for checking, discovering the problem, and rolling back the change.
So when I look at a protocol now, I end up turning an extra page in the background mechanisms.
The homepage APY is for everyone to see. What makes me want to dig a little deeper isn’t the headline number—it’s whether, in case something goes wrong, it leaves users time.
When you look at DeFi projects, do you specifically check things like Timelocks?
@TermMax #TermMax
When I used to look into DeFi security, my first instinct was basically to check audits, multisigs, and whether there had been any incidents. But TermMax has something more subtle here: some key parameters aren’t something an admin can just change—then they take effect instantly.
Its Vault has a Timelock.
Roughly, the process is: the Curator first submits the change, then it enters a waiting period. Only after the time is up can it be formally accepted. The default waiting time is 1 day, and this isn’t something you can set arbitrarily—the official range is a minimum of 1 day and a maximum of 30 days. During the waiting period, there’s also a role called the Guardian, who can review modifications that haven’t taken effect yet. If something looks wrong, they can remove/cancel it. (TS Finance Docs)
I think the most useful part here isn’t the number “24 hours” itself—it’s that it intentionally leaves a gap.
If, for example, a fee parameter is changed by mistake, or there’s a permissions problem, and the change executes immediately, the faster the chain processes it, the less time there is for others to notice the issue. A Timelock effectively splits “submitting the change” and “the change actually taking effect” into two separate things.
TermMax even adds Timelock protection separately to places like the Oracle—areas that affect collateral valuation and liquidation decisions. (TS Finance Docs)
This kind of design usually doesn’t make much of a splash.
When the market is normal, nobody is going to think it’s that impressive just because a protocol parameter change has to wait a day. People might even find it annoying or inconvenient. But if something abnormal happens—like a permission failure or an incorrect action—then that day may be exactly the window for checking, discovering the problem, and rolling back the change.
So when I look at a protocol now, I end up turning an extra page in the background mechanisms.
The homepage APY is for everyone to see. What makes me want to dig a little deeper isn’t the headline number—it’s whether, in case something goes wrong, it leaves users time.
When you look at DeFi projects, do you specifically check things like Timelocks?
@TermMax #TermMax