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.

The practical question is not whether to use a wallet on multiple devices, but which device should hold the signing key and which should only watch. Everything else follows from that split.

• Nothing syncs except the key. Balances come from the chain, so the only thing that actually travels between devices is the seed or private key.
• Each device is a full signing surface. Three devices means three chances for a compromised machine, a malicious extension, or an observed screen.
• One signer, many viewers. A single signing device with watch-only views elsewhere keeps convenience and removes most of the exposure.
• Wiping is part of the setup. A device you stopped using is still a signer until its key material is destroyed.

What actually syncs between devices

Almost nothing syncs, and the exceptions matter. A wallet balance is read from the network by each device independently; it is not copied from one to another. Two devices showing the same number are two devices reading the same ledger.

The key is the only portable object

When a wallet appears “synced”, what happened is that the same key was imported on the second device. The seed phrase, a private key, an encrypted backup file, or a hardware device carried between machines — all of these are ways of putting the same signing authority in a second place. There is no protocol that shares a balance without sharing the ability to spend it.

What genuinely does sync

Some wallets sync preferences: address labels, contact lists, hidden tokens, and sometimes encrypted backups held on a server. These improve usability and are not custody. The distinction is worth keeping straight, because syncing settings feels like syncing safety and it is not.

Watch-only is the exception that matters

A watch-only wallet holds a public key or address and no signing material. It can display balances and build transactions but cannot approve them. This is the only form of multi-device access that adds convenience without adding a signing surface.

Why a wallet on multiple devices concentrates risk

Risk does not spread evenly across devices. It concentrates on whichever device is used for everything else, and on the overlap periods when a device is being retired.

Three devices do not triple your risk. They triple the number of environments that must each stay clean, and risk compounds with every environment that does not.

The general-purpose machine

A laptop used for browsing, downloads, and email is the weakest signer in any set. Extensions update themselves, clipboard contents are readable, and a single malicious package can watch everything the browser does. If one device must hold the key, it should be the device with the fewest other jobs.

The overlapping retirement

When a phone is replaced, the old handset usually stays functional for weeks. During that period the same key exists on both devices, and the old one often has weaker screen locks, older software, and a backup that was never verified. Retirement is a step, not a drift.

The counted surface

It helps to count signing surfaces explicitly rather than devices. One laptop with two browsers and two wallet extensions is four surfaces, not one. Two phones with a cloud backup each add two more places where key material may exist.

A worked count

Take a common setup: a laptop with a browser extension, a phone with a mobile wallet, and a tablet used occasionally. That is three devices. Add a second browser profile on the laptop for work, and a cloud backup enabled on the phone: five places where the key or an encrypted copy of it exists. Remove the tablet and disable the cloud backup and the count halves to three without any loss of daily convenience. The arithmetic is unglamorous, and it is the entire argument for consolidating.

Assigning roles to devices

The useful pattern is role separation: one device signs, the rest observe. The table below maps common roles to what each device should hold.

The travelling row is the one most people get wrong. A phone that leaves the house should hold a small balance under its own key, so that losing it costs the balance rather than the account.

Setting up a wallet on multiple devices without widening exposure

The order below front-loads the verification, because the expensive mistakes happen when a second device is added before the first is proven.

1. Confirm the primary device can restore from its written backup alone before adding anything else.
2. Decide which device is the only signer, and write that decision down where you will see it.
3. Install watch-only views on every other device using the public address, never the seed.
4. If a second signer is genuinely needed, treat it as a backup and store it offline rather than in daily use.
5. Disable automatic cloud backup of wallet data on any device that holds key material.
6. Label each device in the wallet’s device or account list so a future audit is readable.
7. Wipe retired devices before they leave your control, and verify the wipe by restoring the account elsewhere.

Step seven is verification, not ceremony. A wipe you did not test is a belief about a device you no longer hold.

The post Same Wallet on Three Devices: Sync and Risk appeared first on LadyChain.