Did you know?
An ERC-20 allowance is stored by the token contract. Closing a browser, disconnecting a wallet or deleting a website does not necessarily revoke the allowance.
Alicia authorises a school supplies desk to spend up to ten ART credits. The desk closes its website, but the signed permission remains in the club ledger until changed under its rules.
Blockchain systems can make a narrow operation independently checkable without proving every surrounding organisational claim. This article follows the evidence from the initial instruction to the final accepted outcome. It uses fictional classroom credits rather than real funds.
Quick answer
An ERC-20 allowance is stored by the token contract. Closing a browser, disconnecting a wallet or deleting a website does not necessarily revoke the allowance. The key is to identify the exact network, contract, authorised actor, current state and result. A successful preliminary step does not necessarily complete the wider process.
What happens first?
Alicia authorises a school supplies desk to spend up to ten ART credits. The desk closes its website, but the signed permission remains in the club ledger until changed under its rules. The important starting point is the rulebook: which accounts can act, what must they authorise and what data are submitted? A label in a wallet interface cannot replace those underlying rules.
What does the blockchain verify?
A blockchain verifies the applicable signatures, contract conditions and state transitions under its protocol. It does not automatically verify a signer’s real-world independence, the truth of a merchant’s claims or the enforceability of every off-chain promise. That boundary is essential to understanding why a token approval can outlive the website.
Where the misunderstanding begins
An ERC-20 allowance is stored by the token contract. Closing a browser, disconnecting a wallet or deleting a website does not necessarily revoke the allowance. Readers often move from a true narrow fact to a broad guarantee. Instead, write the exact claim beside the evidence that supports it. If an outside institution, service or human decision is involved, identify that dependency separately.
The technical mechanism
Explain allowances, spender addresses, infinite approvals, permit signatures, revocation, transaction costs and malicious lookalike interfaces. The precise behaviour depends on the deployed implementation, chain and current permissions. A reviewer should inspect accepted contract state and actual transaction outcomes rather than relying on a promotional screenshot.
Why identity and authority matter
An address identifies a cryptographic account or contract in a network context. It does not independently establish who controls every relevant key, which institution stands behind a service or whether multiple apparent participants are genuinely independent. Legal and operational responsibilities need their own evidence.
What a successful transaction does not prove
A transaction receipt can demonstrate a particular accepted execution under the network’s rules. It cannot guarantee future performance, business solvency, delivery of goods or that an external system has performed a corresponding action. The relevant end state must be checked separately.
What happens when a step fails?
A request may be rejected before submission, revert during execution, wait for a later authorised operation or remain incomplete because another service has not acted. Those states should not be conflated. A clear interface explains which condition remains unmet and what evidence is available.
Why governance remains important
Smart contracts can restrict who acts and when, but governance determines policies, participant selection, emergency response and how real-world obligations are handled. Concentrating authority or leaving critical responsibilities unspecified can undermine the value of technically correct controls.
What the school-club example teaches
Alicia authorises a school supplies desk to spend up to ten ART credits. The desk closes its website, but the signed permission remains in the club ledger until changed under its rules. Now ask the class to identify the recorded action, the authorised decision-maker, the rule that permits it and the actual completed result. A correct ledger entry should never be used to imply a second action happened unless there is evidence for that action.
How to evaluate a claim
First identify the exact chain and contract. Next check the current permissions and any related contracts. Then distinguish signed intent from successful execution. Finally examine whether any external party must deliver, redeem, confirm or administer the result. Each question addresses a separate possible failure.
Common misconception: the technology guarantees everything
Cryptographic verification can be strong while the initial data, business rules or real-world representation are incomplete. A genuine on-chain event should be described accurately rather than stretched into a universal safety guarantee.
A classroom worksheet
Draw four columns headed Claim, Evidence, Responsible Party and Remaining Condition. Use the fictional school example. Enter the initial request in the first row and each later approval or execution as a separate row. Mark an outcome complete only when its actual condition is met. Repeat with one missing signature, one delayed service and one incorrect assumption about authority.
Seven questions worth asking
Which exact contract is involved? Who controls the relevant keys or roles? What permission is being exercised? What event or transaction has actually occurred? Which later step remains? Can another actor change the rules? What outside evidence is needed to establish the promised benefit? These questions expose the difference between a valid digital record and a complete trustworthy process.
Frequently asked questions
Is the blockchain record itself necessarily wrong?
No. A record can be correct while the conclusion someone draws from it is too broad.
Can the system be secure and still fail users?
Yes. External dependencies, misleading rights descriptions and operational failures can matter even when consensus works correctly.
Does a signature prove a real person’s identity?
Not by itself. It supports a claim about cryptographic authority under a defined key and message.
Can governance change the outcome?
Only within the actual permissions, upgrade mechanisms and legal arrangements available to it.
Is an audit a guarantee?
No. An audit addresses specified code and assumptions at a particular time.
What is the main lesson?
An ERC-20 allowance is stored by the token contract. Closing a browser, disconnecting a wallet or deleting a website does not necessarily revoke the allowance.
Sources and connected reading
The primary technical reference is the relevant protocol documentation. For deeper explanations in eduKateSG, see Why Multisignature Wallets Still Need Security Rules, Why Disconnecting a Website Does Not Revoke Token Approvals, What a Blockchain Bridge Does and Does Not Guarantee, Why a DAO Vote Does Not Automatically Execute a Proposal. Each addresses a related distinction between cryptographic evidence, permission, execution and outside responsibility.