On August 23, 2026, approximately $8.5 million was drained from Term Finance’s Ethereum vaults despite the protocol having a seven-day timelock.
This was not a conventional exploit involving reentrancy, oracle manipulation, flash loans or compromised private keys. The attacker abused Term Finance’s custom governance system, while the underlying vault contracts executed actions they considered authorized.
We will do our best to explain the attack and the problem with the timelock as simply as possible.
The attack followed six main steps:
- The attacker submitted a malicious governance proposal.
- Nobody vetoed it during the voting window.
- The proposal became executable.
- The proposal disabled the 7-day timelock.
- The remaining actions executed immediately.
- Approximately $8.5 million was drained.
1. The attacker submitted a malicious proposal
On the ETH side, the attacker deposited approximately 0.5 ETH into the Meta Vault and received 0.4852 tmvETH shares. This represented only around 0.017% of the total share supply.
Shortly afterwards, a newly deployed contract controlled by the attacker submitted proposal 5.
The proposal contained 17 actions designed to remove the timelock, withdraw WETH from legitimate strategies and redirect it into a contract controlled by the attacker.
It also used the same generic description as previous legitimate proposals:
Vote YES to veto the curator’s proposed vault parameter changes. Otherwise, the transaction will become executable when this proposal expires.
The description looked routine, but the underlying calldata was publicly available and contained the attacker’s contracts several times.
One important question remains unanswered. Why could an unprivileged address with such a small vault position submit a proposal with this level of authority?
The onchain evidence shows that it happened, but Term Labs has not yet published a complete postmortem explaining the authorization path.
2. Nobody vetoed the proposal
For those who do not understand the difference between approval governance and veto governance, it is simple.
With approval governance, supporters must actively vote to approve a proposal. If nobody votes, the proposal fails.
Veto governance works in the opposite way. Participants are given time to object. If the required veto threshold is not reached, the system assumes everyone is fine with the proposal and allows it to proceed.
Term Finance used veto governance.
The attacker submitted the ETH proposal on August 17. Vault LPs then had approximately six days to inspect and reject it.
Nobody did.
No legitimate LP, curator, guardian or security operator reached the required veto threshold, even though the proposal and its malicious calldata were publicly visible.
This was the first failure. A waiting period only creates time to react. It cannot force anyone to monitor the proposal or stop it.
3. The proposal became executable
After the veto window expired, the governance contract considered the proposal valid.
This did not mean the funds had already moved. It meant the attacker was now permitted to begin executing the proposal’s 17 actions.
The veto window closed at approximately 06:25:35 UTC on August 23. Twelve seconds later, the attacker called executeProposal().
The attacker did not need to convince a majority of depositors to support the proposal. They only needed to submit it and wait for nobody to veto it.
However, another protection was still supposed to stand between the proposal and the vault’s assets. This was a Zodiac Delay Module with a cooldown of 608,400 seconds, which is slightly more than seven days.
Normally, transactions passing through this module should be queued and delayed before execution.
4. The proposal disabled its own timelock
This is the most important part of the attack.
The proposal’s first actions included:
- setTxCooldown(0)
- setTxExpiration(0)
- enableModule(attackerExecutor)
Immediately before the exploit transaction, the Zodiac cooldown was still set to 608,400 seconds. The proposal then changed it to 0.
The confusing part is that two different waiting mechanisms existed.
The first was the governance veto window. It gave LPs several days to reject the entire proposal.
The second was the Zodiac transaction cooldown. It was supposed to delay the individual transactions sent to the vault’s Gnosis Safe.
The proposal survived the first waiting period because nobody vetoed it. Once it became executable, its first action removed the second waiting period.
The change to the timelock was not protected by its own independent delay. The same governance system constrained by the timelock could immediately disable it.
Once the cooldown became zero, the attacker could queue and execute the remaining actions in the same transaction.
The timelock did not technically malfunction. The problem was that governance was allowed to turn it off.
5. The remaining actions executed immediately
After disabling the cooldown, the proposal recalled WETH from four legitimate strategies used by the ETH Meta Vault.
It reduced their debt allocations to zero, returning approximately:
- 44.37 WETH from Shorewoods ETH
- 43.88 WETH from August Digital ETH
- 1,445.51 WETH from Parity Prime ETH
- 1,307.98 WETH from Parity Core ETH
These strategies held positions across protocols including Aave and Morpho.
The proposal then added a contract controlled by the attacker as an authorized strategy. The contract reportedly called itself:
Fixed Recipient WETH Exit Strategy
Its maximum debt was set to type(uint256).max, allowing the vault to allocate an effectively unlimited amount of WETH to it.
The vault transferred approximately 2,841.74 WETH to the malicious strategy, which immediately forwarded the assets to the attacker.
A second transaction used a similar path against five USDC vaults and extracted approximately 1.68 million USDC. The attacker later swapped it into DAI.
The total loss was approximately $8.46 million, commonly reported as $8.5 million.
6. A timelock is not a security guarantee
The lesson is not that timelocks are useless.
A timelock gives teams, depositors and security operators time to inspect and stop dangerous actions. But it only provides an opportunity to react. It cannot guarantee that someone will actually react.
In Term Finance’s case, the first delay remained public for days, but nobody vetoed the proposal.
The second delay existed, but the proposal could set it to zero.
The first protection failed because nobody responded. The second failed because governance controlled the mechanism intended to restrict it.
Protocols should therefore ask more than whether a timelock exists:
- Who can submit proposals?
- Does a proposal require active approval, or does silence allow it to pass?
- Who monitors proposals and inspects their calldata?
- Can an independent guardian cancel malicious actions?
- Can governance modify or remove the timelock?
- Are timelock changes protected by a separate delay that cannot be bypassed?
A timelock does not automatically prevent malicious governance. It only creates time for someone to notice and respond. It provides little protection if the proposal can simply turn it off.