Solana Token Delegates and Close Authority: Check the Difference

On Solana, a token-account delegate can spend or burn an approved amount, while a close authority controls account closure under the token program's rules. Those are separate permissions. Revoking a delegate does not automatically change a close authority or remove a mint-level permanent delegate.

Start with the token account, not the wallet total

The token-account reference describes an account holding tokens for one mint and one token-account owner. That account can also contain a delegate, delegated amount and optional close authority. Your wallet may control several token accounts, so inspect the specific address named by a transaction rather than assuming that one displayed token row identifies every relevant account.

The word owner can also mean the program that owns an account at Solana's base layer. In this context, distinguish that program owner from the token-account owner's authority stored inside the account. A correct Token Program label does not establish that the human controller or spending permissions are the ones you intended.

An ordinary delegate has an account-level allowance

According to the Approve Delegate documentation, approval gives an address permission to transfer or burn a limited quantity from that token account. The account stores one current delegate and allowance at a time. A new approval replaces that pair; it does not add another independent delegate slot.

Use the mint's decimals when interpreting raw units. In a fictional account with a two-decimal token, an allowance of 2,500 base units represents 25 displayed tokens. If the account holds 80 tokens, the standard allowance is not permission to spend all 80. Equally, seeing a small current balance does not prove an outstanding allowance has become irrelevant.

An allowance is permission, not evidence that spending already happened. Inspect confirmed transactions and current state separately. A delegate address may belong to an authorized subscription or another legitimate workflow; unfamiliarity is a reason to verify its purpose, rather than proof of theft. Approval alone also does not transfer the private key controlling the wallet.

Close authority needs a separate review

The Close Token Account guide explains that closure deletes the account and sends its lamports to a selected destination. For an ordinary non-native token account, the token balance must be zero first. Therefore, a close authority should not be described as an unrestricted token-transfer allowance.

There is a material exception: a wrapped SOL token account can close with a token balance, releasing its underlying SOL. The wrapped SOL explanation shows why its token amount and lamports are connected. A permission that looks like reclaiming an empty account's storage deposit needs more careful review when the account actually holds wrapped SOL.

When an explicit close authority is set, that role matters; it is not safe to assume the token owner can always close independently. The original Token Program's processor reference selects the configured close authority, falling back to the token owner when none is set. Other program versions and extensions should be checked against their own rules.

Permanent delegate is not another name for an allowance

The Token Extension Program has a PermanentDelegate mint extension. Its authority can authorize transfers and burns across token accounts for that mint. A holder cannot remove this mint-level authority by revoking the ordinary delegate on one token account. Check the mint's extension data before interpreting a clean account-level delegate field as a complete permissions audit.

This does not mean that every Solana token has a permanent delegate. Nor does the extension's presence alone tell you whether an issuer has acted improperly. It is a control capability to understand when deciding what an asset represents and what custody assumptions apply. Do not sign a site-provided transaction that claims to remove a mint authority you do not control.

Review a proposed fix before authorizing it

1. Locate the exact token account, mint and governing token program. Save the relevant transaction signatures and current permission fields.
2. Identify the role at issue: ordinary delegate, close authority, owner or mint-level extension authority. Do not treat their labels as interchangeable.
3. For an unwanted ordinary allowance, use a trusted wallet's supported revocation flow and inspect the account affected before signing.
4. For a close-authority or owner change, verify who currently has permission to make it. A site promising a universal reset may be asking for an unrelated signature.
5. After the action finalizes successfully, re-read current account state and inspect other accounts that may have separate permissions.
6. If keys themselves were exposed, treat that as a wider compromise. Removing one allowance does not make an exposed signing key private again.

The Revoke Delegate guide says revocation clears the current delegate and resets the delegated amount. This is a forward-looking permission change, not a reversal of completed transfers. Do not interpret a disconnected website or a removed browser session as proof that the onchain revocation occurred.

Changing roles is also distinct from revoking spending. The Set Authority reference describes role-specific changes. Avoid a blanket instruction to set every field to None: different roles have different validity and consequences. A clear preview should name the relevant account, role and resulting authority.

Check the recovery destination as carefully as the permission

A storage-deposit reclamation request should identify which account is closed and where its lamports go. The account's original creator is not automatically the recipient. The rent-exempt calculator can help with storage-balance context, but a balance estimate does not certify a transaction or its destination.

If you later use a no-account swap, follow the current order instructions after resolving the wallet permissions. A swap is not an account-permission repair tool. For the separate process of sending funds to an exchange order, use how the service works; do not approve an unfamiliar delegate merely because a page presents it as a prerequisite for a normal transfer.