Temporary ERC-20 approvals: A cheaper & safer way to do DeFi

We explore how temporary ERC-20 approvals, recently enabled by transient storage, can improve security and lower gas costs for DeFi users.

TL;DR:

• Temporary Approve (ERC-7674) is a proposed extension to ERC-20 tokens that aims to improve security and gas costs for DeFi transactions.
• ERC-20 token approvals can leave a user’s balance vulnerable to exploits of an approved contract, even after the user has finished interacting with that contract.
• Unlike existing ERC-20 approvals, temporary approvals last only for a single transaction, reducing a user’s exposure to contracts they have approved.

Introduction

Earlier this year, Ethereum’s Cancun upgrade introduced a new feature: transient storage. This feature introduces a middle ground between memory and permanent storage, allowing for a new way to handle data within the EVM whereby it is stored for the duration of a single transaction.

One of the notable use cases highlighted in the transient storage Ethereum Improvement Proposal (EIP) is the implementation of ERC-20 token approvals that are valid for only a single transaction. This means that instead of granting broad approvals that remain active until explicitly revoked, users can initiate transactions with a more precise and temporary level of access.

This new approval type, specified in ERC-7674. can make DeFi approvals safer as well as cheaper. We welcome your thoughts and feedback on this topic, so be sure to reach out to us to share your insights.

Transient storage

The Cancun upgrade, which went live on Ethereum on Mar 13, 2024, introduced transient storage opcodes via EIP-1153. These new opcodes (“TSTORE” and “TLOAD”) function similarly to the existing storage opcodes, (“SSTORE” and “SLOAD”). However, the key difference is that the storage values are discarded at the end of the transaction, rather than being retained permanently. As a result of this temporary nature, the transient storage opcodes are considerably cheaper to use compared to their persistent storage equivalents.

Existing ERC-20 approvals

Existing ERC-20 approvals, as specified in the standard, persist after the call to “approve.” While there is some convenience in only needing to approve a contract to transfer your funds once in order to authorize many withdrawals, there is a risk in having a standing approval. If a bug is later found and exploited in an approved contract that allows an attacker to spend allowed balances in an unexpected way, your funds can be stolen.

The risk isn’t just theoretical. According to revoke.cash,  a tool for removing ERC-20 approvals from your wallet, ~$417M has been stolen since 2020 from crypto users via token approvals.

ERC-20 approvals have long been a headache for devs and EVM users both in terms of security and user experience. In addition to the potential for loss described above, ERC-20 approvals generally require a second transaction for a single DeFi action–a bad user experience with respect to both time and cost.

Previous attempts have been made to alleviate the pain points of ERC-20 approvals. For instance, Vittorio Minacori published ERC-1363: Payable Token in 2020. It is an extension of ERC-20 functionality that would allow users to transfer tokens and then make a call to the receiving contract. This pattern could avoid the need to set an approval at all by changing the pattern for DeFi transactions. As an example:

BeforeAfter1. Approve DeFi contract on the ERC-20 token contract you are trying to spend

2. Call DeFi contract to draw tokens from your balance and perform the desired action

1. Call `transferAndCall` on the ERC-1363 enabled token, which will transfer tokens to a DeFi contract then call that contract within the same transaction

ERC-1363 could therefore improve both the user experience (by not requiring a separate approval transaction) and security by limiting one’s exposure to a contract to a single transaction.

The downside of ERC-1363 is that it requires both ERC-20 tokens and DeFi contracts to make changes from their current patterns–tokens would need to implement new functions (for example, `transferAndCall`), and DeFi contracts to support callbacks like `onTransferReceived` in the case of `transferAndCall`.

ERC-7674: Temporary Approve

ERC-7674, “Temporary Approval Extension for ERC-20,” proposes a new type of ERC-20 approval named `temporaryApprove` that only persists for the duration of a single transaction. This approval type is made possible by EIP-1153 transient storage.

Unlike ERC-1363, Temporary Approve can be compatible with existing DeFi protocols utilizing `transferFrom` while alleviating the security concern of creating a traditional standing ERC-20 approval.

Avoiding the standing approval has benefits for both the user and the application developer, as it reduces the risk for both parties:

1. the user reduces the amount of loss for which they are at risk, and
2. the developer reduces the total exposure of an approval exploit on their contracts

OpenZeppelin has created a draft implementation for integration with an ERC-20 token contract.

Using Temporary Approve

Currently, Temporary Approve cannot be used by externally owned accounts (EOAs), as EOAs cannot currently make multiple calls within a single transaction.

Temporary Approve can be utilized now by smart contract accounts (SCAs) and eventually by EOAs with the inclusion of EIP-7702. EIP-7702 introduces a new transaction type that sets the code for an EOA account for a single transaction with the goal of augmenting the capabilities of an EOA.

In fact, in the “motivation” section of EIP-7702, one use case that is mentioned explicitly is:

“allowing multiple operations from the same user in one atomic transaction. One common example is an ERC-20 approval followed by spending that approval.”

EIP-7702 will allow an EOA to set a temporary approval and then initiate a DeFi action (such as swapping tokens) within the same transaction like so:

Temporary Approve

Approximate approval storage costs

EOA

100 initial TSTORE

1. Call temporaryApprove( ) on token contract

+ 100 TLOAD to read approval

2. Call swap ( ) on DeFi contract

+100 TSTORE to modify approval

= ~300 gas

An alternative pattern that would be to set a permanent approval, initiate a DeFi action, and then set the permanent approval to 0. While the end result would be similar, temporary approvals reduce complexity and gas cost to nearly a tenth of the traditional cost. Note that you could in theory set the approval at the beginning of the transaction with the exact amount of tokens needing to be spent, but not all DeFi actions spend a predetermined amount of tokens (for instance, buying a specific amount of another token on Uniswap).

Traditional Approve

Approximate approval storage costs

EOA

20k initial sstore

1. Call temporaryApprove( ) on token contract

+ 2100 cold sload

2. Call swap ( ) on DeFi contract

+ 100 warm sload

3. Call approve( ) on token contract to set to 0

+ 100 warm sstore

+100 warm sstore

- 19,900 refund

=~2500 gas

EIP-7702 is currently slated to be in the Pectra hard fork, Ethereum’s next upgrade. Once EIP-7702 goes live, however, there may still be a delay in being able to easily send multiple calls if wallets do not support EIP-7702 functionality from day one.

Reach out and contribute

We’re looking for more thoughts on temporary approvals. We would love to hear from you, especially if you are:

1. A DeFi application developer that works with ERC-20 approvals and is interested in using temporary approvals in your application
2. Planning on launching an ERC-20 token and are interested in integrating temporary approvals
3. Maintaining an upgradeable ERC-20 token and are interested in an upgrade to include temporary approvals
4. Any combination of the above

Also note that ERC-7674 is not finalized. If you have thoughts on changes that could be made to the current draft, you can voice your opinion on the Ethereum Magicians forum.

Links and resources

• ERC-7674: Temporary Approval Extension for ERC-20 Draft
• EIP-1153: Transient storage opcodes
• ERC-20: Token Standard
• EIP-7702: Set EOA account code
• EIP-7600: Prague Hard Fork
  
  

Acknowledgements

Thanks to Hadrien Crubois, an engineer at OpenZeppelin and one of the authors of ERC-7674, for reviewing this post.

Note that this blog post does not indicate what features Circle may or may not support in future upgrades to its products.

¹ SSTORE gas costs are estimated using EIP-3529: Reduction in refunds.

© 2024 Circle Internet Group, Inc

‍