Which permission expires in a Permit2 request?

In Permit2’s AllowanceTransfer flow, the signature deadline and allowance expiration are different fields. One limits when the authorization can be submitted; the other limits how long the resulting spender allowance remains usable.

The official Permit2 structure places sigDeadline on the permit and expiration inside its token permission details. Review both when the wallet displays them.

Consider the sequence

Hypothetical example: a permit must be submitted within ten minutes, but its spender allowance expires tomorrow. If submitted promptly, the resulting permission can remain usable after the ten-minute signing deadline. The short submission window did not make the allowance last only ten minutes.

Conversely, a signature with a long submission deadline is not useful for transfers after its resulting allowance expiration if that expiration is already past.

Identify which layer still exists

The token’s ERC-20 allowance to Permit2 may have no expiry merely because the Permit2 spender allowance expired. It is stored elsewhere. SignatureTransfer uses a different one-time authorization flow and should not be read as if it contains the same standing allowance fields.

When a swap reports expiry, preserve the exact error and request type. Refreshing a swap quote may not renew the permission that failed.

Do not accept distant future timestamps solely to avoid interruptions. Convert unfamiliar timestamps through a trusted display and decide whether the requested duration fits your intended activity. Amount and duration together determine the permission you are granting.