## 1. What happened

On May 11, 2025, MobiusDAO's MBU token on BNB Chain was exploited for approximately $2.15 million. The attacker deposited 0.001 WBNB (about $0.67) and minted 9.73 quadrillion MBU tokens through a decimal-handling bug, then dumped the tokens on PancakeSwap for stablecoins and routed the proceeds through Tornado Cash in 21 transfers of 100 BNB each. The project had launched only three days earlier, on May 8.

Source: https://web.archive.org/web/20250514000000/https://rekt.news/mobiusdao-rekt/

## 2. Root cause

The exploit was a smart-contract bug: a double multiplication of decimals in the deposit/mint function. The contract called `getBNBPriceInUSDT` to obtain the BNB price, which already returned a value scaled to 18 decimal places (~$656 represented as `656 * 10**18`). The deposit function multiplied this 18-decimal value by `10**18` again before computing the MBU mint amount, inflating the deposited value by a factor of 10**18. The contract had no mint cap and no validation of the resulting token quantity. The code was reportedly not open-source, had no public audit, and had no documented team.

Source: https://web.archive.org/web/20250514000000/https://rekt.news/mobiusdao-rekt/ (crediting Quill Audits' autopsy)

## 3. Pattern

**Precision / decimal-scaling error (missing decimal-place validation).**

The vulnerable shape, in pseudocode:

```
function deposit(uint256 wbnbAmount) external {
    uint256 bnbPrice = getBNBPriceInUSDT();  // returns value with 18 decimals, e.g. 656e18
    uint256 usdValue = wbnbAmount * bnbPrice * 1e18;  // BUG: extra 1e18 multiplier
    uint256 mintAmount = usdValue / MBU_PRICE;
    _mint(msg.sender, mintAmount);
}
```

The price oracle already returns an 18-decimal fixed-point value, but the contract applies a second `1e18` scaling factor, treating the oracle value as if it were raw integer dollars.

Source: https://web.archive.org/web/20250514000000/https://rekt.news/mobiusdao-rekt/

## 4. The check that would have caught it

1. **Unit test with real input values**: Test the `deposit` function with a known WBNB amount (e.g. 0.001 WBNB at $656/BNB) and assert that the minted MBU amount equals the expected value within a tolerance of 1%. A correctly-written test would have surfaced the 10**18 discrepancy immediately, since the minted amount would be off by 18 orders of magnitude.

2. **Invariant: minted amount must not exceed deposited value times the oracle price.** A fuzz or invariant test that asserts `mintedAmount <= (depositedAmount * bnbPrice) / 1e18 * (1 + maxSlippage)` for any deposit size. The invariant would fail for any non-zero deposit under the buggy code, producing a 10**18x over-mint.

Source (pattern): https://web.archive.org/web/20250514000000/https://rekt.news/mobiusdao-rekt/

## 5. Sources

- https://web.archive.org/web/20250514000000/https://rekt.news/mobiusdao-rekt/ (primary, comprehensive post-mortem)
- Blockaid (first detection): credited in the rekt.news article above
- Cyvers (confirmation): credited in the rekt.news article above
- Quill Audits (contract analysis / autopsy, including Noveleader's breakdown): credited in the rekt.news article above
- AstraSec (analysis): credited in the rekt.news article above
- CertiK: credited in the rekt.news article above

The Quill Audits blog post at https://www.quillaudits.com/blog was not archived by the Wayback Machine at the time of writing; its analysis is preserved through the rekt.news article which quotes it directly. The project's own post-mortem, if one existed, could not be located; the rekt.news article notes that MobiusDAO issued a statement blaming "BSC Byzantine consensus mechanism" rather than publishing a technical post-mortem.