A Solana send can transfer native SOL or a token managed by a token program. Wallets often present both through a similar send screen, but the underlying accounts and possible costs differ. Understanding those differences helps when a transfer preview includes account creation, a balance seems absent, or an explorer reports a status you have not seen before.
Start with the Solana send overview for the basic preparation sequence. This guide focuses on the network details behind that sequence: the token's identity, the account receiving it, the SOL budget, and the evidence needed to confirm the outcome.
Distinguish native SOL from tokens on Solana
SOL is the network's native currency and is used to pay transaction fees. Tokens on Solana are commonly described as SPL tokens. A mint account identifies a particular token, while token accounts record holdings of that mint for their respective owners. The wallet's asset list brings these records together into a familiar balance display.
A token name or symbol alone does not establish its identity. When the destination expects a particular token, confirm the mint through trusted receiving instructions or the asset issuer's established information. Also confirm that the receiving service supports that token on Solana. A label shared with an asset on another blockchain does not make the two deposits interchangeable.
The network matters even when the address looks plausible. Solana mainnet is separate from development and testing clusters. Before investigating a missing transfer, establish which network the wallet and explorer are displaying. An empty search on the wrong cluster does not describe what happened on the intended one.
Why a token transfer can involve another account
A Solana token account holds units of a specific mint and records the authority that can control those tokens. An associated token account, or ATA, is a commonly used token account with an address derived from the wallet owner, mint, and token program. This gives applications a consistent way to locate a wallet's account for a particular token.
If the required receiving account does not exist, the transfer workflow may create it. Account creation requires a minimum SOL balance for its onchain storage in addition to the transaction fee. The payer can be someone other than the recipient. The official Solana token account documentation explains the account structure and the funding role.
Read account creation in the preview
An account-creation line can explain why one token send needs a different SOL budget from another. Check which account is being created, which token it belongs to, and who is funding it. Do not assume every amount leaving the fee payer is the network transaction fee; account funding is a separate part of the cost review.
For ordinary wallet use, follow the destination's supported receiving workflow. Avoid manually substituting a mint address or an account copied from an explorer into a recipient field. The issuer's mint, a wallet's public address, and a token account can appear near one another, but they serve different purposes. Clear receiving instructions are more reliable than guessing from where an address appears.
Keep the SOL budget visible
Solana transactions require a fee paid in SOL. The fee includes a base component and can include a prioritization component. A prioritization fee may improve scheduling relative to competing transactions, but it cannot guarantee execution or repair an invalid instruction. Review the wallet's current estimate instead of relying on an old example.
For a token transfer, check both the token balance and the SOL balance available to the payer. A wallet may have enough tokens for the intended send while lacking SOL for the transaction or required account creation. An application may arrange a separate payer, but that arrangement should be clear in its supported workflow.
When sending native SOL, include the fee and any additional planned actions in the balance review. If you intend to send tokens afterward, consider their fee requirements before removing your available SOL. Recheck the budget for each transaction; a sequence of transfers is easier to reconcile when every preview explains its own costs.
Review the instructions as well as the amount
A Solana transaction can contain several instructions. The network executes them together: if an instruction fails, the transaction's state changes are reverted, although a transaction that is processed and fails can still incur a fee. This is why a single activity item may describe account setup and a token transfer in the same operation.
Read enough of the preview to understand the requested actions. For a straightforward send, the recipient, asset, amount, and payer should match your plan. If the wallet shows unfamiliar authority changes, additional asset movements, or an operation you cannot explain, stop and investigate through the wallet's established documentation before signing.
The wallet send checklist provides a repeatable review order. Compare the full destination address with trusted instructions and verify the token mint where relevant. If a small test is appropriate, account for deposit minimums and all costs, then verify actual receipt before preparing the remaining amount.
Understand processed, confirmed and finalized
Solana tools can report different levels of commitment, which describe the network confidence associated with the observed block. These words should be read as status definitions rather than interchangeable versions of a green check mark.
- Processed: a node has processed the block containing the transaction. This is an early view and can still be rolled back.
- Confirmed: the block has received votes from a supermajority of active stake.
- Finalized: the block has reached the network's strongest standard confirmation state.
Also read whether the transaction succeeded. Commitment describes the block's standing; it does not replace checking the operation's error status or the asset movement. A failed transaction recorded in a finalized block is still a failed transfer. Verify the receiving amount and account alongside the status.
For a hosted deposit, the service may apply its own crediting requirement. Compare the explorer record with that requirement and the account's deposit history. If the transaction succeeded but the balance is absent, avoid sending again merely to test whether the first one worked.
What an expired or missing transaction means
Ordinary Solana transactions use a recent blockhash with a limited validity window. A transaction that has not landed before its blockhash expires cannot simply be treated as indefinitely pending. The wallet may need to construct a new transaction using fresh network information. Specialized durable-nonce workflows behave differently, so use the wallet's supported diagnosis.
A missing explorer result alone is not enough to authorize a retry. First verify the network, copy the transaction signature accurately, and check the sending wallet's activity. The explorer or its data provider may not have the same view as the wallet at that moment. The useful question is whether the original transfer was actually included and succeeded.
Before creating a new send, resolve that question through the wallet's transaction status and an appropriate network record. Repeatedly signing new transactions can create separate transfer attempts. Keep each signature with its status so an old attempt does not disappear from your accounting. The pending crypto transfer guide explains a structured approach to collecting that evidence.
When the recipient cannot see the token
Start with the successful transaction record and verify the exact destination account, mint, and amount. Then review the recipient wallet's supported asset display. A wallet interface is a view of network data, so a missing asset row should lead to a record check before it leads to another payment.
For an exchange, compare the mint and network with the account's current deposit instructions, including any required reference information and minimum amount. The guide to sending crypto to an exchange explains how to prepare a useful deposit support record. Share the signature and relevant public details through the service's established support channel, never a recovery phrase.
Conclusion: match the account, budget and outcome
A careful Solana send establishes which asset is moving, which account should receive it, and what SOL funding the complete transaction requires. After submission, check both execution success and commitment status, then confirm the recipient's credit. These distinctions help explain account-creation costs and prevent an unclear wallet display from turning into an unnecessary duplicate transfer.
