Permit2 introduces a low-overhead, next generation token approval/meta-tx system to make token approvals easier, more secure, and more consistent across applications. It allows token approvals to be shared and managed across different smart contracts creating a more unified, cost-efficient, and safer UX. As more projects integrate with Uniswap Permit2, we can standardize token approvals across all applications. In turn, it will improve the user experience by reducing transaction costs while improving smart contract security.

Permit2 is a union of 2 contracts, SignatureTransfer and AllowanceTransfer.

The SignatureTransfer contract handles all signature-based transfers, which means that an allowance on the token is bypassed and permissions to the spender only last for the duration of the transaction that the one-time signature is spent.

The AllowanceTransfer contract handles setting allowances on tokens, which means it give permissions to spenders on a specified amount for a specified duration of time. Any transfers that then happen through the AllowanceTransfer contract will only succeed if the proper permissions have been set.

• Need
• Features
• Working Model

Need

Originally defined in ERC20, the canonical token approve method suffered from a couple of weaknesses:

1. Users had to send an approval transaction for each new application they wanted to use. This led to a confusing UX where users might be asked to send multiple transactions before using an application, wasting gas and time.

2. For convenience's sake, applications asked users to approve the maximum allowance, giving applications access to a wallet’s entire token balance for an indefinite amount of time. Though Uniswap has never suffered from an exploit, infinite approvals can be hacked to steal user tokens.

Users could interact with application contracts without requiring prior approval by appending a signed permit message to their transaction.

Features

• Allows applications to have a single transaction flow by sending a permit signature along with the transaction data.
• Set approvals on multiple tokens or execute multiple transfers with one transaction.
• Remove allowances on any number of tokens and spenders in one transaction.
• Approvals can be time-bound, removing security concerns around hanging approvals on a wallet. Revoking approvals do not necessarily have to be a new transaction.
• Users can bypass setting allowances entirely by releasing tokens to a permissioned spender through a one-time signature.

Working Model

• Make a call for approve() on an ERC20 to grant an infinite permission to the canonical Permit2 contract.
• Then sign an off-chain "permit2" message that signals that the protocol contract is allowed to transfer tokens on her behalf.
• Now call an interaction function on the protocol contract, passing in the signed permit2 message as a parameter.
• The protocol contract calls permitTransferFrom() on the Permit2 contract, which in turn uses its allowance (granted in 1.) to call transferFrom() on the ERC20 contract, moving the tokens held by you.

It might seem like a regression to require the user to grant an explicit allowance first. But rather than granting it to the protocol directly, the user will instead grant it to the canonical Permit2 contract. This means that if the user has already done this before, say to interact with another protocol that integrated Permit2, every other protocol can skip that step.

Instead of directly calling transferFrom() on the ERC20 token to perform a transfer, a protocol will call permitTransferFrom() on the canonical Permit2 contract. Permit2 sits between the protocol and the ERC20 token, tracking and validating permit2 messages, then ultimately using its allowance to perform the transferFrom() call directly on the ERC20. This indirection is what allows Permit2 to extend EIP-2612 like benefits to every existing ERC20 token.

References

• Uniswap Permit2 docs
• Github link for Permit2
• Introducing Permit2 & Universal Router

Videos

• TWAMM: Time-Weighted Average Market Maker
• MobyMask: An Initiative to Eliminate Phishers
• Fractional NFTs: EIP-4675 using EIP-1155 & EIP-1633

More Articles

• Transient Storage for Beginners: EIP-1153 Explained
• How Layer 3 in Future will look like?
• An Overview of Beacon Chain API