dmdv
December 17, 2020, 9:35am
1
Hi
I cannot see any logic behind transfer.
It calls transfer
It call approve
* Emits an {Approval} event indicating the updated allowance. This is not * required by the EIP. See the note at the beginning of {ERC20}. * * Requirements: * * - `sender` and `recipient` cannot be the zero address. * - `sender` must have a balance of at least `amount`. * - the caller must have allowance for ``sender``'s tokens of at least * `amount`. */ function transferFrom(address sender, address recipient, uint256 amount) public virtual override returns (bool) { _transfer(sender, recipient, amount); _approve(sender, _msgSender(), _allowances[sender][_msgSender()].sub(amount, "ERC20: transfer amount exceeds allowance")); return true; } /** * @dev Atomically increases the allowance granted to `spender` by the caller. * * This is an alternative to {approve} that can be used as a mitigation for * problems described in {IERC20-approve}.
Shouldn’t this be the other way?
Approve (and fail if there’s not enough allowance)
Transfer
1 Like
Hi @dmdv ,
Welcome to the community
In the case of ERC20
, the order is irrelevant because _transfer
and _approve
are independent and never call any other contract: they are executed atomically.
However , this is very relevant for users that intent to override _transfer
or _approve
with their own implementations: we should be clear about the order in which these things happen.
See: https://github.com/OpenZeppelin/openzeppelin-contracts/issues/2030#issuecomment-568487500
1 Like