On this page

A Solana stake account is the on-chain account that holds a staker's delegated SOL, created via the Solana stake program and owned by the staker — distinct from the validator's identity, vote, and withdraw accounts, and distinct from a stake pool program that manages many stake accounts on stakers' behalf. A stake account has its own keypair, its own balance, and its own delegation target; rewards accrue directly to it each epoch.

The stake account is the fourth account type a staker encounters alongside the validator's three-keypair model (see the vote vs. identity entry) — but it belongs to the staker, not the validator. The validator's vote account is what a stake account points at; ownership and authority never cross between the two.

What a stake account holds

A stake account is a system account owned by the Solana stake program. Its on-chain state includes:

  • Balance. The SOL committed to staking, plus accrued rewards. Rewards are added to the balance automatically each epoch; there is no separate claim operation.
  • Delegation target. The pubkey of a validator's vote account to which the stake is currently delegated. A stake account can be undelegated, delegated to one vote account, or in transition between states.
  • Activation state. One of inactive, activating, active, or deactivating, queryable via the getStakeActivation RPC method (see the stake activation entry).
  • Authorized staker. The keypair authorized to delegate, deactivate, split, or merge the stake account.
  • Authorized withdrawer. The keypair authorized to withdraw SOL from the stake account once it is deactivated. By default both authorities are the same keypair (the staker's wallet), but they can be split for advanced custody setups.

The two authorities on a stake account are independent of the validator's withdraw authority on the vote account. The validator's withdraw authority controls the validator's vote account; the staker's withdraw authority controls the staker's stake account. They are different keys at different on-chain locations.

Stake account operations

The stake program supports a small, fixed set of operations on a stake account:

  • Create. The staker's wallet creates a new system account, transfers SOL into it, and assigns the stake program as owner. The account is inactive until delegated.
  • Delegate. Point the stake account at a vote account pubkey. The stake enters activating state and warms up over approximately one epoch before earning rewards.
  • Deactivate. Issue a deactivation instruction. The stake enters deactivating state and cools down over approximately one epoch before becoming withdrawable.
  • Withdraw. Once the stake is inactive after cooldown, the authorized withdrawer can move SOL out of the stake account into any wallet.
  • Split. Divide one stake account into two stake accounts with proportional balances and identical delegation state. Useful for partial unstaking without disturbing the rest of the position.
  • Merge. Combine two stake accounts into one, subject to compatible authority and activation-state rules.
  • Redelegate. Under current protocol mechanics, switching validators requires deactivating the existing stake (incurring the cooldown) and then delegating to the new vote account (incurring the warmup). Some tooling labels this flow "redelegation" but it is the deactivate-then-delegate sequence; the cooldown applies.

Each operation is a transaction signed by the appropriate authority. Hot-wallet and cold-wallet stakers issue identical instructions; the signing path differs (see the hot vs. cold wallet entry) but the on-chain stake account is identical in both cases.

Stake account vs. stake pool

A stake account is owned by an individual staker and delegates to one specific validator. A stake pool (see the stake pool entry) is a smart contract program that holds many stake accounts on behalf of many depositors and distributes their pooled SOL across a selected validator set algorithmically. The two should not be conflated:

  • A staker holding native stake accounts has direct on-chain ownership of each account, individual delegation choice, and exposure to one validator's specific skip rate and commission.
  • A staker holding an LST like mSOL or jitoSOL holds an SPL token claim against the pool's stake accounts — the staker does not have an individual stake account at all. The pool's contract holds the stake accounts; the staker holds a tokenized claim.

A single wallet can hold both native stake accounts and LSTs simultaneously — they are different account types serving different liquidity and selection trade-offs.

Naming traps

  • "Stake account" vs. "stake pool" — the first is an individual on-chain account owned by one staker; the second is a smart-contract program managing many stake accounts on behalf of many stakers. The terms are not interchangeable.
  • "Staking address" is ambiguous — it could mean the stake account pubkey, the staker's wallet pubkey, or the vote account pubkey the stake is delegated to. Specify which.
  • The stake account's keypair is the staker's, not the validator's. A validator cannot move SOL out of a staker's stake account; only the authorized withdrawer can, and that is the staker's keypair by default.

Sources

Stake account model cited: Solana stake program semantics at epoch 971, 2026-05-15. The account model is protocol-level and stable; per-account state updates each epoch as delegation, activation, and reward accrual proceed.