Solana token approvals: inspect a delegate and revoke its allowance

Find the holding account before reading the allowance

A wallet address can control several token accounts, including several for the same mint. Each holding account has its own state. Start with the mint and the exact source token account named by the approval or by the unexplained movement.

Inspect the base account's owning program, then decode its token state under that program. The Token Program account owner and the token owner stored in its data describe different roles. The stored token owner normally controls the ordinary approval, while the program enforces its rules.

Read the delegate address and delegated amount in raw units, then format that amount using the mint's decimals. An explorer's app label is useful context; the stored public key identifies the current permission.

Follow a bounded approval

Use an illustrative token with six decimal places. A holding account contains 500 tokens, or 500,000,000 raw units. Its owner approves a delegate for 100 tokens, recorded as 100,000,000 raw units. A delegate transfer of 30 tokens consumes part of that authorization.

The resulting token balance is 470 and the remaining ordinary allowance is 70, assuming no other movements or approval changes. The allowance is permission to use part of a balance, not a second balance added to it. An approval for more than the current balance does not create tokens.

A token account stores one current ordinary delegate and allowance. Approving a new delegate replaces that pair. Keep the scope of this rule at the holding-account level; application-specific permissions can use different program state.

Revoke and verify the new state

The Token Program's Revoke instruction clears the ordinary delegate and resets the delegated amount to zero. Use a trusted wallet control or the official program workflow that supports the actual token program. Review the source account and operation before signing.

Confirm acceptance, then read the same holding account again. A successful response from a website is less useful than seeing the intended fields cleared in accepted state. Keep the signature if you need to show when the permission changed.

Revocation affects future authorized use. It does not reverse a transfer that already executed. If you use an application that relies on that allowance, revocation may stop its later actions until you establish a new permission.

Two controls affect different records

Check the powers that an ordinary revoke does not cover

Token-2022 can define a permanent delegate on the mint. That role can authorize transfers and burns across accounts for the mint under the extension's rules. An individual token-account owner cannot remove that mint-level role through an ordinary account Revoke.

A SetAuthority operation changes a particular authority, such as a token-account owner or a mint's freeze authority. It is a different state change. Review the role, old authority and new authority rather than treating every permission change as the same approval.

Native SOL also uses a different account model from an SPL token holding account. A generic token-approval scanner does not prove that all possible wallet risks have been examined.

Keep browser sessions separate from account permissions

Disconnect a site to stop the ordinary wallet connection. Revoke an onchain delegate to remove that stored token permission. Inspect message-signing requests according to the service action they authorize. These controls affect different records.

For a review of an old application, list the exact accounts it used, inspect their current authorities and remove the permissions you no longer intend to grant. If signing keys may be exposed, continue with the separate compromised-wallet response. An attacker who can sign as the owner can authorize a new permission.