The March 13 flash loan attack<\/a> against Euler Finance resulted in over $195 million in losses. It caused a contagion to spread through multiple decentralized finance (DeFi) protocols, and at least 11 protocols other than Euler suffered losses\u00a0due to the attack<\/a>.<\/p>\n Over the next 23 days, and to the great relief of many Euler users, the attacker returned all of the exploited funds<\/a>.<\/p>\n But while the crypto community can celebrate the return of the funds, the question remains whether similar attacks may cause massive losses in the future. <\/p>\n An analysis of how the attack happened and whether developers and users can do anything to help prevent these kinds of attacks in the future may be helpful.<\/p>\n Luckily, Euler\u2019s developer docs clearly explain how the protocol works, and the blockchain itself has preserved a complete record of the attack.\u00a0<\/p>\n According<\/a> to the protocol\u2019s official docs, Euler is a lending platform similar to Compound or Aave. Users can deposit crypto and allow the protocol to lend it to others, or they can use a deposit as collateral to borrow crypto. <\/p>\n The value of a user\u2019s collateral must always be more than what they borrow. Suppose a user\u2019s collateral falls below a specific ratio of collateral value to debt value. In that case, the platform will allow them to be \u201cliquidated,\u201d meaning their collateral will be sold off to pay back their debts. The exact amount of collateral a user needs depends upon the asset being deposited vs. the asset being borrowed.<\/p>\n Whenever users deposit to Euler, they receive<\/a> eTokens representing the deposited coins. For example, if a user deposits 1,000 USD Coin (USDC<\/a>), they will receive the same amount of eUSDC in exchange.<\/p>\n Since they become worth more than the underlying coins as the deposit earns interest, eTokens don\u2019t have a 1:1 correspondence with the underlying asset in terms of value.<\/p>\n Euler also allows users to gain leverage by minting<\/a> eTokens. But if they do this, the protocol will send them debt tokens (dTokens) to balance out the assets created. <\/p>\n For example, the docs say that if a user deposits 1,000 USDC, they can mint 5,000 eUSDC. However, if they do this, the protocol will also send them 5,000 of a debt token called \u201cdUSDC.\u201d <\/p>\n The transfer function for a dToken is written differently than a standard ERC-20 token. If you own a debt token, you can\u2019t transfer it to another person, but anyone can take a dToken from you if they want to.<\/p>\n Related: <\/strong>Liquidity protocol Sentiment exploited for over $500K<\/strong><\/a><\/em><\/p>\n According to the Euler docs, a user can only mint as many eTokens as they would have been able to by depositing and borrowing over and over again, as it states,\u00a0\u201cThe Mint function mimics what would happen if a user deposited $1,000 USDC, then borrowed $900 USDC, then redeposited that $900 USDC, to borrow $810 more USDC, and so on.\u201d<\/p>\n According to a blog post from Euler, each user has a \u201chealth score\u201d based<\/a> on the value of the eTokens held in their wallets vs. the value of the dTokens held. A user needs to have a greater dollar value of eTokens than dTokens, but how much more depends on the particular coins they are borrowing or depositing. Regardless, a user with enough eTokens will have a health score greater than 1. <\/p>\n If the user barely falls below the required number of eTokens, they will have a health score of precisely 1. This will subject them to \u201csoft liquidation.\u201d Liquidator bots can call a function to transfer some of the user\u2019s eTokens and dTokens to themselves until the borrower\u2019s health score returns to 1.25. Since a user who is barely below the collateral requirements will still have more collateral than debt, the liquidator should profit from this transaction.<\/p>\n If a user\u2019s health score falls below 1, then an increasing discount is given out to the liquidator based on how bad the health score is. The worse the health score, the greater the discount to the liquidator. This is intended to make sure that someone will always liquidate an account before it accumulates too much bad debt.<\/p>\n Euler\u2019s post claims that other protocols offer a \u201cfixed discount\u201d for liquidation and argues why it thinks variable discounts are superior.<\/p>\n Blockchain data reveals that the attacker engaged in a series of attacks that drained various tokens from the protocol. The first attack drained around $8.9 million worth of Dai (DAI<\/a>) from the Dai deposit pool. It was then repeated over and over again for other deposit pools until the total amount was drained.<\/p>\n The attacker used three different Ethereum addresses to perform the attack. The first was a smart contract, which Etherscan has labeled \u201cEuler Exploit Contract 1,\u201d used to borrow from Aave. The second address was used to deposit and borrow from Euler, and the third was used to perform a liquidation.<\/p>\n To avoid having to repeatedly state the addresses that Etherscan has not labeled, the second account will be referred to as \u201cBorrower\u201d and the third account \u201cLiquidator,\u201d as shown below:<\/p>\n The first attack consisted<\/a> of 20 transactions in the same block.<\/p>\n First, Euler Exploit Contract 1 borrowed 30 million DAI from Aave in a flash loan<\/a>. It then sent this loan to the borrower account.<\/p>\n After receiving the 30 million DAI, borrower deposited 20 million of it to Euler. Euler then responded by minting approximately 19.6 million eDAI and sending it to borrower. <\/p>\n These eDAI coins were a receipt for the deposit, so a corresponding amount of dDai was not minted in the process. And since each eDAI can be redeemed for slightly more than one DAI, the borrower only received 19.6 million instead of the full 20 million.<\/p>\n After performing this initial deposit, borrower minted approximately 195.7 million eDAI. In response, Euler minted 200 million dDAI and sent it to borrower.<\/p>\n At this point, borrower was near their eDAI mint limit, as they had now borrowed about 10 times the amount of DAI they had deposited. So their next step was to pay off some of the debts. They deposited the other 10 million DAI they had held onto, effectively paying back $10 million of the loan. In response, Euler took 10 million dDAI out of borrower\u2019s wallet and burned it, reducing borrower\u2019s debt by $10 million.<\/p>\n Related: <\/strong>Allbridge offers bounty to exploiter who stole $573K in flash loan attack<\/strong><\/a><\/em><\/p>\n The attacker was then free to mint more eDAI. Borrower minted another 195.7 million eDAI, bringing their eDAI total minted to around 391.4 million. The 19.6 million eDAI in deposit receipts brought borrower\u2019s eDAI total to about 411 million. <\/p>\n In response, Euler minted another 200 million dDai and sent it to borrower, bringing borrower\u2019s total debt to $400 million. <\/p>\n Once borrower had maximized their eDAI minting capacity, they sent 100 million eDai to the null address, effectively destroying it. <\/p>\n This pushed their health score well below 1, as they now had $400 million in debt vs. approximately $320 million in assets.<\/p>\n This is where the liquidator account comes in. It called the liquidate function, entering borrower\u2019s address as the account to be liquidated.<\/p>\n In response, Euler initiated the liquidation process. It first took around 254 million dDAI from borrower and destroyed it, then minted 254 million new dDai and transferred it to liquidator. These two steps transferred $254 million worth of debt from borrower to liquidator.<\/p>\n Next, Euler minted an additional 5.08 million dDAI and sent it to liquidator. This brought liquidator\u2019s debt to $260 million. Finally, Euler transferred approximately 310.9 million eDAI from borrower to liquidator, completing the liquidation process.<\/p>\n In the end, borrower was left with no eDAI, no DAI, and 146 million dDAI. This meant that the account had no assets and $146 million worth of debt.<\/p>\n On the other hand, liquidator had approximately 310.9 million eDAI and only 260 million dDAI.<\/p>\n Once the liquidation had been completed, liquidator redeemed 38 million eDAI ($38.9 million), receiving 38.9 million DAI in return. They then returned 30 million DAI plus interest to Euler Exploiter Contract 1, which the contract used to pay back the loan from Aave.<\/p>\n In the end, liquidator was left with approx. $8.9 million in profit that had been exploited from other users of the protocol.<\/p>\n This attack was repeated for multiple other tokens, including Wrapped Bitcoin (WBTC), Staked Ether (stETH) and USDC, amounting to $197 million in exploited cryptocurrencies.<\/p>\n Blockchain security firms Omniscia and SlowMist have analyzed the attack to try and determine what could have prevented it.<\/p>\n According to a March 13 report from Omniscia, the primary problem with Euler was its \u201cdonateToReserves\u201d function. This function allowed the attacker to donate<\/a> their eDAI to Euler reserves, removing assets from their wallet without removing a corresponding amount of debt. Omnisica says that this function was not in the original version of Euler but was introduced in Euler Improvement Proposal 14 (eIP-14).<\/p>\n The code for eIP-14 reveals<\/a> that it created a function called donateToReserves, which allows the user to transfer tokens from their own balance to a protocol variable called \u201cassetStorage.reserveBalance.\u201d Whenever this function is called, the contract emits a \u201cRequestDonate\u201d event that provides information about the transaction.<\/p>\n Blockchain data shows that this RequestDonate event was emitted for a value of 100 million tokens. This is the exact amount that Etherscan shows were burned, pushing the account into insolvency.<\/p>\n In their March 15 analysis, SlowMist agreed<\/a> with Omniscia about the importance of the donateToReserve function, stating:<\/p>\n \u201cFailure to check whether the user was in a state of liquidation after donating funds to the reserve address resulted in the direct triggering of the soft liquidation mechanism.\u201d<\/p><\/blockquote>\n The attacker might have also been able to carry out the attack even if the donate function had not existed. The Euler \u201cEToken.sol\u201d contract code on GitHub contains<\/a> a standard ERC-20 \u201ctransfer\u201d function. This seems to imply that the attacker could have transferred their eTokens to another random user or to the null address instead of donating, pushing themselves into insolvency anyway.<\/p>\n However, the attacker did choose to donate the funds rather than transfer them, suggesting the transfer would not have worked.<\/p>\n Cointelegraph has reached out to Omniscia, SlowMist and the Euler team for clarification on whether the donateToReserves function was essential to the attack. However, it has not received a response by publication time.<\/p>\n Related:\u00a0<\/strong><\/em>Euler team denies on-chain sleuth was a suspect in hack case<\/a><\/strong><\/p>\n The two firms agreed that another major vulnerability in Euler was the steep discounts offered to liquidators. According to SlowMist, when a lending protocol has a \u201cliquidation mechanism that dynamically updates discounts,\u201d it \u201ccreates lucrative arbitrage opportunities for attackers to siphon off a large amount of collateral without the need for collateral or debt repayment.\u201d\u00a0Omniscia made similar observations, stating:<\/p>\n \u201cWhen the violator liquidates themselves, a percentage-based discount is applied […] guaranteeing that they will be \u2018above-water\u2019 and incur only the debt that matches the collateral they will acquire.\u201d<\/p><\/blockquote>\n In its analysis, SlowMist advised developers on how to prevent another Euler-style attack in the future. It argued that lending protocols should not allow users to burn assets if this will cause them to create bad debt, and it claimed that developers should be careful when using multiple modules that may interact with each other in unexpected ways:<\/p>\n \u201cThe SlowMist Security Team recommends that lending protocols incorporate necessary health checks in functions that involve user funds, while also considering the security risks that can arise from combining different modules. This will allow for the design of secure economic and viable models that effectively mitigate such attacks in the future.\u201d<\/p><\/blockquote>\n A representative from DeFi developer Spool told Cointelegraph that technological risk is an intrinsic feature of the DeFi ecosystem. Although it can\u2019t be eliminated, it can be mitigated through models that properly rate the risks of protocols. <\/p>\n According<\/a> to Spool\u2019s risk management white paper, it uses a \u201crisk matrix\u201d to determine the riskiness of protocols. This matrix considers factors such as the protocol\u2019s annual percentage yield (APY), audits performed on its contracts, time since its deployment, total value locked (TVL) and others to create a risk rating. Users of Spool can employ this matrix to diversify DeFi investments and limit risks.<\/p>\n The representative told Cointelegraph that Spool\u2019s matrix significantly reduced investor losses from the Euler incident.<\/p>\n \u201cIn this incident, the worst affected Smart Vaults, those designed by users to seek higher (and riskier) yields, were only affected for up to 35%. The lowest affected vault with exposure to Euler strategies (via Harvest or Idle), in comparison, was only affected by 6%. Some vaults had zero exposure and were thus not impacted,\u201d they stated.<\/p>\n Spool continued, \u201cWhile this is not ideal, it clearly demonstrates the ability of the Smart Vaults to provide tailored risk models and to distribute users\u2019 funds among multiple yield sources.\u201d<\/p>\n Cointelegraph got a similar answer from SwissBorg, another DeFi protocol that aims to help users limit risk through diversification. SwissBorg CEO Cyrus Fazel stated that the SwissBorg app has \u201cdifferent yield strategies based on risk\/timeAPY.\u201d <\/p>\n Some strategies are listed as \u201c1: core = low,\u201d while others are listed as \u201c2: adventurous = risky.\u201d Because Euler was given a \u201c2\u201d rating, losses from the protocol were limited to only a small portion of SwissBorg\u2019s total value locked, Fazel stated.<\/p>\n SwissBorg head of engineering Nicolas R\u00e9mond clarified further that the team employs sophisticated criteria to determine what protocols can be listed in the SwissBorg app.<\/p>\n \u201cWe have a due-diligence process for all DeFi platforms before entering any position. And then, once we\u2019re there, we have operation procedures,\u201c he said, adding, \u201dThe due diligence is all about TVL, team, audits, open-source code, TVL, oracle manipulation attack, etc. [\u2026] The operation procedure is about platform monitoring, social media monitoring and some emergency measures. Some are still manual, but we\u2019re investing to automatize everything based so that we can be extremely reactive.\u201d<\/p>\nHow Euler Finance works<\/h2>\n
eTokens are assets, while dTokens are debts<\/h3>\n
Users liquidated if health scores drop to 1 or below<\/h3>\n
How the Euler attack happened<\/h2>\n
![\"\"](\"https:\/\/s3.cointelegraph.com\/uploads\/2023-04\/de209c59-de96-4111-a5f0-c47d27d33da4.png\" "\\"\\"")
![](\"https:\/\/s3.cointelegraph.com\/uploads\/2023-04\/121845fc-77d1-4b2f-ab92-dcd9d221c3e6.png\")
![\"\"](\"https:\/\/s3.cointelegraph.com\/uploads\/2023-03\/acbec5c5-383f-4f01-b2a2-2180ddda0bdd.png\" "\\"The")
What went wrong in the Euler attack<\/h2>\n
![\"\"](\"https:\/\/s3.cointelegraph.com\/uploads\/2023-04\/6593351d-3a31-4c53-b8b0-f370d3b2bf09.png\" "\\"\\"")
![\"\"](\"https:\/\/s3.cointelegraph.com\/uploads\/2023-04\/9468dae7-622f-438c-bdcf-9bddfbd8cfd0.png\" "\\"\\"")
How to prevent a future Euler attack<\/h2>\n