Handle nonstandard token return values in swap adapters

A successful low-level call does not always prove a token transfer succeeded. An ERC-20 method can return false, and some widely integrated token implementations omit the expected return data.

The ERC-20 specification requires callers to handle false. OpenZeppelin's SafeERC20 helpers address compatibility with return-value differences. Use reviewed wrappers appropriate to your contract version rather than writing an unchecked transferFrom call.

Know which layer owns the transfer

A front-end adapter usually does not execute token transferFrom itself. The selected router or settlement contract owns that behavior. Confirm the provider supports the token and route; changing the browser ABI cannot repair an incompatible router.

If you are writing a contract that receives and swaps tokens, distinguish call-level success, decoded boolean success and actual balance movement. A transfer-tax token can deliver less than the nominal amount even when its call succeeds. Return-value compatibility is not the same as tax compatibility.

Do not weaken validation globally

Accepting empty return data should be part of a specific reviewed helper's semantics, not a rule that treats every unexpected response as success. Likewise, swallowing a revert and continuing can leave downstream accounting based on tokens the contract never received.

Test a conforming token returning true, one returning false, one returning no data and one reverting. Verify that failed movement cannot be followed by a swap assuming the full amount arrived.

For an existing integration incident, record token address, chain, router version and the exact failing call. A symbol-based conclusion such as this token always works will not identify which implementation or execution path caused the problem.