Add ERC: Temporary Approval Extension for ERC-20

[byshape]

Among all cases of ERC-20 token transactions, a popular one is when smart contracts approve token spending to other contracts. Often tokens are approved for only one transaction.

Following the ERC-20 standard, if a smart contract wants to approve the spending of tokens to another smart contract for only one transaction, this causes the allowance saved in storage to be updated and retrieved.

Token allowances utilising EIP-1153 transient storage are a cheaper alternative to the regular storage allowances.

[eip-review-bot]

✅ All reviewers have approved.

[ZumZoom]

Commit 85f7d71 removes EIP-1153 reference from the description section but it seems that EIP Walidator needs to be fixed instead:

https://github.com/ethereum/ERCs/actions/runs/8536634399/job/23385573486#step:3:14

Error: error[preamble-refs-description]: unable to read file ``erc-1153.md``: Io: JsValue(Error: ENOENT: no such file or directory, open 'ERCS/erc-1153.md'

It seems that it disallows referencing any EIP in the description section.

[Amxx]

IMO "transient" is a technical name that refers to the underlying mechanism used here, but should not be exposed in the ABI or in the "docuementation" or this feature. I propose using "temporary allowance" instead of "transient allowance", as I believe this naming would be more user-friendly for people that have no knowledge of EIP-1153

[Amxx]

This ERC should clearly mention that:

• No event is required when setting a temporary/transient allowance
• This ERC does not break ERC20's transferFrom, because setting a temporary/transient allowance falls in the scope of "explicitelly authorizing the transfer"

[byshape]

Mikhail @ZumZoom and I have collected some opinions on naming transient/temporary, with the majority leaning towards temporary as the friendlier option. So I replaced uses wherever it was appropriate.

[ernestognw]

I left a review, thanks for pointing out @Amxx!

The ERC looks good, but since it's defining an interface for a temporary approval, I don't see why to restrict this to transient storage. While it makes sense, I think the benefits of this kind of approval can be achieved regardless of transient storage support in a context where using storage may not be a big deal (e.g. an L2)

I would suggest generalizing the interface and its semantics while keeping the suggestions for using transient storage if EIP-1153 is available, but I understand the intention of making a transient-approval ERC 😅

[byshape]

@ernestognw Thank you for your comments!

While it makes sense, I think the benefits of this kind of approval can be achieved regardless of transient storage support in a context where using storage may not be a big deal (e.g. an L2)

Do you already have any ideas on how this could be implemented?

[ernestognw]

A quick thought was another mapping with approvals per block number (or timestamp), in this way it's not needed to clean up the value at the end since it will just get invalidated immediately.

Here's a quick PoC

[byshape]

I prefer to keep the temporary storage for this ERC within a transaction rather than a block. EIP-1153 already operates within these limits so that compatible chains will be able to use this functionality. The rest may try to implement this logic in any other non-conflicting way.

[Amxx]

@byshape created https://github.com/byshape/ERCs/pull/1 to update this PR. We should stry to get it merge sonner rather than latter.

[github-actions[bot]]

The commit 8a11a8715c50573b759692d0d7da6c9aa34d16bf (as a parent of e16794235979b3d69767725404d42f2d4b7f0dc9) contains errors. Please inspect the Run Summary for details.

[SamWilsn]

I took the liberty of fixing your EIP/ERC links. You do need to use [ERC-20](./eip-20.md) when linking to ERCs because of a quirk in our rendering system.