Intas.Tech
Intas.Tech

Lower transaction fees and better UX on Ethereum

A few weeks ago, Uniswap Labs released an improvement for token permissions that previously remained unresolved with the ERC-20 standard and Permit1 (EIP-2612): Permit2.
 

A good user experience and gas cost optimization are important building blocks when implementing use cases on a public blockchain. The original permission method in Ethereum had weaknesses. Users had to send multiple approval transactions depending on the application, which could lead to confusion. For convenience, some apps even asked users to approve their maximum available token balance, which then gave apps access to the entire token balance of the wallet for an indefinite period, putting all users’ tokens at risk in the event of a potential hack. Later, the permission system in Ethereum was improved by introducing granular permissions that allowed applications to better control access to the token balance. However, older tokens do not support this feature, and not all newer tokens have adopted it.

 

How do ERC-20 token approvals work by default?

The standard model of ERC-20 tokens in Ethereum requires two transactions, each of which incurs gas charges: An approval and an interaction (see Figure 1). 

Figure 1: Approval process in the standard model of ERC-20

  1. Bob calls the approve() function on an ERC-20 to grant issue approval for a smart contract.
  2. Bob calls the interaction() function, which in turn calls transferFrom() on the ERC20 token smart contract to transfer the tokens.

The standard model has two disadvantages:
  1. Poor usability: Users have to approve each new protocol with a separate transaction for each token they want to use.
  2. Poor security: Many applications often require unlimited approvals to address the UX problem from point 1. Consequently, if the protocol were hacked, all tokens would compromise all users who had granted open-ended permission.

 Good to know: Ethereum Request for Comment (ERC) is the protocol to introduce new improvements to the network by developers. New ERCs are created by submitting the proposal through EIP (Ethereum Improvement Proposal). EIP is a design document consisting of the information related to a new feature or its process – to provide information to the Ethereum community.

Permit (EIP-2612) model as the first improvement

To improve the standard model, “EIP-2612 Permit Extension for EIP-20 Signed Approvals” was introduced. EIP-2612 is an extension of the ERC-20 token standards, which is expected to solve the previously mentioned problems (see Figure 2).

Figure 2: Approval process of EIP-2612

  1. Bob signs an off-chain approval message giving permission to a smart contract to issue an (EIP-2612) token.
  2. Bob sends the signed message as part of the interaction with the smart contract.
  3. The smart contract calls permit() on the token, which consumes the permit message and signature and gives the smart contract a permit.
  4. The smart contract now has permission, so it calls transferFrom() on the token and can take the tokens held by Bob.


This solves the original problems of the ERC20 approach:

  1. The user never has to submit a separate approve() transaction.
  2. Permit signatures are granted and consumed immediately.
  3. Amount limits and expiry times can be set.


The problem, however, is that this approach is out of the question in most cases, as EIP-2612 is an extension of the ERC20 standard, and this feature is only possible for new tokens. So, there are very few larger tokens that can benefit from this.

The solution is called Permit2

In the research for product improvements for Uniswap, the team at Uniswap Labs has identified a new market standard to solve the problems from both the standard model and EIP-2612: Permit2 (see Figure 3).

Figure 3: Approval process of Permit2

  1. Bob calls approve() on an ERC-20 to give the Permit2 smart contract unlimited approval.
  2. Bob signs an off-chain Permit2 message signaling that the protocol smart contract is allowed to transfer tokens.
  3. Bob calls an interaction function of the protocol smart contract and passes the signed permit2 message as a parameter.
  4. The protocol smart contract calls permitTransferFrom() on the permit2 smart contract, which in turn uses permission granted from point 1 to call transferFrom() on the ERC-20 smart contract and transfer the tokens held by Bob.

The permission is not granted to the protocol but to a Permit2 smart contract. This means that once the user has granted permission, this step can be skipped for all subsequent applications, provided the applications also use Permit2.
Instead of calling transferFrom() directly on the ERC-20 token to perform a transfer, a protocol permitTransferFrom() is called on the Permit2 smart contract. Permit2 sits between the protocol and the ERC-20 token, tracks and validates Permit2 messages, and ultimately uses the permit to perform the transferFrom() directly on the ERC-20. Redirection allows Permit2 to extend EIP-2612 benefits to all older existing ERC-20 tokens. As with EIP-2612, Permit2 messages also expire to limit the attack surface in case of potential hacks.
 
Conclusion
Permit2 helps improve the user experience when interacting with applications and reduces gas charges. Permit2 is a non-updatable open-source smart contract that can be used in Ethereum, Optimism, Arbitrum, Polygon, and Celo. 
Have gas fees prevented you from implementing use cases so far? Then please contact us. We will be happy to work with you to identify implementable use cases and advise you on the optimal use of technologies ranging from Layer2 solutions to gas cost optimization.

Download our Bitcoin Carbon
Emissions Study

In collaboration with the Frankfurt School Blockchain Center we applied the Bitcoin Climate Neutrality Investment Standard (BCNIS) to assess the proportional carbon footprint for Iconic Funds Physical Bitcoin ETP (ISIN: DE000A3GK2N1).

Enter your email to download the Study

Download Our Studies

The Carbon Emissions of Bitcoin From an Investor Perspective

Bitcoin Carbon Footprint Analysis - Iconic