# Incident - Analytic Summary ## Incident Analysis ### Incident On 5th May at approximately 19:52 Berlin Time, the DEUS Finance project and its DEI token listed on the Chronos Exchange on the Arbitrum platform experienced a significant security breach due to a bug in the DEI token implementation. An unknown attacker exploited the implementation and stole all funds from the underlying Liquidity Pool. Amidst the turmoil, numerous users bought, sold, and transferred their DEI tokens, exacerbating the situation. The projected loss for users of the DEUS Finance platform currently stands at approximately -5,838,827.80. More details [here.](/contracts/reimbursement-guide/dei-depeg.md) ### Exploiter Profile \ We postulate that the initial attack was a hurried and inadequately prepared exploit. The evidence that led us to this assumption includes the attacker's rushed development, as evidenced by an MEV bot front-running them on BSC. Interestingly, the attacker removed USDC from the pool but redeposited DEI back into the pool. This allowed participants to purchase DEI for cents and transfer it to other LP pools. If the attacker had allocated more time for planning, they could have simultaneously targeted all LP pools across all chains. Moreover, they could have been the first to exhaust all bridge funds for movement to Fantom. However, their rushed actions created massive arbitrage opportunities for other participants rather than capitalizing on them themselves. These actions resulted in losses for DEI holders. However, the losses didn't benefit the initial attacker, which leads us to believe that the attack was more of a quick and dirty solution. We conjecture that the attacker opted for a rushed approach, likely fearing that someone else might discover the bug or that his main target was causing maximum damage. More about the [attack itself](broken://pages/rUOMJC5AmyEu6U6I6WDu). ### Impact Assessment The full extent of the damage is yet to be determined. However, as of the recent estimates, full recovery for LPs is estimated at 70%, restoring DEI to its total value, backing at 90% as before. More about the [recovery.](broken://pages/2PWdIXskWgSBK3Se4kpz#recovering-funds) ### Technical Analysis The technical cause of the exploit is tied to implementing a self-written permissionless `burnFrom` function within the DEI token contract. The DEI team had previously decided to implement the Lossless ERC20 contract, which created an issue when trying to implement a `burnFrom` due to LERC20's lack of a `_spendAllowance` function. As a result, the DEI team implemented a custom-written burnable function, which led to the exploit. More about the [attack details](/contracts/reimbursement-guide/dei-depeg/incident-analytic-summary/attack-details.md) & the [reasoning](/contracts/reimbursement-guide/dei-depeg/incident-analytic-summary/the-cause-for-the-exploit.md). ### Recovery Plan The DEI team is working on a recovery plan, which includes thoroughly assessing the damage and restoring balances for DEI holders and LPs. In the mid-term, the team is looking at internal & external structural changes to ensure that such an incident do not occur again in the future. A detailed recovery plan will be released in the upcoming weeks [here.](/contracts/reimbursement-guide/dei-depeg/incident-analytic-summary/reimbursement-plan.md) ### Moving forward * Future Preventative Measures Lessons Learned. * Proposed Changes in security processes [Here](/contracts/reimbursement-guide/dei-depeg/incident-analytic-summary/moving-forward.md), we will formulate a strategic evaluation and blueprint designed to preempt and mitigate such errors in future operations. ### --- # Agent Instructions: Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://docs.deus.finance/contracts/reimbursement-guide/dei-depeg/incident-analytic-summary.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.