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.