The platform that once stood as the cornerstone of decentralized lending recently suffered a devastating $200M exploit. While Euler Finance was raking in over a billion dollars in total deposits, there was one critical flaw hiding in the code the entire time. The Euler attack is one of the most complex DeFi exploits to date and showcases how a series of individually valid smart contract interactions can be sequenced into a cascading chain of catastrophic consequences. In this post, we’ll walk through the mechanics of the exploit and the subtle bug that resulted in one of the most expensive cybersecurity attacks of all time.
Background
The victim in this attack was a well-known platform named Euler Finance. Euler was an app on the blockchain (a decentralized app, or a “dApp”) that let users lend and borrow cryptocurrency without any centralized intermediaries.
People liked Euler’s platform because it offered an efficient, decentralized way to earn yield on your crypto assets by lending them out to other users with interest. Users could deposit assets like Ethereum or USDC into the Euler protocol to earn interest at competitive rates. On the flip side, borrowers could take out loans against their assets to increase leverage and unlock additional liquidity without selling. Since decentralized lending protocols have no trusted middleman, all loans on the platform were overcollateralized.
- Overcollateralized loans are just a type of loan where you borrow less money than the value of your collateral.
Overcollateralized loans facilitate lending in a way that safeguards lenders against borrower defaults and sudden price drops. In theory, overcollateralized loans should keep lenders safe.
The Attack
The attacker behind the Euler exploit was patient, methodical, and quietly studied the blueprints for months before striking. And by blueprints I mean Euler’s open-source smart contracts, sitting publicly visible on GitHub for anyone to read.
Liquidation
To understand this attack, we need to understand the concept of liquidation. Liquidation of a loan occurs when a borrower’s collateral drops too low in value to safely cover the loan, and a third-party steps in to sell the collateral and repay the debt to reduce the lender’s risk. Liquidators earn a profit by keeping a portion of the proceeds. In a decentralized lending protocol, liquidation is crucial for maintaining solvency of the lending pool and protecting lenders from losses.
The Exploit
The attacker was very familiar with Euler’s liquidation logic, and he used it to deliberately drain $200M from the protocol. The attacker exploited a vulnerability in the donateToReserves() function combined with Euler’s debt liquidation logic, using flash loans and a highly orchestrated sequence of calls to manipulate the protocol’s internal accounting and walk away with millions.
Euler used custom ERC-20 tokens to track user’s deposited and borrowed assets (eTokens and dTokens, respectively). Depositors earn interest via an increasing exchange rate between eTokens and their underlying assets, while borrowers incur debt in dTokens, both managed in an on-chain book keeping model. The protocol used these token balances to track the health score of user’s positions using a simple formula, defined as:
healthScore = MaxLTV / currentLTV
MaxLTV is the protocol’s maximum loan-to-value (LTV) ratio, and currentLTV is the borrower’s actual LTV ratio. Positions with healthScore < 1 are eligible for liquidation. Euler’s soft liquidation mechanism applies a sliding penalty of a 0% fee at healthScore = 1 down to a maximum 20% fee at healthScore ≤ 0.8, incentivizing liquidators by allowing them to seize collateral at a discount proportional to the borrower’s under-collateralization.
Core Vulnerability
At the heart of the exploit was the donateToReserves() function in the eToken smart contract. Most state-modifying function calls in Euler’s protocol were routed through a “risk manager” module to ensure eToken balance remains ≥ dToken balance post-operation. Critically, the donateToReserves() function did not include the protocol’s standard checkLiquidity() invocation, meaning it never re-evaluated the caller’s health score after burning their collateral. By bypassing the health check, an attacker could intentionally force themselves into insolvency while still retaining outstanding debt. By controlling both the borrower and the liquidator roles, the attacker was able to make self-liquidation profitable by turning the internal accounting errors into realized gains.
Step-by-Step Attack Mechanics
- The attacker deployed two smart contracts:
- Violator: Executes flash loan, initial deposit, minting, and donation.
- Liquidator: Performs self-liquidation once Violator is insolvent.
- Violator initiates a flash loan from Aave for 30 million DAI (a stablecoin worth $1 USD per token).
- Violator deposits 20 million DAI into Euler, minting ~19.5 million eDAI.
- Violator calls mint() to borrow 195.6 million eDAI and 200 million dDAI, using the freshly minted eDAI as self-collateral (healthScore ≈ 1.04).
- Violator repays 10 million DAI of the dDAI debt using the remaining flash loan funds, burning 10 million dDAI and boosting healthScore to ~1.09.
- Violator calls mint() again for another 195.6 million eDAI and 200 million dDAI, pushing healthScore back down to ~1.02.
- Violator calls donateToReserves() to burn 100 million eDAI (far exceeding the 10 million DAI needed to repay), slashing collateral without liquidity checks. This drives healthScore to < 0.8, enabling liquidation at the maximum 20% discount.
- Violator invokes Liquidator to initiate the liquidation process.
- Liquidator calls liquidate() on Violator’s position.
- Liquidator transfers captured balance to Violator.
- Violator withdraws 38.9 million DAI from the liquidity pool, burning ~38 million eDAI in the process.
- Violator repays the flash loan, retaining ~8.9 million DAI in profit.
All of these steps were executed atomically within a single transaction and confirmed in the same block. This process was then repeated by the attacker a few more times until he acquired ~$197 million USD worth of various crypto assets.
Technical Insights & Mitigations
This exploit underscores the critical importance of coupling every state-changing operation with rigorous, context-aware liquidity checks and invariant testing. The core issue stemmed from the donateToReserves() function bypassing the standard checkLiquidity() call, allowing users to burn collateral without triggering a re-evaluation of their health score. This lapse broke a key invariant: the value of a user’s collateral should always safely exceed their debt. The omission of this invariant opened the door to insolvency-based exploits.
To prevent similar vulnerabilities in the future, DeFi protocols should adopt the following best practices:
Invariant Testing: A post-donation liquidity invariant (healthScore ≥ 1) should have been implemented, preventing self-induced insolvency before it happens. This practice must be enforced consistently in real-world DeFi applications, regardless of how benign the function may seem.
Context Aware Audits: Developers and auditors must evaluate how each function behaves when interacting with global protocol rules, not just in isolation. Functions that appear low-risk in isolation can introduce systemic threats when they bypass core safeguards.
Automated Invariant Testing: Robust invariant tests should be built into the test suite to assert that critical relationships (like eToken balance ≥ dToken balance) are preserved after every operation. Tools like Echidna and Foundry can help automate this process.
Fail-Safe Defaults: Protocols should implement default deny logic, where any failure of a safety check results in a transaction revert, not a silent pass-through.
Aftermath
The Euler Finance exploit, initially resulting in a loss of approximately $197M, culminated in an extraordinary recovery effort that saw the return of around $240M to users. In a stunning twist of fate, the value of the crypto assets had appreciated by over $40M during the recovery period. This surprisingly successful outcome was achieved through a combination of strategic negotiations, community engagement, and the unwavering dedication of Euler’s team. The recovery process was filled with challenges, including multiple red herrings, interference from the notorious Lazarus Group, and the unpredictable behavior of the attacker, who eventually returned the funds after a series of on-chain and off-chain communications.
Conclusion
The Euler Finance attack underscores a crucial lesson for DeFi builders: even subtle oversights in smart contract logic can unravel entire protocols. The massive consequences of this hidden bug highlight the extreme precision required in blockchain software development. While Euler’s proactive recovery efforts ultimately mitigated user losses, the reputational damage and loss of trust significantly impacted the platform’s standing in the DeFi community. Moving forward, protocols must adopt rigorous invariant testing, comprehensive code audits, and fail-safe design principles as foundational components rather than afterthoughts. By internalizing these lessons the decentralized finance industry can better safeguard itself against similarly sophisticated attacks and establish the trust required for mainstream adoption.