Unchecked call return value

Vulnerable code

function payOut(address to, uint256 amt) external onlyOwner {
    to.call{value: amt}("");       // return value discarded
    paid[to] += amt;                    // recorded regardless
}

// The ERC-20 variant, equally common:
function deposit(uint256 amt) external {
    token.transferFrom(msg.sender, address(this), amt);
    balance[msg.sender] += amt;         // credited even if transfer failed
}

Why it breaks

If the recipient is a contract whose receive() reverts, or is out of gas, the call returns false and execution carries on. Your paid mapping now claims money was sent that wasn't. The ERC-20 case is worse: some widely-used tokens return false instead of reverting on failure, and some (famously USDT) return nothing at all, so the call succeeds while transferring zero.

Watch the attack run

The same bug as a stepped sequence. Play it, or walk through with the arrow keys.

The fix

function payOut(address to, uint256 amt) external onlyOwner {
    (bool ok, ) = to.call{value: amt}("");
    require(ok, "payout failed");
    paid[to] += amt;
}

// For tokens, use SafeERC20 — it handles both
// false-returning and void-returning implementations.
using SafeERC20 for IERC20;

function deposit(uint256 amt) external {
    token.safeTransferFrom(msg.sender, address(this), amt);
    balance[msg.sender] += amt;
}

The invariant

The fix above is what an audit gives you. This is what monitoring gives you: the thing that should always be true once the contract is live, stated precisely enough to check every block.

invariant  delta(internal_accounting)
           == delta(token.balanceOf(address(this)))
  per block, tolerance 0

How to test for it

A finding you cannot reproduce is an opinion. Write the test before you write the fix, watch it fail, then make it pass.

contract RejectingReceiver {
    receive() external payable { revert("no thanks"); }
}

function testPayoutRevertsOnFailure() public {
    RejectingReceiver r = new RejectingReceiver();
    vm.expectRevert("payout failed");
    vault.payOut(address(r), 1 ether);
}

Where it has caused real losses

Fee-on-transfer and rebasing tokens compound this problem. A vault that credits amt rather than the actual balance delta will over-credit every deposit of a fee-taking token, and the shortfall is drained by whoever withdraws last. Several yield aggregators have lost funds this way.

What we check during review

The robust pattern for any token deposit is to measure the balance before and after and credit the difference, rather than trusting the amount parameter:

uint256 before = token.balanceOf(address(this));
token.safeTransferFrom(msg.sender, address(this), amt);
uint256 received = token.balanceOf(address(this)) - before;
balance[msg.sender] += received;