Unchecked Call Return Value: The Silent Failure Draining Vaults

The Bug in One Sentence

Solidity's low-level calls — `call`, `send`, `delegatecall`, `staticcall` — do **not** revert on failure. They return a `bool`. If you ignore that bool, your contract happily proceeds as if the call succeeded, even when it didn't.

That's it. That's the whole bug. And it has been emptying vaults since 2016.

Why It Still Happens in 2025

Developers coming from higher-level languages assume that "if the call failed, it would throw." Solidity disagrees. The EVM treats `CALL` as a value-returning opcode, not an exception-propagating one. Combine that with the deprecated-but-still-used `address.send()` (which returns false on failure with a 2300 gas stipend) and you get a footgun that compiles cleanly, passes most unit tests, and breaks in production.

It gets worse: many ERC-20 tokens (USDT being the famous offender) do not return a boolean at all on `transfer`. A naive `require(token.transfer(...))` will revert on USDT because there's no return data to decode. A naive `token.transfer(...)` with no check will silently fail on tokens like ZRX that return `false` instead of reverting on insufficient balance.

The Vulnerable Pattern

```solidity
// VULNERABLE
contract Auction {
address public highestBidder;
uint256 public highestBid;

function bid() external payable {
require(msg.value > highestBid, "bid too low");

// Refund the previous highest bidder
highestBidder.send(highestBid); // <-- return value ignored

highestBidder = msg.sender;
highestBid = msg.value;
}
}
```

If `highestBidder` is a contract whose fallback reverts, runs out of the 2300 gas stipend, or simply doesn't exist as payable, the `send` returns `false`. The previous bidder is never refunded — but the state still updates, and their ETH is permanently locked in the contract.

This is almost verbatim the **King of the Ether (2016)** bug. The contract crowned new monarchs and tried to pay out the previous one with `send()`. When the previous king was a contract with an expensive fallback, the payout silently failed. The throne updated. The ETH stayed put. Hundreds of ETH were stuck — a meaningful sum then, a fortune now.

The Fix

Pattern 1: Check the return value

```solidity
(bool success, ) = highestBidder.call{value: highestBid}("");
require(success, "refund failed");
```

Better, but introduces a denial-of-service vector: a malicious previous bidder can revert in their receive function and block all future bids.

Pattern 2: Pull payments (recommended)

```solidity
// FIXED
contract Auction {
address public highestBidder;
uint256 public highestBid;
mapping(address => uint256) public pendingReturns;

function bid() external payable {
require(msg.value > highestBid, "bid too low");

if (highestBidder != address(0)) {
pendingReturns[highestBidder] += highestBid;
}
highestBidder = msg.sender;
highestBid = msg.value;
}

function withdraw() external {
uint256 amount = pendingReturns[msg.sender];
require(amount > 0, "nothing to withdraw");
pendingReturns[msg.sender] = 0; // CEI: effects before interaction

(bool ok, ) = msg.sender.call{value: amount}("");
require(ok, "withdraw failed");
}
}
```

This is the OpenZeppelin `PullPayment` pattern. The recipient pulls funds when they choose; one failing recipient cannot grief the rest of the system.

ERC-20 Silent Failures

The token version of this bug is even nastier:

```solidity
// VULNERABLE — many things wrong here
function deposit(IERC20 token, uint256 amount) external {
token.transferFrom(msg.sender, address(this), amount);
balances[msg.sender] += amount;
}
```

If the token returns `false` (like older OMG, ZRX), the user gets credited without paying. If the token is USDT and you wrap it in `require(...)`, it reverts because USDT returns no data. Use `SafeERC20`:

```solidity
using SafeERC20 for IERC20;

function deposit(IERC20 token, uint256 amount) external {
token.safeTransferFrom(msg.sender, address(this), amount);
balances[msg.sender] += amount;
}
```

`safeTransferFrom` handles both the boolean-returning and the no-return-data cases, and reverts on either form of failure. There is no excuse to write raw ERC-20 transfers in 2025.

Real-World Carnage

**King of the Ether (Feb 2016)** — ~98 ETH stuck due to unchecked `send` to contract recipients. The canonical case study.
- **Akropolis (Nov 2020, $2M)** — While the headline cause was a reentrancy/flash-loan combo, the exploit chain relied on assumed token transfer success that was never validated against the resulting balance delta. Same family of mistake.
- **Countless rugpull-adjacent ERC-20 forks** — Tokens with broken `transfer` implementations are routinely listed on DEXes that don't check return values, leading to phantom liquidity provisions and stuck LP positions.

If you're auditing a protocol that touches arbitrary tokens (DEX, lending market, bridge), every single external call needs return-value handling. Run our [free AI audit](https://www.cryptohawking.com/audit) — it flags every unchecked low-level call and raw ERC-20 transfer in your codebase in minutes.

Detection Checklist

Grep your codebase for:

`.call(` / `.call{` without `(bool` capture
- `.send(` anywhere (just remove it; it's deprecated for good reason)
- `.transfer(` on `address payable` (2300 gas stipend will break post-Istanbul recipients)
- Raw `IERC20.transfer` / `transferFrom` without `SafeERC20`
- Inline assembly `call` opcodes — easy to miss the returned status

Static analyzers like Slither catch most of these (`unchecked-lowlevel`, `unchecked-send`, `unchecked-transfer`). They will not catch logic bugs where you check the return value but then ignore it semantically — for that you need humans. Our [manual audit](https://www.cryptohawking.com/audit/manual) ($5,000, 3 business days, paid in ETH/SOL/USDT) reviews every cross-contract interaction for exactly this class of subtle failure.

The Rule

If a function returns a value, you handle it. No exceptions. If the language designer bothered to put `bool` in the return signature, the language designer is telling you something. Listen.

Never write `someContract.call(...)` and walk away. Never write `token.transfer(...)` without `SafeERC20`. Never use `send`. And when in doubt, use pull payments — your users can withdraw on their own gas, on their own time, with their own failure modes.

Your vault will thank you.