Key Highlights
- DBXen hack exploited ERC2771 mismatch, letting attackers claim years of rewards instantly.
- Permissionless forwarders still risk miscalculating fees, leaving staking contracts vulnerable.
- Repeated burn-cycle and sender bugs show smart contracts remain exposed to high-value exploits.
DBXen, a decentralized finance (DeFi) platform, suffered a major contract exploit on Thursday morning, resulting in an estimated $150,000 loss, according to blockchain security monitor BlockSec Phalcon.
The attack exploited flaws in ERC2771 meta-transactions—a system that lets users interact with smart contracts through a “forwarder” address to simplify transaction handling. The bug arose from how DBXen tracked who was performing a transaction. While the burnBatch() function correctly recorded the actual user, the onTokenBurned() callback mistakenly referenced the forwarder’s address.
This mismatch caused the system to treat the forwarder as the active participant, allowing the attacker to manipulate rewards and fees and drain extra tokens from the contract.
BlockSec Phalcon highlighted this as a cautionary tale for DeFi projects relying on meta-transaction frameworks without thorough auditing.
The exploit targeted DBXen’s staking system, which generates $DXN tokens when users burn $XEN, a process meant to reduce the overall supply of XEN.
According to TreeCityWes.xen on X, the attacker took advantage of two issues: an open (permissionless) transaction forwarder and a bug in the fee system that applies to newly created addresses. By posing as a brand-new user, the attacker tricked the contract into thinking they had been staking for a long time, allowing them to claim a large amount of accumulated rewards.
“The protocol effectively backdated a brand new address to cycle 0 and paid it 3 years of fee income,” the post explained. In total, the attacker drained 65.28 ETH and minted 2,305 DXN, moving funds out via LayerZero within minutes.
ERC2771 bug and fee accounting flaws
The attack happened because DBXen got confused about who was actually sending transactions. The system used two ways to check the sender—_msgSender() and msg.sender—but they didn’t match. This mismatch broke the reward calculations in claimFees() and claimRewards(), letting the attacker claim way more than they should.
On top of that, brand-new addresses were treated as if they’d been staking for years, receiving all the accumulated fees from 1,085 cycles.
This kind of problem has happened before. In February 2026, hackers hit the BNB Smart Chain, stealing over $438,000 from SOF and LAXO tokens. They exploited glitches in the burn functions, which let them inflate token values and manipulate liquidity pools. Still in February, Ethereum and Base networks saw a $2.26 million FOOMCASH hack caused by misconfigured zkSNARK verification keys, showing that repeated mistakes keep leaving smart contracts vulnerable.
Lessons from recurring exploits
DBXen’s breach isn’t a one-off; it’s a clear example of the recurring ERC2771 sender-inconsistency problem. The permissionless forwarders are still being used without making sure every state update correctly tracks the sender.
Adding to this, weak business logic around burn cycles makes these systems even more vulnerable. Protocols keep shipping permissionless forwarders without ensuring every single state update uses the same sender resolution
Developers need to carefully audit forwarders and make sure every function consistently references the correct sender. Beyond the financial loss, these exploits show that staking protocols with complicated reward cycles remain exposed. Without immediate fixes, similar attacks could keep happening across new token ecosystems.
Also Read: BONK.fun Hack Exposes Users to Wallet Drainer Threat
