Permit2 integration has two authorization layers

A Permit2 signature cannot move a token that has never authorized Permit2 to spend it. There are two permission layers, and a production client should track both.

The Permit2 overview describes a prerequisite ERC-20 approval to the Permit2 contract. Permit2 then manages downstream permissions using its own modules. A wallet showing a signed message does not prove that the prerequisite transaction has occurred.

Represent the layers explicitly

AllowanceTransfer manages stored permissions with expiration. SignatureTransfer uses a signature-based one-use transfer model. Do not mix their nonce or expiration rules.

Handle a fresh wallet

Check the token's allowance to Permit2 first. If insufficient, request the documented approval and wait for confirmation. Then refresh any quote or typed-data payload that may have expired. Validate the downstream spender and signed amount before asking for the permit signature.

Use the provider's supported deployment information for the selected chain. An address seen on another network is not enough evidence. The token approval also has a lifetime independent of the one-use signature; consuming that signature does not necessarily remove the token's standing allowance to Permit2.

A focused test starts with zero token allowance, signs valid typed data, and verifies that the application still blocks execution. A second fixture starts with ample token allowance but an expired downstream permission. These two failures should reach different recovery steps rather than a generic approve-again loop.