How to Verify a Solana Token Burn on Solscan
A wallet animation can tell you that an action finished, but a transaction receipt tells you what happened. When verifying a Solana burn, the important questions are whether the transaction succeeded, which asset was affected, how many units were destroyed, and whether account rent was also recovered.
This guide uses Solscan as the explorer entry point. Interface labels can change, so focus on the underlying fields and instructions. You do not need to connect a wallet or sign anything to inspect a public transaction.
How do you verify a token burn on Solscan?
Open the transaction signature in Solscan and confirm success. Inspect the relevant burn instruction, exact mint, source token account, and amount, including inner instructions. Check account closure and SOL balance changes separately. A transfer to a burn address or a hidden wallet item does not prove a proper burn.
Solana's Burn Tokens documentation explains the program operation. The task is to locate evidence of that operation in your successful transaction, not merely to find a word such as burn in an account label.
Where do you find the transaction signature?
Use the completion screen, your wallet's activity history, or the tool's recorded transaction link. A signature identifies the transaction. It is different from your wallet address, the token mint, or the source token account.
Open Solscan directly and search for the signature, or follow a trusted transaction link from the application. Check that the page is for the intended network and transaction. An unrelated recent transaction from the same wallet is not a substitute for the actual receipt.
For a multi-transaction cleanup, save all signatures. You may need one receipt for the first batch and others for later batches. Do not describe the entire selection as completed if you have evidence for only part of it.
What should you check before reading the instructions?
First confirm that the transaction succeeded. A failed transaction can contain an attempted burn instruction or logs from partial execution without establishing a completed burn. Read the final status and any error before interpreting the activity summary.
Then compare the signer and relevant source account with your intended operation. The fee payer and asset owner need not always be the same address, so do not identify the asset solely by whichever wallet appears first. Match the exact mint and token account you selected.
Record the slot or time alongside the signature. Those fields help place the receipt in context when comparing account state, later activity, or multiple cleanup attempts. A current balance alone may reflect additional transactions after the burn you are investigating.
Which instruction proves token destruction?
For ordinary token burns, inspect the relevant Token Program burn operation, such as Burn or BurnChecked, and its decoded amount and mint. The displayed units should be interpreted with the token's decimals; raw integer amounts are not always the human-readable quantity.
For NFT or other program-mediated operations, expand the instruction detail and relevant inner operations. Metaplex-aware burns can involve more than a plain top-level token instruction. Use the asset standard and program path to interpret the receipt.
If an explorer cannot decode the operation, keep the conclusion unresolved until you inspect it through a suitable decoder or RPC response. A missing friendly label does not prove failure, and an attractive summary badge does not replace account-level evidence.
Why is a dead-address transfer different?
A transfer moves tokens between accounts. A proper burn destroys units according to the token program's burn behavior. Sending tokens to the well-known incinerator address can strand them without performing that same supply-reduction operation.
That is why “the destination is a burn address” is not enough for this verification. Inspect what the instruction actually did. The Solana dead-address guide covers the separate developer workflow for properly burning supported stranded tokens.
Likewise, a wallet's hide action changes its display rather than establishing token destruction. Use a transaction receipt when making an on-chain claim about a burn, and use display language when all you did was hide an item.
How do you verify account closure and rent recovery?
Look for the close operation affecting the intended account and inspect its SOL destination. A burn and a closure can appear together, but either needs its own evidence. Empty-account cleanup may legitimately contain closure without any burn at all.
Use this receipt checklist:
| Claim you want to make | Evidence to inspect |
|---|---|
| Tokens were destroyed | Successful burn, mint, source, and amount |
| An empty account was closed | Successful close operation and source account |
| Rent reached a wallet | Destination and relevant lamport changes |
| The wallet gained a net amount | Full before-and-after balance accounting |
| A whole cleanup completed | All necessary successful batch signatures |
For an illustrative case, suppose a receipt shows a closure but no burn. The accurate statement is that an empty account was closed. Do not report token destruction simply because the action originated from an application whose name includes incinerator.
Why might the balance change differ from the preview's gross recovery?
Account rent can be one part of the transaction's accounting. Network costs, service fees, partner fees, required account setup, and other operations may affect the wallet's final change. Inspect the complete transaction rather than selecting only the largest incoming amount.
Also keep assets separate. A transaction may include token movement as well as SOL movement. A token-denominated reward is not a SOL rent refund, and recovering wrapped SOL principal is not the same as recovering an account's storage deposit.
For developer-level inspection, Solana's getTransaction RPC returns transaction and metadata information at a requested commitment. A missing response from one provider is not sufficient evidence that the transaction never existed.
What should you save as a burn receipt?
Save the signature or explorer link, network, successful status, mint, token amount, and relevant source account. If your claim includes recovered SOL, record the destination and explain whether your number is gross recovery or net wallet change.
Keep this record specific to what you verified. Do not infer a tax result, a token's overall safety, or every holder's activity from one transaction. The receipt is useful precisely because it supports a concrete claim about one action.
Related Reading
Frequently Asked Questions
How do I prove that a Solana token was burned?
Find the successful transaction and inspect the relevant burn operation, exact mint, source account, and amount. A transfer to a dead address or a disappearing wallet tile is not equivalent evidence. For complex NFT transactions, follow the asset program and inner instructions rather than relying solely on a summary label.
Does a Close Account instruction prove a token burn?
No. Closing an empty account recovers its remaining lamports without burning tokens. A transaction can contain both a burn and a closure, but they establish different actions. Verify the burn amount and mint separately from the closed account and SOL destination when documenting a combined burn-and-close transaction.
Why is my SOL increase different from the rent returned?
The wallet balance change can include network fees, protocol or partner charges, account creation, and other instructions in the same transaction. Check the full balance accounting instead of comparing one transfer with the final total. A gross account refund is not automatically the net increase in the wallet.