CrowdSent Blog Team · 10 October 2026 · Blockchain literacy
A token approval gives another address permission to spend a defined amount of a particular token on an owner’s behalf. In the common ERC-20 model, that permission is an allowance recorded by the token contract. It is separate from the owner’s balance and from the transaction that later moves tokens.
This distinction explains why an approval can succeed without completing a swap or deposit. It also explains why closing a website does not necessarily remove its contract’s spending permission. The permission exists in a ledger, not just in the browser session.
The examples below use fictional token and address labels. No live approval, wallet connection or signature is needed. The aim is to understand what a request authorizes and what the resulting record proves, including the important differences among standard allowances, permit signatures and NFT operators.
Read a token approval as a specific permission
A basic ERC-20 allowance has an owner, a spender and an amount within one token contract. The network is part of its context. “App X has permission” is shorthand; the operative spender is an address, which may be a contract or another account.
The ERC-20 specification defines approve, allowance and transferFrom. In the standard model, approve sets the amount a spender may use, allowance reports the remaining permission, and transferFrom is the mechanism for an authorized transfer on another owner’s behalf.
Read an invented permission as: “On Chain A, Token T records that Spender S may spend up to 120 displayed token units belonging to Owner O.” It does not grant the same permission for Token U, a different owner or a different network merely because the app displays them together.
The transaction’s destination can be the token contract even though the spender is a different address encoded inside the request. A review that looks only at the destination field can therefore miss who receives the spending authority. The exact function and arguments matter.
Balance and allowance move independently
Start with Owner O holding 300 Example Tokens and no allowance for Spender S. Assume a conventional implementation, finite allowances that decrease when used, no transfer fees and no other activity. These assumptions make the arithmetic explicit.
After a successful approval of 120, the balance remains 300 and the allowance becomes 120. No Example Tokens have moved merely because the permission was set. The owner may separately pay a network execution fee in the relevant fee asset.
Now S makes a permitted transfer of 70 Example Tokens. The owner’s balance falls to 230, and the remaining allowance falls to 50. If a later unrelated payment brings 20 tokens into the owner’s account, the balance rises to 250 while the allowance remains 50.
Finally, suppose a successful revocation sets the allowance to zero before any further spend. The token balance stays 250. The earlier transfer of 70 is not reversed. Revocation changes future permission under this model; it is not a refund or an undo command.
The sequence has two separate columns: balance 300 → 300 → 230 → 250 → 250, and allowance 0 → 120 → 50 → 50 → 0. Keeping them apart makes it clear why an approval amount should not be subtracted from the balance as if it were a completed payment.
A spending cap is a quantity, not a price guarantee
An allowance is normally stated in token units. It does not establish the dollar value of the authorized amount, a minimum amount received in a swap or the quality of the application that will use it. Those depend on different instructions and conditions.
Wallet interfaces may display a human-readable spending cap. MetaMask’s spending-cap explanation describes token-specific permissions. Its interface is an example; the authoritative amount is the value accepted by the particular token contract.
For a token with six decimals, 120 displayed units corresponds to 120,000,000 raw units. A raw request for 120 would instead represent 0.000120 displayed units under that scale. Check the token’s actual decimal definition rather than assuming all assets use the same one.
“Unlimited” usually means a very large allowance rather than permission to create tokens from nothing. OpenZeppelin’s ERC-20 implementation reference describes a maximum-integer allowance that is not reduced by transferFrom. Other implementations can differ.
A continuing allowance can also matter for tokens received later. If the current balance is zero but the permission remains active, an incoming balance may become spendable under that permission. A screenshot of an empty account does not establish that every outstanding authorization has expired.
Connecting and disconnecting change a different relationship
A basic wallet connection lets a site interact with the wallet interface under granted connection permissions. It does not, by itself, create a standard ERC-20 allowance. Modern wallets can expose additional permission systems, so the actual request still needs to be read rather than classified solely by a button label.
MetaMask’s disconnect documentation explicitly distinguishes disconnecting from revoking token approvals. Removing a website connection does not inherently send a transaction that changes the token contract’s allowance.
In the worked example, closing the tab after approving 120 would leave the recorded allowance at 120 until it was used or otherwise changed. The website’s current visibility and the spender’s on-chain permission are different facts.
Likewise, changing a local app password does not rewrite the allowance. A permission inventory should identify the network, owner, token and spender instead of relying on the list of websites currently shown as connected.
A signature can authorize spending-related changes
Some tokens support ERC-2612 permit, which allows a signed message to authorize an allowance change that can later be submitted on-chain. The owner need not personally submit the ordinary approval transaction. Someone still submits a transaction to use the permit, and the signature can have real consequences.
The ERC-2612 specification includes an owner, spender, value, nonce and deadline within its authorization design. The deadline limits when the permit can be accepted. It does not automatically make the resulting standard ERC-20 allowance expire at that time.
For a fictional example, a permit signed today may be submitted before tomorrow’s deadline and establish an allowance that remains afterward. A reader who interprets “deadline tomorrow” as “spending permission disappears tomorrow” would be describing the wrong condition.
A zero current allowance also does not necessarily invalidate every outstanding signed permit. The signature’s nonce, deadline and relevant contract behavior matter. An unused valid authorization could affect a later state. This is why checking one allowance value and examining outstanding signatures are related but distinct questions.
Never put a usable signed authorization in a public research note. A signature can be actionable without revealing the private key. Use labels and invented values to explain the format.
Permit2 adds a separate permission layer
Permit2 is a separate contract system, rather than the ERC-2612 extension implemented inside a token. Its documented flows depend on the token first allowing Permit2 to transfer the owner’s tokens. Permissions for an application through Permit2 are another layer.
The Permit2 overview distinguishes single-use signature transfers from reusable allowance transfers. Its allowance-transfer documentation describes a separate expiration field for its time-bounded allowances.
Draw this as two records: Token T permits Permit2, and Permit2 permits Application S under specified conditions. An inspection that sees only the first record does not fully describe S’s current permission. Conversely, removing one application-level allowance need not erase the underlying token approval to Permit2.
This layered example shows why “revoke everything” is an imprecise technical description. Identify which permission, contract and network the operation changes. Other signature or smart-account schemes have their own rules and should not be assumed to match either standard.
Revocation changes future authority when it takes effect
For an ordinary ERC-20 allowance, revocation commonly means setting the allowance for that spender to zero. It requires the relevant state change to be successfully included. A submitted request, a pending wallet screen or a disconnected site is not the final state.
MetaMask’s revocation guide explains the on-chain nature of this operation and its gas cost. The CrowdSent gas-fee guide provides the unit distinction between the token permission and execution fees.
Changing a nonzero allowance to another nonzero amount has an ordering issue described in ERC-20: the old allowance might be spent before the new value takes effect. In a simplified example, an existing 100-unit allowance is used first, then a replacement 50-unit allowance becomes available. The two actions could permit 150 units in total across that sequence.
Resetting to zero and checking its effect before establishing a new allowance can separate those stages, but it cannot retroactively prevent spending that happened before the reset. Do not describe a pending revocation as a guaranteed shield.
Historical Approval events are evidence of changes, not necessarily the current allowance. Later spending or another approval may have changed it. Match the read to the correct network, contract, owner, spender and block context.
NFT operator approval has a different scope
ERC-721 supports approval for a particular token identifier and a separate operator approval covering all of an owner’s NFTs within that contract. The ERC-721 specification distinguishes these functions.
An “approve all” request in that context should not be interpreted as a 120-unit ERC-20 allowance. It can cover current and future holdings in the specified NFT contract until changed. It also does not automatically mean every asset on every network. Permission scope needs the token standard and contract.
When an interface’s explanation conflicts with those details, pause the interpretation and verify the underlying request. The source-verification guide offers a useful discipline for checking a site’s claims. Familiar branding alone does not authenticate a spender address or its current code.
Frequently asked questions
1. Does approving 120 tokens transfer them immediately?
A basic approval sets permission. In the worked example, the balance stays 300 while the allowance becomes 120. A subsequent transfer changes the balance. Some interfaces bundle several operations, so inspect the actual request rather than its short label.
2. Can a spender use an allowance in several transfers?
A conventional finite allowance can be consumed across transfers until the remaining permission is exhausted or changed. The example’s 70-unit transfer leaves 50. The exact token implementation and any additional permission system determine the behavior.
3. Does a token approval give away the private key?
It grants a particular spending permission without disclosing the key. That can still be consequential. The ability to move approved tokens does not require learning the owner’s secret, so secrecy of the key alone does not neutralize an unwanted allowance.
4. Can an approval cover tokens received later?
Yes, when permission remains available under the applicable rules. A future incoming balance can be exposed to that authority. The current balance, allowance amount and duration are separate fields to inspect.
5. Does an ERC-20 approval authorize native ETH spending?
The standard allowance belongs to the named token contract. Native ETH does not use that ERC-20 allowance mechanism. Wrapped ETH is a token with its own contract. Separate smart-account permissions can have broader scope and require their own interpretation.
6. Is a gas-free signature harmless?
No. A signed permit can later authorize a state change, even if the owner pays no immediate network fee. Read the contract, spender, amount, nonce and time conditions. Whether a fee appears now does not determine the signature’s authority.
7. Does a permit deadline expire an allowance?
For ERC-2612, it limits acceptance of the permit. The allowance created through a valid permit has the token’s ordinary behavior. Permit2 allowance expiration is a separate field in a different system. Do not treat all displayed dates as the same condition.
8. Does revocation recover tokens already transferred?
No. A successful revocation changes the specified future permission. It does not reverse earlier completed transfers. Keep any investigation of past transfers separate from verification that the remaining allowance was changed.
9. Is the last Approval event enough to know current access?
Not always. Spending and later operations can alter the state, and implementations differ in which allowance changes emit events. Check the current applicable allowance and any additional permission layer at a defined block context.
10. Can approvals be studied without granting one?
Yes. Read standards, official documentation and public state using placeholder examples where possible. A basic literacy exercise does not require a live signature or disclosure of recovery material. Treat any request for those as a separate action needing its own purpose.
Prepared 10 October 2026. Examples are hypothetical and explain mechanisms rather than current market conditions. This article is educational and does not provide investment recommendations.