The short answer: disconnecting a wallet from a dapp does not revoke its existing token approvals. If your goal is to remove a contract's permission to spend a token, check the allowance itself. A disconnected website and an on-chain spending permission are different things. That distinction is easy to miss precisely because the disconnect button feels so reassuring. Nice clean interface; unfinished security chore.
MetaMask makes the distinction explicit in its documentation: disconnecting changes the dapp connection, but approvals can remain. Think of disconnecting as ending the conversation with a website, not automatically cancelling every permission previously granted to its contracts. That is an analogy, not a claim that all wallets behave identically. The practical question is narrower: does this particular spender still have an allowance for this particular token?
The ERC-20 standard supplies the mechanics. An approval authorizes a spender to withdraw up to a specified amount, potentially across multiple transfers. The allowance function reports what remains. Approving a token is therefore not necessarily a one-off payment, and it is not permission to spend every asset in your wallet. Scope matters: identify the token and spender rather than treating a familiar project name as a complete explanation.
My preferred pre-signing checklist is deliberately boring: which network am I using, which token is involved, who is the spender, and what amount am I authorizing? Compare the request with the action you actually intended. A small swap and a very large allowance deserve an extra pause. If the interface hides the important details or you cannot establish why the permission is needed, stopping is a perfectly useful outcome. There is no prize for being the fastest clicker.
There is a reasonable counterargument to strict limits: reusable approvals reduce friction. If you repeatedly use the same application, approving every interaction can be inconvenient. MetaMask also notes that approvals are part of normal dapp use. The point is not that every approval is malicious. It is that convenience should be a conscious choice, with an amount and a spender you understand, rather than a permanent default you never revisit.
For existing permissions, use your wallet provider's official documentation to reach the appropriate approval-management interface or your network's block explorer. MetaMask's revocation guide lists explorer approval checkers and explains that revocations happen on-chain and require gas. Check the network and account before acting, review the transaction, then verify the resulting allowance after confirmation. A submitted request is not the same as a confirmed change. Revocation removes a permission; it does not promise recovery of funds already transferred.
There is another wrinkle: no gas prompt does not mean no consequence. ERC-2612 defines a permit mechanism that changes an ERC-20 allowance using a signed message. Someone else can submit that permit on-chain. In other words, you can authorize a meaningful permission without personally broadcasting the approval transaction at the moment you sign. Read the spender and value, not just the reassuring absence of a transaction fee.
The permit deadline deserves special attention. In ERC-2612, it limits when the permit can be accepted; the successful call sets the allowance. It is not, by itself, an automatic expiry date for that resulting spending permission. That distinction follows from the standard's specified state change. Different permit implementations can have different semantics, so do not generalize one wallet screen into a rule for every token or signature flow.
My takeaway is permission hygiene, not permission panic. Before authorizing, understand the scope. When you stop using an application, check whether its allowances still match your intentions. After changing one, verify the result instead of trusting the click. This note covers the ERC-20 and ERC-2612 mechanisms linked below, not every NFT, smart-account or cross-chain permission system. It is educational security context, not personalized financial advice or a guarantee that a wallet is safe. A useful habit beats a comforting button.