Token Approvals in Crypto: Allowances, Unlimited Spending, Permit2, and How to Revoke Safely

Token approvals are permissions that let another Ethereum address—usually a smart contract—move a specified amount of an ERC-20 token from your wallet. The mechanism is part of the ERC-20 standard itself: the official ERC-20 specification defines approve(spender, value), allowance(owner, spender), and transferFrom(from, to, value). That combination is what lets a decentralized exchange, lending market, bridge, staking app, or other contract use tokens that remain in your wallet until the application actually needs to transfer them.

The security problem is that an approval can remain valid after you close the website, disconnect the wallet, or forget the interaction. If the approved spender is malicious or later becomes compromised, the remaining allowance may still be usable. A token approval is therefore not merely a one-time confirmation screen. It is an onchain authorization state that deserves the same attention as other wallet permissions.

Key takeaways

• Connecting a wallet to a dapp and approving token spending are different actions.
• Disconnecting a wallet from a website does not revoke ERC-20 allowances already recorded onchain.
• An approval identifies three things that matter: the token contract, your wallet, and the spender address.
• The allowance amount is a cap, not necessarily an immediate transfer.
• Unlimited approvals reduce repeated approval transactions but increase the value of a compromised spender.
• Revoking an ERC-20 allowance normally means submitting another onchain transaction that reduces the allowance, often to zero.
• EIP-2612 permit can create or change an allowance from a signed message, while Permit2 introduces another permission layer with signature-based and time-bounded flows.
• A hardware wallet protects the signing key; it does not make a dangerous approval safe after you authorize it.
• Review approvals by network and contract address, not only by dapp name or token ticker.
• If a suspicious approval is still unused, revoking it quickly can reduce risk; revocation cannot reverse tokens that have already been transferred away.

How the ERC-20 approval model works

The standard ERC-20 flow separates ownership from delegated spending.

Imagine Alice owns 1,000 USDC and wants to deposit 250 USDC into a DeFi protocol. The protocol cannot simply take the tokens because Alice owns them. A common two-step flow is:

1. Alice calls the USDC token contract and approves the protocol’s spender address.
2. The protocol later calls transferFrom to move up to the authorized amount.

If Alice approves exactly 250 USDC and the application transfers all 250, the remaining allowance should be exhausted under the token’s implementation. If she approves 1,000 USDC and only 250 is spent, a remaining allowance may still exist.

The approval is stored by the token contract, not by the website. Closing a browser tab does not erase it.

This distinction is especially important for smart-wallet users. BTC-Pulse’s smart contract wallet guide explains how authorization can become programmable through ERC-4337 or delegated account logic. Token allowances are another layer: the wallet may have sophisticated owner rules while still granting a separate token contract permission to a spender.

Approval is not the same as a transfer

An approval changes permission. A transfer changes token ownership.

Suppose a wallet contains 10,000 units of Token X and approves Router Y for 2,000. Immediately after the approval:

• the wallet still owns the 10,000 tokens;
• Router Y has an allowance of up to 2,000;
• no 2,000-token transfer has necessarily occurred.

If Router Y later uses transferFrom for 600 tokens, the remaining allowance may become 1,400, depending on the token implementation.

This matters during incident response. Seeing an Approval event does not prove the funds were stolen. Seeing a later Transfer or successful transferFrom is a separate event.

It also matters when a wallet shows a frighteningly large spending cap. The displayed amount represents permission scope, not necessarily money already moved.

Why apps ask for large or unlimited approvals

Repeated approvals cost gas and add friction. A user who swaps the same token every week may not want to authorize the router every time.

Many applications therefore request a very large allowance, sometimes effectively unlimited. In Solidity, implementations often represent an unlimited approval with the maximum uint256 value.

Benefits:

• one approval can support many future actions;
• fewer approval transactions mean less gas;
• application flows can feel simpler.

The downside is persistent authority. If the spender is exploitable, upgraded maliciously, hijacked through governance, or simply the wrong contract, the authorization can expose much more than the amount the user intended to spend in one session.

The best approval amount is not always “exact amount” and not always “unlimited.” It is a threat-model decision. A frequently used, well-understood contract may justify a larger cap for some users. An unfamiliar dapp should not receive broad authority merely because the interface defaults to it.

Disconnecting a wallet does not revoke approvals

A wallet connection typically lets a site see your public address, request signatures, and ask your wallet to submit transactions. Disconnecting ends that interactive relationship in the wallet interface.

It does not rewrite ERC-20 state.

MetaMask’s disconnect guidance explicitly distinguishes disconnecting from revoking: an existing token approval can remain active even after a dapp has been disconnected.

The practical rule is:

disconnect = stop the website session

revoke = change the token permission onchain

If you suspect a malicious approval, disconnecting the site is sensible, but it is not the complete remediation step.

What revoking actually does

For ordinary ERC-20 allowances, revocation is generally another transaction that changes the spender’s allowance, commonly to zero. Because it changes blockchain state, it costs network gas.

MetaMask’s revocation guide notes that users can review allowances through supported wallet tools or network block explorers and submit a revocation transaction.

A successful revocation affects future use of the allowance. It does not:

• recover tokens already transferred;
• reverse an earlier swap;
• remove a malicious contract from the blockchain;
• cancel permissions on another network;
• necessarily invalidate a separate signature-based permission system.

That last point becomes important with permit and Permit2.

An ordinary approve(spender, 0) does not, by itself, invalidate an outstanding EIP-2612 signature: it normally does not advance the permit nonce. If the signed nonce is still current and the deadline has not passed, anyone holding that signature can submit it and restore the signed allowance. EIP-2612 does not require a dedicated nonce-cancellation function. Use only the token’s verified cancellation mechanism, if available, or a successfully submitted replacement permit using the same current nonce; competing submissions can still race. The permit deadline limits submission, not the lifetime of the resulting ERC-20 allowance.

EIP-2612 permit: approval by signature

The EIP-2612 specification extends ERC-20 with a permit function. Instead of the token owner directly sending an approve transaction, the owner signs structured data containing fields such as the spender, amount, nonce, and deadline. Another party can submit that signature onchain.

This improves user experience because the approval and the application action can often be bundled or relayed.

It also changes what a user should recognize as dangerous. A request can create spending authority even when the wallet is asking for a signature rather than an obvious onchain approval transaction.

EIP-2612 includes a nonce for replay protection and a deadline that can limit how long the permit is usable. If the deadline is effectively unlimited, the authorization window can be long.

The practical lesson is not “signatures are unsafe.” It is that “this is only a signature” is not a security argument. Read what the signature authorizes.

Permit2 adds another permission layer

Uniswap’s Permit2 documentation describes two major components:

• SignatureTransfer, for one-time signature-based transfers;
• AllowanceTransfer, for token allowances with specified amounts and durations.

Permit2 can reduce repeated approvals across compatible applications. Typically, a token first grants an ERC-20 approval to the Permit2 contract; after that, signed Permit2 permissions can authorize specific spenders under Permit2’s rules.

This creates two layers to understand:

1. token contract → Permit2 allowance;
2. Permit2 → application/spender permission.

If a user is investigating risk, checking only one layer may be incomplete.

A malicious signature can also be dangerous even though the signature itself is not an ordinary ERC-20 approve transaction. MetaMask’s current signature-phishing guidance discusses Permit2 because attackers can try to obtain signed permissions rather than asking for the victim’s seed phrase.

AllowanceTransfer stores a reusable allowance inside Permit2, indexed by owner, token and spender, with amount, expiration and nonce. It can be set by an onchain Permit2 approve or a signed permit. SignatureTransfer does not create that standing spender allowance: it consumes a one-use signed authorization during the transfer. Both flows still require sufficient token→Permit2 ERC-20 approval. A one-use signature can remain usable until its deadline if its nonce is not spent or invalidated.

For Permit2 AllowanceTransfer, reducing an allowance or calling lockdown does not itself invalidate outstanding permit signatures. invalidateNonces(token, spender, newNonce) advances that permission’s nonce; it does not itself clear an existing allowance. SignatureTransfer uses a separate unordered nonce bitmap: invalidateUnorderedNonces(wordPos, mask) invalidates selected nonce bits. Revoking token→Permit2 approval blocks token transfers while that approval remains zero, but does not erase Permit2 state or signed messages; restoring it can re-expose still-valid permissions.

A practical permission map

The table is deliberately architectural. Exact wallet buttons and supported networks change over time.

Approval risk is scoped by token and network

An ERC-20 allowance belongs to a specific token contract on a specific chain.

Approving a spender for USDC on Ethereum does not automatically approve that spender for USDC on Base or Polygon. Approving one token does not authorize every token in the wallet.

That scoping is useful, but it creates another source of mistakes: users may look at the right ticker on the wrong network.

BTC-Pulse’s USDC vs USDC.e guide explains why native and bridged token contracts can represent economically similar assets while still being different onchain tokens. When reviewing approvals, the exact token contract matters for the same reason.

Worked example: exact approval vs unlimited approval

Assume a wallet owns 5,000 Token A and wants to deposit 400 into Protocol B. Assume an ordinary implementation that reduces finite allowances on spending, with no later approval or permit changes.

Option 1: exact approval

The user approves Protocol B for 400.

If the protocol spends the full 400, there may be no remaining allowance.

Exposure from that authorization is bounded near the intended amount, although the transaction can still fail or the approved contract can still behave badly within that scope.

Option 2: approval for 5,000

The user approves the full current balance.

Protocol B deposits 400, leaving a potential 4,600 allowance.

If the wallet later receives another 3,000 Token A, the spender’s remaining authorization does not automatically become 7,600; it remains whatever allowance is stored. But the existing 4,600 can still matter even if the user forgot the original deposit.

Option 3: effectively unlimited approval

The wallet grants a very large allowance.

The user deposits 400 today and returns months later. If the spender remains authorized, future Token A balances can be exposed up to the allowance.

This is the operational reason stale approvals deserve periodic review.

Decision tree: should you revoke an approval?

1. Do you recognize the spender?

If no, verify the contract address independently. A familiar dapp name in a wallet interface is not enough.

If yes, continue.

2. Do you still use the application?

If no, revoking unnecessary permissions reduces attack surface.

If yes, continue.

3. Is the allowance much larger than your expected use?

If yes, consider reducing the cap if the token and wallet workflow support it.

If no, the permission may already be appropriately scoped.

4. Is the spender upgradeable or controlled by governance?

If yes, you are trusting not only the current code but also the mechanism that can change it.

5. Is this an ERC-20 approval, Permit2 permission, or another signature scheme?

Identify the layer before assuming one revoke action covers everything.

6. Has the contract suffered an incident?

If yes, follow the project’s verified incident instructions and independently verify the spender address before signing a revocation.

How to audit approvals safely

A practical review process looks like this:

1. Choose the network you actually use.
2. Open a trusted approval viewer, wallet portfolio, or official block explorer.
3. Verify your own public address.
4. Review token, spender address, allowance amount, and last interaction.
5. Flag unknown or obsolete spenders.
6. Revoke or reduce permissions one at a time.
7. Verify the revocation transaction on the block explorer.
8. Repeat on other networks where the wallet has been active.

Etherscan’s token approval checker is one example for Ethereum. BscScan and other explorers provide similar tools for their networks. Wallets can also integrate approval management directly.

Do not enter a seed phrase or private key into an approval checker. A legitimate checker only needs the public wallet address and, for a revocation, a normal wallet signature/transaction flow.

Common mistakes

“I disconnected the site, so it cannot spend anymore”

False. Disconnecting does not erase an existing allowance.

“A hardware wallet prevents approval exploits”

A hardware wallet can protect the private key from extraction. If the user intentionally signs a harmful approval, the hardware device faithfully authorizes it.

“Revoking one token protects the whole wallet”

Approvals are scoped. Other tokens, NFT operators, chains, Permit2 permissions, or smart-wallet modules can remain active.

“Approval means funds already moved”

No. Approval establishes authority; transferFrom or another spending action moves tokens.

“Zero allowance means there is no other permission”

It means the checked ERC-20 allowance is zero. It does not prove there is no NFT operator approval, Permit2 permission, smart-wallet session key, or other authorization.

Edge cases

Upgradeable spenders

A contract may be safe today while its implementation can be upgraded tomorrow. Review who controls upgrades, timelocks, and governance.

Proxy addresses

The spender shown in an allowance may be a proxy rather than the implementation contract. Checking only the implementation address can therefore miss the actual approved spender.

Tokens with non-standard behavior

ERC-20 is a standard, but deployed tokens can differ in implementation details. Do not assume every token handles allowance changes identically.

Changing an existing non-zero allowance to another non-zero value with approve can race with spending: the spender may use the old allowance before replacement, then spend the new one. EIP-20 recommends interfaces set the allowance to zero before setting a new value for the same spender. Confirm the zeroing transaction and re-check token state before granting a new cap; this does not undo earlier spending or guarantee your revocation wins the race. Some deployed tokens, such as USDT, require a zero reset for non-zero replacements, and some return no boolean value. Check the token’s implementation rather than assuming a standard wallet flow will work.

Pending malicious transactions

If an attacker already submitted a transaction using your allowance, revocation and the attacker’s transfer can compete for inclusion. There is no guarantee the revoke confirms first.

Smart wallets

A smart wallet may have internal spending policies in addition to token allowances. Revoking an ERC-20 approval does not necessarily disable a wallet module or session key.

A simple approval hygiene policy

For an active DeFi wallet:

• use a separate account for experimental dapps where practical;
• approve only the amount or duration you actually need when the interface supports it;
• verify spender addresses for unfamiliar applications;
• review stale allowances periodically;
• treat signature requests as potentially meaningful permissions;
• revoke after one-off interactions if keeping the approval provides no benefit;
• keep long-term reserves away from accounts that accumulate broad dapp permissions.

This is risk reduction, not a promise of safety. Smart-contract vulnerabilities, compromised frontends, malicious signatures, and wallet-owner mistakes can still cause losses.

FAQ

What is a token approval?

It is an authorization recorded by a token contract—or created through a supported permission system—that lets a spender move a specified amount of tokens on the owner’s behalf.

Does revoking token approvals cost gas?

For ordinary onchain ERC-20 revocations, yes. You are submitting a transaction that changes contract state.

Should I revoke every approval after every swap?

Not necessarily. Exact best practice depends on transaction frequency, gas cost, wallet value, and the contract’s risk. Unused broad approvals are the clearest candidates for removal.

Can an unlimited approval drain future deposits?

If the spender retains a sufficiently large allowance and later becomes malicious or compromised, newly received tokens of that approved contract can remain exposed up to the stored allowance.

Is Permit2 safer than normal approvals?

It offers useful controls such as signature-based transfers and time-bounded allowances, but it creates a different authorization model. Safety depends on what the user signs and which spender receives permission.

BTC-Pulse Take

Token approvals are one of the most important examples of the difference between wallet ownership and wallet authorization. You can keep your seed phrase offline, use a hardware wallet, and still expose tokens by granting a contract permission to spend them.

Check both recorded allowances and outstanding signed authorizations: authority can reside in the token contract, in Permit2 state, or in an unsubmitted signature. Check the token, network, spender, amount, duration and permission layer.

For frequently used protocols, approvals can be a reasonable usability trade-off. For one-off or unfamiliar interactions, narrower and shorter authority is usually easier to defend.

This article is educational and does not provide financial or security guarantees.

Sources

• Ethereum Improvement Proposals — ERC-20 Token Standard
• Ethereum Improvement Proposals — ERC-2612 Permit Extension
• Uniswap Developers — Permit2 Overview
• MetaMask Help Center — What is a token approval?
• MetaMask Help Center — How to revoke allowances/token approvals
• MetaMask Help Center — How to disconnect a wallet from a dapp

• Etherscan — Token Approval Checker

• Uniswap Permit2 — AllowanceTransfer implementation

• Uniswap Permit2 — SignatureTransfer implementation