Summary

The use of safeApprove for setting allowances in ERC-20 token contracts is deprecated due to inherent vulnerabilities similar to those found in the approve function of the ERC-20 standard. This deprecation is highlighted in the OpenZeppelin contracts library (https://github.com/OpenZeppelin/openzeppelin-contracts/blob/bfff03c0d2a59bcd8e2ead1da9aed9edf0080d05/contracts/token/ERC20/utils/SafeERC20.sol#L38-L58), which recommends using safeIncreaseAllowance and ```safeDecreaseAllowancev instead to mitigate potential security risks.

Vulnerability Details

Impact

The code uses safeApprove to reset allowances to zero and then set new allowances to type(uint256).max, which is a common pattern to avoid having to approve each transaction individually. This pattern itself mitigates the primary risk associated with changing allowances, as these is a resetting to zero before setting a new allowance. However, the deprecation notice suggests that even this pattern is discouraged due to the inherent risks in the approve mechanism. While the specific implementation mitigates the most common risk by resetting allowances to zero before setting new ones, the use of safeApprove is still discouraged due to the potential for unexpected behavior in certain edge cases. For example, if there's a bug in the token contract that doesn't properly handle the reset to zero or if there's unexpected behavior in how transactions are ordered or confirmed, it could lead to vulnerabilities.

Tools Used

Manual review

Recommendations

To mitigate the vulnerabilities associated with safeApprove, it is recommended to refactor the code to use safeIncreaseAllowance and safeDecreaseAllowance. These functions are designed to safely adjust allowances in a way that avoids the potential for race conditions and ensures allowances are modified as intended.