Basic · LESSON 08 OF 08
8. Staking, validators, and the stake-account lifecycle
By the end, you can explain how native sol delegation supports stake-weighted consensus, distinguish a stake account's total balance from its effective delegated amount, identify stake-account authorities, and trace activation, deactivation, rewards, and withdrawal without making an investment claim.
Look up Solana terms in the glossary
Optional reading history is saved only in this browser. It is not a scored checkpoint or exam result.
In this lesson8 field notes · practice · sources · checkpoint
Read a text version of this diagram
The flow starts with wallet SOL and a separate stake account with a stake authority and a withdraw authority. The learner delegates that account to one validator. An ordinary transfer into an already-delegated account increases its balance, not its delegation; Solana recommends a separate stake account for added delegation. Stake warms up across epoch boundaries before it may become active and reward-eligible; rewards are not guaranteed. A signed deactivation starts cooldown. Network limits can span epochs, leaving a fully inactive portion withdrawable while the remaining portion continues deactivating. Check delegated and inactive amounts, withdraw authority, and lockup before deciding what is active or withdrawable. Arrows mark observed transitions, not promised timing.
- WALLET SOL
- STAKE ACCOUNT
- DELEGATE
- ACTIVATING
- ACTIVE
- DEACTIVATING
- INACTIVE
- WITHDRAW
FREE INTERACTIVE CASEBOOK · ONLINE OR OFFLINE
Read the stake state before you act.
Work through six fictional stake-account records. Check active and inactive amounts, account authorities, epoch, lockup, and RPC-method evidence before deciding what a record proves. This casebook is local-only: it does not connect a wallet, call an RPC, sign a transaction, or save answers.
Open the Stake Lifecycle Casebook Download the offline casebookEvery address, amount, and observation is fictional. Real stake state is cluster-specific and can change at epoch boundaries.
Staking adds voting weight; it is not a wallet transfer to a validator
Proof of stake lets validator voting influence depend on stake delegated to the validator. A SOL holder may delegate through a wallet that supports native staking. Delegation changes how stake contributes to consensus; it does not hand the validator the learner’s recovery phrase or withdraw authority. Keep the distinction clear: the learner authorizes a stake-account instruction, the validator participates in consensus, and the cluster records the resulting state. A wallet button is an interface to an on-chain action, not the action’s final proof. Check the selected network and transaction details before approving anything. This lesson stays read-only; you do not need to own SOL, connect a wallet, or create a stake account to complete it. The Academy never asks for a recovery phrase or private key. A balance on an exchange or in a custodial service may have different control and withdrawal terms from a native Solana stake account, so do not treat those product types as interchangeable.
A stake account has its own state and authorities
A stake account is a program-owned account with a structure for delegated stake; it is different from a normal system account used to hold and send SOL. Its address is a lookup handle, not necessarily a keypair whose private key controls the account. Solana documents a stake authority and a withdraw authority. The stake authority can sign delegation, deactivation, split, merge, and authority-change operations. The withdraw authority can withdraw inactive stake and can change either authority. They may be the same address or different addresses. This division is why an explorer label or unfamiliar account address is not enough to understand who can act. Inspect the configured authorities using a trusted read path. Never ask a validator, RPC provider, course, or support person to receive your recovery phrase.
Delegation moves through epoch-based states
Delegating does not make stake active in the same instant that a wallet returns a signature. Solana’s current stake-account reference describes a warm-up in which portions become active at epoch boundaries; the network limits how much total stake can change state in an epoch. The visible path is generally inactive → activating → active. After a deactivation request, active portions move through deactivating toward inactive. A large or network-limited deactivation can be partial: the account may still be labeled deactivating while some stake has already become inactive and may be withdrawable. Inspect inactive and effective amounts, not only the account-level status. Warm-up and cooldown duration depend on the network’s other stake changes, so a fixed number of hours or epochs is not a promise. A node’s status response and an explorer view are observations with an endpoint, cluster, and time. Record all three if comparing them. Activating does not mean the wallet request failed. Deactivating does not establish that the full balance is available or that none of it is; check the amount in each state. Wait for evidence of the relevant amount instead of guessing from elapsed time.
An RPC method can disappear without the account disappearing
Some older staking tools call `getStakeActivation`. Solana now marks this method removed in Agave v2.0, with no single-method replacement. A `Method not found` response describes that endpoint’s supported methods; it does not prove that a stake account is invalid or absent. To calculate activation for the current epoch, a reader must fetch and decode the stake account and StakeHistory sysvar with `getAccountInfo`, obtain the current epoch with `getEpochInfo`, and apply the protocol’s warmup/cooldown rules. Reproducing the legacy active/inactive amounts also requires the account’s total lamports and rent-exempt reserve; subtracting effective stake from delegated stake alone can misstate what is inactive. Current account and sysvar responses cannot reconstruct arbitrary historical epochs. In this Foundations lesson, use a current trusted viewer rather than writing a decoder, and report the cluster, endpoint, observation time, and fields inspected.
One stake account delegates to one validator at a time
A single stake account can be delegated to one validator at a time. If an owner wants separate delegations, separate stake accounts are required; Solana’s account reference describes splitting an account as one way to create another account with part of the funds. Do not infer that every lamport in a stake account is actively delegated just because the account has a validator name. An account can contain inactive or transitional stake, and deposited SOL does not by itself prove the delegation state the owner expects. Ordinary SOL sent to an already-delegated stake account increases its balance but does not automatically increase its delegation. Check the delegated and effective amounts separately. Solana recommends creating a separate stake account for additional delegation; do not deactivate and redelegate an existing account based only on this lesson. This structure also makes splitting consequential: check the destination stake account, authority configuration, cluster, and transaction summary before signing. A validator’s public identity and advertised metrics are evidence to inspect, not a guarantee about future uptime or rewards. The Academy does not rank validators or recommend one.
Rewards are conditional; no percentage is promised here
Native staking can make an owner eligible for protocol rewards when stake is active, but a lesson cannot promise a rate or outcome. Solana’s official overview describes reward results as depending on changing network conditions and validator factors such as uptime and commission. The linked overview also contains figures that may age; check the current wallet and current official documentation rather than relying on a copied percentage. A quoted estimate is not a guaranteed payment, does not prove the stake is active, and does not remove price, operational, or custody risks. This is educational material, not financial advice. You do not need to stake, buy SOL, choose a validator, or take a financial risk to earn a course credential. If an app says “guaranteed,” stop and verify the exact product terms before approving anything.
Deactivation and withdrawal are separate actions
To withdraw native stake, the requested amount must be inactive and the configured withdraw authority must authorize the withdrawal. When deactivation spans multiple epochs, a fully inactive portion may be withdrawn while the remaining stake continues deactivating. A lockup may still prohibit moving inactive SOL until its date or epoch condition is met. A deactivation instruction is not an instant redemption promise, and an account-level status alone does not show how much is withdrawable. Before an actual withdrawal, read the inactive amount, configured authorities, lockup, network, destination, and wallet-simulated transaction. Leave enough SOL available for any separate network transactions the owner chooses to make, and read the exact fee shown by the wallet. The fee is paid by the transaction’s fee payer; the Academy never sponsors a learner’s staking or credential transaction. No action in this learning exercise touches a live account.
Read an example without signing it
Use the fictional record in the guided practice. It lists Devnet, stake account `StakeExampleA`, stake authority `LearnerExample`, withdraw authority `RecoveryExample`, validator `ValidatorExample`, and status `deactivating`. The record reports no lockup.
What does the status tell you? `Deactivating` means the cooldown has started. It does not tell you how much SOL is inactive. At an epoch boundary, some stake may become fully inactive while the rest continues cooling down. Check the inactive amount before deciding what can be withdrawn. Then verify the withdraw authority and lockup.
The record does not show the exact time remaining, future rewards, validator quality, or the real identity of its example keys. For a real investigation, record the cluster, account address, explorer or RPC endpoint, observation time, and returned fields. If sources disagree, record both results and check whether they query the same cluster and recent state. Do not fill gaps with a screenshot caption or promotional estimate.
A detail worth keeping.
Delegation is an account-state and consensus relationship. It does not mean that a validator receives the owner’s secret key. Keep authority, validator identity, effective stake, and displayed wallet balance as separate facts.
Work through an example
In the fictional record, `deactivating` says the cooldown is in progress; it does not show how much stake is currently inactive. Solana allows a fully inactive portion to be withdrawn while the remaining portion continues deactivating. Check the requested amount, withdraw authority, and lockup before concluding what can move now.
Read the fictional records in this lesson and make an evidence table for each: cluster, total account balance, delegated and effective amounts, stake-account state, stake authority, and withdraw authority. Mark each claim as observed or unknown. For the deactivating account, decide what may be withdrawable and explain why the status plus “no lockup reported” does not establish an amount; identify the inactive amount and authority check. For the active account receiving a 5 SOL transfer, explain why its higher balance does not prove higher delegation or rewards, then outline the separate-account path Solana recommends. Use no real address, wallet, RPC credential, or funds.
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. Most exercises work on paper or with a local test; only a lesson that clearly says “read-only Devnet” makes a public network request.
- Draw the path from a normal wallet balance to a created stake account without treating either address as a private key.
- Label the stake authority and withdraw authority, then map one operation each authority may sign.
- Place inactive, activating, active, and deactivating on a state diagram; mark that epoch boundaries affect transitions.
- Explain why `getStakeActivation` can return `Method not found` on current nodes and list the account, StakeHistory, and epoch inputs needed for a current-state calculation.
- Use the official stake-account reference to explain why one account cannot delegate to two validators at the same time.
- Classify an ordinary SOL transfer into an already-delegated account; distinguish the new balance from delegated stake and explain the separate-account path for additional delegation.
- Classify the fictional Devnet record and list the inactive amount, authority, and lockup evidence needed before a withdrawal.
- Review the current wallet and official references only if you later choose to stake; do not sign or submit a transaction for this lab.
Before you move on, check your reasoning
- Which authority signs a deactivation?
- What does “activating” establish, and what does it leave unknown?
- What does an account-level deactivating status tell you, and what evidence shows how much may be withdrawn now?
OPEN SELF-CHECK · UNGRADED
Pause and test your reasoning
Practice 1 of 4
A stake account displays “activating” after its delegation instruction was confirmed. What does this status support?
Reveal the answer and explanation
One best answer: Delegation is still warming up at epoch boundaries; check the account again before claiming it is active.
Solana documents stake warm-up and cooldown across epoch boundaries. A transaction confirmation and the later effective stake state are different pieces of evidence; the state does not promise an exact completion time.
Sources: Stake Accounts
Practice 2 of 4
One stake account is delegated to Validator A. The owner wants a separate delegation to Validator B. Which model is correct?
Reveal the answer and explanation
One best answer: Use a second stake account for the separate validator delegation.
A Solana stake account delegates to one validator at a time. The owner can use separate stake accounts for distinct delegations and keep the appropriate signing authorities under their control.
Sources: Stake Accounts
Practice 3 of 4
A fictional stake account is deactivating and lists no lockup. What should a learner say about withdrawal?
Reveal the answer and explanation
One best answer: Check the inactive amount; verify withdraw authority and lockup before withdrawing.
A deactivating account may contain both inactive stake and stake still cooling down. A fully inactive portion can be withdrawn while the rest deactivates; check the exact amount, withdraw authority, and any lockup.
Sources: Stake Accounts · Staking and Inflation FAQ
Practice 4 of 4
A 5 SOL transfer reaches a stake account that already has 20 SOL delegated. The balance rises, but the delegated amount remains 20 SOL. What should the learner conclude?
Reveal the answer and explanation
One best answer: The balance only changed; delegate additional stake separately.
Solana’s staking overview says SOL sent to an already-delegated stake account is not automatically delegated. It recommends creating a separate stake account for additional delegation. Check current account state rather than treating a higher balance as active or reward-eligible stake.
Sources: Staking and Inflation FAQ
This practice is not scored, saved, or part of a certificate. Account-based lesson checkpoints and level exams remain separate.
Never enter a recovery phrase or private key into a learning site or lesson exercise.
READ THE SOURCE
Go deeper in the official docs
Reviewed on 2026-10-04. Protocol documentation can change; check the linked page’s current version as you use this material.
YOUR PROGRESS, SAVED
Ready for the checkpoint?
Make a free account to save your progress and unlock the quizzes.
Create free account