A swap can finish while the permission behind it remains active. Token approvals let a specified address spend tokens from your wallet, within the authority you grant. Closing the application does not necessarily remove that authority.
This guide focuses on ERC-20 tokens on Ethereum and other EVM networks. Other token standards and blockchains use different permission systems. The practical task is to understand the spender, the amount and the scope before approving, then remove permissions you no longer need.
An allowance is a spending limit attached to a spender
In the usual ERC-20 workflow, approve sets an allowance, allowance reports the remaining amount, and transferFrom lets the authorised spender move tokens under the token contract’s rules. The approval transaction generally establishes permission; the application’s later action uses it.
Identify four things: the network, token contract, owner address and spender address. A website’s name is not the permission itself. The spender may be an application contract or another address, and its code determines how that authority can be used.
Consider a hypothetical wallet holding 200 tokens. You approve a spender for 100 tokens. The balance remains 200 until tokens actually move. If the spender then transfers 40 tokens under a standard finite allowance, your balance becomes 160 and the remaining allowance becomes 60. Those are separate numbers.
The spender may use the remaining permission without another approval prompt, subject to the applicable contract rules. A new approval normally replaces the existing allowance with the amount you specify; it does not automatically add that amount to the old limit.
Unlimited approvals can reach future deposits
An application may request a very large allowance so you do not need a fresh approval for each transaction. This can reduce repeated steps and approval costs, while leaving a larger amount exposed to the spender’s authority.
Some common implementations treat the maximum integer allowance as unlimited and do not reduce it when tokens are spent. Do not assume every use steadily consumes an unlimited permission.
An allowance can also remain when your token balance reaches zero. If you later receive more of the same token at that address on the same network, the existing permission may become useful again. An empty wallet view does not establish that its old permissions have disappeared.
Choosing a smaller limit reduces the amount available through that permission. It does not establish that the application is trustworthy or that the proposed transaction is sensible.
Revoke the permission you actually granted
Review allowances when you stop using an application, cannot identify a spender, discover an unnecessarily large limit, or learn of a relevant security incident. The objective is to remove an unnecessary route to spending.
- Check the account and network. A permission on one chain is separate from a permission on another.
- Identify the token and spender. Use a trusted wallet permission screen or the appropriate block explorer. A familiar label alone does not verify an address.
- Read the proposed change. For a standard ERC-20 allowance, revocation usually sends an on-chain transaction setting that spender’s allowance to zero. Confirm the token, spender and new amount.
- Verify confirmation. On-chain revocation costs network gas, even if a service sponsors it. Check that the transaction succeeded and the relevant allowance now reflects the intended change.
A pending revocation has not yet changed the chain’s state. A spender may act before it confirms. A completed revocation limits future use of that allowance; it does not recover tokens already transferred.
Disconnecting a website changes the wallet’s connection to that site. Existing on-chain approvals require a separate change. If private keys or recovery words have leaked, permissions are only part of the incident: revocation does not remove another person’s ability to sign with those keys.
If you use a personal wallet alongside KTX, keep wallet permissions separate from platform account security. KTX’s guide to custodial and non-custodial wallets explains who controls transaction authorisation and recovery. See KTX’s seed-phrase backup guide for protecting recovery material, and never provide recovery words to a website offering to revoke permissions.
Signed permissions need a second check
A wallet may ask for a signature instead of an immediate approval transaction. A signature can still create meaningful authority. ERC-2612 permits, for example, let another party submit your signed authorisation to establish an allowance.
The permit’s deadline limits when that signature may be submitted. It does not automatically give the resulting ordinary ERC-20 allowance an expiry date. Setting an allowance to zero also does not necessarily invalidate an older, unused permit signature; its nonce and validity rules need separate attention.
Permit2 introduces another layer: the token’s approval to the Permit2 contract, followed by permissions for particular applications. Its allowance-based permissions and one-time signature transfers have different rules for amounts, expiry and nonces.
Review each applicable layer and outstanding signed authorisation. A checker that reads current on-chain allowances may not reveal every signature that has been signed but not submitted. A reassuring allowance screen cannot account for a permission it cannot yet see.
Frequently asked questions
Do I need an ERC-20 approval to send native ETH?
A normal transfer of native ETH does not use an ERC-20 allowance. Wrapped ETH is a token and can use that mechanism. Account-level permissions are a separate matter.
Does one unlimited approval cover every asset in my wallet?
A conventional ERC-20 approval concerns a specific token and spender. It does not automatically cover every token or NFT. A single signing request can, however, contain several permissions, so review its full scope.
Why might a wallet ask me to set an allowance to zero before changing it?
Some token implementations require it, and replacing a non-zero allowance can create transaction-ordering risks. Follow the supported workflow; a reset cannot undo spending that already occurred.
Will a hardware wallet stop a harmful approval?
It helps protect signing keys. You can still authorise a dangerous permission with those keys. Review the transaction details and spender rather than rely on the device alone.
Do NFT approvals work like token allowances?
ERC-721 supports approval for an individual NFT and operator approval across that NFT contract. These are different from an ERC-20 quantity allowance. Check the standard and scope before revoking.
This article provides general education, not personalised security or investment advice. Token implementations and wallet interfaces vary. Never disclose private keys or recovery phrases.