Connecting a wallet to a Web3 application does not usually give that application unrestricted access to every asset. The more important action often comes one step later, when the user approves a token for a smart contract to spend.
That approval allows a decentralized exchange to swap tokens, a lending protocol to deposit collateral, or a marketplace to transfer an asset. It is a normal part of using many dApps. It can also remain active long after the user closes the website.
The result is an awkward security gap: a wallet may look disconnected while an old contract still has permission to move a particular token. If the contract, its upgrade mechanism, or the user’s signed authorization is malicious, that allowance can put funds at risk.
This guide explains what token approvals are, how they differ from wallet connections and signatures, how to inspect them, and when to revoke them.
What is a token approval?
On EVM networks such as Ethereum, many fungible tokens follow the ERC-20 standard. The token contract keeps track of balances, but it can also keep an allowance: permission for another address or smart contract, called the spender, to transfer up to a specified amount on behalf of the token owner.
Two ideas matter:
- Approval sets or changes the amount a spender may use.
- Allowance is the remaining amount that spender is authorized to transfer.
Suppose a wallet holds 1,000 units of a token. A decentralized exchange router cannot simply take 100 tokens for a swap. The user first authorizes that router to spend the token. The router can then call the token contract to transfer the approved amount during the swap.
The approval belongs to a specific combination:
- wallet address;
- token contract;
- spender contract;
- blockchain network.
Approving one token does not automatically approve every token in the wallet. An approval on Ethereum also does not create the same permission on another network. This specificity is useful, but it makes permissions easy to forget when users interact with many tokens, dApps, and networks.
For background on the code performing these actions, see the explanation of how smart contracts work.
Why dApps request approvals
Approvals exist because smart contracts need a controlled way to perform an action the user requested without receiving the user’s private key.
A DEX may need permission to move the input token into a swap. A lending protocol may need to transfer tokens into a pool. A subscription or automation contract may need a defined spending allowance. The contract receives permission over the token, not ownership of the wallet’s seed phrase.
That distinction is important. A standard token approval does not reveal the seed phrase or private key. It does, however, authorize the spender to transfer a particular token under the rules of the allowance.
The permission may be used immediately and only once, or it may remain available for future interactions. The risk depends on:
- which spender was approved;
- how much was approved;
- whether the contract can be upgraded;
- whether the dApp or interface is authentic;
- whether the permission is still needed;
- whether a signature created a separate authorization.
This is why wallet security is broader than protecting recovery words. The guide to seed phrases and private keys explains access to the wallet itself; token approvals govern what authorized contracts may do after the wallet is already in use.
Limited and unlimited token approvals
A limited approval authorizes a defined amount. If a swap needs 100 tokens, the user may approve exactly 100. Once the contract spends them, little or no allowance remains.
An unlimited approval gives the spender a very large allowance, often the maximum value the token contract can represent. Interfaces use this approach to avoid asking for a new approval before every future transaction. It saves time and gas, particularly for frequently used protocols.
Unlimited does not mean that the contract immediately receives the entire wallet. It means the contract can transfer the approved token up to the available balance and allowance when the relevant function is used.
The trade-off is straightforward:
- exact or limited approvals reduce long-term exposure but may require more approval transactions;
- unlimited approvals improve convenience but leave a larger standing permission;
- session or time-limited permissions, where supported, can reduce exposure without requiring an approval for every action.
There is no rule that every unlimited approval is malicious. Many established protocols use them. The problem is that the potential impact becomes larger if the spender is compromised, misconfigured, upgraded maliciously, or impersonated by a phishing site.
Disconnecting a dApp is not the same as revoking approval
Wallet interfaces often show a list of connected sites. Disconnecting a site removes its ability to request information or new actions through that active wallet connection. It is useful, but it does not normally change allowances stored by token contracts on the blockchain.
Think of the difference this way:
- a wallet connection is the open communication channel between the browser or app and the wallet;
- a token approval is an on-chain permission recorded by the token contract;
- a signature can authorize a message or action without necessarily creating an immediate on-chain transaction.
Closing the channel does not erase a permission that was already recorded. Deleting browser history, removing a site from MetaMask, switching devices, or uninstalling a wallet extension also does not automatically revoke on-chain allowances.
To remove an ERC-20 allowance, the wallet usually needs to submit a new blockchain transaction that sets the spender’s allowance to zero or another lower amount. That transaction requires a network fee.
How to check token approvals
Users can review approvals through a wallet’s built-in security interface, a blockchain explorer’s approval checker, or a reputable permission-management service.
Before connecting the wallet, verify the domain independently. Approval dashboards are themselves common phishing targets because visitors arrive with a security concern and expect to sign or submit transactions.
For each permission, check:
- The blockchain network.
- The wallet address being reviewed.
- The token contract.
- The approved spender.
- The remaining allowance.
- The estimated value currently exposed.
- The date or transaction associated with the approval, if available.
The spender name shown by an interface is a convenience label, not final proof. If a permission looks unfamiliar, open the spender address in a trusted explorer and inspect whether it is verified, what transactions it performs, and which protocol links to it.
Knowing how to read the underlying transaction is useful here. A blockchain explorer can show the contract, method, address, status, and token activity.
How to revoke a token approval
The exact interface varies, but the underlying process is similar:
- Open a trusted approval-management interface.
- Select the correct network.
- Connect or enter the wallet address to inspect permissions.
- Find the token and spender you no longer trust or use.
- Choose revoke or reduce allowance.
- Review the transaction in the wallet.
- Confirm the network, token contract, spender, and gas fee.
- Submit the transaction.
- Wait for confirmation and refresh the approval list.
Revoking is itself an on-chain transaction. The wallet needs enough native network currency to pay gas, such as ETH on Ethereum or the corresponding native asset on another EVM network.
The transaction should modify an existing allowance. Be cautious if the wallet prompt contains an unexpected token transfer, contract deployment, asset sale, or unrelated interaction.
After confirmation, verify that the allowance is zero or reduced to the intended amount. Do not rely only on a success message from the website.
Which approvals should you revoke?
Revoking every approval after every transaction creates extra fees and friction. Leaving every approval active forever creates unnecessary exposure. A risk-based review is more practical.
Consider revoking when:
- you no longer use the dApp;
- the spender or protocol is unfamiliar;
- the approval came from a suspicious link;
- the allowance is unlimited and the wallet holds a meaningful balance;
- the protocol has reported an exploit or compromised interface;
- the contract has been replaced or deprecated;
- the wallet is moving from active use to long-term storage;
- you cannot explain why the permission exists.
A frequently used, well-understood protocol may keep a limited allowance if that fits the user’s risk tolerance. High-value wallets should generally keep fewer standing permissions than small experimental wallets.
Users who regularly make a crypto swap through DEX infrastructure will encounter approvals more often than users who only receive and send assets. That is one reason to separate long-term holdings from an active Web3 wallet.
Token approvals, Permit signatures, and Permit2
Not every spending authorization begins with a visible approve transaction.
Some tokens support a mechanism commonly called Permit. Instead of first sending an on-chain approval transaction, the user signs a structured message. Another party can submit that signature to the blockchain, where it creates the allowance if the signature is valid and has not expired or been used.
This can improve UX and reduce the number of transactions. It also means “I only signed a message” is not a sufficient safety check. A signature may grant spending authority even when the user did not pay gas at the moment of signing.
Permit2 is a more general permission system used by some applications. A user may first approve the Permit2 contract for a token and then sign more specific permissions for individual applications. This separates the token-level approval from later signed authorizations, but introduces another layer users need to understand.
When a wallet asks for a signature, inspect:
- the requesting domain;
- the token and amount;
- the spender;
- the expiration time;
- the chain;
- whether the permission is one-time or reusable;
- whether the wallet can decode the message clearly.
Reject blind signatures and unreadable authorization requests unless you fully understand the hardware, application, and transaction flow.
What to do after a suspicious approval or signature
If you approved an unknown contract but funds have not moved, act before investigating at leisure.
First, stop interacting with the suspicious site. Open a trusted approval checker through a clean browser session or known bookmark, then revoke the relevant permission on every network where it may exist.
Next, inspect recent transactions and signatures. If the wallet holds material funds and you suspect broader compromise, move remaining assets to a new wallet created on a clean device. Revoking one token allowance does not repair a leaked seed phrase, malicious extension, or compromised signing device.
A practical response is:
- Revoke the suspicious token approval.
- Check other tokens and networks.
- Disconnect unknown connected sites.
- Review recent on-chain activity.
- Remove suspicious browser extensions or apps.
- Move funds if the wallet’s keys or device may be compromised.
- Stop using the old address for business receipts or reserves.
Changing the wallet password is not enough if the seed phrase or private key was exposed. It only changes local access to that wallet application.
Be skeptical of “recovery services” that request a seed phrase, upfront payment, or remote access. The same urgency that led to the first mistake can make a second scam more convincing.
Other wallet permissions users confuse with approvals
Web3 wallets expose several actions that look similar but have different consequences.
Connected sites
A connected site can see the public wallet address and request signatures or transactions. Disconnecting it closes that communication path, but does not remove on-chain token allowances.
Transaction signatures
A normal transaction signature authorizes a specific blockchain transaction. The wallet should display the destination, network, value, gas, and contract interaction.
Message signatures
A message signature may prove wallet ownership, sign in to a service, place an order, or authorize a Permit. Some messages have no financial effect; others can be used to create powerful permissions.
NFT approvals
NFT standards have their own approval models. An approval may cover one token or authorize an operator to manage all assets in a collection. These permissions need a separate review from ERC-20 allowances.
Network and token visibility
Adding a network or importing a token into a wallet changes what the interface displays. It does not by itself authorize spending. A fake token can still be used as bait for malicious links, so unexpected assets should not be treated as free money.
The broader review of MetaMask’s features and risks helps place these permissions in context.
Safer habits for active Web3 wallets
Approval hygiene works best when it is part of a wallet architecture, not an occasional panic after a suspicious prompt.
Use one wallet for active dApp interactions and another for reserves. Keep only the amount needed for current activity in the Web3 wallet. Review unlimited approvals periodically, especially after trying a new protocol.
Before approving anything:
- open the dApp from a verified source or bookmark;
- check the network and token;
- prefer a limited amount when practical;
- read the spender and transaction details;
- avoid links sent through unsolicited messages;
- verify security alerts through the project’s official channels.
These habits complement protection against other wallet attacks, including fake addresses inserted into transaction history.
What token approvals mean for a business
A company may use Web3 wallets for swaps, treasury management, liquidity operations, contractor payouts, or protocol interactions. Those wallets should not be treated like personal browser wallets.
Business controls can include:
- an approved list of protocols and spender contracts;
- transaction simulation and independent review;
- limited allowances for high-value tokens;
- a separate wallet for experimental dApps;
- periodic approval reports;
- documented incident response;
- multisig or another shared authorization model for treasury actions.
The company should also separate Web3 activity from customer payment processing. A wallet that signs experimental DeFi permissions should not be the only destination for business revenue or reserves.
CryptumPay can handle customer-facing crypto invoices, payment status, transaction history, and withdrawals without requiring employees to expose an operational Web3 wallet to every customer payment. The company can then transfer settled funds according to its own treasury policy.
This separation supports the broader security controls businesses need around crypto payments: wallet permissions, payment verification, AML screening, access control, and treasury authorization solve different parts of the risk.
Token approval checklist
Before approving or revoking a permission, confirm:
- You are on the intended network.
- The token contract is genuine.
- The spender belongs to the protocol you intended to use.
- The amount is appropriate for the action.
- An unlimited approval is genuinely necessary.
- The wallet clearly explains the transaction or signature.
- You have enough native currency for gas.
- You know how to verify the resulting allowance.
- High-value reserves are stored separately.
Token approvals are not inherently dangerous. They are a core mechanism that lets smart contracts work with user-owned tokens. The risk appears when permissions are broader than necessary, remain active longer than expected, or are granted through a malicious interface.
The safest approach is not to fear every approval. It is to understand what is being authorized, limit standing access, and revoke permissions that no longer have a clear purpose.
FAQ
Does disconnecting MetaMask revoke token approvals?
No. Disconnecting a site removes the active wallet connection, but on-chain token allowances normally remain until they are changed through a blockchain transaction.
Does revoking an approval cost gas?
Usually yes. Updating an ERC-20 allowance is an on-chain action, so the wallet needs the network’s native asset to pay the transaction fee.
Can an approval expose my seed phrase?
A standard token approval does not reveal the seed phrase. It can authorize a spender to transfer a particular token. If the seed phrase was entered into a website or shared, assume the whole wallet is compromised.
Will revoke recover stolen tokens?
No. Revoking can prevent future use of the allowance, but it cannot reverse transfers that have already been confirmed.
Should I revoke every unlimited approval?
Not automatically. Review who the spender is, whether you still use the protocol, the value exposed, and your risk tolerance. Old, unknown, or unnecessary unlimited approvals are strong candidates for removal.
