EIPs Explained: EIP-2612
Background
EIP-2612 is purpose built to allow an ERC20 token approval to occur within the same transaction it is consumed. This builds upon two previous standards: EIP-20 and EIP-712. We will briefly cover some of the important aspects of these two standards but if you are unfamiliar with either, we recommend you review them first before continuing with this article.
EIP Summary
EIP-2612 can be thought of as an extension of EIP-20. For those unfamiliar with EIP-20, it is the standard that describes the API requirements for nonfungible ERC-20 tokens. EIP-2612 adds 3 new functions to the ERC-20 token standard: permit(), nonces(), and DOMAIN_SEPARATOR().
The bulk of the added functionality can be found within the permit() function of this EIP. It takes the owner of the ERC-20 tokens, the account that will be given permission to spend on behalf of the owner, the value to set the approval to, a deadline, and a signature in order to update the approval mapping for the ERC-20 token.
Let’s take a practical look at how permit() works by reviewing an implementation of it by the popular OpenZeppelin library:
We’ll further break this up into three sections:
Deadline Enforcement
In this first line, we see that the deadline is being enforced by comparing it to the current timestamp. If the current block’s timestamp is greater than the deadline, we know that the time limit has passed and we revert the transaction. This check allows users to provide an expiration date for their signed approval.
Signature Hash Encoding
In these two lines, the hash of the parameters is being set up so that a signature can be recovered from it. Note that it contains all of the relevant information mentioned in the EIP: the owner, spender, value, and deadline. The _useNonce() wrapper is a fancy way of incrementing the nonce immediately after it has been consumed. Constructing the hash in this way means the original signer needs to have signed off on all of this same information in order for the signature recovery to work properly. The correctly encoded EIP-712 hash for this domain is constructed using the hashed struct and domain separator.
This is a good time to step out of the permit() function and discuss the domain separator. The domain separator is used to limit a signature to a domain. This is useful to ensure users aren’t signing a blank check. By incorporating information such as the ERC-20 token name and chainID into the domain, the signature shouldn’t apply broadly across other apps and chains.
Signature Recovery
Last, we recover the address of the signer using both the signed hash and the values that represent the signature and recovery identifier themselves. The ECDSA.recover call is a wrapper around the ecrecover precompile. This precompile returns the public key from a signature, the recovery identifier, and a signed message. If the public key matches the owner then we know the owner originally signed this message and the approval will be made.
And that’s the bulk of the added functionality! We’ll now go over a few use cases and security considerations for those considering using EIP-2612 functionality in their protocol.
Use Cases
1. Gasless Transactions
One very popular use of EIP-2612 is for performing gasless transactions. Since the EIP-712 style signatures can be gathered offchain, the user is not expected to be the party that posts the transaction containing the call to permit(). Protocols can therefore offer gasless transactions for their users that may have otherwise required a user to interact directly with an app.
2. Reduced Approval Footprint
As we covered in “Top 5 Smart Contract Vulnerabilities of 2023”, unrevoked approvals are a major source of lost funds for users in DeFi. Leveraging EIP-2612 to collect signatures on the spot for approvals, it is feasible for protocols to offer their users a seamless experience without requiring a permanent max approval. This can help users reduce their approval footprint and potentially keep them safe during protocol hacks.
3. Batched Transactions
Interactions across apps that handle tokens making use of EIP-2612 can be batched together. Batching can improve intra transaction composability, allowing users to interact with multiple protocols and potentially be less susceptible to transaction ordering attacks. Batched transactions can also benefit from the ability to be made gasless for users.
Security Considerations
Replay Protection
It’s important that the signing domain be unique, otherwise signatures can be replayed across domains. In practice, popular EIP-712 libraries take care of a lot of this for you. We recommend using unique names and/or versions when constructing each of your tokens to improve the robustness of replay protection.
Signature Malleability
Signature malleability occurs when non-unique signatures can be considered valid for the same signed output. The EVM opcode ecrecover itself can return the same address for non-unique signatures. Similar to replay issues, much of this can be mitigated by using popular libraries which reject a second set of signatures that ecrecover would accept.
ecrecover Silent Failure
As mentioned in EIP-2612 itself, the ecrecover precompile fails silently and returns the 0 address for the signer on failure. This means that it’s important to check that the signer is not the 0 address when performing a permit(). Most of the well-known libraries account for this by throwing an error when ecrecover returns 0.
Protocol Complexity
Adding EIP-2612 functionality to a protocol can increase the complexity. In addition to adding frontend capabilities for gathering signatures, the contracts themselves often require both permit functionality and traditional non-signature based functionality as well. Protocols should therefore keep in mind the potential increase in deployment costs as well as complexity when choosing to add EIP-2612 functionality.
Censorship Potential
It is typical for protocols that implement EIP-2612 functionality to also submit the transactions on the user’s behalf. This means that the user relies on the protocol to submit their transaction in order to interact with its apps.
Closing Thoughts
EIP-2612 offers additional functionality that is useful for protocols that wish to offer gasless or batched transactions. If implemented properly, it also can help users reduce their approval footprint and allow them to interact with dApps more safely. Using existing libraries can help development teams avoid common cryptographic pitfalls and implementing a traditional way to interact with their dApps in addition to the EIP-2612 methods can limit the risk of censorship issues.
If you’re interested in a smart contract audit or other security services, get the process started by visiting afterdarklabs.xyz or reaching out to info@afterdarklabs.xyz directly.
