Token approvals: disconnecting a dapp does not revoke its allowance
Disconnecting a dapp does not revoke its token allowance. A connection is a wallet session; an allowance is spending permission stored in a token contract. Changing that permission usually needs a separate onchain action and fee.
Which action removes which permission?
A connection and an allowance are different things
Think of a connection as a line of contact with your wallet. An allowance is permission stored in a token contract. The contract is a program that follows rules. Removing the line of contact does not change that program’s record. A wallet privacy review should check both.
- Before approving: Check the token, network, spender, and allowed amount.
- After finishing: Review whether the old allowance is still needed.
- If a key is stolen: Do not assume that changing one allowance protects the account.
| Action | What it changes | What it does not do |
|---|---|---|
| Disconnect a site | The wallet session | Erase an onchain allowance |
| Change an allowance | That spender’s token permission | Recover tokens already taken |
| Close the browser | The open page | Change the token contract’s records |
Keep in mind: A revocation cannot undo a transfer that has already happened.
How is an allowance different from a connection?
A connection lets a website communicate with a wallet interface. A token allowance authorizes a spender contract under that token’s rules. Closing a tab or disconnecting a site normally does not change the allowance. It remains in the token contract’s records until used or changed according to the contract.
Read the spender and the amount
An approval prompt can grant a narrowly scoped amount or a very large allowance. Check the network, token, spender address, and amount. Familiar branding in the web page is not sufficient evidence that the spender is the intended contract. Token standards and permit-based workflows can behave differently.
What does revoking an allowance change?
Changing an ERC-20 allowance typically requires an onchain action and a fee. Use a trusted interface reached through a verified source, inspect what you are signing, and allow for confirmation. Revocation prevents future use of that allowance; it cannot reverse an earlier transfer or fix a compromised recovery phrase.
Reduce the future attack surface
Review old permissions after finishing with an application. Prefer an amount appropriate to the action when the interface supports it. If a key is compromised, a permission cleanup alone is not a recovery plan. Distinguish a malicious allowance from a stolen signing key before deciding what to do next.
Example: two spenders need two separate reviews
Suppose a standard ERC-20 token records an allowance of 100 units for spender A and 50 units for spender B. You change A’s allowance to zero.
That change concerns A. It does not also remove B’s separate 50-unit allowance. The amounts are permissions, not proof that either spender has already transferred tokens. Inspect the token and spender together rather than treating all approvals as one setting.
After the change is confirmed, check A’s updated allowance and review B separately. A wallet connection list cannot replace this token-by-token permission check.
Check the source
This is an original, AI-assisted educational explanation. Sources and limitations are provided for verification; it is not personalized financial advice. Read the editorial policy or report a correction.
