A cleanup pass over connected sites is cheap and takes minutes, but only if you separate two different things that the word “connection” covers: a session that can read your address, and an approval that can move your tokens.

• Disconnecting is not revoking. Disconnecting ends a session. It does not cancel a token approval, which lives in the token contract.
• Sessions outlive intent. Many sites keep a connection indefinitely, and a wallet will keep offering it as a signature option long after you stopped using the site.
• Every connection is a link between addresses. A site that sees two of your addresses can associate them, which is a privacy cost even with no funds at risk.
• Clean up in order: revoke, then disconnect, then verify. Doing it in the other order leaves approvals behind with no session left to remind you of them.

What a connection actually grants

A connection grants a site the ability to see your address and ask your wallet to sign. It does not, on its own, grant the ability to move funds. That requires a separate approval or a signature you provide, which is why “I only connected” and “I signed something” are very different statements.

Read access and the address graph

Once connected, a site can read your balance history, your token holdings, and every transaction your address has made. It can also group you with other addresses if you connect several from the same browser session. This is the quiet cost: no funds move, but a profile accumulates.

Signature requests that carry authority

Some signatures are harmless login proofs; others authorise a transfer or a delegated spender. The critical distinction is whether the message you sign names an amount and a spender. A login message references your address and a domain. An approval references a contract and typically a limit. If a “login” prompt contains a number and a contract address, it is not a login.

Session keys and delegated signers

Some applications create a temporary key that can act for a limited period or a limited scope. These sessions are convenient and are also the ones most likely to be forgotten, because no approval appears in a token’s records. Their only visible trace is often the connection list itself.

Why stale connected sites matter

A stale connection is low risk in isolation and meaningful in aggregate. The risk is not that an abandoned site suddenly gains powers; it is that old sessions widen the surface without anyone watching it.

A connection you cannot remember making is a permission you cannot evaluate. The list is only useful if you prune it often enough to recognise every entry.

Compromised front ends

A site that was trustworthy when you connected may later serve different code, be sold, or be left unmaintained. An existing session means the site already has a channel to request signatures from you, and a familiar name in the prompt is exactly what makes a malicious request easy to accept.

The audit problem

During an incident, the first question is which applications could have requested the signature that caused it. A short, current connection list answers that in a minute. A list of sixty entries across three years answers nothing.

Auditing connected sites

The audit is a comparison, not a review of each site’s legitimacy. You are checking whether the list matches what you believe you have used recently.

• Open the wallet’s connection manager and export or screenshot the current list before changing anything.
• Mark every entry you have used in the past month. Those are the ones you are actively relying on.
• Mark every entry you recognise but have not used recently. These are candidates for removal, not emergencies.
• Mark every entry you cannot place at all. These get removed first.
• For each remaining entry, check whether the site’s domain still resolves and whether the brand is spelled exactly as you remember it.
• Record the connection dates if the wallet shows them, and note anything created in a window you do not remember.

Screenshotting first matters. If a cleanup removes something you later need, the record tells you what to reconnect and saves an hour of reconstruction.

Comparing session types and what cleanup removes

Different connection types leave different residue, and one cleanup action does not cover all of them.

The middle two rows are the ones that cost money. Everything above them is a privacy and attention problem; everything from the token approval row down is a custody problem, and it is resolved on-chain rather than in a settings screen.

Cleaning up connected sites in the right order

Order matters because revoking requires a session to a tool that can send the transaction, while disconnecting removes that convenience.

1. Revoke token and collection approvals first, using a block explorer or approval tool you navigated to by typing its address.
2. Confirm each revocation on-chain. A submitted revocation that failed is still an active approval.
3. Return to the wallet and disconnect every entry you could not place, then the unused ones.
4. Sign out on the sites themselves where an account exists, so the site also clears its stored session.
5. Delete unused pairings, especially any tied to a device you no longer carry.
6. Re-check the list after a day. Some sites reconnect automatically when a tab is still open in the background.
7. Set a reminder to repeat the audit monthly, and treat the list as a review item rather than a one-off cleanup.

Step six catches the most common surprise: a site that reappears because a forgotten browser tab is still running its reconnect logic.

The post Connected Sites: Cleaning Up Wallet Sessions appeared first on LadyChain.