Our guide on token approvals covers the usual way you let an app spend your tokens: you send an on chain transaction calling approve, and you pay a small gas fee for it. On Base that fee is normally tiny, but it is still a transaction, and it still needs ETH in your wallet to cover it. A growing number of apps skip that step entirely and ask for a signature instead. No transaction, no gas, and sometimes no ETH in your wallet at all. This article explains how that works, why it was built, and what it means for how carefully you should read the popup.
The standard behind it: EIP-2612
The mechanism most apps use for this is called EIP-2612, usually just referred to as "permit." It is a small addition some ERC-20 tokens include on top of the standard token contract. Our ERC-20 guide covers the base standard every token follows. Permit adds one more function, called permit, that lets a token holder authorize a spender by signing a message instead of sending a transaction.
Native USDC on Base, at contract address 0x833589fCD6eDb6E08f4c7C32D4f71b54bdA02913, is one of the more widely used tokens that supports this. Not every token does. Support for permit depends on how the token's contract was written, so an app that relies on it usually checks first and falls back to a normal on chain approval if the token does not support it.
What actually happens when you sign
When an app asks for a permit signature, your wallet shows a structured message rather than a wall of transaction data. That structure comes from EIP-712, the same signing standard covered in our signature requests guide. A permit message typically includes:
- The token contract
- The spender being approved, usually the app's own contract
- The amount being authorized
- A deadline after which the signature stops being valid
- A nonce, so the same signature cannot be replayed twice
You sign this message with your wallet's private key, but signing it does not touch the blockchain and costs nothing. The signature itself is just data. Someone still has to submit it in a transaction that calls the token's permit function, and that is usually done by the app's contract, bundled together with whatever action you actually wanted, like a swap or a deposit. One transaction ends up doing the work that used to take two: approve, then act.
Why this exists
Two problems drove permit's adoption. The first is cost. A separate approval transaction is extra gas on top of the transaction you actually care about. On networks where gas is expensive, cutting that in half matters. Base fees are already low, as our gas fees guide explains, but removing a step is still removing a step.
The second problem is bigger: needing ETH just to approve a token you want to spend. A new user who only holds USDC, for example, cannot pay Base's gas fee without first acquiring ETH, which is a confusing extra hurdle for someone new to self custody. A permit signature sidesteps this because signing costs nothing. The app's contract, or a relayer working with it, covers the actual gas when it submits the permit and the action together. This is one of the ideas behind gasless transactions more broadly, which our paymasters guide covers in more depth.
It still authorizes spending, so treat it like an approval
Here is the part worth slowing down for. A permit signature is not a lightweight, low stakes action just because it skips gas. Functionally, it authorizes a contract to move a specific amount of your tokens, exactly like an on chain approve call does. The only difference is who submits it to the blockchain and when. A malicious site that gets you to sign a permit for an unlimited amount, or for a spender it does not clearly disclose, can drain that token from your wallet the moment it submits the signature, with no further action from you required.
This matters because permit signatures are easy to rush past. They look like just another wallet popup, often without the word "approve" anywhere on the screen, and unlike a transaction there is no gas fee prompting you to pause and check the details. Before signing, look at what your wallet displays: which token, which spender, and how much. If the amount shown is unlimited, or far larger than what the action actually requires, treat it the same way you would treat an unlimited approve request. Our guide on checking and revoking approvals applies here too. A permit that has been signed and submitted shows up as a normal allowance once it lands on chain, and it can be revoked the same way as any other approval.
Permits with a deadline that never gets used
One more detail worth knowing: signing a permit message does not automatically use it. You could sign one and then close the tab before the app submits it. The signature sits unused until its deadline passes, at which point it simply stops being valid. This is one reason a deadline exists in the message at all. It caps how long a signature you granted stays usable, so a signature you signed and forgot about does not remain valid indefinitely. It does not, however, protect you if the deadline was set far in the future or if the transaction is submitted right away, so the deadline is a safety net for stale signatures, not a substitute for checking the amount and spender before you sign.
What to actually check
The mental model is simple even though the mechanism is new: a permit signature and an on chain approval do the same job. One costs gas and shows up as a transaction right away. The other costs nothing to sign and only becomes a real allowance once someone submits it. Neither should be approved on autopilot. Before signing, confirm the token is the one you expect, the spender is the app you meant to use, the amount matches what the action requires, and the deadline is reasonably short. If any of those look wrong, reject the request and check the app through a source you trust before trying again.