Permit2 has two permission layers: what should you review?

Permit2 involves two permission layers: the token must let Permit2 move it, and Permit2 must have the required authorization for the application’s spender. Reviewing only the first approval misses the second decision.

Layer one: token to Permit2

You grant the Permit2 contract an ERC-20 allowance for a specific token. The amount can be limited or effectively unlimited. That permission is recorded by the token contract and can remain after an individual swap.

Layer two: application authority

Uniswap’s Permit2 overview distinguishes AllowanceTransfer, which manages amount-and-time-bounded spender allowances, from SignatureTransfer, which authorizes a nonce-scoped transfer using a signature.

The application’s spender and signed terms matter even when the Permit2 contract itself is genuine. A malicious request can misuse a familiar permission system by asking you to authorize the wrong spender or amount.

Review the two layers independently

1. Verify the Permit2 deployment for the chain through official protocol sources.
2. Check the token-level cap.
3. Read the application authorization’s spender, token, amount and applicable validity fields.
4. Determine whether it is a standing allowance or a one-time transfer authorization.

A wallet may request the token approval only once, then show signatures for later uses. That change in presentation is not a reason to stop reading requests.

Revoking token access to Permit2 can stop transfers through that allowance, but do not assume it invalidates every unused signature permanently. Reauthorizing the token later can matter if other authorization conditions are still valid. For suspicious signatures, inspect the scheme-specific invalidation options.