How to send SOL and verify the payment

Get the receiving details for the intended route

Ask the recipient for their Solana receiving address and confirm the network. For a deposit service, open its current SOL deposit flow and use the details shown there. For another self-custody wallet, use the receiving screen for its selected Solana account.

Solana mainnet, devnet and testnet have separate state. An address copied from a test exercise can look valid on mainnet while referring to a different economic context. Keep the network with your transfer record.

Copy the address from the intended source, then compare the full destination in the final request. Address-history entries and shortened prefixes can make a wrong destination look familiar. If the route uses a name service, review the resolved address.

This guide concerns ordinary SOL payments. A validator's vote address is a delegation target, not a substitute for the native-staking procedure. Sending a normal payment to a program or other specialised address does not invoke the application operation you had in mind.

Choose the amount and understand the remaining balance

Open Send, select SOL and enter the destination and amount. The wallet prepares the requested payment and estimates its costs. A straightforward transfer uses a System Program instruction and names a transaction fee payer.

In a teaching example, Alice starts with 2 SOL and sends 0.25 SOL. Assume she pays a total network fee of 0.000005 SOL and there are no other instructions or account costs. Her ending balance is 1.749995 SOL, while Bob receives 0.25 SOL.

The 0.000005 SOL is a chosen example fee. Your wallet's current estimate and the eventual transaction's fee field describe your operation. A transaction with extra signatures, a priority component or additional actions can differ.

A Max button may reserve costs according to the wallet's own implementation. Read its proposed recipient amount and your remaining funds. If you intend another unsponsored action later, that action will also need a fee payer with enough SOL.

A new recipient can introduce a storage minimum

An ordinary address with no existing account state is different from a funded receiving account. Solana's runtime restricts new accounts from entering a below-minimum storage state. A tiny first transfer can therefore fail a rent-related check even when the sender can pay the processing fee.

Query the current minimum for the relevant account data size using getMinimumBalanceForRentExemption. A basic SOL account has zero data bytes. Use the actual cluster's result rather than a fixed number copied from an old walkthrough, especially during a phased rent reduction.

As a teaching calculation, suppose the required zero-data reserve is 500,000 lamports, the recipient has no account and the proposed receipt is 100,000. The proposed new balance would fall below that selected requirement. Increasing a priority payment does not fund the missing recipient balance; the operation needs a supported amount or funding arrangement.

The selected numbers are not current network constants. Inspect the actual error, recipient state and requested transfer. For an existing recipient, read the resulting balance and transaction instead of assuming that every small payment needs a new reserve. The storage-balance guide explains creation, recovery and closure as separate operations.

Transfer 0.25 SOL from a 2-SOL balance

Review the exact action before signing

Check the selected account, cluster, destination and amount in the wallet's approval screen. Inspect the program and any decoded additional instructions. A payment request should be explainable in terms of the operation you chose.

If a hardware signer is involved, compare the information available on its display with the requested action. The wallet can prepare a transaction while a separate device provides the signature.

Approve only after the message is final. The signature authorises the message bytes, so changing the amount or destination afterward requires a new signature. Signing also does not guarantee that the network will execute the request: funding, validity and program checks still apply.

After the application submits it, save the signature or transaction ID. If the screen shows a submission problem, retain that identifier before starting another attempt. The initial request can still have reached the network.

Read the payment’s result

Open the signature in an explorer on the correct network. First read the execution result. A transaction can be final in the accepted history and still report an execution failure; finality and success are separate fields.

For the simple payment, locate the System Program transfer, its source and destination and the amount. Then inspect the fee payer and the SOL balance changes. For our teaching example, the sender's decrease includes both 0.25 SOL and the fee.

Confirm the destination's receipt through its account data. If that destination belongs to an exchange, also check the exchange's internal deposit record. Network receipt and customer credit are two stages.

A wallet's activity list is a convenient summary. The signature links to the more precise evidence. Keep it with the agreed amount and recipient when paying an invoice or resolving a transfer question.

Resolve the common failure paths

Insufficient SOL. Compare the transfer amount plus actual required costs with the fee payer's spendable balance. Tokens in the same wallet do not automatically pay a SOL requirement.

Expired or unknown blockhash. A wallet normally obtains validity information while preparing the request. Delays and differing RPC views can make it unusable. Inspect the original signature and use the wallet's supported refresh flow before signing a new attempt.

Successful transfer, stale wallet display. Check the destination account and network directly. Refresh the interface or investigate its data service after the receipt is established.

No clear result. Continue checking the same signature with suitable history coverage. A timeout means you lack an answer, not that no payment happened. Follow the diagnostic sequence before authorising a duplicate.

If the recipient address was wrong, inspect where the transfer actually went and contact the relevant recipient or service if identifiable. Validators do not have a general payment-cancellation function.

Common questions