Full article
Scenario: retire permissions for unused services
After trying an exchange or deposit application, review permissions that may outlive your use of it. This workflow covers ordinary token allowances, not every NFT approval, signed permit or smart-account permission. Start with one account on one network and expand only after completing that review. A recognizable service label is a clue for investigation, not proof that every associated contract is trustworthy.
Prerequisites: prepare four identifiers
Record wallet address, network, token contract and approved spender, plus the allowance and reason for retaining it. Symbols can be duplicated, so compare contract addresses. Reach the tool through official documentation and verify its domain instead of using an advertisement or unsolicited message. Confirm network support and the native-token balance needed for fees. Neither inspection nor revocation requires handing over your recovery phrase.
Steps: investigate before revoking
In MetaMask Portfolio, review Spending Caps under Overview. Begin with permissions you know are obsolete. Choose Revoke for the intended entry, then inspect the wallet's account, network and transaction request before submitting. Confirm it removes the intended permission rather than granting a new large allowance. Handle one entry at a time, record its transaction hash and wait for confirmation before refreshing. If you cannot identify an entry, investigate the original interaction rather than experimenting with an unfamiliar signing request.
Costs and limits: removal is an onchain action
Revocation normally incurs a network transaction fee. Estimate the cost before submitting and budget for multiple entries; a failed transaction may still consume gas. Using the relevant function again may require another approval and another fee. Disconnecting a website does not remove token allowances. Clearing the connected-sites list therefore cannot replace this review, even when the interface looks reassuringly empty.
Failures: recognize a security incident
Do not mark a pending transaction complete or repeatedly resubmit without checking its status. For a failure, inspect the transaction, fee balance and selected network first. An empty list may reflect the wrong account or unsupported permissions. Revocation cannot recover stolen assets or repair an exposed recovery phrase. Unexpected transfers require the official incident-response process instead of routine cleanup. If a sweeper may be active, do not keep topping up gas to attempt revocations.
Completion: verify the changed permission
Check transaction success and confirm that the relevant token-and-spender allowance is zero using an approval checker on the same network. Only then mark that entry complete. Give every retained approval a clear purpose and leave unidentified permissions explicitly unresolved. Save the review date, transaction hashes and a reminder without storing secrets. This evidence confirms the permissions you actually handled; it does not certify the entire wallet as risk-free or cover permissions the chosen tool cannot inspect.
For example, if two of three old approvals are removed and one transaction remains pending, record two completed entries and one follow-up. Add future permissions to the same log after using a new application, so the next review starts from evidence rather than memory.