Add `ERC7674` (draft) #5071

Amxx · 2024-06-07T14:49:32Z

ERC-7674 is still WIP, but having it implemented as a draft contract would be valuable for users

Pending discussions:

if (value > 0) {...} in ERC20._spendAllowance vs if (value > 0) super._spendAllowance(...) in ERC20TemporaryApproval
- remove _approve call when value is 0
- skip super call if temporary allowance covers everything
emit event when temporary allowance is set/updated ?

PR Checklist

Tests
Documentation
Changeset entry (run npx changeset add)

changeset-bot · 2024-06-07T14:49:47Z

🦋 Changeset detected

Latest commit: f8c2e7d

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 1 package

Name	Type
openzeppelin-solidity	Minor

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

.changeset/serious-carrots-provide.md

test/token/ERC20/extensions/ERC20TemporaryApproval.test.js

.changeset/serious-carrots-provide.md

contracts/interfaces/draft-IERC7674.sol

ernestognw · 2024-06-07T20:14:03Z

contracts/token/ERC20/ERC20.sol

+        if (value > 0) {
+            uint256 currentAllowance = allowance(owner, spender);
+            if (currentAllowance != type(uint256).max) {
+                if (currentAllowance < value) {
+                    revert ERC20InsufficientAllowance(spender, currentAllowance, value);
+                }
+                unchecked {
+                    _approve(owner, spender, currentAllowance - value, false);
+                }
            }
        }


Didn't we decide against address poisoning for similar reasons we would decide against filtering value == 0?

About address poisoning we decided to:

not revert if value is 0 (for many reason)

keep emitting the transfer event.

The changes here don't introduce a revert, and don't remove any event.

The logic here is the following:

if the temporary allowance is enough, we should not sload/sstore the persistent value (otherwize it break the point of gas savings). So we can do it in two ways:

in ERC20TemporaryApproval._spendAllowance only do the super call if value > 0

this is bad practice if someone else overrides _spendAllowance

in ERC20 change the semantics of _spendAllowance to mean "if there is nothing to spend, we are good anyway".

If we look at ERC20._spendAllowance, this has the following impact

if value = 0, currentAllowance cannot be smaller than value. ERC20InsufficientAllowance is never triggered, so the if doesn't change anything regarding the revert.

if value is 0, 5.0 code does:

load the allowance (from a potentially overridable function)

substract zero from it

set it as the new allowance, without emitting an event.

So there is a change, we are no longer calling _approve with the current value. It may be possible to create edge cases where the missed call to an overrident _approve has an effect. IMO its a non issue.

About address poisoning, it doesn't change the possibility of doing it (or not doing it). It makes it cheaper though, because the poisonning call would not read/write the zero allowance.

@frangio curious to having your opinion on this if in the core ERC20.

It may be possible to create edge cases where the missed call to an overrident _approve has an effect.

Hm, I have a vague memory that this actually was a concern for a project once... It does seem quite risky to change this in a minor version.

Could we implement this by overriding only allowance and _approve instead of _spendAllowance?

I have no idea how. In particular I'm not sure how to make transferFrom spend only temporary allowance, without touching the normal allowance, when the temporary allowance is enough

I think it's possible, but not without the same problem of not invoking super._approve. There seems to be no way around that.

in ERC20TemporaryApproval._spendAllowance only do the super call if value > 0

this is bad practice if someone else overrides _spendAllowance

This is true, but it may be preferable than changing the behavior of ERC20 in a minor version. I think it's worth considering.

Its what I used to do, before realizing there was a way to have the super call always happen.
I'm leanning toward the current version, but I'm open to re-using the old one

As discussed, I re-implemented the old one.

It negativelly affect the tests because the error emitted in some edge conditions depends on _approve being called (with spender = 0 and value = 0).
See 0490902

contracts/token/ERC20/README.adoc

contracts/token/ERC20/extensions/draft-ERC20TemporaryApproval.sol

ernestognw · 2024-06-07T20:26:40Z

contracts/token/ERC20/extensions/draft-ERC20TemporaryApproval.sol

+     * Requirements:
+     * - `spender` cannot be the zero address.
+     *
+     * Does NOT emit an {Approval} event.


This raises an interesting discussion about using events for signaling transient storage updates.
I first thought it shouldn't be needed, but it may disrupt indexers. The case I'm considering is when a company uses an indexer to report financial operations to authorities, for such cases there may be some transfer events they can't track because they were transient.

Whether it's relevant or not for most people is another discussion, but I see one of the main points of the ERC is to provide cheaper allowances, in that case, it'd be a matter of time before getting it widely adopted where possible.

What do you think?

IMO not having events would make it harder to look for historical activity/usage -- especially when transient operations will occur inside other contracts, so it's not as easy as just looking for the temporaryApproval selector in transactions' calldata.

i think that optimizations related to removing events is a separate discussion with regards to shadow logs.

We already not have event to notify of allowance changes in transferFrom. Honestly, if we don't have those, I'm not sure why we would need one here.

On thing event are usefull for it tracking state changes ... but here, the (allowance) state doesn't really change. At the end of the tx its reset anyway. Its not like you are setting an allowance that will stay forever if you forger about it (that IMO needs to be notified)

I've thought about this in the past for ERC-6909X (a proposed extension I designed) and ended up deciding to make events a "SHOULD":

ERC-6909 requires Approval and OperatorSet events to be emitted when allowance and operator status respectively are set. ERC-6909X tokens SHOULD emit these events as part of temporary approvals for strict compliance. The omission of these events during temporary approvals may confuse indexers that rely on events to track allowances and operators. For example, an indexer that assumes the events are complete may conclude that a spender has zero allowance in a case where in fact it has non-zero allowance.

It's not a "MUST" because I understand that for max savings tokens would want to omit them.

But that was in the context of ERC-6909 compliance... which by default has transfer events that include the operator.

We already not have event to notify of allowance changes in transferFrom. Honestly, if we don't have those, I'm not sure why we would need one here.

This is a valid point.

IMO not having events would make it harder to look for historical activity/usage

Right. Based on other's comments I realize it's not a big deal since users may decide whether or not to add an event. That's the decision we took by removing the event from ERC20's _spendAllowance.

We already not have event to notify of allowance changes in transferFrom. Honestly, if we don't have those, I'm not sure why we would need one here.

Yes, I agree with this. The difference is that the event is not defined in this case whereas regular ERC20 users would identify the lack of the Approval event during testing and before deploying/upgrading.

Seems like this is a recommendation in the ERC already. It should be specific: https://github.com/ethereum/ERCs/pull/358/files#r1633892313

contracts/token/ERC20/extensions/draft-ERC20TemporaryApproval.sol

cairoeth · 2024-06-07T20:58:50Z

contracts/token/ERC20/extensions/draft-ERC20TemporaryApproval.sol

+     * Requirements:
+     * - `spender` cannot be the zero address.
+     *
+     * Does NOT emit an {Approval} event.


IMO not having events would make it harder to look for historical activity/usage -- especially when transient operations will occur inside other contracts, so it's not as easy as just looking for the temporaryApproval selector in transactions' calldata.

i think that optimizations related to removing events is a separate discussion with regards to shadow logs.

contracts/token/ERC20/extensions/draft-ERC20TemporaryApproval.sol

test/token/ERC20/ERC20.behavior.js

contracts/token/ERC20/extensions/draft-ERC20TemporaryApproval.sol

ernestognw · 2024-06-28T23:54:44Z

contracts/token/ERC20/extensions/draft-ERC20TemporaryApproval.sol

+    /**
+     * @dev {_spendAllowance} override that consumes the temporary allowance (if any) before eventually falling back
+     * to consumming the persistent allowance.
+     */


Suggested change

*/

* NOTE: This function skips calling `super._spendAllowance` if the temporary allowance

* is enough to cover the spending.

*/

test/token/ERC20/extensions/draft-ERC20TemporaryApproval.test.js

Add ERC20TemporaryApproval

969dacf

Amxx added this to the 5.1 milestone Jun 7, 2024

Amxx commented Jun 7, 2024

View reviewed changes

.changeset/serious-carrots-provide.md Outdated Show resolved Hide resolved

Amxx added 4 commits June 7, 2024 16:50

Update .changeset/serious-carrots-provide.md

ac39524

testing

b69b988

update

162d942

coverage

1b66ff4

Amxx requested review from ernestognw and cairoeth June 7, 2024 17:50

Amxx added 2 commits June 7, 2024 21:43

doc

2527ef6

Update draft-IERC7674.sol

40765c0

Amxx commented Jun 7, 2024

View reviewed changes

test/token/ERC20/extensions/ERC20TemporaryApproval.test.js Outdated Show resolved Hide resolved

Amxx added 2 commits June 7, 2024 22:02

Update test/token/ERC20/extensions/ERC20TemporaryApproval.test.js

1d285c7

rename events in helper

a6b8cb7

ernestognw reviewed Jun 7, 2024

View reviewed changes

cairoeth reviewed Jun 7, 2024

View reviewed changes

update

281510a

Amxx force-pushed the feature/erc-7674 branch from a65c473 to 80261e2 Compare June 10, 2024 11:31

update

036ed54

Amxx force-pushed the feature/erc-7674 branch from 80261e2 to 036ed54 Compare June 10, 2024 11:33

rename ERC20TemporaryApproval -> ERC7674

8f15f1f

Amxx changed the title ~~Add ERC20TemporaryApproval~~ Add ERC7674 Jun 10, 2024

Amxx changed the title ~~Add ERC7674~~ Add ERC7674 (draft) Jun 10, 2024

Amxx added 3 commits June 10, 2024 20:48

rename

b2d4966

if value greater than zero check in ERC20TemporaryApproval

17833c7

fix tests

0490902

Amxx force-pushed the feature/erc-7674 branch from bac03e6 to 0490902 Compare June 13, 2024 14:05

spelling

ddd7576

Amxx commented Jun 13, 2024

View reviewed changes

test/token/ERC20/ERC20.behavior.js Outdated Show resolved Hide resolved

Update test/token/ERC20/ERC20.behavior.js

cf3c26d

Amxx requested review from frangio, ernestognw and cairoeth June 27, 2024 13:44

ernestognw reviewed Jun 29, 2024

View reviewed changes

Apply suggestions from code review

f8c2e7d

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Add `ERC7674` (draft) #5071

Add `ERC7674` (draft) #5071

Amxx commented Jun 7, 2024 •

edited

Loading

changeset-bot bot commented Jun 7, 2024 •

edited

Loading

ernestognw Jun 7, 2024

Amxx Jun 10, 2024 •

edited

Loading

Amxx Jun 10, 2024 •

edited

Loading

Amxx Jun 10, 2024

frangio Jun 10, 2024

Amxx Jun 10, 2024

frangio Jun 10, 2024

frangio Jun 10, 2024 •

edited

Loading

Amxx Jun 11, 2024 •

edited

Loading

Amxx Jun 13, 2024 •

edited

Loading

ernestognw Jun 7, 2024

cairoeth Jun 7, 2024

Amxx Jun 10, 2024

frangio Jun 10, 2024 •

edited

Loading

ernestognw Jun 12, 2024

cairoeth Jun 7, 2024

ernestognw Jun 28, 2024

-     */
+     * NOTE: This function skips calling `super._spendAllowance` if the temporary allowance
+     * is enough to cover the spending.
+     */

Add ERC7674 (draft) #5071

Are you sure you want to change the base?

Add ERC7674 (draft) #5071

Conversation

Amxx commented Jun 7, 2024 • edited Loading

PR Checklist

changeset-bot bot commented Jun 7, 2024 • edited Loading

🦋 Changeset detected

Choose a reason for hiding this comment

Amxx Jun 10, 2024 • edited Loading

Choose a reason for hiding this comment

Amxx Jun 10, 2024 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

frangio Jun 10, 2024 • edited Loading

Choose a reason for hiding this comment

Amxx Jun 11, 2024 • edited Loading

Choose a reason for hiding this comment

Amxx Jun 13, 2024 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

frangio Jun 10, 2024 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Add `ERC7674` (draft) #5071

Add `ERC7674` (draft) #5071

Amxx commented Jun 7, 2024 •

edited

Loading

changeset-bot bot commented Jun 7, 2024 •

edited

Loading

Amxx Jun 10, 2024 •

edited

Loading

Amxx Jun 10, 2024 •

edited

Loading

frangio Jun 10, 2024 •

edited

Loading

Amxx Jun 11, 2024 •

edited

Loading

Amxx Jun 13, 2024 •

edited

Loading

frangio Jun 10, 2024 •

edited

Loading