DMi Token Hack Analysis

DMi Token Hack Analysis

Overview:

On December 8, 2025, the DMi token (DMI/WBNB pair) on BSC Chain suffered a AMM reserve-manipulation exploit, resulting in an estimated theft of ~138.68 WBNB (~$124.4K USD) in a single atomic attack transaction.

The vulnerability originated from a critical logic flaw in the DMi token’s transfer() implementation, which redirected /burned the entire transferred amount whenever the recipient was the PancakeSwap pair. This behaviour violated the invariant assumptions of the AMM and caused token balance desynchronization between the pair’s actual on-chain balances and its internal reserves used for swap pricing..

This attack is a canonical case of SC03:2025 Logic Errors under OWASP Smart Contract Top 10; specifically, breaking AMM reserve invariants via erroneous ERC20 transfer semantics.

Smart Contract Hack Overview:

• Attack Transaction:0x2330a
• Victim Contract: 0xfbE04 (proxy), 0xd88c7 (DMi)
• Attacker Addresses:0x47f7B , 0x6DC0D
• Attack Contract:0xdD065
• OWASP SC Top 10: SC03:2025 Logic Errors

Decoding the Smart Contract Vulnerability:

• The root cause of the exploit lies in the transfer-handling logic of the DMi token, specifically within the transfer() function. This function contains a critical branch that treats transfers to the PancakeSwap liquidity pair differently from all other transfers.
• Instead of delivering the transferred tokens to the pair contract; as required by the AMM design, the function diverts the entire amount to an external fee/ burn address (outfee_add). This behavior fundamentally violates the ERC-20 contract expectations under which AMMs operate.
• In a PancakeSwap-style AMM, whenever a user inputs tokens into a swap, the pair contract must actually receive those tokens so its on-chain token balance and its internal reserves remain synchronized. These reserves are the basis of the AMM pricing formula (x * y = k), and every swap relies on the assumption that the pair’s balances accurately reflect the tokens transferred to it.
• However, the DMi implementation breaks this assumption outright. Whenever a caller attempts to send DMi tokens to the pair, the contract silently executes:

if (_isPancakePair(to)) {
    _transfer(owner, outfee_add, amount);
} else {
    _transfer(owner, to, amount);
}

• So, rather than sending tokens to the pair, the contract diverts 100% of the tokens to a fee/burn address (outfee_add) whenever the receiver is the liquidity pool.
• This means the pair contract receives zero tokens, even though the AMM logic believes it should have received amount. As a result, the pair’s true ERC-20 balance diverges immediately from its reserve variables ( reserve0, reserve1), leaving the AMM in a corrupted, desynchronized state.
• This violation alone is enough to break the AMM’s pricing model, but the situation becomes significantly worse because transferFrom() does not apply the same redirect behavior:

_transfer(from, to, amount); // always transfers directly to 'to'

• This asymmetry enabled the attacker to craft precise sequences where certain token inflows to the pair are delivered normally (via transferFrom()), while others are silently removed from the pair’s expected balance (via transfer()).
• By combining these two inconsistent behaviors inside a single atomic transaction, the attacker intentionally created moments where the AMM believed the pair possesses a large quantity of DMi tokens, while in reality those tokens were never deposited or have been burned or redirected.

Attack Sequence:

The attacker first obtained a flash loan of ~102.7 WBNB from the Moolah lending contract.

They forwarded the borrowed WBNB into their exploit proxy contract to begin the manipulation.

The contract then performed a sequence of DMi transfers and swaps against the DMi/WBNB PancakePair.

Whenever the attacker used transfer(), the DMi token redirected all tokens away from the pair, preventing the pair from receiving the expected swap input.

When using transferFrom(), tokens were delivered normally to the pair, creating an intentional imbalance between the pair’s actual token balance and its internal reserves.

This alternating pattern caused the AMM to enter a state of reserve desynchronization, as reflected by Swap events showing tiny amount0In but massive amount1Out.

Sync events soon showed the pair’s DMi reserve collapsing to extremely low values (e.g., reserve1 = 502), confirming the manipulated reserve state.

With the AMM’s reserves distorted, the attacker triggered a final swap that overpaid WBNB, far beyond what should occur in a valid trade.

The attacker’s proxy contract received the inflated WBNB output, repaid the flash loan, and sent the remaining 138.68 WBNB as profit to the attacker’s wallet.

Mitigation and Best Practices:

• Ensure transfer() and transferFrom() both route through a single internal function that computes fees and performs token movements identically. Asymmetric behaviors create exploitable ordering conditions inside a single transaction.
• Transfer hooks such as _transfer_before() must never modify balances, trigger value transfers, or update external state. Restrict them to pure accounting and move all externalized reward distribution to explicit claim functions to avoid reentrancy and side-effect desync.
• Transfers to liquidity pools must always deposit the tokens into the pair contract. If fees are required, deduct only a portion and forward the remainder to the pair. Redirecting or burning the full amount instantly breaks AMM reserve invariants.
• Any conditional path that changes how tokens reach a recipient; especially AMM pairs, should be explicitly validated, audited, and bounded. Default behaviors must revert when unsafe or undefined, rather than silently redirecting or consuming tokens.
• To prevent such vulnerabilities, the best Smart Contract auditors must examine the Smart Contracts for logical issues. We at CredShields provide smart contract security and end-to-end security of web applications and externally exposed networks. Our public audit reports can be found on https://github.com/Credshields/audit-reports. Schedule a call at https://credshields.com/
• Scan your Solidity contracts against the latest common security vulnerabilities with 494+ detections at SolidityScan.

Conclusion:

SolidityScan is an advanced smart contract scanning tool that discovers vulnerabilities and reduces risks in code. Request a security audit with us, and we will help you secure your smart contracts. Signup for a free trial at https://solidityscan.com/signup

Follow us on our Social Media for Web3 security-related updates.

SolidityScan — LinkedIn | Twitter | Telegram | Discord