Working with Solana Accounts and Lamports

A lot of beginner confusion comes from treating a wallet, an address, and an account like they are three different things.

For this lesson, use a simpler model:

A wallet keypair controls an address
That address points to an on-chain account
That account can hold a balance in lamports

When you send SOL, you are changing the balance stored in accounts on the network.

That is the core idea this exercise is meant to lock in.

This lesson assumes you already finished the devnet setup lesson. If something looks wrong, run solana config get first and make sure your CLI is still pointed at devnet.

What You Are Learning

By the end of this exercise, you will be able to:

create two separate wallet keypairs
inspect the address behind each wallet
fund one wallet on devnet
transfer SOL to a second wallet
inspect the receiving account and read its important fields
understand what lamports and rent mean in practice

The Mental Model You Need First

Before you type commands, keep these two facts in your head:

SOL is the user-facing unit
Lamports are the smallest unit underneath

The relationship is simple:

1 SOL = 1,000,000,000 lamports

So if you send 0.01 SOL, you are really moving 10,000,000 lamports.

You do not need to memorize that number forever. You do need to understand that the CLI may show balances in either SOL or lamports depending on the command flags you use.

Step-by-Step Exercise

Step 1: Create Two Wallets

Create two fresh keypairs so you can send funds between them.

terminal

solana-keygen new --outfile wallet1.json
solana-keygen new --outfile wallet2.json

These files are not just labels.

They contain the private keys for two different wallets. In this exercise:

wallet1.json will be the sender
wallet2.json will be the receiver

Step 2: Inspect the Addresses Behind Those Wallets

A keypair file is local. The public key derived from it is the on-chain address.

Print both addresses:

terminal

solana address -k wallet1.json
solana address -k wallet2.json

You should see two different base58 addresses.

That matters because it proves you are working with two separate accounts, not two names for the same wallet.

If you want, copy the second address somewhere temporary so you can recognize it in the next steps.

Step 3: Check the Starting Balances

New wallets on devnet usually start with no SOL.

Confirm that before funding anything:

terminal

solana balance -k wallet1.json
solana balance -k wallet2.json

You should see 0 SOL or something very close to it.

This is your baseline. From here on, every command should change something you can observe.

Step 4: Fund Wallet 1

Now give the sender some devnet SOL.

terminal

solana airdrop 2 wallet1.json
solana balance -k wallet1.json

After the airdrop, wallet1 should show about 2 SOL.

If the airdrop fails, check these first:

you are on devnet
you are not being rate-limited by the faucet
you did not accidentally fund a different wallet

Step 5: Transfer SOL to Wallet 2

Now send funds from the first wallet to the second.

terminal

solana transfer wallet2.json 0.01 --from wallet1.json --allow-unfunded-recipient

This command is doing four important things:

wallet2.json tells the CLI who should receive the funds
0.01 is the amount in SOL
--from wallet1.json says which wallet should sign and pay
--allow-unfunded-recipient allows the transfer even if the receiving account has not been funded before

Why that last flag matters:

If the recipient account does not exist on-chain yet, Solana has to create it as part of the transfer flow.

Step 6: Confirm the Balances Changed

Check both wallets again.

terminal

solana balance -k wallet1.json
solana balance -k wallet2.json
solana balance wallet2.json --lamports

You should now see:

wallet1 has a little less than before because it sent funds and paid a fee
wallet2 now has about 0.01 SOL
the lamport view shows about 10000000 lamports in wallet2

That is the same balance shown in two different units.

Step 7: Inspect the Receiving Account

Now look at the account itself instead of just the balance.

terminal

solana account wallet2.json

Pay attention to these fields in the output:

lamports: the raw balance stored in the account
owner: for a normal wallet, this should be the System Program
executable: this should be false for a wallet account
dataLength: for a plain system wallet, this is usually 0

This is the first time you are looking at account state directly instead of only looking at a wallet app or balance number.

What Rent Means Here

Solana accounts need enough balance to stay alive on-chain.

That minimum is called the rent-exempt threshold.

For an empty system account, you can inspect it with:

terminal

solana rent 0

Why this matters:

wallet accounts need enough lamports to exist and pay fees
program-owned accounts often need to be funded above a rent threshold based on their data size
later, when you create accounts for programs, rent becomes part of account design

Right now, you do not need to calculate rent by hand. The important thing is to understand that account storage on Solana is not free, and balance is part of keeping account state alive.

What You Just Proved

This exercise was small, but it gave you four important facts:

A wallet keypair maps to a real on-chain account
Balances live in accounts, not in your CLI or your laptop
SOL and lamports are the same value shown in different units
A transfer is not abstract magic, it is a state change you can inspect before and after

That is the foundation for understanding transactions in the next lesson.

Common Mistakes

Using the wrong wallet by accident

When you work with multiple keypairs, always pass -k wallet1.json or -k wallet2.json explicitly. If you do not, the CLI may fall back to the default wallet in your global Solana config.

Assuming the transfer amount is in lamports

For solana transfer, the amount is in SOL by default. If you send 0.01, you are sending 0.01 SOL, not 0.01 lamports.

Forgetting that fees exist

After the transfer, the sender will not be reduced by exactly 0.01 SOL. It will be reduced by the transfer amount plus a small network fee.

Thinking every account stores user data

A plain wallet account is usually just a system-owned account with a balance and no custom data. Program accounts are where richer state starts to appear.

Summary

You created two wallets, funded one, transferred SOL, inspected the receiving account, and checked the same balance in both SOL and lamports.

That means you now understand the basic unit of state on Solana:

accounts hold value
keypairs control accounts
transfers update account balances
rent affects whether accounts can stay alive on-chain

Next, you can move into transactions with a much better mental model because you have already seen what a balance change looks like from the CLI.

Working with Solana Accounts and Lamports

What You Are Learning

The Mental Model You Need First

Step-by-Step Exercise

Step 1: Create Two Wallets

Step 2: Inspect the Addresses Behind Those Wallets

Step 3: Check the Starting Balances

Step 4: Fund Wallet 1

Step 5: Transfer SOL to Wallet 2

Step 6: Confirm the Balances Changed

Step 7: Inspect the Receiving Account

What Rent Means Here

What You Just Proved

Common Mistakes

Summary

On this page

Solana Assistant

Welcome to Solana Assistant