Polygonscan
Polygonscan token approvals and spending limits
Polygonscan token approvals let you review and revoke permissions that allow another address to spend tokens on Polygon PoS. Each ERC-20 allowance belongs to a particular owner, token contract and spender on that network. Revoking it requires an onchain permission change and gas; disconnecting a decentralized app leaves that permission unchanged. NFT approvals use different rules, including permissions for an individual token or an operator across a token contract. A submitted transaction hash does not prove that revocation succeeded. The relevant permission must actually change before the selected spender loses access through that authorization.
Reviewing a Spender and Correcting a Mistaken Revocation
An approval review starts with the owner account, token contract and approved spender on Polygon PoS. Match those addresses before authorizing any change; the spender and
token contract
have different roles. The Token Approvals tool provides the review and revocation interface. For a standard ERC-20 allowance, revocation requests
approve(spender, 0)
on the token contract. A wallet-paid transaction also needs enough native POL for gas.
A pending or failed request calls for checking the transaction status and current allowance for those same addresses. If the request names a different spender, its successful execution changes a different permission.
Wallet rejection, a reverted call or a still-pending request does not complete the intended permission change.
In this hypothetical example, a Polygon PoS account holds 83.5 units of an ERC-20 token. It approves 31.5 units for one spender and 12.5 units for another. A revocation mistakenly names the second spender, although the reader wants to remove the first.
The first spender still has 31.5 units of allowance because only the second permission changed. Repeating that transaction would leave the same error. The targeted correction requests
approve(spender, 0)
for the first spender on the same token contract, after checking the account and spender.
Once execution succeeds and the first allowance reads zero, that spender loses access through this permission. The second allowance also remains zero if nothing else changes it. The approval updates do not themselves transfer the 83.5 tokens. A fresh approval could later restore a permission that is needed.
Does Disconnecting a Wallet Remove Its Approvals?
Disconnecting a wallet does not revoke token approvals because connection settings and token permissions live in different places. Disconnection ends the app connection in that wallet; an approved spender can still use a remaining allowance under the token contract’s transfer rules. Public address activity also remains public after disconnection. Removing that spending permission requires an onchain change for the relevant owner, token and spender.
ERC-20 Spending Limits and Token Balances
An ERC-20 spending limit authorizes a spender to use up to the remaining allowance for a particular token and owner. That amount represents permission, not a transfer or a reservation of tokens. Available balance and the contract’s transfer conditions also constrain spending. An empty balance does not necessarily clear the allowance, so later receipts can become spendable under the remaining permission.
A successful ERC-20
approve
call replaces the existing allowance for the same owner and spender within that token contract.
The permission can support repeated spending within its limit. An allowance displayed as unlimited permits spending beyond one intended use, within the available balance and the contract’s rules. It does not grant access to every token in the wallet.
A smaller allowance may require another approval before a later action can spend more. A broad allowance can reduce repeated approval requests while leaving more spending authority active. An allowance amount is not the wallet’s total value or a payment to the explorer.
The spender address identifies the authorized caller. It can differ from the transaction destination and the eventual token recipient.
How Do NFT Approvals Differ From ERC-20 Allowances?
ERC-721 approvals can cover an individual NFT or an operator’s access to the owner’s NFTs within one contract. The per-token permission and the operator setting are separate authorizations. Clearing an individual approval does not disable an operator, and disabling an operator does not clear separate individual approvals. To revoke an individual ERC-721 approval, the owner or an authorized operator calls the NFT contract’s approve function with the zero address and that NFT’s token ID. For a standard operator permission,
setApprovalForAll(operator, false)
disables that operator for the authorizing owner within the token contract.
The
isApprovedForAll(owner, operator)
read reports this permission; ERC-721 uses
getApproved(tokenId)
for individual approvals. Standard ERC-1155 operator approval covers the owner’s token types within that contract. Additional interfaces can support narrower permissions, so the standard operator setting does not describe every custom authorization.
What Does a Revocation Cost on Polygon PoS?
A revocation costs the network gas required to execute its permission change; the amount varies with execution and gas prices. A wallet-paid revocation on Polygon PoS uses native POL for gas. The wallet’s transaction estimate concerns that network charge. The allowance amount describes tokens that the spender may use, so it is a different quantity from the fee.
Setting an allowance to zero does not make transaction execution free. The zero is the spender’s resulting token limit. Revocation can therefore require native gas funds even when the approval update transfers none of the approved token. A fixed fee estimate would miss changes in network conditions and the token contract’s execution.
Approval History, Current State and Contract Code
Approval events record permission changes, while current contract reads answer what permission exists now. An old
Approval
event does not establish the remaining allowance after later spending or replacement approvals. The relevant ERC-20 read is
allowance(owner, spender)
on the token contract. Event logs distinguish an approval update from a token transfer; those records describe different actions.
Contract verification makes matched source code available for inspection. The application binary interface, or ABI, describes callable functions and their argument types. Source code shows the authorization checks and transfer restrictions behind those functions. Verification does not certify the safety of giving a spender access to tokens. Published source also leaves the actual allowance and operator settings unchanged.
Things people ask about Polygonscan token approvals
Can I Review Token Approvals Without Connecting a Wallet?
Public approval state can be inspected without authorizing a wallet connection or signing a transaction. ERC-20 allowance checks use owner and spender addresses. ERC-721 and ERC-1155 operator checks use owner and operator addresses; an individual ERC-721 approval check uses the token ID. Changing an allowance requires authorization from the affected account; merely looking up its address does not grant that authority.
Will Revoking a Spender Return Tokens Already Transferred?
Revocation changes a spending permission and does not reverse completed token transfers. An allowance reduced to zero blocks further spending through that allowance, subject to the token’s implementation. It does not move tokens back from a recipient or withdraw assets that the account already deposited into another contract.
Why Does a Raw Allowance Look Larger Than the Displayed Token Amount?
A raw ERC-20 allowance uses the token contract’s integer units, while a displayed amount may apply the token’s decimal precision. Conversion divides the raw amount by ten raised to that precision. The ERC-20 decimals method is optional, so a missing value does not justify assuming a particular precision.
Does Transferring an ERC-721 NFT Clear Its Individual Approval?
An ERC-721 transfer clears the individual approval for that NFT under the standard. Operator permissions are separate settings belonging to an owner within the collection contract, so transferring an NFT does not revoke the previous owner’s operator approvals. The new owner’s operator permissions govern that NFT after transfer.
Why Might Changing an ERC-20 Limit Involve a zero-allowance Transaction First?
ERC-20 interface guidance recommends setting an existing nonzero allowance to zero before assigning a different nonzero value for the same spender. This concerns the same owner and token contract. It addresses the ordering risk when replacing an active allowance. The token contract need not enforce that sequence, and a pending reset leaves an existing allowance usable.
Is Revocation Enough After a Private Key Leak?
Revoking allowances does not remove an attacker’s control of an externally owned account whose private key has leaked. That key can authorize fresh approvals or direct transfers from the account. The issue extends beyond the existing spender permissions, so an empty approval list does not establish that the account is secure.