Guide · Wallet risk · · by Stefan Tsezarov
What you actually sign when you approve a token
Permission to spend can matter as much as a payment.
You open a swap app, choose a token and connect your wallet. Before the swap, your wallet asks you to approve spending.
No tokens appear to leave. It looks like a setup step.
It is a setup step—but it gives another address permission to move your tokens. Depending on what you approve, that permission can remain long after you close the site.
Approvals are a normal part of using crypto apps. The risk is granting more access than you intended, or granting it to the wrong address.
This guide explains what that access means, what to check before signing, and what to do if you have already approved something suspicious.
It covers Ethereum and compatible networks. Other blockchains use different permission systems.
01An approval gives permission to spend
Your wallet holds the keys you use to authorise actions. Your token balance is recorded in the token's smart contract.
For a swap or lending app to move those tokens, it usually needs your permission first. You grant that permission to an address called the spender. The permitted amount is called an allowance.
Suppose you want to swap 50 USDC.
- Approving 50 USDC lets the spender take up to that amount.
- Approving unlimited USDC lets it take your available USDC balance, including USDC you receive later, while that permission remains active.
That approval concerns the specified token on that network. It does not, by itself, give access to everything in your wallet.
A standard token approval generally has no expiry. It remains until you change or revoke it, or its allowance is spent. Closing the website or disconnecting your wallet does not remove it. Revoke.cash explains the difference between disconnecting and revoking.
02Different requests give different permissions
Wallet wording varies. These are the main requests to recognise:
| Request | What it can authorise |
|---|---|
| Approve or spending cap | A spender may move up to a specified amount of one token. |
| Set approval for all | An operator may transfer all your NFTs within the specified collection or contract, including ones you acquire later while approval remains active. |
| Permit | A signature that can be submitted later to create a token allowance. |
| Permit2 | A signature that can authorise a time-limited allowance or a one-time transfer, depending on the request. |
“Approval for all” is broader than approving one NFT, but it is still scoped to the relevant NFT contract. ERC-721 defines these permissions.
A signature can authorise spending without a gas fee
A standard approval normally requires an on-chain transaction. A permit starts with an off-chain signature: signing it does not itself create a blockchain transaction or charge gas.
Someone else can submit that signature later and pay the transaction fee.
For a standard ERC-2612 permit, the deadline is the last time the signature can be submitted. It is not an expiry date for the allowance created when it is submitted. ERC-2612 specifies how this works.
Permit2 works differently. It requires an existing token approval to the Permit2 contract, then supports either time-limited spending permissions or one-time signed transfers. Uniswap's Permit2 documentation explains both routes.
You do not need to memorise the standards. Remember this:
No gas fee does not mean no financial consequence.
Not every signature grants spending access. A login message can serve a different purpose. Read what the request authorises instead of judging it by the “Sign” button.
03How scammers use these permissions
A fake site does not always ask you to send crypto. It may ask you to “verify your wallet”, “claim a reward” or “continue”.
Behind that button is a request giving an attacker spending access.
The site may then show an error. You close it, assuming nothing happened. But the attacker may already have a usable approval or signature.
The transfer can follow immediately or later. You receive no second request to approve it.
Your recovery phrase does not have to be stolen for this to happen. Even a hardware wallet cannot protect you from a harmful permission you authorise yourself. Revoke.cash describes this limitation.
04Five checks before you approve or sign
1. Match the request to your intended action
A swap can reasonably require access to the token you are selling.
A simple login or ordinary airdrop claim should not need unrestricted access to your existing tokens. If the site says “Verify” and your wallet says “Approve spending”, stop and establish why.
2. Check who receives the permission
The spender is the address receiving access. A familiar logo or contract name is not proof that it belongs to the app.
Use the app's official documentation to check the expected contract and network. Some apps use several contracts, so guessing from an address label is unreliable.
3. Limit the amount
Where your wallet allows it, approve only what the action needs.
For a 50 USDC swap, an unlimited allowance exposes more USDC than necessary. A smaller cap limits that exposure; it does not make a malicious spender trustworthy.
4. Read signatures with the same care as transactions
Look for the token, spender, amount, network and any deadline or expiry. Field names vary.
If the wallet cannot explain the request clearly enough for you to understand it, reject it and investigate through the app's official documentation.
5. Keep savings separate from unfamiliar apps
Use a separate wallet with a small balance for trying new services. Avoid connecting the wallet holding your long-term savings.
This limits what a harmful approval can reach.
05If you already approved something
If you suspect an active theft, act promptly. Routine approval cleanup and an exposed signature are different situations.
For existing approvals:
- Open Revoke.cash or Etherscan's Token Approval Checker directly. Avoid links sent by unsolicited “support” accounts.
- Check each network you use. You can inspect a public address without signing a transaction.
- Revoke permissions you no longer need, prioritising suspicious spenders and unnecessary unlimited allowances.
- Confirm that each revocation transaction succeeds. Network fees apply.
Revoking removes spending permission. It does not recover assets already transferred. Disconnecting the site is not a substitute. Revoke.cash's FAQ covers these limits.
If you signed a suspicious permit
An unused signature may not appear in an approval checker.
Revoking a visible allowance may not invalidate that signature. For example, an unexpired ERC-2612 permit can still create an allowance if its nonce—the counter preventing reuse—remains valid. See the ERC-2612 specification.
Consider moving affected assets to a separate wallet you control. Do not return them to the exposed address until the signature has been invalidated or can no longer be used. Moving assets and revoking permissions can race with an attacker; neither guarantees you will act first.
If your recovery phrase or private key was exposed, create a wallet with a new recovery phrase. Another account derived from the exposed phrase is not a secure replacement.
Be wary of unsolicited recovery offers, especially demands for an upfront payment or your recovery phrase.
06What SaveSaveSaveSave can help you check
The message scanner can flag wording that pushes you towards signing messages, approving unlimited spending or granting broad token permissions.
That is a warning about the text you paste. It is not an inspection of the request inside your wallet.
The scanner does not establish what a signature authorises, list your existing allowances or guarantee that a spender is trustworthy. An address check with no reported warnings is not a reason to approve it.
Use an approval checker to review existing permissions. Before granting a new one, establish three things:
Who can spend, which assets they can reach, and how much you are allowing.
The spender address and the site in the illustration are fictional. This guide is general information, not financial advice.