📘Understanding Approvals

Book an audit with Zokyo

Understanding the Approval Mechanism

To thoroughly grasp the security implications associated with ERC20 token approvals and the potential pitfalls and protections offered by OpenZeppelin's safe approvals, it is crucial to first understand the intricacies of the standard approval mechanism in ERC20 tokens. This will lay the foundation for understanding not only how standard approvals can be manipulated for malicious intent, but also how the correct and incorrect use of safe approvals can respectively mitigate or contribute to these security vulnerabilities.

Approve()

In the ERC20 token standard, the approve() function is used to give another Ethereum address (usually a smart contract) an allowance, or the approval to transfer a certain amount of token on behalf of the token owner. This is a critical part of how decentralized exchanges, DeFi protocols, and other smart contract-based systems function.

Here is the typical signature of the approve() function:

function approve(address _spender, uint256 _value) public returns (bool success)

In this function:

• _spender is the address which will be given the right to spend the owner's tokens.

• _value is the amount of tokens they can spend.

When a token holder calls the approve() function, they allow the _spender to withdraw tokens from their address up to the specified _value. The _spender can carry out the transfer operation multiple times until the total transferred amount reaches the _value.

This approval mechanism opens the door to a more interactive and open financial system. However, if not handled correctly, it can lead to significant security vulnerabilities, which we'll discuss in the next section.

SafeApprove()

OpenZeppelin, a well-established library for secure smart contract development, has proposed improved handling of the approve() function through the implementation of safeApprove(). This function was intended to mitigate potential vulnerabilities associated with the standard ERC20 approve() function - particularly, the approval race condition.

Here is a snapshot of the safeApprove() function:

    function safeApprove(IERC20 token, address spender, uint256 value) internal {
        // safeApprove should only be called when setting an initial allowance,
        // or when resetting it to zero. To increase and decrease it, use
        // 'safeIncreaseAllowance' and 'safeDecreaseAllowance'
        // solhint-disable-next-line max-line-length
        require((value == 0) || (token.allowance(address(this), spender) == 0),
            "SafeERC20: approve from non-zero to non-zero allowance"
        );
        _callOptionalReturn(token, abi.encodeWithSelector(token.approve.selector, spender, value));
    }

In safeApprove(), a prerequisite check ensures that the current allowance is zero before setting a new one. If the allowance isn't zero, the function reverts. Therefore, the allowance can only transition from zero to a non-zero value or vice versa. This aims to eliminate the approval race condition, a potential exploit where an attacker can leverage an existing approval allowance to transfer tokens ahead of your allowance alteration.

It is essential to note, however, that despite safeApprove()'s objective, proper usage in tandem with other security practices is crucial for effective protection against token approval vulnerabilities. Improper usage can still introduce security vulnerabilities, a subject we'll dive deeper into in later sections.

Currently, it seems that safeApprove() may be deprecated. Despite this, it could still be present in numerous deployed smart contracts, thus remaining a relevant consideration during security auditing.