Post‑Mortem: How the Yearn yETH Exploit Minted Unlimited yETH and Raided the stETH/rETH Pool

Executive summary

On the surface the Yearn yETH incident looked like a straightforward drain: an attacker walked away with millions, and some proceeds moved through Tornado Cash. Reporting indicates the exploit resulted in a single large loss event (≈$9M) and subsequent laundering steps. The pattern and on‑chain traces point to a classical asset‑accounting / exchange‑rate manipulation in a vault — where the vault’s conversion math was tricked into issuing more shares than the attacker funded — then converting those minted shares into stETH/rETH liquidity and extracting value from a bespoke pool.

This post‑mortem reconstructs a plausible exploit flow, explains the vulnerability class, details the timeline and forensic clues, and offers protocol and investor mitigations. For operational readers: many of the recommendations are concrete enough to be audited into vault code and monitoring stacks.

(Quick reference: public reporting on the incident and laundering is summarized in this report.)

High‑level reconstruction of the attack

What the attacker needed to accomplish

• Create yETH shares without supplying equivalent underlying ETH value (i.e., minting shares out of thin air).
• Convert those over‑issued shares into illiquid assets in a bespoke stETH/rETH pool, extracting liquidity and moving into regular tokens.
• Obfuscate and launder proceeds (Tornado Cash was used, per reporting).

Likely technical vector (summary)

1. The attacker used a transient state manipulation (commonly via flash loans or temporary token manipulation) that altered the vault’s view of total assets or its exchange rate function.
2. The vault (or its adapter) computed a share amount to mint using that manipulated snapshot, allowing the attacker to receive more shares than they fairly funded.
3. Immediately after minting, the attacker swapped the inflated shares for stETH/rETH liquidity in a bespoke pool that lacked proper slippage/limit controls and could be front‑run or emptied quickly.
4. Extracted tokens were washed through Tornado Cash and other mixers to obfuscate provenance.

Below we unpack each step and link it to typical code smells and forensic signals.

The vulnerability class: asset‑accounting & exchange‑rate manipulation

Yearn vaults (and more broadly ERC‑4626 style vaults) live or die by two invariants:

• totalAssets() accurately reflects the underlying pool size (in base units); and
• the share ↔ asset conversion math (assetsPerShare or convertToShares / convertToAssets) is monotonic, robust to transient state, and not callable with attacker‑controlled inputs that can change within the transaction.

When either invariant is broken — for example, because an adapter reports assets computed from manipulable reserves (a lending or AMM pool) or because the contract trusts external state that can be changed mid‑transaction — an attacker can create a mint inflation vector. This is the same family of vulnerabilities seen in several prior vault exploits.

Common root causes in this class:

• Blind reliance on an external adapter's balance or an on‑chain oracle without reentrancy and snapshot protections.
• Using a price or reserve read that is not atomic with the share minting operation, allowing flash loans or sandwiching transactions to change the denominator.
• Incorrect handling of token decimals, rebasing tokens, or transfer hooks that alter balances during a call.
• Missing upper bounds on mintable shares per transaction or per block.

The exploit against yETH fits this pattern: the attacker gained a temporary, transaction‑local advantage in how assets were accounted and used it to mint shares above the true backing.

Step‑by‑step plausible exploit flow (technical)

1) Preparation: a capital‑efficient flash supply

• Attacker obtains a large flash loan in ETH or a stable asset, or combines native holdings with a temporary manipulation of a paired asset (rETH / stETH).
• The goal is to create a temporary imbalance in the bespoke stETH/rETH pool or in an adapter’s reported reserves that the vault uses for totalAssets().

2) Manipulate reported assets / exchange rate

• Vault adapters often compute totalAssets by querying external pools or querying token balances after internal operations. If the adapter reads a pool that the attacker can skew (e.g., by routing a huge swap through the pool that temporarily changes reserves), the computed exchange rate will be wrong for that instant.
• Example: if totalAssets() uses a pool balance that reflects pre‑swap state but convertToShares uses a post‑swap supply number, a mismatch occurs. The attacker leverages that mismatch.

3) Mint inflated yETH

• Using the manipulated snapshot, the attacker calls deposit/mint and receives more yETH shares than the fair backing. This step is atomic with the earlier manipulation, so the vault sees only the manipulated state.
• Crucially, because the attacker’s operation is atomic, the protocol cannot detect that the underlying pool was reverted to its normal state after the transaction completes.

4) Convert shares to stETH/rETH in bespoke pool and drain liquidity

• The attacker swaps the minted yETH for assets in a bespoke stETH/rETH pool. If the pool lacks robust slippage controls, price oracles, or is shallow by design, it can be emptied once the attacker mints an outsized position.
• This step converts the synthetic share inflation into real token value (stETH, rETH, and then to more liquid tokens).

5) Launder via Tornado Cash and other mixes

• Extracted assets are split, bridged, and sent through mixing services. Public reporting and on‑chain traces show Tornado Cash used to hide the fund trail — a common laundering route for DeFi exploits.

(For reporting on the amount and Tornado Cash laundering, see this summary report.)

On‑chain forensic clues to look for during triage

When reconstructing this or similar incidents, these on‑chain signals are high‑value for a rapid assessment:

• Single transaction mint events where share supply increases disproportionately relative to assets locked (look for Mint / Transfer events on the vault and compare to balance changes). A spike in totalSupply not matched by increased underlying assets is a red flag.
• Large, same‑block swaps involving the vault’s adapter target pools (look for big swaps into/out of the stETH/rETH pool in the same TX). These often show up as high‑slippage swaps with different internal calls in the same trace.
• Flash‑loan entry and repayment calls surrounding the main transaction (Aave/Uniswap router or popular flash‑loan patterns). This indicates capital efficiency used to create temporary state.
• Immediate outflows of stETH/rETH to DEXes, bridges, or mixers. Look for rapid sequence: mint → swap → bridge → Tornado deposit.
• Tornado Cash deposits from the same address cluster shortly after extraction. These are strong signals of intent to obfuscate. CryptoPotato’s reporting confirms Tornado Cash involvement in this incident.

From a forensic standpoint, capturing the entire call trace (internal transactions) is essential — many vault exploits are invisible if one looks only at top‑level transfers.

Timeline (detection & response patterns)

• T0: Attack transaction executed; vault reports a large share mint and an abnormal outflow.
• T0 + minutes: On‑chain monitoring alerts (if active) on abnormal mint/withdraw patterns and pool imbalance.
• T0 + minutes–hours: Protocol teams and security responders begin triage: identify affected vaults, pause strategies, and isolate adapters.
• T0 + hours: Emergency pause or migration (if implemented) is triggered, stopping further deposits and limiting withdrawals while the root cause is investigated.
• T0 + days: Full post‑mortem and public disclosure, potential whitehat recovery or bounty negotiations depending on attacker behavior.

Typical weak points in response that lengthen exposure:

• No emergency pause on vaults or insufficiently privileged multisig delays response.
• Lack of observability into adapter internals or inability to map adapter ↔ pool relationships.
• No automatic circuit breakers for anomalous share issuance.

Protocol‑level mitigations (engineering checklist)

Below are practical measures to reduce the probability and impact of this class of exploit. Prioritize engineering fixes by how quickly they can be implemented and how much they reduce risk.

1. Enforce atomic and auditable asset accounting

   • Implement invariant checks: after any deposit/mint, assert that totalAssets() >= previousTotalAssets() + depositedAssets * (1 - smallTolerance).
   • Add sanity checks on convertToShares and convertToAssets to prevent negative or zero denominators and absurd exchange rates.

2. Snapshot / lock oracle or adapter state within the transaction

   • Make sure the read used for share conversion is taken from the same consistent internal snapshot as the balance used to compute the mint. In practice, read the pool state only once and reuse that value for conversions.

3. Harden adapter code

   • Treat external pools as untrusted: require adapters to validate pool reserves with multiple sources or to use time‑weighted oracles for larger pools.
   • For shallow bespoke pools, require explicit whitelisting with governance oversight and stricter limits.

4. Rate limits and per‑tx caps

   • Add per‑tx and per‑block caps on maximum shares minted or maximum deposit value relative to vault liquidity.
   • Consider a configurable delta limit (e.g., no single deposit can increase totalSupply by >X%).

5. Emergency controls and observability

   • Add an emergency pause that can be triggered in minutes and has a documented process.
   • Deploy real‑time monitors for: (a) share issuance vs asset inflows, (b) swaps involving vault adapters, (c) flash loan signatures.

6. Use conservative accounting for rebasing / non‑standard tokens

   • Any token with transfer hooks, rebasing behavior, or off‑chain backing must be wrapped in a vetted adapter that normalizes its accounting.

7. Economic safety nets

   • Consider insurance or multisig buffer funds for quick partial reimbursement.
   • Limit exposure to shallow bespoke pools by requiring multi‑sig strategy approval and periodic audits.

8. Formal verification & audits

   • Apply property‑based tests and formal verification for share ↔ asset invariants. Audits should include adversarial “flash loan” style test cases.

Investor & risk officer mitigations

• Diversify exposure across vaults and strategies: avoid concentrated bets on new or bespoke pools that can be shallow.
• Watch token unlock calendars: supply shocks (large token unlocks) can amplify price moves after an exploit — the market context matters when exits are attempted (see reporting on token unlocks and supply risk for background). This overview discusses imminent token unlocks and supply‑side pressure.
• Prefer vaults with clear emergency pause policies and public dashboards for deposits, withdrawals, and adapter mappings.
• Maintain a small, immediate‑access collateral buffer for on‑chain positions to cover rebalancing during stressed events.
• If you’re an institutional allocator, insist on stress testing (flash‑loan scenarios, oracle manipulation) before allocation.

Detection playbook for incident responders

1. Immediately snapshot the vault state: totalSupply, totalAssets, adapter balances, recent events.
2. Pull full transaction traces for suspicious mint events (internal calls are essential).
3. Identify entry liquidity (flash loans, large swaps) and exit rails (DEXes, bridges, mixers like Tornado Cash).
4. Coordinate with indexers and on‑chain analytics providers to identify clustering of addresses and likely laundering paths.
5. If possible, trigger emergency pause and notify on‑chain governance stakeholders.
6. Communicate quickly but accurately to users and custodians to avoid panic withdrawals that exacerbate losses.

Lessons learned and closing thoughts

• This exploit reinforces a persistent truth: vaults that aggregate third‑party pools inherit their manipulability. Any adapter that treats external pools as trusted data sources must implement conservative validation and invariant checks.
• Observability matters as much as code correctness. Many protocols can prevent rapid asset loss if they detect abnormal share issuance or pool manipulations in real time and can pause strategy execution.
• Economic context (token unlocks, shallow pools, concentrated liquidity) amplifies technical failures. Operational risk teams should marry on‑chain risk signals with market calendars.

For DeFi engineers and auditors: treat share‑to‑asset math as a security boundary. Add monotonic checks, per‑tx caps, and atomic snapshots, and test the vaults against adversarial flash loan scenarios as part of CI. Risk officers should require those tests and monitoring before approving strategy launches.

Bitlet.app and other custody/earn platforms that integrate vaults should incorporate these engineering and monitoring recommendations into their risk playbooks.

Sources

• Detailed incident report and laundering notes: Yearn Finance loses $9M in single transaction exploit of yETH vault
• Context on supply‑side risks and token unlocks that can compound post‑exploit pressure: Ethena ENA lead $218 million token unlocks overview