Check a Solana send from mint to receipt

Identify SOL or the exact token mint

Start with the recipient's current receiving instructions. If you are sending a token, verify its mint identity and confirm that the destination supports that asset on Solana. A token symbol is not enough to establish that two balances represent the same asset. For a hosted account, also check any deposit minimum or reference requirement.

Confirm that the wallet and destination use the intended network. Mainnet, devnet, and testnet are separate clusters. An address or transaction signature viewed on the wrong cluster may show no useful result, so establish the network before diagnosing an apparently missing payment.

Account for the receiving token account

A Solana token account records holdings of a specific mint for an owner. Wallets often use an associated token account, whose address is derived from the owner, mint, and token program. If the receiving account needs to be created, the transaction can require a minimum SOL balance for its storage as well as a network fee.

The official token account guide explains how creation is funded. Review any account-creation line in the preview and identify the payer. A mint address identifies a token; it is not a substitute for the recipient instructions. Let the supported wallet workflow handle the account details you have verified.

Keep the fee budget and instructions clear

Solana network fees are paid in SOL and can include a prioritization component. Review the current proposed cost rather than expecting every transfer to cost the same. When sending tokens, confirm both the token amount and the SOL funding required from the payer. Account creation, when needed, is a separate budget item.

A transaction may include more than one instruction. Check that all proposed actions fit the intended send. Unexpected authority changes or additional asset movements deserve investigation before signing. The SOL and token send guide explains the account model and why a single transaction can contain several related actions.

Check success and confirmation separately

Save the transaction signature and inspect the result on the correct network. Check whether the operation succeeded, which asset moved, and which account received it. Then read the commitment status: processed is an early observation, confirmed has a supermajority of stake voting on the block, and finalized is the strongest standard confirmation state.

The Solana RPC commitment definitions describe these levels. A finalized record can still contain a failed operation, so status strength does not replace checking success. For a hosted recipient, compare the record with its own deposit policy. Use the pending transfer checklist before deciding that a second send is needed.

Common Solana send questions

Why can a token send need extra SOL?

The payer may need to fund creation of a receiving token account in addition to the transaction fee. Check the preview's breakdown and current account state. Do not assume the recipient must fund every part; the supported workflow determines which account pays.

Is a missing explorer result a reason to retry?

First verify the network, signature, and wallet activity. Ordinary transactions have a recent-blockhash validity window, so an expired attempt needs different handling from one already included. Resolve the original outcome through the wallet's supported status workflow before signing a new independent payment.