Basic · LESSON 01 OF 06
1. Solana, SOL, and a shared ledger
By the end, you can explain solana’s validator, proof of history, consensus, sol, wallet, and shared-ledger roles, including how cluster-specific alpenglow migration changes consensus.
Read the workflow
The wallet controls the signing key and approves a message. The RPC service transports a signed transaction or returns a read result; it does not hold the learner’s key. The selected Solana cluster processes transactions and stores the resulting SOL, token, and program account state. A signature and its cluster must be considered together.
- WALLET + SIGNER
- SIGNED MESSAGE
- RPC RELAY
- CLUSTER ACCOUNT STATE
Read a text version: Proof of History and consensus roles
The upper row represents a cluster still using legacy TowerBFT: Proof of History contributes verifiable ordering and pacing, then validators execute or replay transactions and use stake-weighted TowerBFT votes to establish agreement. The lower row represents a cluster after its Alpenglow migration: Votor uses direct validator votes and quorum certificates to establish finality. The visual does not mean all clusters migrate together. Transaction execution stays in the SVM, and Proof of History alone never decides which fork is accepted.
- Proof of History orders legacy entries
- TowerBFT validators vote and build lockout
- Votor direct validator votes
- Quorum certificates establish finality
FIELD NOTE 01
A network, not an account provider
Solana is a network whose validators execute transactions and agree on ledger state. An application is a separate product built around that network. A website can go offline while the ledger continues. An exchange balance may instead be a claim on the exchange: it is not automatically an asset controlled by your own signing keys.
FIELD NOTE 02
Proof of History and consensus answer different questions
A validator selected as leader proposes ordered entries for its slot. In the legacy TowerBFT design, Proof of History (PoH) creates a verifiable sequence that helps establish ordering and pacing. Validators execute or replay the transactions and vote on which fork to accept. PoH is not, by itself, a vote, a validator identity check, or the rule that makes a block canonical. As each cluster migrates to Alpenglow, its Votor consensus protocol replaces TowerBFT: validators exchange votes directly and certificates record agreement. PoH no longer paces block production on a migrated cluster, while the SVM continues executing transactions. Migration happens separately on Mainnet, Devnet, and Testnet. Read-only `getAgGenesisCert` requests returned `null` for Mainnet and certificate objects for Devnet and Testnet on 2026-09-29; Solana defines those results as not migrated and migrated. A `Method not found` error instead means the RPC node is too old to answer. Check the cluster and RPC response live rather than carrying a status forward.
FIELD NOTE 03
What SOL does
SOL is the native asset used for transaction fees and staking. A lamport is a small accounting unit: one SOL equals one billion lamports. Token balances and SOL balances are different. Owning a token does not ensure that a wallet has enough SOL to submit a transaction.
FIELD NOTE 04
A wallet signs; the shared ledger stores account state
A wallet is the learner-facing software for finding addresses and requesting signatures. In a common self-custody setup, the wallet can use a signing key locally; the secret key should not be sent to the academy, an RPC provider, or an explorer. The wallet usually asks an RPC endpoint for account and transaction data, then displays its observation. That balance is not stored inside the wallet app: it is derived from account state on a particular Solana cluster. A normal address can have an account holding lamports, while token quantities are recorded in token accounts associated with a mint. Programs keep their own state in other accounts. Some services instead show an internal database balance and control the withdrawal keys themselves. When a balance or approval appears on screen, ask which cluster and address it refers to, who controls the signing authority, and whether the displayed fact came from a chain read or a service's private records.
FIELD NOTE 05
Transactions change shared state atomically
A Solana transaction is a signed message containing one or more instructions. Each instruction names a program and the accounts that program may read or change. The runtime executes the instructions in sequence as one atomic operation: if an instruction fails, the requested state changes are rolled back. The transaction fee can still be charged for a failed attempt. That distinction explains why a wallet may show a fee even when a transfer did not complete. It also explains why checking only the first instruction is not enough: review the full message and each program it invokes. When you describe a result, separate the wallet signing step, RPC submission, execution result, and the commitment level observed afterward.
FIELD NOTE 06
Trace a payment using separate evidence
Suppose Ana intends to send 0.2 SOL to Ben. First, both learners identify the intended cluster and verify Ben's address; matching a nickname is not enough. Ana's wallet builds a transaction message and asks the required signer to approve it. A returned signature identifies a signed transaction, while an RPC response can show that a service accepted a submission request; neither alone proves successful execution. The cluster processes the instructions atomically. The explorer or another RPC read can then show the execution result, fee, and resulting account state at a stated commitment level. Check the same cluster, the recipient address, and the transaction result together. If execution fails, requested instruction changes roll back, but a transaction fee may still be charged. A careful report records the cluster, signature, execution status, fee, and relevant before-and-after account evidence. It does not turn a wallet's “sent” label into proof of settlement.
FIELD NOTE 07
Read amounts and costs as separate facts
SOL is the native asset and lamports are its integer subunits: one SOL is one billion lamports. A wallet balance is an observation about an address on a specific cluster; it does not describe SOL held in an exchange account or guarantee that every displayed token is authentic. Solana transaction fees are paid in SOL and have a base component plus an optional prioritization component. Account creation may also require a separate minimum balance for storage. Before a learner signs a mint, the wallet should show the destination and its current cost estimate. Do not hard-code a promised fee or treat a prior estimate as a quote: the transaction, network conditions, and account state can change.
FIELD NOTE 08
Separate ledger proof from human claims
A public ledger can show that an address signed or received an asset, subject to the exact transaction and program rules. It cannot tell you by itself who controls the address in everyday life, whether a human completed a course honestly, or whether an issuer’s assessment was rigorous. A website may show a name next to an address, but that pairing is an application statement unless it was verified by another process. When writing a report, state the narrow observation first, then name the source and cluster. Put conclusions about legal identity, learning effort, or professional competence in a different evidence category unless you have independent proof for them.
MAKE THE CONNECTION
A detail worth keeping
A ledger is a shared record, not a promise about the organisation around it. Different wallets can show the same network in different ways. Ask which state is being queried, how current it is, and which authority signed the action. PoH was an ordering and pacing aid in the legacy consensus design, not agreement by itself. Alpenglow changes the validator voting/finality path separately on each cluster, while transaction execution remains in the SVM.
Work through an example
For 0.2 SOL, move the decimal nine places: 200,000,000 lamports. Compare this integer with the wallet display. Keep calculations in integer units until the final display to avoid rounding mistakes.
On paper, trace a fictional 0.2 SOL payment. Mark the wallet and signing authority, the RPC relay, the selected cluster, the sender and recipient account state, and the evidence needed to report success. Calculate the transfer in lamports, then list what a wallet screenshot, a returned signature, and a successful execution result each do and do not prove. Include the fee as a separate possible debit and explain how a custodial exchange balance can differ from a self-custody account observation. Use no real address, wallet, or funds. Then read the official Alpenglow migration guide and `getAgGenesisCert` RPC reference. Classify a null result, a certificate object, and a method-not-found error correctly. If you make optional read-only requests to Mainnet, Devnet, and Testnet, record each cluster and the observation date; do not infer one cluster’s state from another.
GUIDED PRACTICE · BASIC
Do the work, one step at a time
Use fictional addresses and disposable test data. Do not enter a recovery phrase or private key. Unless a lesson explicitly says “read-only Devnet,” use paper or a local test and do not connect to a public network.
- Convert a sample amount to integer lamports.
- Trace one fictional payment from signing to final evidence.
- Explain which party is trusted at each step.
- Mark which observations would still be missing after a wallet screenshot.
- Read the Alpenglow status RPC reference and distinguish null, certificate object, and method-not-found responses.
Before you move on, check your reasoning
- Convert 0.025 SOL to lamports.
- Explain who can sign, who relays, and what evidence confirms settlement.
- Describe one thing a blockchain record cannot establish.
OPEN SELF-CHECK · UNGRADED
Pause and test your reasoning
Devnet reports an Alpenglow genesis certificate, but your Mainnet RPC returns null. What is the strongest conclusion?
- Mainnet has migrated because both clusters use Solana.
- Devnet’s result does not establish Mainnet’s migration state; check Mainnet with a current compatible RPC.
- Mainnet has failed because null means the chain is offline.
Reveal one best answer and its explanation
One best answer: Devnet’s result does not establish Mainnet’s migration state; check Mainnet with a current compatible RPC.
Migration is cluster-specific. A null response from a compatible endpoint means that cluster has not reported the certificate, while an unsupported-method error is inconclusive. Record the cluster, endpoint capability, and observation time.
Sources: Alpenglow Upgrade Guide ↗ · getAgGenesisCert RPC Reference ↗
This practice is not scored, saved, or part of a certificate. Account-based lesson checkpoints and level exams remain separate.
Scored checkpoints and level exams are online and require a free account. They are not included in this pack.
READ THE SOURCE
Go deeper in the official docs
Reviewed on 2026-09-29. Protocol documentation can change; check the linked page’s current version when you reconnect.