A gas-free signature can authorize token spending: understanding Permit2

Read the request even when there is no gas fee

Your wallet asks for a signature, with no gas payment and no immediate deduction. Read it anyway: ERC-2612 allows a signed message to set a token allowance, and another address can submit a valid permit onchain. Signing costs no gas, but subsequent onchain execution still has a network cost. Someone else may then use the permission you signed.^[1]

Permit2 has two permission layers

ERC-2612's permit is implemented by the token contract itself. Permit2 is a separate contract. Before using it, you grant Permit2 an allowance through the token contract. You then use Permit2 to specify which spender—the address authorized to spend—can use which tokens and how much. Identify both layers when checking permissions.^[1][2]

A single-use signature or a reusable allowance

Permit2's AllowanceTransfer stores a spender's allowance and expiry. The spender can make repeated transfers while conditions such as sufficient remaining allowance and a valid expiry are met. SignatureTransfer instead authorizes a transfer with a single-use signature and uses a nonce to prevent reuse. Think of the nonce as an identifier that stops the same authorization being spent again.^[5][6]

Single-use does not mean small. That one authorization can still cover more tokens than you intend to hand over. And consuming a SignatureTransfer signature ends that signature's spending permission; it does not automatically remove the token contract's underlying approval of Permit2.^[2][6]

The signature can expire before the allowance does

Read two AllowanceTransfer fields separately. sigDeadline limits when the signature can be accepted; expiration limits how long the resulting spender allowance remains valid. The first can be short while the second is long. One approaching date does not establish when every permission ends.^[3][5]

ERC-2612's deadline also limits acceptance of the permit. The standard does not automatically expire an established allowance when that deadline passes. Tokens can implement different permit variants, so the actual contract still matters.^[1]

Match the permission to your intended action

A practical check starts with the network, token contract, spender, amount and each deadline. Do they match what you intended to do? This checklist is our editorial guidance based on the mechanisms above. If the interface shows data you cannot interpret, reject the request, open the official documentation yourself and clarify it before proceeding.^[1][3][4]

If you have signed a suspicious message, disconnecting the website does not revoke onchain permissions. Identify what needs attention: the token's approval of Permit2, a spender allowance within Permit2, or an unused signature. Setting an AllowanceTransfer allowance to zero does not automatically invalidate every unused signature. That module has a separate nonce-invalidation function, and SignatureTransfer has its own mechanism. The appropriate action depends on the module and wallet support; a button labeled Revoke does not establish that every risk has been resolved. Onchain revocation generally still requires a network fee.^[5][6][7]

Scope and production disclosure

This guide draws on official documentation and contract source code. It does not involve live wallet transactions or a contract security audit, and it does not report a new Permit2 vulnerability. AI assisted with the article and conceptual illustration, which were checked and reviewed through BlockBlah's editorial process.