Etherscan token approvals: spending limits and revocation

Inspect approvals for the correct address

An Ethereum address identifies whose permissions the Token Approval Checker displays, and the wallet's network must match that contract state before any signed change.

Token and approved spender addresses

The ERC-20, ERC-721 and ERC-1155 tabs separate permissions by token standard. Filtering by current holdings can hide approvals for tokens the wallet no longer holds, even while the permission remains active. Use the broader approvals view to review those remaining permissions. The token contract identifies the asset; the approved spender identifies the address allowed to move it. Matching both addresses distinguishes the permission under review. A recognizable label can help identify a contract, while source code verification makes matched code inspectable. Neither property changes the permission's scope.

Authorization and confirmation

Inspection needs no wallet connection. Editing or revoking requires a connected wallet authorized to act for the approval's owner. A directly submitted Ethereum change needs ETH for gas. A zero current allowance or disabled operator status confirms the selected permission is inactive at the state you read. A transaction hash alone does not establish that change.

Allowances separate permission from token balances

An ERC-20 allowance belongs to a particular owner, token contract and spender. It lets that spender call transferFrom within the allowance and available token balance. Approval itself changes permission without transferring the approved amount. The spender and eventual recipient may be different addresses, so the approval identifies who can initiate delegated spending. A large allowance cannot supply tokens absent from the wallet, and an empty balance does not clear a persistent allowance.

Does disconnecting my wallet remove token approvals?

Disconnecting a wallet does not revoke permissions already recorded in a token contract. Disconnection ends the site's connection to the wallet; persistent onchain approvals remain active independently of that connection. Closing a browser tab also leaves that permission untouched. Connecting to the checker lets the wallet receive requests, while signing the intended revocation authorizes an onchain change.

NFT permissions for one item or an owner's holdings within one contract

NFT permissions specify which items an operator may move, so an ERC-20 spending amount cannot describe their scope.

ERC-721 approval for one NFT

approve names an approved address for a particular token ID, and getApproved reads that address. Clearing it uses the zero address, and transferring the NFT clears this item-level approval automatically.

ERC-721 operator approval

setApprovalForAll grants an operator access to the owner's NFTs within that contract. Setting its boolean argument to false removes this operator permission. Item-level approval and operator approval remain separate, so clearing one does not necessarily remove the other's access.

ERC-1155 operator approval

The standard operator permission covers the owner's token IDs within the same contract. It does not impose a separate spending quantity for each ID. isApprovedForAll reports whether the operator remains authorized. This scope extends to later holdings under that permission; it does not cover unrelated token contracts.

Pending revocations and Ethereum gas

A revocation changes the effective permission only when its transaction executes successfully and the token records the intended state. While it remains pending, the spender can still use the existing allowance.

Execution can fail without clearing access

Ethereum reverses the contract-state changes of a reverted transaction and still charges its execution fee. Rejecting the wallet request submits no revocation. Treat pending, failed and successful transactions separately when judging whether access remains.

View full-size image

The network fee depends on execution

A directly submitted Ethereum revocation needs ETH for gas. Its fee depends on gas actually used and the effective gas price. The token's approval implementation affects the work required, while network conditions affect the price. Reading permissions does not require an onchain transaction or gas payment. The wallet's gas estimate concerns the transaction cost, not the number of token units you are authorizing.

Should I reduce an allowance or revoke the spender?

Keep a limited allowance when a known operation still needs delegated access; revoke it when you no longer want that spender to pull the token. A finite allowance limits the remaining spending quantity. An unlimited approval allows repeated access without regularly increasing the limit, and some token implementations leave that allowance unchanged after use. Existing permission can also apply to tokens received later. A smaller allowance limits the quantity exposed to that spender without changing how its contract behaves.

When changing a nonzero allowance, account for spending which may execute before your update. A standard ERC-20 approve call replaces the spender's existing allowance with the specified value. The standard recommends setting the allowance to zero before assigning another nonzero amount. Some tokens require this reset. Confirm the reset before establishing the new limit, and recheck any intervening spending. This does not reverse transfers already executed.

Signed permits and layered permissions

An ERC-2612 permit lets someone submit a signed authorization to update a token allowance. Its validity depends on the signed fields, the owner's current nonce and the submission deadline. Signing alone does not update the onchain allowance; the permit must execute to record the permission.

An ordinary ERC-20 approve reset does not itself invalidate an unused ERC-2612 signature, so a valid permit can establish permission again after the reset. Its submission deadline does not make the resulting basic ERC-20 allowance expire. Cancellation must follow the mechanism the token implements.

Permit2 separates the token's approval to Permit2 from application-specific authorizations. Its AllowanceTransfer module records amounts and expirations; SignatureTransfer uses single-use signatures. Removing an application's permission differs from removing the underlying token approval, which affects every application using that token through Permit2. A view of current token allowances cannot establish that every outstanding signature has been cancelled.

Individual and batch revocation choices

Etherscan supports revoking individual approvals and selecting multiple approvals through its batch revocation feature. Individual changes make a particular token and spender easier to isolate. Batch selection helps remove several unused permissions together. Review the selected calls and the wallet's proposed execution before signing, then confirm each intended permission's resulting state. A batch selection alone does not establish successful execution or a particular fee. Revoking one spender leaves other spenders' permissions intact, and future operations pulling tokens may need fresh authorization.

Revocation leaves private-key access unchanged; someone controlling the wallet's signing credentials can authorize transactions independently of a token allowance.