Connecting a wallet usually shares selected account details and lets a site send requests to the wallet. A token approval separately authorizes a spender to move a specified token amount on-chain. Disconnecting ends the site's wallet session; it does not revoke existing allowances, undo signed transactions or erase usable signatures. Check each permission separately.
Read the permission behind Connect
A website can place Connect, Sign and Approve buttons beside one another. That layout makes them look like steps in one permission. They can change different records, controlled by different systems.
For an ordinary Ethereum account connection, the wallet decides which accounts to expose to the application. EIP-1193's account-access guidance recommends explicit requests rather than exposing accounts by default. EIP-2255 describes wallet permissions by the invoking site, permitted method and any restrictions. An account appearing on a page is evidence of account access, not evidence that a token allowance was created.
WalletConnect, the named protocol, is one way to establish the communication session. Its session specification separates requested chains, methods and events from the accounts approved for the session. Read those requested capabilities. A familiar app name or a successfully scanned QR code does not establish that every later request is appropriate.
Connection also has a privacy consequence. Once a site learns a public address, disconnecting cannot make it forget that address or make its public transactions private. Ethereum's block-explorer documentation describes publicly accessible account balances, tokens and transaction history. Removing wallet access can stop that channel from supplying information; public chain data remains observable through other channels.
Separate requests, signatures and stored allowances
The following matrix covers ordinary EVM account connections and ERC-20 spending. It distinguishes a request reaching the wallet from authority already granted outside the session.
| Action | Record or authority created | What disconnecting changes |
|---|---|---|
| Connect selected accounts | Site access in wallet or session settings | Removes that connection; previously learned public addresses remain known |
| Request a transaction | A request awaiting the wallet's decision | Do not use disconnection as proof that an unresolved request was rejected |
| Sign and broadcast a transaction | A signed instruction submitted to the network | Does not cancel that instruction or reverse an executed transfer |
| Successfully execute an ERC-20 approval | Allowance for an owner, token and spender on one chain | Leaves the on-chain allowance unchanged |
| Sign a spending permit | A signature whose use depends on the relevant contract's rules | Does not invalidate an otherwise usable authorization |
Under ERC-20, an approval sets the amount a spender may use through the token's allowance mechanism. The website domain is not part of that stored permission. An application can use several spender addresses, and a spender can serve several interfaces. There is therefore no reliable one-to-one mapping between a wallet's connected-site list and its token approvals.
A transaction request is different again. Seeing a prompt is not signing it; signing is not proof of successful execution. Ethereum's transaction lifecycle distinguishes broadcast, pending status, block inclusion and finality. A transaction already broadcast can be processed after the site connection ends. Its receipt and resulting state need their own check.
Do not turn this matrix into a promise that every wallet always asks before every action. For example, MetaMask's advanced-permission documentation describes supported grants with spending, time and condition limits that can let applications act without repeated approvals. Such a grant deserves a separate review of its limits and cancellation mechanism. A screen requesting ongoing spending authority is more consequential than ordinary account visibility, whatever the site's button says.
Follow a permission after its site disconnects
Consider a hypothetical account holding 900 units of token Q. Spender S receives a finite allowance of 300 Q. Assume S can invoke the token's transfer mechanism, and later uses that authority maliciously. This is a deliberately unsafe scenario demonstrating what disconnection changes, not a claim that an arbitrary caller can spend through every router.
Assume a conventional token whose finite allowance decreases by the amount spent, with no transfer fees, rebasing, other approvals or signed permits. The OpenZeppelin ERC20 implementation documents this finite-allowance behavior. Network fees are separate and omitted from this token ledger.
| Confirmed event | Site session | Q balance | S allowance |
|---|---|---|---|
| Starting state | Disconnected | 900 | 0 |
| Connect account | Connected | 900 | 0 |
| Approve S for 300 Q | Connected | 900 | 300 |
| S spends 80 Q for the intended action | Connected | 820 | 220 |
| Disconnect site in the wallet | Disconnected | 820 | 220 |
| S makes an unwanted 50 Q transfer | Disconnected | 770 | 170 |
| Revoke S and verify allowance zero | Disconnected | 770 | 0 |
The balance calculation is 900 − 80 − 50 = 770 Q. The remaining allowance before revocation is 300 − 80 − 50 = 170 Q. The disconnect event subtracts nothing from either number.
No new connection or owner signature was required for S's unwanted transfer under these assumptions: S used authority that already existed. The remaining 170 Q would still have been available through that permission until a successful revocation or another relevant state change. Revocation cannot recover the 50 Q already transferred.
This is why a clean connected-site list is weak evidence about spending exposure. MetaMask's disconnect guidance explicitly separates removing a connection from revoking token approvals. WalletConnect's session deletion specification defines a message telling the peer to close and delete a session; that is a different operation from changing token-contract storage.
The existing token approval and allowance guide goes deeper into finite limits, failed execution and allowance updates. Here the key observation is the crossed state: a session can be disconnected while its former spender still has authority.
A gas-free signature can survive the session too
A spending authorization does not always begin with an owner-sent approval transaction. ERC-2612 lets a valid signed permit set an allowance when executed on-chain. Its fields include owner, spender, value, nonce and deadline; anyone can submit the valid permit.
It follows that closing the wallet session does not cancel a permit someone already holds. Its usability depends on the contract's signature, nonce and deadline checks. The permit deadline limits when it can execute successfully, not merely enter a pending pool; it does not automatically expire the resulting ordinary allowance.
Read the EIP-712 typed-data signature guide when a request presents structured signing fields. Identify what the signature authorizes instead of judging it by the absence of a gas fee. A current zero allowance does not, by itself, establish that no unused spending signature exists. Other authorization frameworks can use different validity and cancellation rules.
Keep any usable signature out of support messages and public notes. Record its non-secret scope and status instead. If you cannot classify the requested authority, reject the request until its purpose is clear.
Verify cleanup across both permission records
For routine retirement of a dapp connection, use the wallet's own connection controls and a verified on-chain view. Closing a tab is not a completion record. If a spender is suspected to be unsafe, prioritize revoking its known authority; do not wait to finish a tidy inventory before acting.
- Identify the account and chain. Record which wallet account was connected and every relevant network. A zero allowance on one chain says nothing about the same-looking token on another. Check the full token and spender addresses against authoritative deployment information.
- Reject unexplained pending requests. Review the wallet's request queue. Separate requests you rejected from transactions you signed and broadcast. For existing transaction hashes, inspect their current receipts and effects through the appropriate network explorer.
- Remove the site connection in the wallet. Check the wallet's connected-app or session list, including other accounts that may have been shared. MetaMask, for example, exposes connected dapps and accounts through its permission settings. Wallet-specific menu names can change.
- Read and revoke the intended allowance. Use a verified wallet or explorer interface. For an ordinary ERC-20 allowance, setting the exact spender's allowance to zero is a separate transaction. Review the token contract and spender inside the request, then verify successful execution and read the resulting allowance at an identified block. A submitted revoke with an uncertain outcome is unfinished work.
- Check additional authorizations. Review signed permits and any advanced spending grants separately. Use that mechanism's documented invalidation or cancellation rules. Do not infer that an allowance change invalidated every signature or delegation associated with the account.
When choosing addresses during this process, use the address-poisoning checklist rather than selecting a familiar-looking entry from transaction history. The connection's display name, token symbol and shortened address are reading aids, not sufficient identification of the permission being removed.
A compromised signing key is a different problem: someone able to sign as the owner may grant fresh authority. Revoking one spender does not remove that ability. Likewise, for centralized-exchange automation, exchange API-key permissions belong to the exchange's credential system. Deleting that key cannot edit a token allowance on a public chain.
Keep a short completion note with the account, chain, removed site session, token and spender, final allowance, read block and status of outstanding signed authorizations. “Disconnected, allowance zero at this block, no unresolved authorization identified” is a useful record with explicit limits. “The site is gone from my wallet” leaves the spending question unanswered.