Why a wallet gets drained after connecting

What connecting actually does

The connection step is worth understanding precisely, because almost every explanation of what happened afterwards starts from a false premise about it.

When you connect a wallet to a site, two things happen. The site learns your public address, which was already public. And the site gains the ability to ask your wallet to sign things, which your wallet will show you before anything is signed.

That is the entire scope. Connecting confers no authority to move anything. A site with a connection can request; it cannot take. If funds left after you connected, the mechanism was something you approved after the connection, not the connection itself.

This distinction matters because people who believe connecting is dangerous learn the wrong lesson. They become afraid of a harmless step while remaining unprepared for the genuinely dangerous one, which arrives looking entirely routine.

How funds actually leave

Three mechanisms account for essentially every drain, and they differ in how obvious they are at the moment of approval.

A direct transfer you approved. The transaction moved assets to an address that was not yours, and the interface described it as a claim, a mint, a verification or a required step. This is the crudest form and the wallet usually shows enough to catch it if the approval screen is read.

A delegation. The transaction granted another address permission to move tokens from your account. Nothing leaves at the moment of approval, which is exactly what makes it effective. The transfer happens later, at a time chosen by whoever holds the delegation, often after you have forgotten the interaction entirely.

A disclosed seed phrase. Any interface asking for a recovery phrase is malicious without exception, and the loss here is total and permanent. No legitimate application, wallet support process or verification step ever needs it.

The middle one is responsible for the majority of cases where someone insists they approved nothing unusual, because from their perspective they genuinely did not see anything leave.

Delegation, the quiet one

Delegation deserves its own section because it is both legitimate and the most common vehicle for loss, and understanding why explains most of what makes this hard to guard against.

The mechanism exists for good reasons. Applications that need to move tokens on your behalf, such as a program executing an order later, need standing authorisation to do so. Requiring a fresh signature for every action would make many things unusable.

The problem is that the approval screen for a legitimate delegation and a malicious one look substantially the same. Both request permission for an address to move tokens. The difference is the address and the amount, neither of which most people examine, and one of which is a long string that means nothing on sight.

An active delegation persists indefinitely. It survives closing the site, disconnecting the wallet and restarting the browser, and it is why a wallet can be drained days or weeks after the interaction that caused it.

What the warning signs look like

The reliable ones are contextual rather than technical, which is fortunate because the technical details are difficult to read quickly.

Urgency. A deadline, a limited allocation, a claim expiring. Urgency exists to prevent the pause during which someone would have looked more carefully.

Unsolicited arrival. A link in a reply, a direct message, an airdrop appearing in your wallet with instructions attached. Legitimate things are rarely discovered this way.

An approval that does not match the action. You clicked connect and a signature request appeared. You clicked claim and a delegation appeared. Any mismatch between what you asked for and what you are being asked to approve is sufficient reason to stop.

A wallet warning you have seen before and dismissed. Wallets flag suspicious programs and unusual approvals. The warnings are imperfect and they are correct far more often than the sites they interrupt.

Unfamiliar tokens arriving in a wallet unprompted deserve specific mention. They are frequently bait, and interacting with them, including attempting to sell them, is the intended trigger. Some are also constructed so they cannot be sold at all, using the mechanisms described in the authority explainer and producing the symptoms in the sell failure guide. The correct response to an unexpected token is to ignore it entirely.

What to do immediately

1. Move whatever remains. A fresh wallet, created now, with a seed phrase that has never touched a screen shared with anything. Do this before investigating anything.
2. Revoke active delegations on the compromised wallet, using a reputable revocation tool reached by typing the address yourself rather than following a link.
3. Assume the wallet is finished if a seed phrase was ever entered anywhere. Revocation does not help; the keys are known and the wallet must be abandoned.
4. Read the transaction history. Identify the specific approval that caused it. This is the step most people skip and the one that prevents a repeat.
5. Warn people, factually. If it came through a link posted in a community you are part of, saying so quickly limits the damage to others.

What does not work is any service offering to recover the funds. Transactions are final, recovery is not technically possible, and every such offer that reaches a victim is a second attempt on whatever is left.

Avoiding it next time

The practices that actually work are few and unglamorous.

Separate wallets by purpose, so that the wallet that connects to unfamiliar sites holds an amount you would accept losing and nothing else. This single habit converts most drains from a disaster into an annoyance.

Read approval screens, specifically the amount and the counterparty rather than the summary line. It takes seconds and it is the only moment at which the outcome is still in your hands.

Type addresses rather than following links, particularly for anything involving revocation or claims. Search results and replies are both routinely poisoned.

Review delegations periodically rather than only after something goes wrong, since a standing authorisation you granted a year ago is still live today.

For teams, all of this applies with more force, because a compromised team wallet holding treasury or liquidity affects everyone holding the token rather than one person. The operational side of that, including how to structure wallets so a single mistake cannot reach the treasury, is covered in the team wallet security guide.