Drained MEV Bot: No-Auth Transfers and Unsafe msg.sender.call

We pulled the drained bot into EVMDecompiler and stepped through the reconstructed callbacks. The bytecode (no published source) made two facepalm-level mistakes:

• msg.sender.call{value: amount}("" ) with zero validation or recipient sanity checks.
• Direct token transfers to msg.sender without any notion of authorization.

Decompiled fragments

function d3MMSwapCallback(address _token, uint256 _amount, bytes calldata) external {
    IERC20(_token).transfer(msg.sender, _amount);
}

function swapX2YCallback(uint256 amountX, uint256, bytes calldata data) external {
    require(amountX <= 0 || amountX == 0);
    (bool success, bytes memory result) = msg.sender.call{value: amountX}("");
    require(success, "SwapX2Y: ERC20 operation did not succeed");
}

function swapCallback(uint256 amount0, uint256 amount1, bytes calldata data) external override {
    _swapCallback(msg.sender, amount0, amount1, data);
}

Why this is fatal

• Value transfer to msg.sender: msg.sender.call hands both control and value to whoever is calling. No whitelist, no invariants — just free money and a nice way to brick funds if the fallback reverts.
• Token transfer to msg.sender: dumping _amount straight into the caller's wallet with no checks means any token balance the bot holds is a short-lived gift.

Safer patterns

• Favor pull-payments or explicit recipient parameters with tight allowlists.
• Skip address.call for value — use guarded withdrawal patterns instead.
• Wrap callbacks in signed intents, nonces, or trusted router checks.

Analysis comes straight from the decompiled bytecode; we renamed functions so the narrative is easier to follow.