Did you know? You can disconnect a blockchain wallet from a website, close every browser tab and never visit the website again—yet an earlier on-chain permission may still exist. It is a surprising distinction, and it explains why “I logged out” is not always the same as “I took back permission.”
The reason is that two different systems are involved. A website connection allows a page or application to interact with the wallet interface under whatever access was granted. A token allowance can be a persistent state recorded by a token smart contract on a blockchain. Disconnecting the page from the wallet does not automatically send a transaction changing the contract’s earlier permission.
In this guide, we will follow a fictional art-club token to see who can spend what, why allowances sometimes remain after one action, what a limited approval changes, how revocation differs from disconnecting, and how to describe the risk without frightening beginners. This is an educational explanation, not advice to connect a real wallet, click an approval website or move digital assets.
The answer in one minute: for a typical ERC-20 token, an owner may authorise a spender address to move up to a defined amount of that token through the token contract’s allowance mechanism. The permission can outlast a browser session or individual intended purchase. Removing a website connection is an interface action; changing the approved on-chain allowance requires an appropriate contract action, subject to that token’s implementation and the network. Checking the current owner, token contract, spender, chain and remaining amount matters more than remembering whether the browser tab is open.
Already familiar with approvals? Skip to “The remaining-permission ledger” for a worked calculation, “The revoke question” for practical distinctions, or “Ten claims to test” for a safety review. The foundational reading route is What Is Blockchain? and the existing specialised Token Approvals: Track Remaining Permission in an Allowance Ledger if your goal is the deeper accounting model. Here we focus on what happens when a person simply disconnects a website.
A school-club permission that outlives the meeting
Alicia is the treasurer of a fictional school art club. Tricia manages the club’s supply orders, and Kai Kai maintains the classroom register. The club has 100 imaginary ART credits. This is a paper exercise; the credits have no real economic value and none of the people are asked to use a public blockchain.
At a meeting, Alicia signs a paper authorisation allowing Tricia to spend up to 40 ART credits on supplies. The meeting ends. Alicia walks out, closes her notebook and stops talking to Tricia. Has the written permission vanished merely because the meeting ended? Not necessarily. Unless the club’s agreed rules say otherwise, the authorisation continues to exist in the register.
The blockchain analogy is that a token allowance can live in contract state, independently of the web page that originally requested it. Signing in to or disconnecting from a website affects the interface relationship. A recorded contract permission is a different kind of fact that participants can query and use under the contract’s rules.
The analogy has limits. A person in a school club can ask a human to negotiate, intervene or reverse a mistake. A public smart contract executes defined code in an accepted history. It does not automatically recognise a human promise to stop spending merely because Alicia feels she has withdrawn her trust.
This is why educational explanations need two verbs: disconnect and revoke. One ends a website connection. The other changes a permission in the relevant authority system, when supported. Treating them as synonyms can leave users with a false sense of safety.
What a wallet connection actually does
A browser wallet can let a website discover or request use of selected public accounts, read relevant information and initiate a transaction or signature request through the wallet interface. The exact capabilities depend on the wallet, the requested permissions and the application’s design. A user normally reviews requests before authorising sensitive actions.
Connecting a wallet is not inherently an unlimited permission to spend every token. A user might connect to read account information or explore an application without making an on-chain approval. Conversely, an app that was once connected may have induced the user to submit a separate, lasting token-approval transaction.
When you disconnect, the wallet changes its relationship with the website. In typical browser-wallet designs, it can stop the website from automatically accessing account details or initiating certain prompts through that connection. This is an interface-level boundary, not a network-wide instruction to erase previous contract state.
Some applications remember public addresses or past user activity independently. A public blockchain can still expose addresses and transactions even if a particular wallet stops sharing them through one website. Disconnecting a site does not make the past ledger private.
A useful beginner question is: “Which permission was granted to the webpage, and which permission was granted to an on-chain contract?” Until the two are identified separately, a screen labelled “disconnected” cannot answer every security question the user has.
For a live example of the distinction in a major wallet’s documentation, see MetaMask: Manage dapp permissions. Its warning is clear: disconnecting a dapp does not automatically revoke token approvals.
How ERC-20 approvals are represented
ERC-20 is a widely used Ethereum token-interface standard. Among its defined methods are approve, allowance and transferFrom. These create a way for a token owner to authorise a spender to move a specified amount of that token on the owner’s behalf under the token’s implemented rules.
The simplest conceptual record has four pieces: token contract, owner account, spender account and allowance amount. The token contract keeps the relevant state. An approved spender may use a supported operation such as transferFrom up to the remaining authorised amount, subject to the token’s other rules and the owner’s actual balance.
Did you notice that the spender is an on-chain address, not the website’s marketing name? The web page may be called “Amazing Art Market,” but the actual allowance points to an address in a specified token contract and network. The identity and behaviour of that address matter more than the logo.
An allowance is also not the same as a balance. Alicia may own 100 ART credits but permit a particular spender to move only 40. Approval does not necessarily transfer 40 immediately. It creates a constrained capability that can be used later within the rules. If Alicia later receives more ART, an unused allowance may still be relevant.
For the precise interface, read EIP-20: ERC-20 Token Standard. This page describes an Ethereum token pattern; it should not be treated as a universal mechanism on Bitcoin or every other network.
The remaining-permission ledger: a simple calculation
Return to the fictional art club. Alicia owns 100 ART credits and approves Tricia’s spending account for 40 credits. The allowance is 40; Alicia’s token balance is still 100 immediately after that approval in the ordinary model. The permission authorises a future action but does not itself buy supplies.
Tricia then spends 12 ART credits under the approved mechanism. If the token follows the ordinary allowance-decrement model, the remaining allowance becomes 28. Alicia’s balance falls by the relevant amount, provided no other changes occur. Tricia later spends another 8, leaving 20 of the original allowance unused.
The arithmetic is easy: 40 minus 12 minus 8 equals 20. The security lesson is bigger. Even after both purchases are complete, the remaining 20 can still matter. Nothing about closing the club’s online ordering page sets it automatically to zero.
Now suppose Alicia receives 50 additional ART credits. Her balance may rise, but the approved allowance does not necessarily disappear. A spender authorised for 20 remaining credits may still have a usable capability, even if Alicia believes the purchasing relationship ended weeks ago.
This example assumes an ordinary token implementation and successful authorised transfers. Real contracts can have additional restrictions or modified behaviour. A serious audit checks actual token and spender state rather than assuming all implementations behave identically.
For students, draw two separate columns: current asset balance and remaining approved amount. Record each event in each column. The first is what the owner has; the second is one set of permissions another address may exercise. They answer different questions.
Why websites request an approval before a trade
Imagine a decentralised exchange application preparing to trade one ERC-20 asset for another. Instead of possessing a customer’s private key, an on-chain contract can require the customer to authorise a certain allowance for the token it needs to transfer. Later, the contract may use the authorised transferFrom path under its rules.
This can support useful workflows. A program can act on the token owner’s earlier permission without being handed the owner’s signing key. The intended operation may be bounded by an amount, and some systems design more precise authorisation flows. That is a meaningful separation of authority.
The risk emerges when the allowance is larger or lasts longer than the user understands, or when the permitted spender’s code or governance is flawed. A legitimate feature can create a lasting exposure if the permission is too broad for the user’s intent.
Sometimes applications prefer large allowances because they reduce repeat approval transactions and associated friction. A user who frequently performs permitted actions may appreciate that convenience. But convenience changes how long the permission remains useful to the spender. It is a trade-off, not a free improvement in safety.
Students should avoid calling every approval malicious. The correct question is whether the amount, token, spender, duration or other conditions match the intended relationship, and whether the user understands what an authorisation enables.
An approval is therefore best understood as a grant of a capability, not a purchase receipt. A purchase receipt shows a result; a capability can affect what may happen next.
Disconnecting, signing out, uninstalling and revoking are different
Consider four actions: closing a browser tab, signing out of a website, disconnecting a dapp inside a wallet, and revoking an on-chain token allowance. The first three may change the local user experience or access to a wallet interface. They do not inherently modify an ERC-20 token contract’s recorded allowance.
Revocation generally means reducing or removing the relevant approved permission in the on-chain authority system. For a typical ERC-20 allowance, setting the approved amount to zero can eliminate the remaining permission for that particular owner-token-spender relationship after the change is accepted. The exact mechanism and support depend on the token and spender design.
Uninstalling a wallet application is especially easy to misunderstand. The token contract does not inspect whether the owner’s phone still has the app installed. Previously accepted network state remains part of the network’s operation. A user may lose access to the wallet interface while an on-chain permission continues.
This is not a claim that a spender can always move every asset indefinitely. A typical allowance is for a specified token and amount, and a transfer is subject to the relevant balances and contract rules. The point is that an earlier capability can remain in force, not that every account is always exposed to universal spending.
The correct vocabulary helps: “I disconnected the site” is a statement about a wallet-app interaction. “The allowance is zero under token contract X for spender Y on chain Z” is a statement about on-chain permission state. The two may both be true, one true, or both unverified.
What an unlimited approval really means
Some interfaces offer an approval that is so large that it operates like an effectively unlimited permission for ordinary user balances. In an ERC-20 context, the approved value may be a very large integer, often the maximum representable value for the relevant unsigned integer type or another similarly broad bound.
A legitimate application may request a high allowance to avoid charging the user for repeated approval transactions. That can simplify future interactions. But if the permitted spender is malicious, compromised or unexpectedly upgraded, an excessive scope can increase the harm that can occur without obtaining a new ordinary approval for every transfer.
It is incorrect to infer that all “unlimited” approvals instantly empty a wallet. The spender must still have a usable capability and an executable route under the actual token and network rules. Nevertheless, broad permissions expand potential exposure, and users should not treat them as harmless just because they were requested by a polished interface.
Compare the permission with the task. If Alicia wants a fictional contract to spend 12 ART credits once, permission covering a huge amount and every future balance may be much broader than necessary. A smaller allowance can limit exposure, though it may require new approval transactions for later uses.
The real assessment should also consider whether the wallet provides clear control over the amount, whether a spender contract can change behaviour, and whether the site honestly describes the request. A low numeric allowance does not cure every scam, but it can make one dimension of risk smaller.
The current MetaMask token-approval explanation discusses how limited versus very large allowances affect user risk. Read it as wallet-specific guidance alongside the ERC-20 standard, not as a substitute for examining the actual contract.
An approval is not a signature that can be withdrawn from history
A contract’s state may be changed by a later accepted instruction, but the original approval transaction remains part of the historical record. If Alicia approved 40 ART and later set the allowance to zero, the later state can reflect no remaining permission for that relation while a historical explorer still displays the earlier approval event.
This is normal for many blockchain systems. Historical records tell you what happened; current state determines what the contract presently allows under its rules. An explorer showing a year-old approval transaction does not necessarily mean the approval is still active. Conversely, the absence of a visible approval in one indexer view does not conclusively establish zero current allowance.
Readers should distinguish an event in the past, the state now, and a claim about possible future actions. A past approval event is one piece of evidence. The current allowance query and relevant implementation details answer a different question.
If an application permits permissions with separate expiration logic, signatures, sessions or roles, those mechanisms must be checked on their own terms. They should not be collapsed into the basic ERC-20 allowance field unless that is genuinely how the application enforces them.
This distinction also matters when discussing audits and disputes. A user may want proof that they revoked an approval. The later accepted transaction and the resulting state can supply relevant evidence without erasing the earlier action. A truthful system does not need to rewrite history to record that authority changed.
Why revoking may itself require a transaction and a fee
An on-chain approval is stored or enforced through blockchain state. Changing that state typically requires an authorised transaction under the relevant network’s rules. That transaction consumes network processing resources, and on Ethereum a revocation can therefore involve a gas fee.
This surprises users who expect a free toggle inside the browser. A wallet interface can display a convenient “revoke” control, but behind the control there may be a transaction that must be confirmed and included before the relevant allowance changes. The user should distinguish a proposed revocation from an accepted one.
If an approval is already being exercised in a pending or accepted action, the ordering of transactions can matter. A revocation cannot retroactively undo a completed transfer. Nor should a user assume that the act of clicking “revoke” prevents all earlier submitted transactions from being ordered first.
Real implementations also vary. Some applications use signature-based approvals such as permits or other delegated authorisation systems, rather than exactly the same approve flow. Revocation support and costs must be understood in that specific design.
For a beginner, the safe lesson is not to rush into unknown “revoke all” websites. Instead, identify the network and permission type, use the wallet’s official documented route or a verified explorer, and understand what transaction or state change the procedure actually performs.
The related fee explanation is Why Network Fees Change When It Gets Busy. It explains why the price of a permission-changing action can vary even though the intended authorisation amount is the same.
A malicious website can request a genuine-looking approval
A scam page can imitate a known exchange, digital-art market or reward service and ask a person to approve a token spender. The confirmation window may show a contract address or a very large amount. The user might focus on the site’s promise of a reward rather than on which authority is being granted.
The dangerous feature is not the appearance of a popup. A real wallet may correctly ask for confirmation of a harmful action that the user initiated through an untrustworthy page. The interface can enforce the instruction the user authorised even if the website’s story about the instruction was false.
A malicious approval can also come from social engineering: a fake support agent says an account must be “verified,” an advertisement claims a prize will disappear in minutes, or a copied brand identity pressures users into approving an unfamiliar spender. None of those stories makes the contract permission safe.
A useful learning exercise is to rewrite the request into plain language: “I am giving spender address X the ability to move up to Y units of token Z on network N under this contract’s rules.” If the person would not knowingly grant that permission, they should not rely on an attractive headline to justify the approval.
Never give a recovery phrase or private key to an approval checker, and do not assume that connecting a wallet is necessary to read ordinary public blockchain information. Official wallet and network documentation is the appropriate starting point for learning how permissions are displayed.
This example is not a set of instructions to exploit a token contract. It is a method for readers to recognise the scope of an authorisation before they create it.
The difference between ERC-20 allowances and NFT approvals
A beginner may encounter the word “approval” when dealing with a fungible token, a digital collectible or a programmable account. Those contexts may use different standards and capabilities. The basic ERC-20 owner-spender-amount model is useful, but it is not a universal description of every approval screen.
Some NFT standards provide ways to approve a transfer for a particular token identifier. Others include operator permissions applying to sets of tokens controlled by the owner. Those can be broader than a single one-time object sale, depending on the relevant standard and contract.
An NFT being displayed in a wallet does not mean a token approval for an unrelated ERC-20 automatically controls it. The actual contract and authority model decide what a spender can do. Likewise, a permission to use one token contract should not be described as permission to spend every type of asset on every network.
A cautious reader identifies the asset type, contract, chain and approval method, then asks which entities are authorised for which operations. An interface that labels different authorisation types as one generic “permission” should be inspected carefully.
This separation matters for teaching. If students memorise “approval equals a number,” they will struggle with operator-style permissions or account permissions that do not follow that shape. The wider concept is delegated authority; the exact representation is specific.
The question stays the same: after the intended activity ends, which authority remains, and which accepted network action would change it? Answering that requires the actual standard and application design rather than a slogan about revoking everything.
Permits, off-chain signatures and the word “gasless”
Some token designs allow a user to sign structured information that can later be submitted on-chain by another participant. ERC-2612, for example, defines a permit-style approval method for compatible tokens. The signing step can be separate from the transaction that applies the permission, and the mechanism includes parameters and replay-related protections.
A signature may feel less serious than a transaction because a wallet can display a “sign message” request instead of the familiar transaction-fee preview. That is a dangerous assumption. The effect depends on what the signed message authorises and on how the contract validates and uses it.
A term such as “gasless approval” may mean that somebody other than the signer submits and pays for the on-chain transaction. It does not mean the signed authority is harmless, nor that the action is unrelated to the blockchain. The application still has to map the signature to the correct owner, spender, amount, deadline and domain under its supported rules.
The article’s main distinction continues to apply: turning off a website connection does not automatically erase a cryptographically valid approval message already issued or change a contract’s accepted state. Some signatures have expiries or other constraints; those must be understood from the actual standard and contract.
Readers need not implement signatures to benefit from the lesson. Before signing unfamiliar structured data, ask whether it creates or delegates authority, whether it is intended for a single action or wider reuse, and which network and contract it concerns.
For specialised readers, the primary document is EIP-2612. Its details should not be generalised to tokens that do not implement the standard.
A paper exercise: close the webpage and follow the state
Draw a table with four columns: action, website connection, token allowance and remaining balance. Begin with a fictional balance of 100 ART and zero allowance. Alicia connects a website: the connection column changes, but allowance stays zero. She grants a 30-credit approval: allowance becomes 30 while balance remains 100.
The application successfully spends 10 ART through the approved mechanism. Under our deliberately ordinary token model, the remaining allowance is 20 and the balance is 90. Alicia now disconnects the website. The connection column becomes “disconnected,” but the allowance column remains 20.
Later, Tricia uses another 5 ART under the permitted route. Remaining allowance becomes 15, and balance becomes 85 in this fictional model. That event shows why a browser-only action cannot be assumed to change an independently recorded contract capability.
Finally, Alicia sends a valid instruction setting the relevant allowance to zero, and the network includes it. The table now shows “disconnected” and “zero allowance.” Historical spending entries remain in the event ledger. No one needs to erase them to describe current permission accurately.
Ask students which action required a private-key-authorised state change, which action affected the webpage only, and which result could be checked from the contract’s state. Also ask whether the exercise proves the spender’s real-world identity or the trustworthiness of a marketplace. It does not.
This is a stronger lesson than simply memorising that allowances are risky. Students see exactly how a small, persistent quantity links one action to the next and why user-interface state is not the same as blockchain state.
What if the spender contract is later upgraded?
Some application architectures route user interaction through contracts whose behaviour or implementation can change under specified administrative controls. Whether a particular spender can change depends on its actual design, ownership, governance and permissions. A user should not assume that the code associated with a familiar address will always have identical behaviour.
Consider the fictional art club’s purchasing contract. The club initially approves a set of suppliers. Later, management changes the processing rules within the authority allowed by the system. A standing allowance may continue to point to the same spender address even though the operational risks associated with that address have changed.
This does not mean every smart contract is upgradeable, or that every upgrade is malicious. It means that a useful approval review includes the question of who controls the spender and what modifications they are empowered to make. Trust in a brand name is not a substitute for understanding control.
A broad unlimited approval may be especially important to reconsider where long-lived access and changing contract behaviour intersect. A limited allowance can reduce one form of exposure, but a compromised user key or a different kind of operator permission may introduce other risks.
A serious analysis should identify both what authority exists now and who can alter the mechanism that exercises it. For technical context, eduKateSG’s Smart-Contract Upgrades: Preserve Stored State and Its Meaning covers the distinct topic of upgradeable state.
A short consumer article need not audit bytecode. It should simply avoid telling readers that a contract address’s earlier reputation guarantees its future behaviour.
What revocation cannot undo
Revocation changes what can happen under the relevant permission after the new state is accepted. It does not reverse a transfer already completed under the old permission. If 12 ART were spent correctly and the remaining 28 were later set to zero, the original 12-credit movement remains a recorded historical event.
Nor does revocation necessarily recover a stolen asset. If an attacker already moved value out of an account, removing that spender’s future ability is a different protective step. Recovery of funds or resolution of a dispute depends on network rules, custody, contractual obligations and sometimes institutions outside the chain.
A token approval can also be just one of several authorities over an account or contract. A user may have granted permissions under multiple token contracts, multiple networks or additional delegation systems. Changing one allowance does not imply that all other rights have been cancelled.
The timing of transactions also matters. A revocation submitted late may not precede another already-pending authorised operation. Ordering, inclusion and finality must be checked before claiming the permission was disabled at a specific moment.
That is why a truthful statement is narrow: “This specified token-spender allowance now reads zero at the verified network state,” rather than “My account is completely safe forever.” The latter claim cannot be established from one approval result.
The broader principle is familiar from other security systems. Cancelling one access badge does not erase what happened during the period the badge worked, and it does not automatically cancel every other key issued to the same building.
How to check permissions without following an unknown link
Start by identifying the exact network, asset contract and account. For ERC-20-style allowances, the relation involves owner, spender and token contract. A token symbol alone is not enough because multiple contracts can display the same name and icon, and equivalent addresses can appear on different chains.
Use a trusted wallet’s official security or permission-management documentation, or a reputable network-specific explorer reached through a separately verified source. Treat any “urgent revoke” link arriving through a private message, advertisement or search-result imitation with caution. A phishing site can use an approval panic to ask for a more dangerous signature.
For public read-only checks, a private key or recovery phrase should not be necessary. Where the service offers to submit a revocation, inspect the specific network transaction and associated fee before authorising it. A result labelled “submitted” is not equivalent to a confirmed, applicable state change.
When a checker lists permissions, note the token, spender, amount and network. Be aware that different checkers may support different token standards, discover different authorisations or use indexing methods that lag behind. If a result is ambiguous, avoid claiming all permissions are absent.
A security review also considers the user’s device and account key. If the key itself is compromised, merely revoking one spender’s allowance may not solve the threat. That problem requires a different recovery and custody analysis.
For broader context, read Ethereum Security and Scam Prevention and How Blockchain Technology Works | Why a Wallet Password Is Not a Recovery Phrase. They cover different layers of the same overall user-safety problem.
Why the word “permission” can become confusing
An approval confirmation window may use words such as permission, allowance, authorisation, access, spender, operator, session or signature. Those terms are related but do not necessarily refer to identical mechanisms. The reader’s task is to identify the exact capability.
A connection permission may let a webpage see an account address. A token allowance may let an on-chain spender move a specified type of token. A session key may permit selected operations under an application-specific policy. A wallet’s local password may protect access to locally stored signing material. One checkbox cannot replace the definitions of all those systems.
This matters when support staff tell a worried customer to “disconnect and reconnect.” Such a step may resolve a wallet interface problem, but it does not diagnose the active allowance. Likewise, resetting a website password does not generally change a public token contract’s spender-authorisation mapping.
Students can make a useful diagram with five boxes: webpage, wallet interface, signing authority, token contract and asset owner. Draw arrows for “can view,” “can propose a transaction,” “can sign” and “can move approved tokens.” The arrows do not all have the same meaning or duration.
If you are explaining the issue to a parent, avoid jargon at first. Say that closing a shop’s webpage may be like leaving a building, while an authorised payment instruction can remain on record. Then introduce the actual technical terms once the distinction is clear.
Good digital literacy is not just recognising security words. It is asking precisely who can do what, for how much, until when and on whose authority.
Ten claims to test before believing a security explanation
“Disconnecting a website removes every approval.” False as a general rule. Website connection state and recorded token allowances are separate; a valid on-chain change is generally required to change an ordinary allowance.
“An approval instantly sends my entire balance.” Not necessarily. approve establishes an allowance under the token’s rules; transferFrom or another supported mechanism may later move tokens. The distinction is important even when the authorisation is unsafe.
“An unlimited approval is always a scam.” Not every broad approval comes from a malicious application. Some legitimate designs use it for convenience. But it increases potential scope, so it deserves careful scrutiny.
“A zero allowance makes every asset safe.” It only addresses that particular authority under the relevant mechanism. Other permissions, contracts, networks and key compromise must be considered separately.
“The website’s display name identifies the spender.” The exact spender address and token contract matter. A brand label or logo is not an independent on-chain identity guarantee.
“I can revoke without any network effect.” An accepted on-chain change normally needs an authorised operation and may incur network fees. The user must distinguish intention to revoke from confirmed revocation.
“A past approval event proves access is still active.” Not necessarily. Later accepted changes can alter current allowance without erasing the old event from history.
“A signed message is always harmless.” Some signatures authorise actions with real consequences when submitted or interpreted by compatible contracts. Their exact content and verification scope matter.
“Revoking reverses a completed transfer.” No. Changing future authority does not automatically unwind earlier accepted effects.
“All token contracts use the same permission model.” Different standards and implementations can have different approval and operator mechanisms. Each claim needs the correct chain and code context.
A good safety explanation replaces each slogan with an observable field, a network rule or a carefully defined limit. That makes it teachable and verifiable.
A decision worksheet for cautious readers
First identify the thing you mean to do. Are you reading a website, connecting an account, signing a message, making an ordinary transfer or granting an allowance to a spender? Do not approve a state-changing or authorisation action merely to view public information.
If an approval is involved, write down the intended token and network, the spender’s full identity as represented on-chain, the authorised amount and the purpose of the permission. Compare it with the actual action requested. Does the request exceed the intended scope? Is the spender the correct party? Does the operation have an expiry or other limitation under the implementation?
Next, consider when the interaction is over. Is a standing permission still necessary? Is the system expected to reuse it for future operations? Who controls the spender contract? Can the user verify the current allowance and understand how to reduce it using official software if that is appropriate?
After any permission change, inspect the accepted result rather than relying solely on a button label. Remember that historical approvals and transfers may remain visible. Do not claim that deleting an app has erased network state.
Finally, distinguish the risks you can control from those requiring a different investigation: a compromised device, stolen seed phrase, fraudulent website, upgradeable spender or incorrect token identity. A single “revoke” action cannot solve every security problem.
This worksheet is for understanding, not a direction to perform live financial operations. For classroom use, practise with imaginary permissions, paper records and non-sensitive examples. Knowing what the screen means is valuable even if you never interact with a token.
Frequently asked questions
Does disconnecting my wallet cancel token approvals?
Not as a general rule. Disconnecting affects the wallet–website connection, whereas a recorded allowance is contract state under a particular token and network. The relevant permission must be checked and, if appropriate, changed through its supported mechanism.
What does ERC-20 approve actually do?
In the standard model, approve(spender, value) permits the spender to withdraw up to the specified amount from the owner’s token balance using the supported mechanism. It does not necessarily move that amount immediately.
What is the difference between a wallet connection and an allowance?
A wallet connection gives a site certain interface access or ability to request actions. An allowance gives an on-chain spender authority under a token contract’s rules. They have different lifetimes and are controlled in different places.
Why would an application request an unlimited amount?
Some applications request broad allowances to avoid repeat approval transactions and their friction or fees. That convenience may increase potential loss if the spender is compromised or malicious. The scope should match the user’s intent and risk tolerance.
Can I have several token approvals at once?
Yes. Different owner–token–spender relations and separate networks can have distinct permissions. Some NFT or advanced account systems also use other operator mechanisms. Checking one relation is not the same as checking every capability.
Does revocation cost a network fee?
It can. A state-changing Ethereum transaction generally consumes gas. The exact mechanism and cost depend on the contract and network. A webpage’s submitted status is not final proof that the allowance has changed.
Can the spender use an allowance after I delete my wallet app?
Removing the interface does not automatically change contract state. Whether the spender can act depends on the current allowance, balances and actual contract rules, not whether the owner still has the wallet installed.
Does a revocation undo a previous unwanted transfer?
Not automatically. A change to future authority does not erase an earlier accepted transfer. The incident may require a separate security, custody or legal investigation.
Do all token approvals work like ERC-20?
No. Other standards, NFTs, smart accounts and signature-based approvals can use different fields and rules. Name the specific token contract and mechanism before explaining its scope.
Is an approval checker that asks for a recovery phrase safe?
No ordinary read-only public allowance lookup needs your recovery phrase or private key. Treat such requests as a warning and rely on trusted official documentation. Never paste secret credentials into a site to inspect public blockchain state.
What if the app says “revoked” but another explorer disagrees?
Compare the same chain, token, spender, owner, block state and permission method. One site may be delayed or may display historical events rather than current state. The original Two Block Explorers guide explains why displays may differ.
What is the key idea for a parent or beginner?
A browser session is temporary, but a digital permission can live in a shared network record beyond that session. Always distinguish “I stopped using the website” from “the permission to act was actually removed.”
Primary sources and your next reading route
EIP-20: ERC-20 Token Standard defines the core allowance interface used in this explanation. EIP-2612 shows how permit-style signatures can provide an alternative authorisation route for compatible tokens. These standards describe mechanisms and assumptions; they do not independently certify any application’s safety.
The MetaMask guidance on managing dapp permissions, token approvals and revoking allowances explains the distinction as a user-facing wallet workflow. The exact menu arrangement can change, so use current official documentation rather than outdated screenshots.
Within eduKateSG, the technical reference Token Approvals: Track Remaining Permission studies the ledger model in greater depth. Read Why Network Fees Change to understand why an accepted permission change consumes resources, and Why a Wallet Password Is Not a Recovery Phrase for a separate account-security distinction.
The clearest conclusion is also the simplest: disconnecting closes a website connection; revoking changes the authority that a contract recognises. Do not confuse a quiet screen with a changed network permission.