Permit2

Permit2 Explained in Detail

Permit2 is Uniswap's approval and signature transfer system. It lets users approve Permit2 once, then authorize token spends through structured signatures or managed allowances.

Auditors usually review the integration, not the Permit2 contract itself.

Smart contract example

A router may use Permit2 to pull tokens before executing a swap. The integration must bind the signature to the exact token, amount, owner, spender, recipient, deadline, and intended action.

If the protocol accepts a broad Permit2 approval but does not bind it to the expected swap, a malicious caller may redirect the spend.

Permit2 in Auditing

Permit2 concentrates approval power. A small integration mistake can make a user signature reusable or redirect tokens, so reviewers should treat it as both a signature and access control risk.

The key question is: does the signed intent match the action the contract actually performs?

Red flags in code

• Permit2 spender is broader than necessary.

• Recipient is caller-controlled or not included in the signed intent.

• Token, amount, owner, or deadline is not checked against expected values.

• witness data is missing when the action needs extra binding.

• Nonce handling assumptions are wrong.

• Contract supports arbitrary Permit2 calls without a strict execution path.

• UI or backend asks users for broad approvals when narrow signatures would work.

How to test or review it

• Trace the full flow from user signature to token transfer.

• Check who is approved as spender and who receives tokens.

• Test replay, expired signatures, wrong token, wrong amount, wrong recipient, wrong caller, and reused nonce.

• If permitWitnessTransferFrom is used, verify the witness includes the exact app-level action.

• Review EIP-712 and signature replay assumptions before trusting the integration.

• Use the smart contract audit checklist to track spender, recipient, nonce, and deadline checks during review.