Summary

The Permit2 protocol introduced by Uniswap does indeed make the process of authorization more convenient for users, saving gas costs across repeated interactions and allowing centralized management of authorizations within the Permit2 contract. However, it also increases the risk of users falling victim to phishing attacks if they unknowingly sign malicious permits, since Permit2 can grant broad spending rights.

How let's analyze:

Before moving foward to the permit2 we have to understand point i) below:

i) Approval + transferFrom

In normal approval and transferFrom methods, users generally approve each specific token to each specific contract before they use any function which implements transferFrom inside it. So they will approve every time when they want to interact with a new protocol contract (or when the allowance is insufficient).

This means:

  • Approval is an on-chain transaction, so the user pays gas for it.
  • Approval is token-specific and spender-specific.
  • If the user interacts with multiple protocols, they usually need multiple approvals.
  • After approval, the protocol contract can call transferFrom without further user involvement until the allowance is exhausted or revoked.

ii) Permit2

Instead of approving multiple times to different protocol contracts, now the users can approve only one time to the Permit2 contract for a given token. After this, whenever they want to interact with different protocols that integrate Permit2, they don't need to approve again, because the approval is already given to Permit2.

However:

  • The user needs to generate a signature off-chain every time they want to use Permit2 successfully.
  • This signature authorizes Permit2 to allow a specific spender (protocol), amount, and expiry.
  • The signature verification happens on-chain, but the user does not pay gas for signing, only for the transaction that consumes the permit.

Important additions:

  • Permit2 supports expirations, nonces, and amount limits, which gives better control than infinite approvals.

Risks:

After introducing the implementation of Permit2, let's analyze the risks associated with it.

In traditional ERC20 token authorization, transactions need to be confirmed. However, with Permit2, once authorization is granted to the Permit2 contract, subsequent authorizations can be achieved through signatures. Users tend to be less cautious when it comes to signatures compared to confirming transactions, and they rarely verify the information contained in the signatures. This significantly increases the risk of phishing attacks. If the wallet being used does not have…

Furthermore, previously, tokens that did not implement Permit can now be authorized through Permit2 using signatures. While this provides convenience, it also increases the risk of users' assets being phished.

Traditional ERC20 token authorization does not have an expiration time. In the Permit2 protocol, however, there is a validity period for authorizations. The duration of authorization depends on the various DApps implementing the Permit2 standard.