A Solana token delegation grants spending authority over a limited amount, not a separate token balance. The delegate can use that authority to transfer tokens or burn them.
| What you need to know |
|---|
| A delegate may transfer or burn tokens within the approved amount. |
| A token account stores one current delegate; a new approval replaces it. |
| The token-account owner signs the approval. |
| Revoking clears the current delegate and resets its delegated amount to zero. |
Suppose an account owner approves application A as delegate. The token account stores A’s public key and the approved amount. A can then act within that allowance without becoming the account’s owner. This is an illustrative sequence; it does not describe an incident involving a particular application.
The permission is broader than a transfer-only reading suggests. The official approval guide explicitly covers transfers and burns. A wallet label that merely says an application can move tokens would leave out a material part of what the approval permits.
One account, one current delegate
The owner next approves application B. That approval replaces A as the token account’s current delegate; it does not append B to an accumulating list of delegates. The scope here is the individual token account. It is not a statement that the wallet can have only one delegated application across all of its token accounts.
That account-level detail changes how an approval history should be read. Two approval transactions in a history do not prove that both named applications still hold authority. The current token-account state determines which delegate is recorded now, and the remaining delegated amount determines the available allowance.
ApproveChecked adds a check of the mint and decimal precision. It does not certify that the proposed delegate is trustworthy. Correct token identification and an acceptable counterparty are different judgments; the instruction helps with the former, not the latter.
Revocation changes the current permission
If the owner revokes the delegation, the token account’s delegate is cleared and its delegated amount becomes zero, as described in the revocation guide. This removes the current delegated authority. It does not undo a transfer or burn that was validly executed earlier.
Reading the example as a permission history gives three distinct states:
- After the first approval, A is the recorded delegate for the specified allowance.
- After the second approval, B replaces A on that token account.
- After revocation, the account has no current delegate and its delegated amount is zero.
At each point, current account state supplies the answer. The history explains how that state arose; it does not preserve permissions that have since been replaced or removed.
