If you have swapped tokens on more than one app on Base, you may have noticed something odd. The first time you use a token on a new app, you get the usual approval transaction, the one that costs a small gas fee and lets the app move that token on your behalf. But on some apps, after that first approval, later swaps skip the gas fee entirely and ask you to sign a free message instead. Often the contract you approved was not the swap app itself, but something called Permit2. This article explains what Permit2 is, why it exists, and what it means for how you manage your approvals.
The problem Permit2 was built to solve
A standard ERC-20 token approval is simple in concept but repetitive in practice. Every app you use has to ask you for its own separate approval on every token you want to trade with it. Swap on one app, approve. Try a different app, approve again, even for the exact same token. Each of those approvals is an onchain transaction, which means gas, which means a delay while you wait for confirmation.
Some newer tokens support a feature called EIP-2612 permit, which lets you sign a free, gasless message instead of sending an approval transaction. It works well, but it only works if the token itself was built with that feature included, and most existing tokens were not. There was no simple way to get gasless, signature-based approvals for a token that never had that feature.
Permit2, built by Uniswap Labs and released as open source, is a workaround that does not depend on the token cooperating at all. Instead of every app needing its own approval, and instead of needing the token to support EIP-2612, you approve one shared, extensively audited contract called Permit2 for a token, one time. After that, any app that integrates with Permit2 can ask you for a free signature to spend that token, instead of a new gas-costing approval every time.
What this looks like in your wallet
The flow usually happens in two parts the first time you use a token with a Permit2-enabled app.
First, a regular approval transaction, just like any other, except the address you are approving is Permit2 rather than the app itself. This step costs gas and appears in your wallet exactly like approving any other contract.
Second, and on every swap after that, a signature request instead of a transaction. Your wallet will show a message to sign rather than a transaction to confirm, and it will not cost gas. This is Permit2 checking that you authorized this specific spend, for this specific app, usually with an expiration time built in.
Because Permit2 is deployed at the same contract address on Ethereum, Base, and most other EVM chains, you may see the exact same address show up as a spender in your approvals no matter which network you are looking at. That is expected. It is not a coincidence and not a sign that something followed you across chains. The developers used a deployment method that produces an identical address everywhere on purpose, so that apps and wallets can recognize it consistently.
Why the expiration matters
A regular ERC-20 approval, unless you specify otherwise, is often set to an enormous number that in practice never expires. It sits there until you manually revoke it, sometimes for years, on tokens you tried once and forgot about.
Permit2 signatures are built around a different default. The signature you sign typically includes an expiration timestamp, often measured in hours or days rather than being open ended. Once it expires, that specific spending permission stops working on its own, without you needing to do anything. This does not make Permit2 risk free, since a spender you granted signature-based access to can still act within the window and the amount you signed for, but it does mean stale, forgotten permissions are less likely to sit around indefinitely the way old unlimited approvals do.
What to check when reviewing your approvals
Because Permit2 splits access into two layers, a normal check of your token approvals only tells you half the story.
The first layer is the ordinary ERC-20 approval that lets Permit2 itself move a given token. Revoking this on a block explorer or approval management tool removes Permit2's own access to that token entirely, which also cuts off every app that was relying on it.
The second layer is the set of individual permissions you signed for specific apps through Permit2. These do not always show up in the same place as a normal token approval, since no separate onchain transaction was created for each one. Approval checking tools that specifically support Permit2 can list these out and let you revoke an individual app's access without touching your broader Permit2 approval for the token. If you use a revoke or approval management tool, check whether it has a distinct Permit2 section, since a tool that only reads standard ERC-20 approval events will miss these entirely.
As with any approval, the signature requests themselves are worth reading rather than dismissing on habit. Your wallet should show which token, how much, which app, and for how long, before you sign. If any of those details do not match what you expect for the action you are taking, it is worth declining and checking the app you are using before you try again.
The bottom line
Permit2 is not a new risk category so much as a more efficient version of an approval you would have made anyway. It removes repeated gas costs, and its expiring signatures are arguably a safer default than the unlimited approvals that became common in earlier years of DeFi. The part worth remembering is that it adds a second place to check when you audit your wallet. A clean list of token approvals does not automatically mean a clean list of Permit2 signatures, so if you periodically review and revoke old access, it is worth looking in both places.