SteerPeriphery Static Analysis Findings

SPY-01S: Improper Invocations of EIP-20 transfer / transferFrom

Type	Severity	Location
Standard Conformity		SteerPeriphery.sol:L144, L146, L159, L162

Description:

The linked statements do not properly validate the returned bool values of the EIP-20 standard transfer & transferFrom functions. As the standard dictates, callers must not assume that false is never returned.

Impact:

If the code mandates that the returned bool is true, this will cause incompatibility with tokens such as USDT / Tether as no such bool is returned to be evaluated causing the check to fail at all times. On the other hand, if the token utilized can return a false value under certain conditions but the code does not validate it, the contract itself can be compromised as having received / sent funds that it never did.

Example:

Copy
144token0.transferFrom(msg.sender, address(this), amount0Desired);

Recommendation:

Since not all standardized tokens are EIP-20 compliant (such as Tether / USDT), we advise a safe wrapper library to be utilized instead such as SafeERC20 by OpenZeppelin to opportunistically validate the returned bool only if it exists in each instance.

Alleviation (200f275c40):

The contract retains usage of the unchecked implementations of transfer / transferFrom although it did introduce the SafeERC20 library to the IERC20 interface. To properly alleviate the exhibit, all transfer / transferFrom function invocations must be prefixed with safe (i.e. transfer -> safeTransfer).

Alleviation (0ed41ccc18):

All referenced unsafe instances have been properly replaced by their safe prefixed counterparts in the latest commit hash as advised.