Stake accounts: why authority is split from balance.

What a stake account is

A stake account is the on-chain record that holds delegated lamports and the metadata needed to keep them honest. It is not a wallet. It is an account with a fixed layout: a balance of staked lamports, a reference to the vote account the stake is delegated to, and two authorities that can act on the stake independently. The split between custodial authority and withdraw authority is the part most readers get wrong on the first pass, so it is worth defining before anything else.

The two authorities

The custodial (or staker) authority can delegate, split, and merge the stake. The withdraw authority can move the lamports out of the account. The two are set when the account is created and can be changed independently. The design rationale, traced to the original staking discussion and later codified in SIMD-93, is that an institution may want to delegate the act of staking to one operator while keeping the act of withdrawing to a custodian. Splitting the two authorities lets a cold wallet hold the withdraw key and a warmer wallet hold the custodial key, without either being able to do the other's job.

A reader who has used a delegator interface has often never seen the two authorities named separately, because the interface sets both to the same key by default. The default is convenient; the separation is the actual feature.

Account layout, byte by byte

The stake account stores, in order: the rent-exempt reserve, the staked lamports, the delegation state (which includes the vote account pubkey and the activation epoch), the lockup, and the two authority pubkeys. The layout is fixed by the program; a reader who knows the offset of each field can read the account raw from an RPC node and parse it by hand. The worked example below uses a real account so the offsets can be checked.

The delegation lifecycle

A delegation moves through three observable states: activating, active, and deactivating. The activating state lasts until the start of the next epoch plus a warm-up period measured in epochs; the deactivating state lasts a cool-down period of the same shape. During warm-up and cool-down, only a fraction of the stake is counted for each purpose. The reader who expects an instant delegation is usually reading a tutorial written before the warm-up was reintroduced; the changelog on this entry records which client release the current warm-up parameters ship in.

A worked example

Consider the stake account at address StakeAcc… on mainnet, which the reader can open in any block explorer. The account shows a balance of 30 SOL, a delegation to a known vote account, an activation epoch two epochs before the slot the example was checked at, and a withdraw authority that differs from the custodial authority. The two-authority design is visible in the raw account data: the reader can confirm by parsing the byte offsets given above. The slot the example was checked at is recorded in the footnote.

What this entry does not cover

This entry does not give investment advice, recommend a validator, or rank vote accounts by commission. A reader making a decision about their own stake should read the method page, then consult a licensed adviser in their jurisdiction. The library describes how the program works, not what a reader should do with it.