How a Staking Program Works on Solana: Design and Pitfalls

Staking is one of the most requested features for Solana tokens: holders lock their tokens and earn rewards over time. It sounds simple, but a staking program holds other people's tokens, so the design and the maths have to be right from day one.

This guide explains how a well-built staking program works, without code, so you can plan one or judge a quote.

The pieces

A typical staking program on Solana has:

• A pool account that stores the settings: which token is staked, which token is paid as rewards, the reward rate, and any lockup rules.
• A vault: a token account owned by a PDA (a program-derived address), so only the program itself can move the staked tokens. No person holds the keys.
• A stake account per user, recording how much they've staked and how much reward they've already been credited.

How rewards are calculated

The naive approach, looping over every staker to pay rewards, doesn't work on-chain: it's too expensive and grows with the number of users.

Well-built programs use a reward-per-share approach instead:

1. The pool tracks a running total: rewards earned per staked token since the pool started.
2. Every time anyone stakes, unstakes or claims, the program updates that total based on the time passed and the reward rate.
3. Each user's reward is their stake multiplied by how much the total has grown since they last interacted.

This keeps every action a fixed, small cost no matter how many people stake, and it's fair to the second.

Design decisions to make

• Fixed rate or fixed budget? A fixed APR is easy to explain but can promise more than you can fund. A fixed pool of rewards shared among stakers is sustainable, but the rate changes as more people stake.
• Where rewards come from. Rewards must be funded: deposited into a reward vault up front or topped up over time. A program that "prints" rewards needs a mint authority, which has trust implications (see mint and freeze authority explained).
• Lockups. Can users unstake anytime, after a fixed period, or with a cooldown? Longer lockups can earn more.
• Early-exit penalties, if any, and where penalty tokens go.

Pitfalls to avoid

• Rounding in the user's favour. Always round rewards down, or tiny repeated claims can drain value.
• Unfunded rewards. If the reward vault runs dry, claims fail. Show the remaining runway publicly.
• Missing account checks. A user must never be able to pass someone else's stake account, or a fake vault. See common Solana program vulnerabilities.
• Token-2022 surprises. If the staked token has a transfer fee, the vault receives less than the user sent; the program must record what actually arrived.
• Upgrade authority held by a single key. Use a multisig or make the program immutable once stable.

Testing it

Test every instruction, including the ones that should fail, run long simulated periods to check reward maths over months, and try edge cases such as staking the smallest possible amount. Then deploy to devnet and run realistic scenarios before mainnet. For anything holding real value, get an independent security review.

NFT staking

The same idea works for NFTs: users lock NFTs instead of tokens, and rewards can depend on rarity or traits. With Metaplex Core, NFTs can even be frozen in the user's own wallet while staked, rather than moved to a vault. See Solana NFT standards.

Build it with us

We design and build staking programs in Rust and Anchor, with tested reward maths and a clean front end. See our DeFi and program development.