Signed Permits vs Approvals: Who Moves the Tokens?
A signed permit authorizes a token transfer by granting a spender allowance; the token contract—not the signature—moves the tokens when that spender calls transferFrom. For a dapp, that means choosing between a separate on-chain approval and a signed authorization submitted with the action. The permit route is usually the more useful choice when the flow can support it.
What the signature actually authorizes
With EIP-2612, the token owner signs typed data stating the spender, allowance amount, nonce, and expiry. The spender then submits that signature to the token’s permit function. If the signature matches the owner and contract, the token records the allowance; a router or spender must still call transferFrom to pull the funds.
That separation is the detail many explanations skip. A stolen or misdirected permit is not a completed transfer, but it can become one if the named spender submits it before expiry. The signature also binds to the token contract and chain domain, so a valid authorization for one contract or network should not be reusable on another.
The numbers decide the risk
The allowance amount is the maximum the spender may pull, not necessarily the amount it will pull. The nonce is a replay counter: once consumed, that exact authorization cannot be submitted again. The deadline limits how long it remains usable. The chain identifier and verifying contract bind the typed message to a particular deployment. Change any of these values and signature verification should fail.
MetaMask Wallet can display the typed-data request, but the wallet display does not make an unfamiliar spender safe. On the Ethereum Network, execution still costs gas, although a relayer can pay it for the user. That is the practical feature: a user can sign once while a router bundles authorization and action into one submitted transaction.
Where the pattern earns its place
In a swap, the router needs authority to pull the input token before it can deliver the output. A permit can remove the separate approval transaction, reducing friction for a first-time user and making sponsored or batched flows practical. A route through Frax Swap is still governed by those same spender, amount, nonce, and deadline fields.
Uniswap Protocol’s Permit2 shows the broader trade-off: users can establish an approval to a shared contract and then sign bounded transfer permissions, but that shared contract becomes part of the trust surface. I would prefer permits when the spender is explicit, the amount is narrow, and the expiry is short. I would change that view only when the token’s permit implementation, domain binding, and revocation behavior proved unreliable; then a conventional approval is easier to inspect and control.