Transient Approval

[Amxx]

In some cases, an ERC20 approval is granted, that is then used in the same transaction. In that case, using storage is expensive, and potentially dangerous if approval persists.

The idea is to have, next to the normal allowance, a transient allowance.

This transient allowance can be set using a new "approveTransient" function that replicates the behavior of "approve" (minus the event)

When doing a transferFrom (or any operation that consumes allowance) the transient allowance is used first. If that is enough, no storage read or right is necessary. If transient allowance is not enough, normal (storage allowance is used)

If EOA multicall becomes available, either through EIP-3074 or EIP-5806, EOAs will be able to:

• set transient allowance
• use that allowance in defi (swap) ?
  In a single transaction. This should save significant amount of gas over the same approach with storage based allowances.

No allowance is left after the tx, reducing risks.

That does not require any change from the consumer side (same transferFrom).

Implementation can be found here

[charles-cooper]

would be extra good with https://eips.ethereum.org/EIPS/eip-7609 ;)

[wjmelements]

1. This makes ERC20 transferFrom use more gas on average. Consider making a different ERC extending or replacing ERC20 for transient transferFrom.

2. I am glad this design makes a separate approve method instead of changing ERC20 approve.

3. Ideally the sload slot is the same as the tload slot so it can reuse the sha3. This isn't possible in Solidity.

4. The batch usage that this design targets already benefits from the SSTORE-reset refund in the EVM. It would not surprise me if the transient pattern used more gas, or if the savings was less than 5000.

[Amxx]

Thank you @wjmelements for your feedback

1. That would definitelly be opt in (extension to ERC-20). Note that if no temporary allowance is set, it only costs a 2 hashes, a tload, and some ifs. That is not 0, but its very small compared to the cost of doing a transferFrom (2 or 3 sstores !)

2. It would definitelly be a different approve methode. We need to keep the ERC20.approve function to keep its behavior!

3. It is not impossible. The difficulty is in figuring out the slot used by the allowance mapping. If using ERC-7201, then that is possible.

4. I've implemented and run the numbers (with an EIP-5806 based multicall). TSTORE is cheaper!

[wjmelements]

3. It is not impossible. The difficulty is in figuring out the slot used by the allowance mapping. If using ERC-7201, then that is possible.

Anything can be done in assembly but in solidity it will compute the same hash twice to determine the slot.