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]

File ERCS/erc-7674.md

Requires 1 more reviewers from @axic, @g11tech, @SamWilsn, @xinbenlv

[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 😅

[ernestognw]

Left some comments in case you're open to generalize it. Feel free to disregard.

[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 byshape#1 to update this PR. We should stry to get it merge sonner rather than latter.

[frangio]

This temporary allowance is to be considered in addition to the normal (persistent) ERC-20 allowance

This forces an SLOAD of the current allowance, resulting in higher costs than one would want from this feature. I think it should be a temporary allowance override instead.

[Amxx]

I disagree.

If the temporary allowance takes priority (this should be mentionned somewhere if it isn't already), and if the temporary allowance is sufficient to cover the need of some function that consumes allowance (transferFrom), then the allowance can be consumed from the temporary part without having to go consume anything in the persistent part.

You only need to lean (and update) the persistent part if the temporary part is not sufficient.

An analogy would be:

• you want to cook rice,
• you have 2kg of rice in your kitchen (fast access - eq to temporary)
• you have 50kg of rice stored in you basement (slow access - eq to persistent)

it is true that:

• you have 52kg available
• to measure how much you have available, you have to check both the kitchen and the basement
• if you need to cook diner, and that diner requires 500g of rice, the kitchen is sufficient, and you don't need to go to the basement. Rice in the basement is available if you need, but you don't need to access it unless there isn't enough in the kitchen for what you are planning to cook.

[Amxx]

What do you think of

Suggested change

Call to `temporaryApprove(spender, value)` allows `spender` to withdraw within the same transaction from `msg.sender` multiple times, up to the `value` amount. This temporary allowance is to be considered in addition to the normal (persistent) [ERC-20](./eip-20.md) allowance, the total value that spender is able to spend during the transaction is thus capped by the sum of the temporary and the normal (persistent) allowances.

Call to `temporaryApprove(spender, value)` allows `spender` to withdraw within the same transaction from `msg.sender` multiple times, up to the `value` amount. This temporary allowance is to be considered in addition to the normal (persistent) [ERC-20](./eip-20.md) allowance, the total value that spender is able to spend during the transaction is thus capped by the sum of the temporary and the normal (persistent) allowances. While it SHOULD be possible for a `transferFrom` operation to consume both types of allowance, the consumption of the temporary allowance SHOULD take priority over the consumption of the persistent allowance. Therefore, if the temporary allowance is sufficient for executing a `transferFrom` operation, the persistent allowance SHOULD not be loaded/updated from the storage. Consumption of persistent allowance, which implies storage accesses, SHOULD be performed only if the temporary allowance is not sufficient for the operation being executed.

[frangio]

Yes, my confusion was because of the effect on the allowance() function. If the allowances have to be added, this forces allowance to read from both. However, in the context of transferFrom it should not be necessary to do this, as you've described.

I am not sure if the effect on allowance is something that we should care about.

[SamWilsn]

Suggested change

	description: An interface for ephemeral ERC-20 approvals
	description: An interface for ERC-20 approvals lasting a single transaction

[SamWilsn]

will only be used once

This is a bit misleading. This approval can be used multiple times, as long as it's in a single transaction.

[SamWilsn]

You should specify the event, or clarify what "specific" means here. The easiest would be to define the event, but leave it optional.

[SamWilsn]

This is all still implementation detail. You should only specify the externally visible behaviour in the Specification section. You can put recommendations in the Reference Implementation section. How about:

Suggested change

The storage for the temporary allowances MUST be different to that of the regular allowance. Compliant contracts MAY use the transient storage [EIP-1153](./eip-1153.md) to keep the temporary allowance. For each `owner` and `spender`, the slot MUST be uniquely selected to avoid slot collision. Each slot index SHOULD be derived from the base slot index for temporary allowances, `owner` and `spender` addresses. Slot MAY be derived as `keccak256(spender . keccak256(owner . p))` where `.` is concatenation and `p` is `keccak256` from the string uniquely defining temporary allowances in the namespace of the implementing contract.

Each temporary allowance MUST persist until the end of the transaction that created it (unless overwritten by another call to `temporaryApprove`.) Each temporary allowance MUST be cleared at the end of the transaction that created it. See [Using Transient Storage](#using-transient-storage) for an example.

Then moving this content to the Reference Implementation section under a "Using Transient Storage" heading.

[Amxx]

(unless overwritten by another call to temporaryApprove or consumed by a call to transferFrom).

[github-actions]

The commit 8a11a87 (as a parent of e167942) 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.