Skip to content
Financial Context Wiki

Permit2 signature risk

Permit2 separates reusable allowances from one-time signature transfers; safe signing requires exact deployment, domain, spender, recipient, amount, nonce, deadline, witness and execution-calldata verification.

Updated

For educational purposes only; not investment advice. Investing may result in loss.

Direct answer

Permit2 combines two distinct authorization systems. AllowanceTransfer stores a reusable owner-token-spender allowance with amount, expiration and ordered nonce. SignatureTransfer consumes a one-time signed maximum with an unordered bitmap nonce and creates no persistent downstream allowance. Both still depend on the ERC-20 token’s owner-to-Permit2 allowance.

A gasless signature can move assets when a spender or relayer pays for execution. Verify the exact chain, deployed Permit2 code, EIP-712 domain, module, token, spender, signed maximum, recipient calldata, nonce and clocks. The legitimate Permit2 contract does not make a malicious spender, recipient, router or witness safe.

Permit2 signature risk
0 / 5
0 items reviewed; 5 items still unresolved

Completing this review does not prove an asset, transaction, or system is safe.

How it works

  1. Pin chainId, network, Permit2 verifyingContract, deployed runtime code, token address and decimals, owner wallet type and intended application. Use an official deployment record; a familiar address or label is insufficient.
  2. Read the upstream ERC-20 owner-to-Permit2 allowance and balance. Identify finite versus unlimited approval and token-specific transfer behavior; this ledger survives expiration of a Permit2 signature or stored downstream allowance.
  3. Identify the exact path and signed primary type: AllowanceTransfer PermitSingle or PermitBatch, or SignatureTransfer PermitTransferFrom or its batch and witness variants. Do not treat transferFrom as the signed type.
  4. Decode the EIP-712 domain and every message entry. For AllowanceTransfer inspect token, uint160 amount, expiration, ordered nonce, spender and sigDeadline. For SignatureTransfer inspect permitted token and amount, unordered nonce, deadline and the spender bound from the caller context.
  5. Decode execution calldata separately. In basic SignatureTransfer, SignatureTransferDetails.to and requestedAmount are execution parameters, not fields in the basic signed permit; the requested amount need only stay within the signed maximum. Verify every batch index and any exact witness hash and type string.
  6. Query current ordered allowance nonce or unordered bitmap word and bit, then simulate the exact caller, calldata, chain and state. Reconcile recipient, router actions, token quirks, balance and both allowance ledgers; simulation can change with state, ordering or reorganization.
  7. Minimize amounts and lifetimes. If suspicious, preserve the typed data and submit the correct upstream approval revoke, downstream allowance revoke or nonce invalidation through a trusted path, treating it as a mempool race; wait for confirmation and reconcile transfers, balances, allowances and bitmap bits.

AllowanceTransfer’s sigDeadline limits when the signed permit may establish or update stored authority; expiration limits how long that stored authority can be spent. SignatureTransfer’s deadline limits its one-time execution. EIP-712 supplies typed hashing and domain separation, not replay protection or intent safety; Permit2’s nonce and deadline rules provide those boundaries.

For a contract wallet, ERC-1271 validity depends on the wallet’s current isValidSignature policy, modules, thresholds and code. Wallet labels, truncated hardware-wallet screens and successful simulations are evidence inputs, not guarantees. Disconnecting a frontend revokes no approval or signature.

Example

  • Two allowance ledgers. The finite token allowance to Permit2 starts at 1,000 USDC; a PermitSingle stores 600 USDC for spender S. After S transfers 225 USDC, the stored amount is 600 - 225 = 375 USDC, while a standard finite upstream token allowance becomes 1,000 - 225 = 775 USDC. Expiring or revoking 375 does not itself clear 775; nonstandard tokens can differ.
  • One-time recipient and amount. A SignatureTransfer signs a maximum of 250 USDC; calldata requests 180 USDC to a merchant. With balance and upstream allowance sufficient, the execution can transfer 180. The nonce is consumed, so the unused 70 USDC is not reusable. If calldata names an attacker as recipient, the basic permit alone does not prevent that redirection by the bound spender.
  • Unordered nonce bitmap. For nonce 513, wordPos = 513 >> 8 = 2, bitPos = 513 & 255 = 1, and mask = 1 << 1 = 2. Execution sets bit 1 of word 2; replaying 513 fails, while nonce 512 at bit 0 remains independent.
  • Revocation race. A stored allowance is 400 USDC. The owner broadcasts revoke-to-zero, but a 300 USDC transfer executes first, leaving 100 USDC; the later revoke sets the remainder to 0. Final allowance zero does not undo the realized 300 USDC loss, so transaction ordering and balances must be reconciled.

Risks

  • Wrong chain ID, deployment or runtime code
  • Counterfeit or unexpected verifying contract
  • AllowanceTransfer and SignatureTransfer confusion
  • Malicious or mistaken spender and caller
  • Recipient chosen through execution calldata
  • Requested amount near the signed maximum
  • Wrong token address, symbol, decimals or raw units
  • Persistent or unlimited upstream ERC-20 approval
  • Excessive downstream amount or expiration
  • Deadline, signature deadline and expiration confusion
  • Stale or raced ordered nonce
  • Reused bitmap bit or overbroad invalidation mask
  • Witness hash or exact type-string mismatch
  • Hidden, duplicated or misindexed batch entry
  • Frontend display or calldata differing from intent
  • Revocation losing a mempool or MEV race
  • ERC-1271 module, signer, threshold or upgrade change
  • Fee-on-transfer, rebasing, paused, blocked or callback token
  • Simulation state drift, failure or reorganization
  • Hardware-wallet confirmation or disconnect mistaken for safety

Common misconceptions

  • A signature with no gas prompt cannot move tokens. Another party can pay execution gas.
  • The official Permit2 address proves the spender and recipient are safe. Permit2 can faithfully execute malicious authority.
  • SignatureTransfer and AllowanceTransfer create the same persistent permission. One is single-use; the other stores reusable allowance.
  • Disconnecting or revoking one layer cancels every path and pending signature. Upstream, downstream and nonce state are separate, and races remain.
  • EIP-712, a hardware wallet or successful simulation proves intent and finality. Each improves visibility or testing but cannot replace field, calldata and confirmed-state verification.

Sources

Navigation

Search the wiki...