@perfect-abstractions/compose/token/ERC20/Approve/ERC20ApproveFacet.solGrant a spender an allowance over the caller's tokens
approve sets the caller's allowance for _spender in ERC20Storage at erc8042:erc20.msg.sender, so no access control is needed.STORAGE_POSITIONbytes32keccak256("erc20"))Sets how many of the caller's tokens _spender may move with transferFrom. The stored allowance becomes exactly _value, overwriting any previous allowance for that spender.
The caller's balance is not checked. You can approve more tokens than you hold, and the limit is enforced later when the spender actually transfers.
Parameters:
_spenderaddressaddress(0)._valueuint2560 revokes it. type(uint256).max grants an unlimited allowance that is never decremented.Returns:
-booltrue. Failures revert instead of returning false.Reverts:
ERC20InvalidSpendererror_spender is address(0).Emitted on every successful approve, including when _value is 0 or unchanged.
_owneraddressmsg.sender._spenderaddress_valueuint256Thrown by approve when _spender is the zero address.
_spenderaddressaddress(0).ERC20TransferFacet alongside this facet. An allowance only does something once a spender can call transferFrom.ERC20DataFacet so callers can read the current value with allowance().type(uint256).max stays valid until you explicitly set it back to 0.approve(_spender, 0).approve only ever writes the allowance of msg.sender, so a caller cannot grant spending rights over anyone else's tokens.
Changing a non-zero allowance can be front-run. If you lower an allowance from N to M, the spender can see the pending transaction, spend N first, and then spend M as well. This facet has no increaseAllowance or decreaseAllowance. To change a non-zero allowance safely, set it to 0, confirm that transaction, then set the new value.
transferFrom and burnFrom reduce allowances without emitting Approval. Rebuilding allowances from Approval events alone gives stale values, so read allowance() for the current number.