Solana token approvals explained, and how to revoke them

Approvals are how most people actually lose tokens. Not through a stolen key. Through one signature, months ago, that quietly handed a program standing permission to take things whenever it felt like it, and that nobody thought about again until the balance was 0.

Worth understanding properly, because the mechanics are less scary than the folklore and the risk is more real than most people assume.

What an approval grants

On Solana, you can name a delegate on a token account and set an amount they're allowed to move.

Once that's set, the delegate can move up to that amount out of that token account without asking again. No second prompt, no confirmation, no notification 3 weeks later when it happens. You already said yes, and that yes has no expiry date attached to it.

Fine when the delegate is a swap program executing the trade you just asked for. Much less fine when it's a contract you approved during something that called itself a verification step.

How this differs from Ethereum

If you came from Ethereum you'll be reaching for the word "allowance", and the shape is similar enough to be useful.

Differences worth knowing: Solana delegations are per token account rather than per token contract, they specify an amount rather than defaulting to unlimited, and setting a new delegate replaces the old one instead of adding to it.

That last property helps. On Solana you don't accumulate a hundred overlapping approvals for the same token the way you can elsewhere. What you can accumulate is one live delegation per token account across many tokens, which is still plenty of surface area.

When approvals are legitimate

Plenty of normal activity involves them, so "never approve anything" is bad advice that people abandon the moment it's inconvenient.

Swapping through an aggregator. Providing liquidity. Staking. Limit orders. Every one of those genuinely needs permission to move a token for you, because the program executes at some point after your signature rather than during it, and it cannot come back and ask you again at that moment.

The test isn't whether an approval is being requested. It's whether you initiated the action that needs one, and whether the amount matches what you asked for.

When they aren't

Some requests have no legitimate version at all.

A site that only needs to read balances, asking for a delegation. A "verification" step that approves a token. An airdrop claim wanting permission over something you already hold. A delegation 50 times larger than the trade in front of you.

Then there's the giveaway pattern, which is urgency. Why would a legitimate protocol need you to approve something in the next 90 seconds? Drainers manufacture time pressure because reading takes time, and reading is the thing that stops them.

How to audit what you've granted

Do this once, then every few months.

Open your wallet address in Solscan and look at your token accounts. Delegated ones show a delegate address and an amount. Any token account with a delegate you don't recognise goes on the revoke list, and 10 minutes of this once a quarter is enough.

Several wallets now surface this directly in their interface, and there are dedicated revoke tools that list delegations and let you clear them in a few clicks. Whichever route you take, the transaction is ordinary and the fee is negligible.

How to spot a wallet drainer covers how the malicious version gets in front of you in the first place.

Revoking

Revoking sets the delegate back to none for that token account. One signature, and a network fee measured in fractions of a cent.

No downside exists here. Be indiscriminate. If you're not actively mid-way through something that needs a live delegation, clearing them all is the correct default, and any service you use again will simply ask for a fresh one when it needs it.

The habit that makes this mostly moot

Separate your wallets by job and the whole category shrinks.

Wallet 1: storage, hardware-backed, connects to nothing and approves nothing. Wallet 2: interaction, funded with what a session needs, used for anything unfamiliar. Then a bad approval is bounded by whatever was in the interaction wallet rather than by everything you own.

Setting that up takes 5 minutes and it's the highest-value security habit available to you. What connecting a wallet shares covers the related confusion between connecting and signing.

Where this touches services

This makes a useful filter, so let's be direct.

A service that runs a campaign on your coin needs one thing from you: a single signed payment. It does not need a delegation over any token, because it isn't moving your tokens. It's trading its own fleet against your mint.

An approval request from a volume service is therefore a category error at best. Any request beyond one transfer belongs in how to judge a volume service, under the heading of reasons to close the tab. The console is a fair reference for the safe flow: connect to read, configure, sign one transfer, done.