Stake Account
Delegates SOL to a validator's vote account. Tracks staker/withdrawer authorities, lockup, delegated amount, and activation/deactivation epochs.
Sample: Stake Account
(cached; refreshes hourly · mainnet only)
A Stake account delegates SOL to a validator's Vote account to earn staking rewards. The 200-byte layout tracks who can manage the stake, how much is delegated, and when activation or deactivation lands.
Solana's proof-of-stake consensus runs on these delegations. SOL holders create Stake accounts pointing at a validator's Vote account; the Stake program manages epoch-based activation, computes per-epoch rewards, and records the credits the validator has earned. Liquid staking protocols like Marinade and Jito hold large pools of Stake accounts on behalf of their depositors.
You encounter Stake accounts in validator dashboards, liquid staking flows, and any RPC call that walks delegations (getStakeActivation, getProgramAccounts on the Stake program).
The layout starts with a 4-byte state enum (Uninitialized, Initialized, Stake, RewardsPool), then the Meta struct (rent_exempt reserve, authorized staker pubkey, authorized withdrawer pubkey, and a Lockup struct of timestamp + epoch + custodian). When the state is Stake (= 2), a Delegation struct follows: the voter_pubkey being staked to, stake_amount, activation_epoch, deactivation_epoch (max u64 if still active), and credits_observed for reward calculation. Two-step authorities — staker and withdrawer can be different keys — let cold storage hold the withdrawer while a hot key manages delegations.