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
Race condition in the ERC20 “approve” function may lead to token theft
Severity: Medium
Difficulty: High
Type: Timing
Description
A known race condition in the ERC20 standard, on the approve function, could lead to token theft. The ERC20 standard describes how to create generic token contracts. Among others, an ERC20 contract defines these two functions:
transferFrom(from, to, value)
approve(spender, value)
These functions give permission to a third party to spend tokens. Once the function approve(spender, value) has been called by a user, spender can spend up to value of the user’s tokens by calling transferFrom(user, to, value).
This schema is vulnerable to a race condition, where the user calls approve a second time on a spender that has already been allowed. If the spender sees the transaction containing the call before it has been mined, the spender can call transferFrom to transfer the previous value and still receive the authorization to transfer the new value.
Recommendation
One common workaround is to use two non-ERC20 functions, allowing a user to increase and decrease the approval (see increaseApproval and decreaseApproval of StandardToken.sol#L63-L98). Ensure users are aware of this extra functionality, and encourage them to make use of it when appropriate.
The text was updated successfully, but these errors were encountered:
#2 Added missing events
#3 bump up compiler version to 0.5.12(same with DAI)
#6 use enum to represent contract state
#7 Added methods to prevent "approve" race condition
Race condition in the ERC20 “approve” function may lead to token theft
Severity: Medium
Difficulty: High
Type: Timing
Description
A known race condition in the ERC20 standard, on the
approve
function, could lead to token theft. The ERC20 standard describes how to create generic token contracts. Among others, an ERC20 contract defines these two functions:transferFrom(from, to, value)
approve(spender, value)
These functions give permission to a third party to spend tokens. Once the function
approve(spender, value)
has been called by a user, spender can spend up to value of the user’s tokens by callingtransferFrom(user, to, value)
.This schema is vulnerable to a race condition, where the user calls approve a second time on a spender that has already been allowed. If the spender sees the transaction containing the call before it has been mined, the spender can call
transferFrom
to transfer the previous value and still receive the authorization to transfer the new value.Recommendation
One common workaround is to use two non-ERC20 functions, allowing a user to increase and decrease the approval (see
increaseApproval
anddecreaseApproval
of StandardToken.sol#L63-L98). Ensure users are aware of this extra functionality, and encourage them to make use of it when appropriate.The text was updated successfully, but these errors were encountered: