How a Forgotten yETH Pool Let an Attacker Mint Infinite Tokens and Walk Away With $9 Million

An old, largely overlooked corner of the Yearn ecosystem became the site of a nine-figure — in token count, not dollars — minting event on November 30. A custom stableswap pool for the yETH liquid staking aggregator, a product the team had all but stopped maintaining, was manipulated into creating 235,443,031,407,908,519,912,635,443,025,109,143,978,181,362,622,575,235,916 units of yETH out of nothing. The figure is not an error; it is simply astronomically large.

The mint enabled a drain that emptied the pool of roughly $9 million in a single transaction, with about 1,000 ETH subsequently routed through Tornado Cash. Yearn's V2 and V3 vaults were unaffected — a narrow silver lining for a protocol now counting its third separate exploit.

Credit: Blocksec, Togbe, yearn, Peckshield, Defi Chad, Banteg, William Li, Blockscout, BanklessTimes

01Detection came after the fact

The first sign of trouble surfaced when researcher Togbe flagged unusual activity on November 30: heavy Tornado Cash traffic paired with abnormal liquid-staking-token movement across Yearn, Rocket Pool, Origin, and Dinero. Shortly after, the same researcher observed the yETH supply figures breaking down entirely, with supply effectively minted to infinity. By that point the exploit was not unfolding — it had already concluded.

PeckShield's alert followed, by which time the funds were already gone. On-chain data pinpoints the attack to 21:11 UTC: a single atomic transaction minted an estimated 235 trillion yETH tokens and cleaned out the pool in one move.

Yearn's public acknowledgment came afterward: "We are investigating an incident involving the yETH LST stableswap pool. Yearn Vaults (both V2 and V3) are not affected." Roughly six hours passed before the team disclosed concrete figures: $8 million pulled from the yETH stableswap pool and another $0.9 million from the yETH-WETH pool on Curve, putting total losses at $9 million.

At the time, about 1,000 ETH — roughly $3 million — had already gone through Tornado Cash, while the remaining ~$6 million still sat in the attacker's wallet. Yearn brought in SEAL911 and ChainSecurity to run point on the incident, and drew comparisons to the recent Balancer exploit — another case where rounding-level precision errors translated into a major payout. Early signs suggested the post-mortem would not be quick.

This is Yearn's third exploit. An $11 million flash loan attack hit the protocol in 2021, and a 2023 incident stemmed from a misconfiguration in the yUSDT token contract. What stands out this time is that the flaw was surfaced through casual, independent research into a product the team itself had largely stopped thinking about.

02Anatomy of the exploit

yETH ran on a bespoke stableswap design with its own math for aggregating liquid staking tokens — architecturally separate from Yearn's vaults, with no shared code with V2 or V3, and without active maintenance attention.

Per Banteg's post-mortem and William Li's technical writeup, the attacker did not find a flaw in the math itself — they used the math as designed to produce an unintended outcome, in two stages.

Stage one — destabilizing the invariant. Repeated remove_liquidity(0) calls — withdrawals of zero value that still forced recalculation — shifted the pool's virtual balances without moving any real assets. Layered with update_rates() calls and a rounding mismatch between the pow_up and pow_down functions, each cycle pushed the relationship between the balance sum (Σ) and balance product (Π) further out of alignment. OETH's automatic rebasing added further noise, until the invariant no longer reflected any coherent state. By the final withdrawal, the pool sat at Σ = 0, Π = 0, and supply = 0 — a state with no physical meaning, which the contract nonetheless accepted without complaint.

Stage two — forcing the mint. The attacker then deposited amounts of negligible value: 1 wei each of wstETH, rETH, and cbETH, plus 9 wei of mETH. That tiny deposit triggered calc_supply(), the Newton-Raphson solver responsible for determining how many LP tokens to issue. Asked to solve for the corrupted Σ/Π relationship, combined with the amplification factor A = 4.5 × 10²⁰, the solver ran into an unchecked arithmetic underflow.

The underlying formula, s' = (AΣ − sr) / (A − PREC), produces a negative numerator whenever AΣ falls below sr. In EVM arithmetic, that negative value wraps around to roughly 2²⁵⁶ — a number near 10⁷⁷ — which the solver then treated as a legitimate input to converge toward. The output: D_new ≈ 2.3544 × 10⁵⁶, minted directly to the attacker's address.

This was not an economic exploit or an oracle manipulation — it was the contract faithfully computing an answer to a question that should never have been askable. Holding these fabricated LP tokens, the attacker drained genuine assets via single-asset withdrawals. Helper contracts deployed only minutes ahead of the attack carried out the mechanical steps, then self-destructed to remove traces of their bytecode. The entire sequence — mint, drain, cleanup — fit inside one transaction and one block.

Banteg's post-mortem later confirmed the root cause: an unchecked underflow inside a Newton solver, triggered by a deliberately corrupted invariant.

03Tracing the funds

The operation was pre-funded through Railgun roughly thirty minutes before the attack executed.

• Funding transaction: 0x68f88d2ffcef1ceafde26fc290cf1d31ff9a461b4ee2aeb68da8aa9cf70e600c
• Primary attacker address: 0xa80D3F2022F6Bfd0B260bF16D72CaD025440C822
• Secondary attacker address: 0xFb63aa935Cf0a003335dCE9Cca03c4F9c0fa4779
• Main attack contract (self-destructed): 0xB8e0A4758Df2954063Ca4ba3d094f2d6EdA9B993
• Secondary/helper attack contract: 0xbb2789b418fA18f9526bA79fa7038d4e6d753f73
• Attack transaction: 0x53fe7ef190c34d810c50fb66f0fc65a1ceedc10309cf4b4013d64042a0331156
• Exploited yETH pool: 0x69accb968b19a53790f43e57558f5e443a91af22

The dust deposit, infinite mint, pool drain, and self-destruct all occurred within a single block, taking the pool from fully operational to empty almost instantly.

Roughly 1,000 ETH (about $3 million) moved directly into Tornado Cash in ten deposits of 100 ETH each, with no delay between the exploit and the laundering step.

• Wallet handling both Tornado Cash flows: 0x3e8e7533dcf69c698Cf806C3DB22f7f10B9B0b97
• Internal calls from the exploit transaction (visible on Etherscan): Internal Calls

Etherscan's internal transaction data shows the exploit, the drain, and the Tornado Cash obfuscation chained together as one atomic sequence, start to finish, within a single block.

Not all of the funds stayed missing. Working with the Plume and Dinero teams, Yearn recovered $2.33 million (857.49 pxETH) through a coordinated effort.

• Recovery transaction: 0x0e83bb95bb9d05fb81213b2fad11c01ea671796752e8770b09935f7052691c35

That still leaves a large share unaccounted for: the primary attacker address currently holds $3.84 million. In rough terms, about a third of the total was laundered, roughly a quarter recovered, and the remainder is still sitting untouched.

04A product nobody was watching

yETH wasn't merely old — it was live, production code that had quietly stopped receiving attention. As Banteg put it: "It was a separate product with quite complex/novel math; it doesn't share any code with vaults." The architecture was fully isolated, running invariant math unique to itself and used nowhere else in the protocol.

Originally built as a meta-aggregator for liquid staking tokens, yETH had effectively been left to run on its own while Yearn's V2 and V3 vaults continued to receive audits, monitoring, and active development. That gap showed clearly in the outcome: the V2 and V3 vaults came through the incident untouched, functioning exactly as intended, while the neglected yETH pool collapsed.

The vulnerable component was an older version of the yETH token contract, unrelated to the vault infrastructure Yearn currently promotes to users — legacy logic that was still processing meaningful volume despite being largely off the team's radar.

Notably, this wasn't a novel bug in current code; it was an old, complex, and unattended system that stayed exploitable simply because nobody had reason to look at it closely until someone did. Yearn's handling followed a familiar pattern: convene a response team, work with Plume and Dinero on partial recovery, and reassure users that the currently promoted products remained safe. The underlying issue wasn't the response itself, but the fact that yETH had operated for years without anyone reassessing whether it should still be running at all.

Credit for the closing observations: as with prior incidents, the pattern raises the same question — who is responsible for auditing products that teams have effectively stopped thinking about?

Roughly $9 million disappeared from a product that was never formally shut down, exploited through math that nobody re-checked, inside a pool that had fallen out of active monitoring. Meanwhile, the V2 and V3 vaults performed exactly as expected, underscoring that Yearn's actively maintained systems are not the problem.

The exposure here wasn't in the products still receiving attention — it was in the ones left running after the team's focus moved elsewhere. Unmaintained legacy code doesn't stop being a risk just because it's forgotten; it simply waits for someone to find the specific sequence that breaks it. This incident is a reminder that isolating a legacy system architecturally can protect the rest of a protocol, but it does nothing to protect the legacy system itself from anyone willing to read its source carefully enough.

With three separate exploits now on record, each involving a different mechanism, the pattern itself is arguably the bigger story: code that's valuable enough to keep running is valuable enough to keep maintaining — and any protocol carrying old, unmonitored contracts should treat them as live liabilities, not historical footnotes.