Originally submitted by warden Dravee in #146, duplicate of #178 related to the use of safeApprove.
This is upgraded from a QA report to standalone issue because it correctly described the revert when trying to call safeApprove on non-zero allowance. QA report that only describe safeApprove as deprecated and unable to identify the revert problem are intentionally not upgraded. Duplicate of #180.
Deprecated safeApprove() function
Using this deprecated function can lead to unintended reverts and potentially the locking of funds. A deeper discussion on the deprecation of this function is in OZ issue #2219 (OpenZeppelin/openzeppelin-contracts#2219). The OpenZeppelin ERC20 safeApprove() function has been deprecated, as seen in the comments of the OpenZeppelin code.
As recommended by the OpenZeppelin comment, I suggest replacing safeApprove() with safeIncreaseAllowance() or safeDecreaseAllowance() instead:
Originally submitted by warden
Dravee
in #146, duplicate of #178 related to the use ofsafeApprove
. This is upgraded from a QA report to standalone issue because it correctly described the revert when trying to callsafeApprove
on non-zero allowance. QA report that only describesafeApprove
as deprecated and unable to identify the revert problem are intentionally not upgraded. Duplicate of #180.Deprecated safeApprove() function
Using this deprecated function can lead to unintended reverts and potentially the locking of funds. A deeper discussion on the deprecation of this function is in OZ issue #2219 (OpenZeppelin/openzeppelin-contracts#2219). The OpenZeppelin ERC20 safeApprove() function has been deprecated, as seen in the comments of the OpenZeppelin code.
As recommended by the OpenZeppelin comment, I suggest replacing safeApprove() with safeIncreaseAllowance() or safeDecreaseAllowance() instead: