What is a token approval?
A token approval is permission for a particular spender to use a specified token from your account under the token contract's rules. For a conventional ERC-20 token, the contract records an allowance for the owner and spender. The permission can remain after you close the app.
That permission is separate from your current balance and from a wallet connection. Before approving, identify the network, token contract, spender and amount. An app name or token symbol alone does not identify all four. The ERC-20 model discussed here does not describe every blockchain, NFT permission or smart-wallet authorization.
This guide focuses on reading an allowance and understanding signed permits. For choosing and backing up a wallet, use the existing custody guide. The exercises below use fictional tokens and require no wallet connection or transaction.
Connect, approve, sign and swap are different actions
Connecting lets a site request access to selected wallet accounts under the wallet's connection permissions. Disconnecting removes that connection; it does not erase a token allowance already recorded on-chain. Public blockchain records also do not become private merely because a site is disconnected.
An approval sets spending permission. A swap is the action that exchanges assets and may use that permission. Signing a message is another category: some messages authorize a login, while others authorize a token allowance or transfer. Read the request's actual meaning instead of assuming every message is harmless.
A successful connection does not prove that an approval or swap succeeded. Keep separate records for the connection, permission transaction or signature, and final transfer. This distinction helps explain why an interface can say connected while a trade still needs authorization.
How much can an approved spender use?
In the standard model, allowance is the remaining permission for a spender, while balance is what the account currently holds. A very large allowance can cover later deposits too, subject to the token's rules. It is not a promise that the app will use only the amount in today's intended trade.
Practice with fictional Token T on Network N. Your balance starts at 250 T and you approve Router R for 80 T. It spends 50 T. In this simplified example, the balance becomes 200 T and the remaining allowance becomes 30 T. Router R cannot use the entire 200 T through that 30 T permission.
Now imagine an unrelated deposit adds 100 T. The balance becomes 300 T but the remaining allowance is still 30 T. If a confirmed revocation sets that allowance to zero, the balance remains 300 T: revocation changes permission, not ownership. Assume ordinary finite allowance accounting, no transfer fee and no other transactions for this worksheet; always inspect actual contract state for a real token.
What does an ERC-2612 permit signature allow?
ERC-2612 lets a supporting token accept a signed message that changes an allowance when someone submits it on-chain. Its fields include the owner, spender, value, nonce and deadline. A nonce is a value used to prevent the same permit from being successfully reused. The person submitting it can be someone other than the owner.
The deadline limits when that permit may be submitted. Under ERC-2612 it is not an expiry time for the allowance after a successful submission. For example, a fictional permit submitted at 19:59 before its 20:00 deadline can leave an allowance in place after 20:00. Do not confuse a signature deadline with an automatic allowance expiry.
A signature can therefore authorize something valuable without immediately showing a network fee to the signer. A token must implement the relevant permit scheme; do not assume every token or similarly named permit has identical rules. Review the actual signing request and the verified documentation for that contract.
How is Permit2 different?
Permit2 is a separate contract system. A token owner first grants an ERC-20 allowance to Permit2. Applications then use permissions handled through Permit2. That creates two things to inspect: the token's allowance to Permit2 and the application's permission through Permit2.
Uniswap documents two modules. AllowanceTransfer keeps an amount and expiration for an approved spender. SignatureTransfer authorizes a single transfer using a signature and nonce. The one-time nature of the second module's application permission does not mean that the token-level approval to Permit2 has disappeared.
A wallet warning about a Permit2 signature deserves the same attention as an approval transaction. Uniswap warns that a malicious signature can exploit an existing approval to Permit2. Check the requested token, spender, amount, network and time limits. A familiar contract or brand does not validate an unfamiliar request.
How do I check and revoke an unwanted approval?
Open your wallet provider's official documentation independently and follow its supported approval-management route. Ethereum.org describes using a relevant explorer or approval-checking tool to inspect permissions. Start with the correct public account and network; an empty result on one network says nothing about another.
Compare the full token and spender addresses with independently verified records. Inspect the current amount and the kind of permission. If you decide to revoke a conventional allowance, review the transaction that sets or removes that permission, including its network fee, before signing. A legitimate approval review does not require your recovery phrase.
After submission, check the transaction outcome and then read the current allowance again. Pending, failed and confirmed are different states. If a revocation fails, do not describe the permission as removed. MetaMask notes that on-chain revocations require gas; the amount varies by network and conditions.
For Permit2, check which layer a tool changes. Revoking one application's internal permission and revoking the token's allowance to Permit2 are different actions and can affect different uses. Follow the documented route for the specific permission rather than guessing from a button label.
- Match account and network.
- Identify token, spender and permission type.
- Review the proposed change and fee.
- Wait for a successful transaction.
- Read the resulting permission again.
What does revocation not fix?
Revocation does not reverse a completed transfer or recover tokens already moved. It also does not repair an exposed private key or recovery phrase. Someone with signing control can authorize new actions. Treat that as a different incident and follow the wallet maker's verified incident guidance rather than relying on one allowance change.
An unused off-chain signature may not appear as an active on-chain allowance. Do not assume that a zero allowance or a clean approval list cancels every previously signed message. Permit mechanisms have their own nonce, cancellation and expiry rules, so suspected malicious signatures need the relevant wallet or protocol guidance.
These checks reduce uncertainty about a specific permission; they do not certify a contract, device or entire wallet as safe. If you cannot explain the request, stop before signing and identify it through verified documentation. Do not test a suspicious request with a funded account.
Five-minute check: which permission remains?
Scenario A: you close a swap site and disconnect it from the wallet, but make no on-chain change. Does that prove its existing ERC-20 allowance is gone? No. Check the allowance separately.
Scenario B: an ERC-2612 permit is successfully submitted before its deadline. The deadline then passes. Does ERC-2612 automatically reduce the allowance to zero? No; the deadline concerns submission of the permit, not the lifetime of the resulting allowance.
Scenario C: a Permit2 SignatureTransfer is used once. Does that prove the underlying token allowance to Permit2 is zero? No. The one-time application authorization and the token-level approval are separate.
Write a short permission record for an app you understand: network; account; token; spender; amount; permission mechanism; relevant deadline or expiry; last verified state. You can practise with invented entries. Keep private keys, recovery phrases and signed authorization payloads out of shared notes.
Sources & further reading
- ERC-20: approve, allowance and transferFrom
- ERC-2612: signed permits, nonces and submission deadlines
- Uniswap: Permit2 permission layers
- MetaMask: revoking token approvals versus disconnecting
- Ethereum.org: checking and revoking contract access
- Uniswap: risks of malicious Permit2 signature approvals
- MetaMask: disconnect a wallet from a dapp
Educational content. Examples are illustrative. Protocols, products and rules can change; consult the linked documentation for current details.