This walkthrough focuses on executing a SOL transfer using the Solana CLI - while understanding the underlying mechanics at each step. If you’ve used payment APIs like Stripe or PayPal, the flow is conceptually similar: authenticate, define recipient, specify amount, submit. The difference is architectural, transactions go directly to the network and finalize in sub-seconds, without intermediaries.
Environment Requirements
- Terminal (macOS, Linux, or Windows WSL)
- Solana CLI installed
- A keypair (existing or newly generated)
1. Configure CLI to Devnet
solana config set -ud
solana config get
Key point:
You are selecting the cluster (network). Devnet is a sandbox environment with no real economic cost. The RPC endpoint (https://api.devnet.solana.com) acts as your interface to the validator network.
Why it matters:
All subsequent commands - balance queries, transfers, account creation are executed against this network.
Example:
2. Check Balance and Fund Wallet
solana balance
solana airdrop 2
Key point:
Transactions require:
- Sufficient balance for the transfer amount
- A small fee for network processing
Airdrop behavior:
- Devnet validators mint SOL for testing
- Requests are capped (typically 5 SOL)
If airdrop fails:
You can fund your wallet using the Solana Faucet as an alternative.
Why it matters:
Without sufficient balance, the transaction cannot be constructed or submitted.
Example:
3. Generate a Recipient Keypair
solana-keygen new --outfile ~/recipient-keypair.json --no-bip39-passphrase
Key point:
You are creating a cryptographic identity:
Private key → signs transactions
Public key → acts as the address
Important nuance:
This account does not yet exist on-chain - it becomes a real account only after being funded.
Why it matters:
Solana distinguishes between:
- Off-chain keypairs (identity)
- On-chain accounts (state containers)
Example:
4. Execute the Transfer
solana transfer <RECIPIENT_PUBLIC_KEY> 0.5 --allow-unfunded-recipient
Key point:
This command:
- Constructs a transaction with a System Program transfer instruction
- Signs it with your private key
- Submits it to a validator via RPC
Flag explanation:
--allow-unfunded-recipient allows the network to create the recipient account implicitly
Why it matters:
On Solana, accounts must be explicitly created and funded. This step combines:
- Account creation
- Value transfer into a single atomic transaction.
Example:
5. Verify State Changes
solana balance
solana balance <RECIPIENT_PUBLIC_KEY>
Key point:
You are querying on-chain state post-finalization.
Expected outcome:
- Sender balance decreases (transfer + fee)
- Recipient balance increases
- Recipient account now exists on-chain
Why it matters:
This confirms the transaction was validated, executed, and finalized by the network.
Example:
6. Inspect the Transaction
Open your transaction using the signature in Solana Explorer:
Key point:
You are viewing the transaction as recorded in the ledger.
Details include:
- Accounts involved
- Instruction data
- Fees
- Slot (block inclusion)
- Confirmation status
Why it matters:
The explorer reflects canonical on-chain data - this is the definitive record of execution.
Example:
View above transaction in solana explorer
Full Command Flow
solana config set -ud
solana airdrop 2
solana-keygen new --outfile ~/recipient-keypair.json --no-bip39-passphrase
solana transfer <RECIPIENT_PUBLIC_KEY> 0.5 --allow-unfunded-recipient
solana balance
solana balance <RECIPIENT_PUBLIC_KEY>
What This Demonstrates
- Direct transaction submission to a decentralized validator network
- Atomic state transitions (account creation + transfer)
- Explicit account model requiring funding for existence
At a systems level, you:
- Defined network context (devnet RPC)
- Generated identities
- Authored and signed a transaction
- Submitted it to the network
- Observed deterministic state changes
This is the foundational workflow for interacting with Solana.
Top comments (0)