Over the past few years, while auditing various kinds of underlying code, I’ve seen far too many pause (“pause”) and unpause (“resume”) functions—and TermMax V2’s contract code keeps these two high-risk interfaces as well. From the team’s perspective, the original intent is certainly good: if a hacker attack occurs or a catastrophic contract vulnerability is exploited, an administrator can hit the pause button immediately to freeze all transactions and preserve the assets in the pool.
But for a lending protocol that focuses on “fixed term (FT)” and “exit at any time (Smart Unwind),” this is actually a fatal logical paradox. Fixed-rate products have extremely strict requirements for liquidity and time windows. Imagine this scenario: when the broader market crashes and your position is nearing liquidation, you want to add collateral before liquidation—or you plan to use the Smart Unwind mechanism to withdraw funds early at a discount to cut losses. At that moment, the administrator decides the system as a whole is at risk and directly calls the pause interface. Your money is instantly forcibly locked inside the contract, and any on-chain action will be rolled back.
When the storm passes and prices have already fallen sharply, the administrator calls unpause to resume trading. By then, your collateralization ratio has already dropped below the threshold—once trading resumes, you’ll be liquidated immediately by liquidation bots. Throughout this process, you made no operational mistake at all. You’re forced to bear the full consequences of the liquidation purely because of the administrator’s defensive action.
My view: keeping emergency pause authority is understandable, but this sword must not be hanging over traders’ heads without constraints. The team must clearly hard-code at the code level: during a pause, can liquidation be triggered or exempted? If forced locking prevents users from adding collateral, who will bear the loss after the system is unfrozen? Treating users’ liquidity as a free buffer for the system’s risk avoidance—this kind of unequal risk transfer is something I absolutely cannot accept.
#termmax @TermMax $BTC
But for a lending protocol that focuses on “fixed term (FT)” and “exit at any time (Smart Unwind),” this is actually a fatal logical paradox. Fixed-rate products have extremely strict requirements for liquidity and time windows. Imagine this scenario: when the broader market crashes and your position is nearing liquidation, you want to add collateral before liquidation—or you plan to use the Smart Unwind mechanism to withdraw funds early at a discount to cut losses. At that moment, the administrator decides the system as a whole is at risk and directly calls the pause interface. Your money is instantly forcibly locked inside the contract, and any on-chain action will be rolled back.
When the storm passes and prices have already fallen sharply, the administrator calls unpause to resume trading. By then, your collateralization ratio has already dropped below the threshold—once trading resumes, you’ll be liquidated immediately by liquidation bots. Throughout this process, you made no operational mistake at all. You’re forced to bear the full consequences of the liquidation purely because of the administrator’s defensive action.
My view: keeping emergency pause authority is understandable, but this sword must not be hanging over traders’ heads without constraints. The team must clearly hard-code at the code level: during a pause, can liquidation be triggered or exempted? If forced locking prevents users from adding collateral, who will bear the loss after the system is unfrozen? Treating users’ liquidity as a free buffer for the system’s risk avoidance—this kind of unequal risk transfer is something I absolutely cannot accept.
#termmax @TermMax $BTC