Third Time Unlucky: A Misordered Parameter in DEI's burnFrom Function Drains $6.5M Across Three Chains
Deus DAO has now been exploited a third time, earning it the distinction of being only the third protocol to appear three separate times on rekt.news's leaderboard. This latest episode arrives just over a year after the project's previous entry.
Holders of the DEI stablecoin were left roughly $6.5 million poorer combined across Arbitrum, BSC and Ethereum, and DEI itself lost more than 80% of its peg in the process.

Notably, Deus's two earlier incidents both took place on Fantom, the chain the project originally launched on, and FTM was untouched this time around — DEI has since expanded to additional chains, which is where this attack played out instead.
The community first flagged unusual activity via an alert on Twitter, and the underlying cause was pinned down shortly after in a follow-up post. Deus itself subsequently confirmed that an exploit had occurred and shared a multisig address for any whitehats wishing to return recovered funds.
Given the protocol's history, questions naturally arose about how much trust a three-time-hacked project can still expect.
Credit for analysis: adamb, Zellic, 0xProtosec
01The bug
The root cause traces back to an upgrade made to the DEI token contract the previous month, which introduced a straightforward coding mistake. Inside the burnFrom function, the two parameters feeding into _allowances — msgSender and account — had been written in the reverse of their correct order.
That ordering mistake opened up what Peckshield described as a public (or, in their phrasing, "pubic") burn vulnerability: anyone could exploit it to seize control of a DEI holder's token approvals and route their balance to an address of the attacker's choosing.
Because the parameters were swapped, an attacker could first grant themselves a large approval on any DEI holder's account. Then, simply by calling burnFrom with an amount of zero against that holder's address, the flawed logic would update the approval in the attacker's favor — after which the holder's funds could be pulled out directly.
A breakdown of the method circulated showing the exact sequence:
identify an address with a huge amount of DEI
approve to this address
call burnFrom with amount = 0 and this address
During the burnFrom it grants approves all tokens from the address to your own
call transferFrom
02Addresses and transactions
Attacker's address (Arbitrum): 0x189cf534de3097c08b6beaf6eb2b9179dab122d1
Example attack transaction (Arbitrum): 0xb1141785b7b94eb37c39c37f0272744c6e79ca1517529fec3f4af59d4c3c37ef
Frontrunning address (BSC): 0x5a647e376d3835b8f941c143af3eb3ddf286c474
Example attack transaction (BSC): 0xde2c8718a9efd8db0eaf9d8141089a22a89bca7d1415d04c05ba107dc1a190c3
Attacker's address (Ethereum): 0x189cf534de3097c08b6beaf6eb2b9179dab122d1
Example attack transaction (Ethereum): 0x6129dd42778345bc278822a7feadeacb933f5e56ce51114e686832ad239307a8

Per an analysis from BlockSec's MetaSleuth, the breakdown of losses came to approximately $5 million on Arbitrum, $1.3 million on BSC, and $135,000 on Ethereum.
03The aftermath
One piece of good news: the BSC-side exploit attempt was frontrun, and an on-chain note sent to the Deus deployer address signaled an intention to hand the funds back. Additional whitehat actors got involved as well, and to date more than $600,000 in USDC has been routed to a recovery multisig.
Not everyone was convinced this was worthwhile, however — some questioned the point of returning funds to a team responsible for such an elementary bug in the first place. Sending recovered assets back to a protocol now on its third strike does seem like it could work against its own logic.
Deus has since put out an update outlining a recovery plan for users who suffered losses, and has also contacted the attacker directly on-chain. That said, the attacker's account was originally funded through Tornado Cash on BSC, which does not bode well for the odds of a voluntary return.
Whether this third strike proves fatal for Deus DAO remains to be seen.
Get new scam files the moment we publish them — usually 2–3 emails a week.