The distinction changes what defence looks like. You cannot audit your way out of a signature you have already given, but you can read what a request is asking for before you approve it, and you can withdraw permissions you no longer need.

• A drainer is a permission request, not an exploit. Nothing is broken; something is granted.
• Approvals outlive the site that asked for them. The permission sits on-chain, not in a browser tab.
• Permit signatures skip the approval step entirely. No on-chain transaction means nothing to revoke afterwards.
• Revocation is cheap and tedious. It is the only reliable cleanup once a permission exists.

What a wallet drainer asks you to sign

Almost every drainer interaction resolves into one of four request types. They differ in scope and in whether you can undo them later, which is the part most interfaces hide.

Token spending approval

This grants a contract permission to move a specific token up to a specific amount. The field that matters is the spender, not the token. A request to approve a token you recognise tells you nothing if the spender is an address you have never seen.

Unlimited approvals are the default on many interfaces because they save gas on later trades. They also mean the permission has no ceiling, and the contract keeps it until you reset it.

Collection-wide approval

For NFTs, a single approval can cover an entire collection rather than one item. Approving one piece can therefore expose every piece you hold from that collection, including ones minted after the approval was signed.

Off-chain permit signatures

A permit is a signed message rather than a transaction. It costs no gas, which is exactly why it appears in phishing flows: there is no gas estimate, no on-chain confirmation screen, and no transaction to inspect afterwards. If the permit is later submitted, the transfer happens without you pressing anything again.

Opaque payloads and blind signing

Some requests arrive as raw bytes that your wallet cannot decode. The wallet can only show a hash. Approving a hash is not approval of anything you can describe, and a signature over an unreadable payload should be treated as a signature over an unknown instruction.

Why a wallet drainer request looks ordinary

These requests use the same standards as legitimate applications, so the wallet has no reason to flag them. The transaction is well-formed. The contract is deployed and verified. The interface may be a convincing copy of one you already use.

The weak point is the summary line. Wallets compress a request into a short sentence, and that sentence often omits the spender, the amount, or both. The detail exists one tap deeper, in a panel most people never open. A drainer depends on that habit.

There is also a timing component. Requests arrive when you are mid-task: claiming a reward, minting, migrating a position. Attention is on the outcome you want, not on the fields in front of you. Anything that adds friction to that moment, such as a second device or a written checklist, is worth more than another article read after the fact.

Treat every signature as a contract with a stranger. The question is not whether the site looks trustworthy, but what the signature would let the other party do tomorrow, after the site has disappeared.

Comparing the request types

How to check a request before signing

Reading a request takes about thirty seconds once you know which fields to look at. The order below is deliberate: address first, because everything after it is meaningless if the target is wrong.

1. Open the full detail view, not the one-line summary.
2. Copy the contract address and compare it against the address published by the project you intended to use.
3. Read the function name. Approval, permit, transfer and batch transfer are four different commitments.
4. Find the spender field and confirm it is the contract you expect, not an arbitrary address.
5. Check the amount. If it is unlimited and you did not intend a long-term position, reduce it.
6. Check the deadline on any permit. A long or absent expiry extends the window for it to be used.
7. If any field is unreadable on your device, decline. A hardware screen showing a hash is not a review.

Reducing what a wallet drainer can reach

Separate wallets do more than any single habit. Keep a small hot wallet for new sites and a holding wallet that never connects to anything unfamiliar. A drainer can only take what the wallet it reached was allowed to move.

Review existing approvals periodically, particularly after using a new application. Most explorers and several independent tools list outstanding allowances by wallet, and revocation is a normal transaction. It costs a fee, and on some networks that fee is the only friction.

Hardware wallets help only when the screen shows the amount and the recipient. If the device displays a hash, it has reduced a signing decision to a confirmation, which is a weaker guarantee than it appears.

One more limit is worth stating plainly. No amount of approval hygiene protects a key that has been copied. A signature is only as safe as the device that produced it, and a phrase typed into a website, a browser extension or a screenshot folder is outside every control described here.

The post Drainer Signatures: What You Are Approving appeared first on LadyChain.

The reason spam tokens work is economic. Writing an entry to a token contract is cheap, and a wallet that displays unsolicited balances gives the sender free screen space in front of exactly the person they want to reach. Understanding that trade is most of the defence.

• Nothing was hacked. These tokens arrive because a contract can credit any address without permission. The wallet is only reporting what the chain says.
• The token is the message. Its name, ticker, or amount often carries a URL or instruction. Reading it is the interaction the sender wants.
• Do not approve, swap, or “claim”. Most harm comes from a signature or approval you grant afterwards, not from the token arriving.
• Hide, do not burn. Hiding is a display setting. Sending the token to a burn address still requires a transaction and can cost more than it removes.

Why spam tokens arrive in the first place

Token standards on most smart-contract networks allow any address to call a transfer function and credit any other address. There is no allowlist, no acceptance step, and no way for a wallet to refuse a balance at the protocol level. A spammer needs one transaction per recipient and can batch thousands of them.

The address book is public

Every address that has ever interacted with a contract is visible. So is every address that received a transfer from a large exchange withdrawal wallet, every address that holds a well-known token, and every address that appears in a public airdrop list. Address lists are compiled once and reused. Being targeted says nothing about you beyond the fact that your address is active.

Cheap credits, expensive attention

A transfer that only writes a balance entry is usually far cheaper than a transfer that moves value between parties, because no liquidity is involved. That asymmetry is the whole business model: near-zero cost per impression, and a small conversion rate is enough to make it worthwhile. Some of these tokens are also designed so that the first person to trade them pays a fee that flows to the creator.

How the token is built to be touched

Most spam tokens are engineered so that curiosity produces a specific action. Recognising the pattern is more useful than memorising ticker names, which change weekly.

Names that impersonate something

Common patterns include a ticker that closely matches a well-known asset, a name that references a claim or a reward, and an amount chosen to look like a rounding error rather than a lure. A balance of a few thousand units of an unfamiliar token is designed to look like a mistake you might want to correct.

Contract behaviour that punishes selling

Some token contracts restrict who may transfer. An address can receive the token but cannot send it, or can send it only to a specific contract. Others apply a fee on transfer that is routed to the deployer. In these cases the token has no market at all — the only exit the contract permits is the one the creator controls.

The safest assumption about an unsolicited token is that its contract was written by someone who wants you to sign something. Treat the balance as an advertisement, not as an asset.

Sites that appear when you look it up

Searching the ticker of an unsolicited token often leads to a site that offers a swap, a “migration”, or a claim. That site is the actual payload. The token exists to make the search happen. Bookmarking a small set of venues you trust, and reaching them only through those bookmarks, removes most of this risk.

Comparing what you might receive

Not everything unsolicited is hostile, and not everything named like a reward is real. The table below separates the common cases by what the sender appears to want.

The last row is the one that requires judgement. Real distributions exist, and they are announced through channels you can check without touching the token itself. The test is not whether the token looks professional — it is whether you can confirm the claim through a source you already trusted before the token arrived.

Handling spam tokens without interacting

The procedure below is deliberately passive. Almost every step avoids a transaction, because a transaction is the part that can cost you something.

1. Do not open the token’s contract through a link inside the token name or a search result.
2. Note the contract address and set the token to hidden in your wallet’s display settings.
3. Check your approval list for that contract address. If nothing is approved, there is nothing to revoke.
4. If an approval exists, revoke it from a block explorer or approval tool you reached by typing the address yourself.
5. Ignore any instruction to “burn” or “return” the token. Burning requires a transaction and gains nothing.
6. Review connected sites for anything unfamiliar, and disconnect what you do not recognise.
7. Repeat the review after any period of inactivity, since approvals can be granted by a single signature months later.

If a wallet already shows an approval to an unfamiliar contract, treat that as the real event and the token as the doorbell. Revoke first, investigate second.

The post Spam Tokens: Why They Appear and What to Do appeared first on LadyChain.

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.