Article· 6 min read· Topic: Security & Scams· by DarkGeneral

Solana Wallet Drainers: What Simulation Warnings Miss

Illustration on a near-black background of a wallet signature request for a reward claim whose preview reads balance changes: none, while red-outlined rows inside the transaction show SetAuthority owner change, Approve delegate and a durable nonce, beside a simulated-to-executed timeline ending in a red dot.

A wallet drainer almost never asks for your seed phrase anymore. It asks for one signature. The site looks like a mint, a claim or a "verify your wallet" page, the popup looks routine, and the preview might even say nothing leaves your wallet. Then, minutes or days later, your tokens are gone.

This is how a Solana wallet drainer actually works at the signing step: the three kinds of requests that hand over control without moving a token, what your wallet's transaction simulation warnings really check, and where that check runs out. Everything here comes from Solana's own docs plus write-ups from Phantom and Blockaid, so you can check me.

Why one signature is enough on Solana

A Solana transaction is a bundle of instructions, and your signature approves the whole bundle at once. There's no per-instruction permission prompt after you click approve. Blockaid puts it bluntly in its write-up on simulation attacks: when you sign, you grant every program in that transaction permission to modify the writable accounts you passed in, so any of them could move your SOL or SPL tokens.

That's why wallets lean so hard on simulation. Before you approve, the wallet runs the transaction against the current chain state and shows you the predicted result. Phantom's security tips describe it as simulating every transaction and showing a plain-language preview, with a warning when something looks suspicious. It's a good tool. It's also the exact thing drainers design around.

The requests that move nothing (yet)

The most dangerous drainer signatures don't drain anything when you sign. A preview built around "balance changes" can look clean, because the balances really don't change. What changes is who's in control.

  • Changing a token account's owner. Every token you hold sits in a token account, and that account stores an owner. Per Solana's set-authority docs, the Token Program's SetAuthority instruction changes one authority on a mint or token account, and the current authority signs the change. Sign one that hands your token account's owner role to someone else, and the account and everything in it is theirs. No tokens moved, nothing to see in the balance column. I explained the owner field in Solana token accounts and rent.
  • Approving a delegate. Solana's docs on delegates say an approval lets another address transfer or burn tokens from your token account up to a set amount, and the token account owner signs it. The drainer sets the amount, so it can cover your whole balance. The theft happens later, in a separate transaction you never see.
  • Signing with a durable nonce. Normal transactions carry a recent blockhash and expire. Durable nonces replace it with a stored nonce value, which removes the 150-slot expiry window and allows delayed submission. That feature exists for offline signing and custody setups. In the wrong hands, it means a signature you gave on a sketchy site stays usable long after you closed the tab.

None of these are bugs. They're normal Solana features with real legitimate uses, which is exactly why a drainer can slip them into a transaction that looks ordinary.

What simulation warnings do catch

Credit where it's due: wallet previews are more than a balance diff now. Phantom's security overview says you get a big warning if a transaction is interacting with a blacklisted program, "calling setAuthority when it shouldn't," trying to detect and evade the simulation, leaving a "dangling approval," or simply draining the wallet. It also says the same system flags suspicious domains, such as sites imitating a popular project.

There's also a warning a lot of people click through without reading. Phantom's help center explains that "This dApp could be malicious" appears when Phantom can't accurately simulate a transaction, because of dynamic or non-standard behavior, so it can't give you the usual protection. Read that one as "the safety check couldn't see what this does." That's not a neutral message. That's the check telling you it's blind.

What simulation can't catch

A simulation is a prediction made at one moment, against the chain state at that moment. Blockaid's write-up describes how drainers exploit that gap with what security people call a time-of-check-time-of-use (TOCTOU) attack:

  • The program behaves during the check. The drainer deploys a program whose malicious path stays switched off while your wallet simulates, so the preview shows a harmless result.
  • The state flips after you sign. The drainer controls the site, so it holds your signed transaction. It sends its own transaction first to flip the switch, then submits yours.
  • Yours runs differently than previewed. Blockaid's real example, from a drainer it tracks called Vanish, drained roughly $3,000 in tokens, with the victim's transaction landing just seven blocks after the attacker's state-setting one.

Blockaid's conclusion is the honest one: simulations "cannot anticipate future changes in the program's behavior." It mentions the Lighthouse protocol, which adds assertion instructions so a transaction fails if the end state doesn't match what was expected, and also notes the limits: extra instructions can push a transaction past Solana's size limit, and it doesn't address most draining attempts.

Durable nonces stretch that same gap from seconds to however long the nonce stays unused. The preview you saw described the chain as it was when you signed, not when the transaction finally lands.

How to sign like someone who's been drained before

  • Treat "nothing changes" as a question, not an answer. If a claim, mint or "verification" shows no balance change but the wallet mentions authority, owner, delegate or approval, stop. A free claim doesn't need control of your token accounts.
  • Never push through a "can't simulate" warning on a site you found through a DM, reply or airdrop. That warning plus an unknown site is the worst combination there is.
  • Use a burner for anything new. A separate wallet with only what you need for that mint or claim caps the damage when a site turns out to be a drainer.
  • Check the receipt afterwards. Open the transaction on an explorer and look for approve or setAuthority instructions you didn't expect. How to read a Solana transaction shows where they appear.
  • Check the site before the signature. Most drainers start as a fake site. My guide on how to check if a crypto website is a scam covers the tells.

If you already signed something bad

Move fast and in the right order. Phantom's drained-wallet article says to disconnect suspicious apps, but warns that disconnecting does not revoke spending permissions you already granted, so you still need to revoke approvals. If the recovery phrase or device may be compromised, move trusted assets to a new wallet, and don't touch unknown tokens while you do it. It's also clear that nobody, not even the wallet maker, can reverse a transaction or recover stolen funds, and there's no promise you get anything back. An owner change can't be undone with a revoke, because the account isn't yours anymore. That's why the habits above matter more than the cleanup.

What this doesn't cover

I'm describing patterns that the Solana docs, Phantom and Blockaid have documented. I haven't tested any specific drainer kit or security product, and I'm not rating one wallet's protection against another. Detection rules change all the time, so a warning that fires today might be worded differently next month. This is also a different case file from address poisoning, where you send the funds yourself, and from token-level traps like a permanent delegate, which I covered in suspicious activity in new token launches.

The takeaway

A Solana wallet drainer doesn't need your keys. It needs one signature that hands over an owner role, a delegate approval or a long-lived signed transaction, and those can all look like "nothing happens" in a preview. Simulation warnings catch a lot, and you should read every one, but they predict the chain at one moment, and drainers build for the moment after. Read what you sign, keep fresh mints on a burner, and treat "can't simulate" as a hard stop. Have you ever caught a sketchy approval in a wallet popup before you signed it?

Still building. Still here. 🫡

Keep reading: all articles · DarkGeneral Labs · live crypto news · latest posts on X.

Copied!