Hubra
Staking · Mechanics

The stake account,taken apart.

Staking on Solana is not a product - it is a small, well-defined program in the runtime. A handful of instructions, a four-state lifecycle, and a deterministic issuance curve. This is the long-form reference.

01
1
Native program

Stake is a first-class Solana program - not a smart contract built on top.

02
7
Instructions

Initialize, delegate, split, merge, authorize, deactivate, withdraw - that is the entire surface.

03
4
Account states

Inactive, activating, active, deactivating. State changes only at epoch boundaries.

Volume № I · Why stake exists

Stake is not a yieldproduct. It is a vote.

Solana is a permissionless, byzantine fault tolerant ledger. To decide which version of history is canonical, validators run the network software and vote on each block. The weight of any given vote is proportional to the SOL delegated to that validator.

Without delegated stake, a validator has no influence. Without votes, the network cannot finalise. The reward you earn is the protocol's way of making participation rational.

i
Consensus weight
Stake is the unit of voice. A validator's vote is weighted by the SOL delegated to it. When you stake, you lend that voice to a specific operator without surrendering custody.
ii
Sybil resistance
Proof-of-stake replaces proof-of-work's energy cost with capital at risk. Forging history would mean controlling a meaningful fraction of the activated supply - measurable, expensive, and visible on chain.
iii
Receipt for participation
Solana mints new SOL each epoch and pays it pro-rata to delegators of voting validators. The reward is not a yield product. It is the protocol's fee for the security stake provides.
iv
Sovereignty
Delegation moves voting rights, not coins. The stake account is owned by your withdraw authority - the validator can never spend, transfer, or freeze your principal.
Volume № II · The issuance schedule

Inflation, on a schedulethe network already wrote.

Solana's reward pool is not a marketing budget. New SOL is minted by the protocol on a curve that decays toward a long-run floor. The schedule is fixed in code; only the network's participation rate can change what each delegator receives.

Initial rate
8.00%

Annualised issuance at activation, February 2021.

Disinflation
−15%

Reduction applied to the rate every twelve months.

Terminal rate
1.50%

The long-run floor. Issuance never falls below it.

Today · year 5.25
3.41% issuance
Reaches floor
~year 11
IssuanceFloor 1.50%
Where rewards come from

Each epoch the protocol mints new SOL equal to one epoch's share of the current annualised issuance rate. That mint is split between the validator (commission) and the delegators (everyone else, pro-rata to active stake).

Real yield, not nominal

A delegator's reward roughly equals issuance ÷ staked share. If 65% of supply is staked at 4.5% issuance, your nominal reward is ≈6.9%. Holders who do not stake are diluted by the same issuance - staking is how you stay even with the schedule, not above it.

Volume № III · The stake program

Seven instructions,and nothing else.

Every wallet, custodian, and DAO that touches stake on Solana is ultimately routing through the same native program. The full instruction set fits on one page.

  1. 01

    Initialize

    Initialize { authorized, lockup }

    Set the two authorities that govern the account. Stake authority can delegate; withdraw authority can move lamports.

    A stake account is just a system-allocated account owned by the Stake program. Initialize binds it to a stake authority (delegation control) and a withdraw authority (custody). Both are independent pubkeys - they can be the same wallet, or split for hot/cold separation.

  2. 02

    DelegateStake

    DelegateStake → vote_account

    Point the stake at a validator's vote account. Activation begins on the next epoch boundary.

    Delegation is a pointer, not a transfer. Lamports stay in your stake account; only the vote weight is assigned. Re-delegation to a new validator is the same instruction - there is no need to deactivate first.

  3. 03

    Split

    Split → new stake account

    Carve a portion of lamports into a new stake account that inherits state and delegation.

    Split is the canonical pattern for partial unstake. The new account starts in the same activation state as the source, with the same authorities and validator. Deactivate the slice you want back; leave the rest earning. Source must keep the rent-exempt minimum.

  4. 04

    Merge

    Merge → destination

    Combine two compatible stake accounts into one. Saves rent, simplifies bookkeeping.

    Two stake accounts can merge only if they match on voter pubkey, lockup, authorities, and credits-observed - and only when both are inactive, both fully active to the same validator, or one is inactive and the other is activating. Otherwise the program rejects the merge.

  5. 05

    Authorize

    Authorize → new pubkey, role

    Rotate stake authority or withdraw authority. The two roles are signed independently.

    Authorize is what makes split custody possible. A staker key (kept warm for delegation) is distinct from a withdraw key (kept cold for principal). Either can be replaced without touching the other, which is how custodians, multisigs, and lockup schedules are layered onto bare stake accounts.

  6. 06

    Deactivate

    Deactivate

    Begin cooldown. The stake stops earning at the next epoch boundary; lamports are still locked until cooldown completes.

    Deactivate is reversible up to the next epoch - re-delegating before the boundary cancels the cooldown. After the boundary the account moves to deactivating; rewards stop accruing on that portion. One full epoch later the account is inactive and lamports become withdrawable.

  7. 07

    Withdraw

    Withdraw → recipient

    Move lamports out of an inactive stake account. Signed by the withdraw authority.

    Withdraw works only on the inactive portion of an account. You can leave the rent-exempt minimum behind to keep the account alive for redelegation, or drain it to zero to close it. Active and activating stake cannot be withdrawn - that is the whole point of the cooldown.

Volume № IV · The state machine

Four states,one boundary at a time.

Stake accounts only change phase at epoch boundaries. Between boundaries, your transactions queue up; on the boundary, the runtime moves you forward. There are exactly four resting points.

Lifecycle
Signed by userRuntime transitionEach transition: one epoch · ~2 to 3 days
  • iInactiveNoYesThe account holds lamports but no validator pointer. Either fresh from initialise, or fully cooled down after a deactivate.Delegate to enter activation; withdraw to drain.
  • iiActivatingNoNoDelegation is signed and committed, but the next epoch boundary has not yet arrived. Stake counts as effective only after that boundary.Wait one epoch; lamports become active automatically.
  • iiiActiveYesNoStake is voting through the chosen validator and earning a share of the network's per-epoch issuance. Voter and authorities can rotate without leaving this state.Deactivate to begin cooldown; redelegate to switch validator.
  • ivDeactivatingNoNoA deactivate has been signed and the next boundary has passed. Lamports stop earning but remain locked through one full epoch of cooldown.Wait one epoch to reach inactive; or re-delegate to cancel.

Edge case: an account can be partially active. Split a stake into two, deactivate one, and the source still earns on the rest. Within a single account, however, lamports always share a single state.

Volume № V · Common questions

The mechanics, without the hand-waving.

The questions allocators ask after the marketing has been put aside.

Stake weights have to be agreed on by all validators before they take effect. The protocol freezes the active set at each epoch boundary so consensus has a stable view of who is voting and with how much. Anything signed mid-epoch waits until the next boundary to apply.

Stake authority controls delegation: which validator the account points at, when to deactivate, when to merge or split. Withdraw authority controls custody: it moves SOL out of the stake account. The two are independent pubkeys, which is what allows a hot/cold key split or a custodian-managed delegation.

Yes. DelegateStake to a new vote account works in any state. The active stake redirects on the next epoch boundary; there is no cooldown, no rewards lost, and no transaction fee beyond the instruction itself.

Merge is only safe when the two accounts have identical activation context. If voter pubkeys, lockups, or authorities differ, merging would either lose information or smuggle a state change past the runtime. The program rejects rather than guess.

No - it decays by 15% each year until it reaches the 1.5% terminal rate, then stays there. Activated in February 2021, the curve is expected to hit the floor near year 11. After that, issuance is constant at 1.5% annualised, perpetually.

The protocol mints one epoch's worth of issuance and distributes it pro-rata to the active stake of voting validators. Your share equals (your active stake / total active stake) × (epoch issuance) × (1 − validator commission). Skipped vote slots reduce the validator's share, not your principal.

Nothing - it keeps voting through the same validator and compounding rewards every epoch, indefinitely. There is no expiration, no required heartbeat, no claim deadline. Stake accounts on Solana are persistent state, not subscriptions.