The Term Finance $1.5M Exploit and the Case for Real-Time Defense

Overview

In late April 2025, Term Finance—a fixed-rate lending protocol—suffered an exploit resulting in roughly $1.5 million in losses. The incident was triggered by a faulty price oracle update for Term’s tETH price feed, which suddenly mispriced collateral and enabled an attacker to perform an abnormal liquidation. Over the span of two quick transactions, the attacker paid a trivial amount of ETH to seize a large amount of collateral, then swiftly moved those funds out of the protocol. Term Finance reported that no smart contracts were directly breached (the bug was isolated to the oracle) and pledged to fully reimburse affected users. This post-mortem analyzes the technical timeline of the exploit and explains how FailSafe’s real-time rule engine could have detected the anomaly and automatically stopped the attack mid-flight. The incident underscores the need for active on-chain defenses like FailSafe that can intervene in the narrow window when multi-step exploits unfold across blocks.

Technical Breakdown and Timeline

The confirmed on-chain timeline shows the attacker executed two transactions in rapid succession to exploit Term Finance’s tETH market:

1. Transaction #1: Block 22353826 @ 02:31:59 PM UTC

Term had a mismatch in decimal precision between oracle components—one component outputting values with 18 decimals instead of the correct 8 decimals. This inconsistency caused Term’s oracle to drastically undervalue tETH, making previously healthy collateralized positions appear under-collateralized.

The attacker capitalized on this glitch by triggering liquidations. With only a very small ETH repayment, they liquidated positions holding over 586 tETH as collateral, obtaining those tokens for far less than their true value. In other words, the attacker paid a pittance (the under-collateralized debt) to seize about $1.5 million worth of ETH-backed assets in this transaction.

2. Transaction #2: Block 22353827 @ 02:32:11 PM UTC

12 seconds later, the attacker’s follow-up transaction extracted the stolen funds. In this step, the attacker swapped or withdrew the seized tETH for actual ETH and transferred the proceeds to their own addresses, effectively draining the mis-priced collateral from Term Finance’s reserves. This second transaction finalized the exploit, converting the illicit gain into assets under the attacker’s control.

The root cause of this two-step attack was traced to a misconfigured tETH price oracle, which fed an incorrect price and erroneously marked healthy positions as liquidatable. Term Finance confirmed that this was an oracle issue (not a smart contract vulnerability) and that the problem was contained to the tETH price feed. Notably, the exploit was not an atomic, single-block event—it was split across two consecutive blocks. This separation is critical: it provided a brief window (on the order of one block time) between the malicious actions. In that short interval, an automated security mechanism could detect the irregular liquidation from Transaction #1 and potentially intervene before Transaction #2 was processed and confirmed.

How FailSafe Would Have Stopped the Hack

The Term Finance incident is a prime example of an attack where FailSafe’s real-time monitoring and auto-response would excel. Because the attacker’s exploit unfolded in two distinct steps (across two blocks), FailSafe would have had the opportunity to catch the issue in the first step and disrupt the second. Here’s how FailSafe could have stopped this hack:

• Immediate Anomaly Detection: FailSafe’s rule-based engine continuously watches for invariant violations in protocol activity. In this case, the Liquidation event in Transaction 1 would have triggered a FailSafe rule flagging an outsized collateral seizure relative to the debt repaid (e.g. hundreds of ETH taken for a negligible payment). Such a real-time invariant violation alert indicates that something was drastically wrong (consistent with an oracle failure or logic bug). FailSafe’s system would detect this suspicious liquidation as soon as the first transaction executed, within seconds.
• Automated On-Chain Response: Upon detecting the anomaly, FailSafe would have immediately broadcast an on-chain emergency action before the next block was mined. For example, FailSafe could trigger a protocol pause on the affected market or a token transfer freeze for tETH using pre-programmed admin controls. This transaction, if mined at the start of Block 22353827, would effectively stop the attack in its tracks—the attacker’s pending second transaction would be blocked or reverted because the protocol had been paused/frozen in time. In practice, FailSafe acts as an autonomous security guardian: it doesn’t just alert, it actively intervenes by executing protective measures on-chain as soon as a rule is violated.

Because the Term Finance attacker relied on a multi-step exploit across multiple blocks (rather than a single instantaneous exploit), FailSafe’s fast reaction cycle could have made all the difference. Our system’s ability to detect threats on the fly and respond within the same block interval means that an attacker’s window for success shrinks dramatically. In this scenario, FailSafe would have caught the irregular liquidation in block 22353826 and prevented the follow-up theft in block 22353827. This highlights a key FailSafe advantage: in situations where hackers can’t (or don’t) execute an entire attack atomically, FailSafe’s invariant monitoring and automatic response provide a powerful defense, halting attacks mid-execution. With FailSafe, even a matter of seconds is enough to turn a nearly catastrophic hack into a thwarted attempt, protecting protocols and their users from loss.