Euler Finance Receives "Generous" Donations

Notice: This page is a freshly imported case study from the original repository. The original content was in a different format, and may not have relevant information for all sections. Please help restructure the content by moving information from the 'About' section to other sections, and add any missing information or sources you can find. If you are new here, please read General Tutorial on Wikis or Anatomy of a Case Study for help getting started.

Euler Finance Homepage

Euler is a non-custodial permissionless lending protocol on Ethereum that enables users to lend and borrow almost any crypto asset. It features a number of innovations, including permissionless lending markets, reactive interest rates, protected collateral, and multi-collateral stability pools. Users can create artificial leverage by minting and depositing assets, but the donateToReserves function was exploited, allowing a hacker to create an unbacked DToken debt. The vulnerability was missed by auditors and smart contract insurance protocol Sherlock, which will pay a claim of $4.5M to Euler. Total losses from the attack were $134.6M in ETH derivatives, $18.6M in WBTC, 34M USDC, and 8.9M DAI.

About Euler Finance

"Democratising the assets people can lend and borrow. Euler is a non-custodial protocol on Ethereum that allows users to lend and borrow almost any crypto asset."

"Euler is a non-custodial permissionless lending protocol on Ethereum that helps users to earn interest on their crypto assets or hedge against volatile markets without the need for a trusted third-party. Euler protocol features a number of innovations not seen before in DeFi, including permissionless lending markets, reactive interest rates, protected collateral, MEV-resistant liquidations, multi-collateral stability pools, and much more. For more information, read the White Paper."

"Euler comprises a set of smart contracts deployed on the Ethereum blockchain that can be openly accessed by anyone with an internet connection. Euler is managed by holders of a protocol native governance token called Euler Governance Token (EUL). Euler is entirely non-custodial; users are responsible for managing their own funds. A convenient and user-friendly front-end to for the Euler smart contracts is hosted at https://app.euler.finance. However, users are free to access the protocol in whatever format they wish; a popular alternative can be found at https://instadapp.io/."

"Permissionless listing is much riskier on decentralised lending protocols than on other DeFi protocols, like decentralised exchanges, because of the potential for risk to spill over from one pool to another in quick succession. For example, if a collateral asset suddenly decreases in price, and subsequent liquidations fail to repay borrowers' debts sufficiently, then the pools of multiple different types of assets can be left with bad debts. To counter these challenges, Euler uses risk-based asset tiers to protect the protocol and its users."

"The Euler Finance protocol permits its users to create artificial leverage by minting and depositing assets in the same transaction via EToken::mint. This mechanism permits tokens to be minted that exceed the collateral held by the Euler Finance protocol itself.

The donation mechanism introduced by Euler Finance in eIP-14¹ (EToken::donateToReserves) permits a user to donate their balance to the reserveBalance of the token they are transacting with. The flaw lies in that it does not perform any health check on the account that is performing the donation."

"Lending on Euler is managed via eTokens (collateral) and dTokens (debt), with liquidations triggered when a user has more dTokens than eTokens.

The exploited vulnerability involved the little-used donateToReserves function which was incorporated into Euler via EIP14 last year. donateToReserves allows users to send eTokens to directly to Euler reserves, however does not contain a check on the health of the user’s position.

The hacker took advantage of this by using two contracts, one of which would incur bad debt via donateToReserves, and the other would act as liquidator.

Using flash-loaned funds and Euler’s leverage system to create a large, underwater position on one contract, the liquidator contract could obtain the inflated eToken collateral at a discount, and withdraw into the underlying assets.

Omniscia, one of Euler’s six auditors, published a detailed post-mortem, summing up the issue as follows:

The attack ultimately arose from an incorrect donation mechanism and did not account for the donator’s debt health, permitting them to create an unbacked DToken debt that will never be liquidated."

"The vulnerability that was exploited stems from how Euler Finance permits donations to be performed without a proper account health check.

The vulnerable code was introduced in eIP-14¹ which introduced multiple changes throughout the Euler Ecosystem. The flaw lies in the first change performed to the EToken implementation (EToken::donateToReserves feature²).

The logic within the Liquidation module will attempt to repay the full debt of the violator, however, if the collateral they possess would not satisfy the expected repayment yield, the system defaults to whatever collateral the user has³.

The assumption of this code block states that a borrower’s available collateral will be insufficient only when:

This can happen when borrower has multiple collaterals and seizing all of this one won’t bring the violator back to solvency

This security guarantee is not upheld by the donation mechanism which permits the user to create “bad debt” in the form of leverage that is uncollateralized by donating their EToken units without affecting their DToken balance."

"SlowMist provided a summary of the addresses and transactions involved: total losses comprised 86k in ETH derivatives ($134.6M), 849 WBTC ($18.6M), 34M USDC, 8.9M DAI."

"Auditors and smart contract insurance protocol Sherlock has taken responsibility for missing the vulnerability in their review of EIP-14 last year, and will pay a claim of $4.5M to Euler.

Euler reached out to the attacker’s address via tx input data:

We understand that you are responsible for this morning's attack on the Euler platform. We are writing to see whether you would be open to speaking with us about any potential next steps.

But with some funds having been sent to Tornado via a pass-through address in what seems like a test, the prospects of returned funds aren’t looking good…

Given Euler’s high-profile and stable reputation, many other DeFi organisations had funds tied up in the protocol.

The fact that so many other projects chose to integrate with Euler is a testament to just how shocking this exploit has been for the community. And many have reached out in support of the Euler team."

This is a global/international case not involving a specific country.

The background of the exchange platform, service, or individuals involved, as it would have been seen or understood at the time of the events.

Include:

• Known history of when and how the service was started.
• What problems does the company or service claim to solve?
• What marketing materials were used by the firm or business?
• Audits performed, and excerpts that may have been included.
• Business registration documents shown (fake or legitimate).
• How were people recruited to participate?
• Public warnings and announcements prior to the event.

Don't Include:

• Any wording which directly states or implies that the business is/was illegitimate, or that a vulnerability existed.
• Anything that wasn't reasonably knowable at the time of the event.

There could be more than one section here. If the same platform is involved with multiple incidents, then it can be linked to a main article page.

The Reality

This sections is included if a case involved deception or information that was unknown at the time. Examples include:

• When the service was actually started (if different than the "official story").
• Who actually ran a service and their own personal history.
• How the service was structured behind the scenes. (For example, there was no "trading bot".)
• Details of what audits reported and how vulnerabilities were missed during auditing.

What Happened

The specific events of the loss and how it came about. What actually happened to cause the loss and some of the events leading up to it.

Key Event Timeline - Euler Finance Receives "Generous" Donations

Date	Event	Description
July 6th, 2022 12:29:16 PM MDT	EIP14 Proposed	EIP14 is proposed on the Euler Governance Forum. TBD more details.
March 13th, 2023 2:50:59 AM MDT	Exploit Transaction	One of the exploit transactions.
March 13th, 2023 3:56:00 AM MDT	Euler Finance Twitter Announcement	Euler Finance posts on Twitter to announce that they are "aware and our team is currently working with security professionals and law enforcement". TBD follow Tweet to PeckShield.
March 13th, 2023 10:16:14 AM MDT	Omniscia Publishes Post Mortem	Omniscia brings a post-mortem online detailing what happened in the attack. TBD more details.
March 14th, 2023 11:20:00 AM MDT	RektHQ Article Published	RektHQ posts an article on the exploit. On March 14, 2023, Euler Finance, one of DeFi's most established lending protocols, suffered a $197 million exploit. The hack involved a little-used donateToReserves function that was incorporated into Euler via EIP14 last year, which allowed the hacker to send eTokens to Euler reserves without checking the health of the user's position. The hacker used two contracts, one of which would incur bad debt via donateToReserves, and the other would act as a liquidator. Using flash-loaned funds and Euler's leverage system, the hacker created a large, underwater position on one contract, allowing the liquidator contract to obtain the inflated eToken collateral at a discount and withdraw into the underlying assets. Euler reached out to the attacker's address, but some funds were already sent to Tornado via a pass-through address in what seems like a test. The exploit not only affected Euler but also other DeFi projects that had funds tied up in the protocol. This event highlights the importance of resilient infrastructure for DeFi's future.

Technical Details

This section includes specific detailed technical analysis of any security breaches which happened. What specific software vulnerabilities contributed to the problem and how were they exploited?

Total Amount Lost

The total amount lost has been estimated at $196,100,000 USD.

How much was lost and how was it calculated? If there are conflicting reports, which are accurate and where does the discrepancy lie?

Immediate Reactions

How did the various parties involved (firm, platform, management, and/or affected individual(s)) deal with the events? Were services shut down? Were announcements made? Were groups formed?

Ultimate Outcome

What was the end result? Was any investigation done? Were any individuals prosecuted? Was there a lawsuit? Was any tracing done?

Omnisicia Post-Mortem

Omniscia, the firm which audited the smart contract, released a post-mortem of the incident.

Total Amount Recovered

There do not appear to have been any funds recovered in this case.

What funds were recovered? What funds were reimbursed for those affected users?

Ongoing Developments

What parts of this case are still remaining to be concluded?

Individual Prevention Policies

Avoid the use of smart contracts unless necessary. Minimize the level of exposure by removing or withdrawing assets whenever possible. Aim to choose smart contracts which have obtained third party security audits, preferably having been audited by at least three separate reputable firms. Pay attention to the audit reports, which smart contracts are covered, and whether the smart contract has been upgraded or modified since the report. Ensure that any administrative functions with the ability to remove funds from the smart contract are under the authority of a multi-signature wallet which is controlled by at least three separate and reputable entities.

For the full list of how to protect your funds as an individual, check our Prevention Policies for Individuals guide.

Platform Prevention Policies

All aspects of any platform should undergo a regular validation/inspection by experts. This validation should include a security audit of any smart contracts, reporting any risks to the backing (of any customer assets, ensuring treasuries or minting functions are properly secured under the control of a multi-signature wallet, and finding any inadequacies in the level of training or integrity of the team. The recommended interval is twice prior to launch or significant system upgrade, once after 3 months, and every 6 months thereafter. It is recommended that the third party performing the inspection not be repeated within a 14 month period.

For the full list of how to protect your funds as a financial service, check our Prevention Policies for Platforms guide.

Regulatory Prevention Policies

All platforms should undergo published security and risk assessments by independent third parties. Two assessments are required at founding or major upgrade, one after 3 months, and one every 6 months thereafter. The third parties must not repeat within the past 14 months. A risk assessment needs to include what assets back customer deposits and the risk of default from any third parties being lent to. The security assessment must include ensuring a proper multi-signature wallet, and that all signatories are properly trained. Assessments must be performed on social media, databases, and DNS security.

For the full list of regulatory policies that can prevent loss, check our Prevention Policies for Regulators guide.