You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Thanks @PatrickAlphaC. This is correct, but forceApprove may be better our case, wdyt?
In the only usage of safeApprove, the intention is to approve to 0, before actual approve to support USDT like tokens. This can be achieved by using forceApprove instead.
You introduce a race condition if you always use forceApprove. Here is the scenario:
Bob forceApprove Sally to spend 10 tokens.
Bob decides he actually wants her to be able to spend 15 instead of 10, so sends another forceApprove transaction for 15 tokens.
Before Bob's transaction lands, Sally notices this, and front-runs the transaction, spends the 10 tokens. Now Bob's forceApprove transaction hits for an additional 15.
Sally is able to spend 25 tokens instead of the 15 she was supposed to spend.
If instead, Bob used safeIncreaseAllowance, he would have increased the allowance by 5, so Sally only would have ever been able to spend the 15 tokens Bob originally intended.
Additionally, the new openzeppelin contracts use forceApproveinside of the safeIncreaseAllowance function anyways.
safeApprove
is deprecated, usesafeIncreaseAllowance
instead.The text was updated successfully, but these errors were encountered: