Permit2 Overview
Learn how Uniswap Permit2 combines signature-based transfers and time-bound allowances for token spending.
Permit2 is a unification of 2 contracts, SignatureTransfer and AllowanceTransfer. The SignatureTransfer contract handles all signature-based transfers, meaning 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, giving 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.
Resources
An external explanation of Permit2 contract patterns and example usage.
Approving Permit2
Before integrating contracts can request users’ tokens through Permit2, users must approve the Permit2 contract through the specific token contract by calling something like:
USDC.approve(permit2Address, totalAmount);To maximize Permit2 utility, users can choose a max approval on the contract where:
totalAmount = type(uint256).max;FAQ
What is the difference between AllowanceTransfer and SignatureTransfer?
Permit2 exposes two independent modules:
- AllowanceTransfer stores a standing, time-bound allowance inside the Permit2 contract. You set an amount and an expiration for a spender, and that spender can call
transferFromrepeatedly until the allowance is exhausted or expires. This suits recurring flows such as repeated swaps or subscriptions. - SignatureTransfer authorizes a single, nonce-scoped transfer through one signature. The permission does not persist after the transaction, so it leaves no standing allowance. Use it when a contract needs tokens infrequently and you want to avoid lingering approvals.
Do I still need a per-token approval to use Permit2?
Yes, but only once per token. Before Permit2 can move a token on a user's behalf, the user makes a one-time standard ERC-20 approval of the Permit2 contract on that token, commonly for the maximum uint256Â amount:
USDC.approve(permit2Address, type(uint256).max);After that, Permit2 manages granular, per-spender, time-bound permissions through signatures or its own approve function, so integrators no longer trigger a separate onchain approval for every spender.
How is Permit2 different from an EIP-2612 permit?
EIP-2612 adds a permit function to a token itself, so it only works for tokens that implement it. Permit2 is a separate contract that works with any ERC-20, including tokens that will never add EIP-2612 support. After the one-time approval of the Permit2 contract, users get signature-based approvals for every such token, plus batching, expirations, and unordered nonces that a bare EIP-2612 permit does not provide.
How do Permit2 nonces and expiration work?
The two modules use different nonce schemes:
- AllowanceTransfer packs an incrementing nonce per owner, token, and spender alongside the amount and an expiration timestamp. Two permits with the same nonce do not cancel each other as long as the token or spender differ.
- SignatureTransfer uses unordered nonces tracked in a bitmap, so signatures can be spent in any order and each nonce is single-use.
Both carry a signature deadline, and AllowanceTransfer allowances also carry their own expiration after which the permission is invalid.
What is the Permit2 contract address, and has it been audited?
Permit2 is deployed at the same address on every chain Uniswap supports except zkSync:Â 0x000000000022D473030F116dDEE9F6B43aC78BA3.
On zkSync it is 0x0000000000225e31D15943971F47aD3022F714Fa.
The contracts are open source in the Uniswap/permit2 repository, which also publishes the third-party audit reports.
Where to Go Next
- Learn allowance flows in Allowance Transfer
- Learn signature flows in Signature Transfer