A token approval lets a specified spender use an account’s tokens under the token contract’s rules. The familiar ERC-20 operation is called Approve; ERC-20 is a token interface standard. Connecting to a site does not approve spending, and disconnecting does not automatically revoke an allowance. EIP-20 defines allowance queries and spending; EIP-2612 lets a qualifying signature establish an allowance. This guide uses a finite-allowance example to explain confirmation, spending, and revocation, with references checked through October 27, 2026.
When a wallet confirmation appears, the hard part is often understanding what you are agreeing to. A site calls it a login, but the wallet asks you to approve a transaction. You disconnect from the site, yet a spender’s allowance remains on-chain. Judging risk only by whether the wallet is connected can miss the actual permission to spend.
We will separate connections, transactions, and signatures, then follow a finite-allowance plan from start to finish. At every step, the question is which state has actually changed—and what that change still cannot prove safe.
Wallet Connections, Transactions, and Signatures Grant Different Permissions
A connection, an Approve transaction, and a message signature are different actions, not one interchangeable authorization. A typical site connection may reveal an account address you choose to share and let the site make further requests. Being able to request an action is not the same as being able to move arbitrary assets. For how wallets hold keys, start with wallets and account control.
Connecting to a Site Does Not Approve Token Spending
Common ERC-20 tokens store spending allowances in the token contract. An owner grants a spender an allowance; that spender may then call transferFrom under the contract’s rules to move the owner’s tokens to a specified recipient. A spender is the address authorized to spend. It may be a contract or an ordinary account. A name such as router does not establish trustworthiness.
MetaMask’s official Disconnect wallet from a dapp explains that disconnecting does not revoke token approvals. Disconnecting changes the interface connection; revocation changes the on-chain allowance. Hardware signing does not automatically reject malicious spending requests either. Hardware key isolation addresses some key-extraction risks, while users must still understand what they sign.
Approve and Permit Become Effective at Different Times
Approve is generally a transaction sent to the token contract. After confirming it in your wallet, wait for successful on-chain execution before recording the new allowance. Refusing to sign, not yet submitting, pending execution, and failed execution are not completed approvals.
Permit offers another route. EIP-2612 lets an owner sign specified data first, then have the owner or another party submit it on-chain. Gas measures billable on-chain execution work. Signing may incur no on-chain gas fee at that moment while allowing a later submitter to establish an allowance. No network charge now does not mean a signature carries no asset risk. Other protocols may use their own signature and spending mechanisms, so one revocation method does not cover them all.
Fix Four Identifiers Before Reading an Allowance
Before querying an allowance, fix the network, owner, token contract, and spender. Leave one out and you may query another chain, account, or token contract. A zero there could be mistaken for proof that the permission you intended to address has been cleared.
Network, Owner, Token Contract, and Spender
The owner identifies whose tokens can be spent. The token contract identifies which token you are querying. The spender identifies who may invoke spending under the allowance. The recipient may differ from the spender; a final receiving address is not automatically the authorized spender.
EIP-20’s allowance(owner, spender) takes the owner and spender as parameters and is called on a particular token contract. Tokens sharing a name are not the same contract. Familiar-looking addresses do not remove the need to verify the network. Obtain the complete identifiers through trusted official entry points and compare them with the request before signing, so you know exactly which state will change.
Allowance Is Not Balance; Unlimited Is Not Free
Balance is what the account currently holds. Allowance is what a specified spender may use under the contract’s rules. Approving 20 neither adds 20 to the balance nor means 20 has already moved. An allowance exceeding the current balance may also expose tokens received later.
An unlimited or very large allowance primarily changes the permitted spending range, not transaction fees. Tokens may implement maximum allowances, allowance reductions, and updates differently. Our example fixes a finite model in which successful spending reduces the allowance; it does not represent every ERC-20 token. If an operation needs only 12, understand why it requests more instead of skipping the scope check for future convenience.
A Finite-Allowance Walkthrough: When 20, 8, and 0 Become True
Record allowance and balance separately to see what each step accomplishes. This is a paper exercise: owner A starts with 100 units of token T, plans to let spender S use 12, then revoke the remainder. A, S, T, and recipient R are labels. There is no real deployment, signature, or transfer, and no token-price or profit assumption.
Step 1: Read the Current Allowance Before Choosing an Action
Fix the example’s network, owner A, token T contract, and spender S. Query the current allowance and find 0. Record the result and query time, then check whether the operation actually requires S to spend on A’s behalf and whether S matches the address shown by a trusted interface. Zero establishes only that this specific on-chain allowance is zero at that moment. It does not prove A has no other approvals or valid signatures.
The plan grants 20, spends 12, then handles the remaining allowance. Twenty is a teaching choice, not a recommended universal limit. If the signing request switches to another S or a token other than T, cancel this attempt and recheck all four identifiers. An earlier check does not authorize a different request.
Step 2: Approve Only 20 and Wait for On-Chain Confirmation
Assume A prepares an Approve transaction setting T’s allowance for S to 20. Check the transaction destination, call data, and network fee too. Here, 20 is in displayed token units. Contracts may store amounts as integers in smaller units, which a trusted interface must convert using the token’s decimals. Do not read a raw integer as the displayed quantity.
After signing but before confirmation, record the status as pending rather than entering an allowance of 20. Only after successful execution and a new query of the same identifiers returns 20 should the status become effective. This step moves no T, so the assumed token balance remains 100. If A pays the network fee, its native-coin balance may decrease separately; that is not T being spent.
Step 3: After Spending 12, Check the Remaining Allowance of 8
Assume S successfully transfers 12 units of A’s T to R under the example’s rules, with no other token movements. A’s T balance becomes 100 − 12 = 88. Under our finite-allowance reduction rule, S’s remaining allowance becomes 20 − 12 = 8. These numbers answer different questions: how much A holds and how much S can still spend.
A check mark on the application page is insufficient. Verify the original transaction succeeded and that the actual token and recipient are correct, then query the current balance and allowance. Another spend or transfer during this period would invalidate the simple 88 and 8 calculation. If execution failed, record actual on-chain state rather than subtracting 12 as planned.
An ordinary ERC-20 allowance follows the permissions granted; it does not necessarily lock the recipient or purpose of every spend. Unless the contract imposes further restrictions, the first transfer to R does not mean the remaining 8 can only ever go to R.
Step 4: Revoke and Confirm Zero, Rather Than Just Submitting
Next, assume A successfully changes the same T allowance for S to 0. While revocation is pending, the existing allowance of 8 does not disappear merely because A clicked a button. The execution order of spending and revocation still affects the outcome. Submitted revocation is not proof that assets are safe.
Record this particular on-chain allowance as zero only after revocation succeeds and a new query returns 0. With no other T movements under our teaching assumptions, A still holds 88. Cancelling permission to spend 8 does not return another 8. It closes the remaining allowance, neither recovering the 12 already transferred nor guaranteeing anything about other permissions.
EIP-20 also warns of transaction-ordering risks when updating an existing nonzero allowance and suggests interfaces first set it to zero before setting a new value. Actual tokens may provide different increase/decrease methods or restrictions. This guidance does not guarantee prevention of every spend before an update. If an attack is suspected, reassess the exposure instead of repeatedly changing the allowance to another number.
What Risks Remain After Revoking One Allowance?
Revocation addresses a specific permission; it does not automatically eliminate other signatures, other token permissions, or exposed keys. Our completed example establishes only that A’s allowance of T to S on the fixed network is zero. Another spender, chain, or asset requires a separate check.
An Unsubmitted Permit Is Separate from the Current Allowance
Add an independent branch: A previously signed an EIP-2612 Permit that has not been submitted. If its nonce, deadline, and other conditions still meet the contract’s requirements, someone may submit it later to establish the specified allowance. A nonce is a sequence value that prevents reuse of the same permit; the deadline constrains when it can be submitted. A deadline still in the future is not a reason to assume safety.
That is why an Approve allowance of 0 does not establish that every unsubmitted signature is invalid. Check the actual protocol, signed permission, and cancellation method. An ordinary approve(0) does not automatically cancel every signature type. No Permit is involved in the 20 → 8 → 0 walkthrough. This separate branch explains the limits of the zero-allowance conclusion; it does not claim a second spend occurred in the example.
Revoking Allowances Cannot Replace Exposed Account Control
If someone else has the seed phrase or private key, the problem extends beyond S’s allowance. Anyone with the relevant control material may create new transactions or approvals. Changing the old app’s password does not retrieve another person’s copy. Continue with private keys and seed phrases to identify accounts derived from the same source.
A revoked screenshot alone cannot close such an incident. Conversely, finding a suspicious approval does not prove a private key has leaked. Separate known exposure from what remains uncertain and act on the actual evidence. Suspicious transfers and compromised account control follows that decision process.
Make Permission Checks a Habit Before Every Signature
Before agreeing, be able to identify the spender, scope, and way the permission becomes effective. A later inventory can reveal unused allowances, but cannot endorse the next unfamiliar signature. Stop if the request is unreadable, the identifiers differ, or a site pressures you to skip verification.
Use Trusted Entry Points, Not Unsolicited Verification Requests
Start from a wallet, official documentation, or allowance-management tool you have independently verified. Do not follow safety-check links in unsolicited messages. Reading public allowances does not require giving support your seed phrase or private key. If a management tool requests a signature or transaction, read that specific request again; a security label does not make it an exception.
MetaMask’s official Spending caps describes viewing and revoking allowances, but a tool’s coverage still limits which permissions it can list. An absent entry does not establish the absence of other chains’ permissions, non-fungible token (NFT) permissions, or protocol-specific signatures. Our ERC-20 walkthrough does not replace their distinct handling rules.
Check Network Fees and Stop Conditions Together
Approve and revocation usually require on-chain transaction fees. A signature-based permission may leave the submission fee to someone else. Who pays is a separate question from whom you allow to spend tokens. See fees for failed transactions for funding requirements versus actual charges.
For routine management, check the fee and budget before acting. If a sweeper bot is suspected, do not simply fund the old account with native coins to complete revocation. A sweeper bot monitors incoming funds and automatically moves assets out quickly. Include stop conditions alongside the allowance so that addressing one permission does not expose more assets.
This article explains mechanisms through hypothetical scenarios. No real approval or revocation was performed, and it is not advice for disposing of a particular person’s assets. Token and protocol implementations vary. For a suspected compromise, assess the actual evidence and use trusted official support.