Search across all documentation pages
Tokenomics on Solana is the closed loop that prices security, inclusion, and protocol change: issuance and dilution, stake that claims rewards, fees and tips for blockspace, and governance that updates the rules. Once you see those pieces as one machine, staking UX, LST integrations, fee bidding, and SIMD-aware design stop looking like separate domains.
Economics Basics is the hands-on fee entry; Inflation & Staking Rewards, Staking & Delegation, Liquid Staking & LSTs, Priority Fee Markets, MEV on Solana, Governance & SIMDs, and Realms & On-Chain Governance each zoom into one mechanism. This page sits underneath: how the economic system fits together for builders.
Solana does not run a separate "tokenomics subsystem" next to the runtime. The same native unit (SOL, in lamports) pays fees, funds rent-exempt deposits, backs stake, and often carries governance weight.
Security is purchased with staked capital that claims issuance. Inclusion is purchased with fees and often tips. Long-lived market rules update through governance, not only app admin keys.
Think of four coupled loops:
Issuance (inflation)
|
v
Stake rewards <---- active stake / validator performance
|
+----> more capital staked or wrapped as LSTs
|
Users / apps ---- fees + tips ----> leaders / validators / MEV pipelines
|
Governance (SIMDs, Realms) ---- updates parameters, programs, treasuriesIssuance grows SOL supply on an on-chain inflation schedule that declines over time toward a long-term floor. Exact rates live in cluster parameters and can move with governance; prefer structural models over a blog APR. New SOL goes primarily into the staking reward path so securing capital is compensated relative to idle capital.
Staking is not "sending SOL to a validator wallet." It is locking SOL in stake accounts, delegating to a vote account, and waiting through epoch-bound activation before stake is fully reward-eligible. Deactivation is staged; unstaking is not an instant transfer.
Fees pay for execution and compete for scarce capacity. A small base fee attaches to signatures; priority fees raise compute-unit price under contention. A large share of fees is typically burned, partially offsetting issuance (treat burn share as parameter-sensitive).
MEV is value from ordering, inclusion, and arbitrage. It often surfaces as tips and bundles outside the plain priority-fee field. Fees and tips both buy inclusion, but they are not the same ledger path.
Governance spans protocol evolution (SIMDs) and application DAOs (Realms). Fee policy, inflation parameters, feature gates, and upgrades can reshape product economics without your next deploy.
Each epoch, the protocol mints SOL according to the inflation schedule and distributes rewards to active stake on voting validators. A validator's commission is taken before the remainder accrues to delegators.
inflation mint (epoch)
|
v
rewards for performing validators
|
+-- commission --> validator operator
|
+-- remainder --> stake accounts (delegators)Realized yield is not "the headline inflation rate." It depends on stake participation, validator performance (uptime, vote credits, non-delinquency), commission, and how long stake was active. Non-staked SOL is diluted: supply grew without an offsetting reward claim.
For product math, use reward ≈ f(inflation, stake_ratio, commission, performance) and live RPC reads rather than a fixed marketing APR.
A stake account holds lamports and stake state. Delegation points those lamports at a vote account. Activation and deactivation move through epoch boundaries.
Wallet SOL
|
v
Stake account --delegate--> Vote account (validator)
| |
| +--> votes / earns credits
v
activating -> active -> deactivating -> inactive (withdrawable under rules)Staking UX must surface warmup/cooldown, wrong vote account (zero rewards), merge/split, and withdraw authority vs stake authority. Read getEpochInfo rather than assuming wall-clock epoch length.
A liquid staking token (LST) is usually an SPL token that represents a claim on SOL staked through a pool or protocol (examples include mSOL, jitoSOL, and others; liquidity often involves Sanctum-style routing). Users deposit SOL, the protocol stakes, and users receive a transferable token usable in DeFi.
The claim is still "staked SOL earning rewards," with composability and often faster market exit, plus smart-contract, liquidity, peg, and provider governance risk.
| Dimension | Native stake | LST |
|---|---|---|
| Asset form | Stake account state | Fungible SPL token |
| Liquidity | Unstake + cooldown | Trade LST if markets deep |
| Rewards path | Accrues on stake / claims | Exchange-rate growth or rebasing |
| Control | Choose validator (or pool rules) | Accept provider set and fees |
| Integration cost | Stake program + epoch UX | Token accounts, pool CPI, depeg cases |
| Best fit | Direct security participation | DeFi collateral, loops, instant liquidity |
If your app holds productive user SOL, decide whether you need native stake, an LST, or a stake pool receipt, and document failure modes.
Under load, not every valid transaction lands. Clients set a compute unit limit and compute unit price via Compute Budget instructions so leaders can rank work by fee intensity.
Base fee is the baseline signature and inclusion cost. Priority fee is the competitive bid when senders want the same scarce slots or hot accounts.
Burn dynamics matter for supply intuition more than per-tx logic. Shipping clients need simulation, fee estimation under load, fresh blockhashes on retry, and not confusing CU price with a MEV tip.
Searchers may pay tips to validators or block engines for bundle inclusion and ordering. That payment can use programs and accounts that never look like a Compute Budget priority fee.
Path A: tx + compute unit price --> leader scheduler / bank
Path B: bundle + tip accounts --> block engine / auction --> leaderPriority fees are the default public fee-market lever. MEV pipelines matter when you integrate searchers, protect users from toxic flow, or stake with tip-sharing validators (including some LST products). See Priority Fee Markets and MEV on Solana.
SIMDs (Solana Improvement Documents) propose protocol-level change: economics parameters, features, and cluster policy. Stake-weighted processes and client releases determine what activates.
Realms is the common on-chain stack for DAOs and treasuries: proposals, voting, and execution for upgrades or spends. App governance is not cluster inflation policy, but both can move product economics.
Prefer explicit authorities: program upgrade authority, DAO-controlled treasuries, and parameter accounts that governance can change without rewriting every client assumption.
A product that uses SOL productively often touches multiple loops:
The blueprint is complete when you can name which loop each product decision sits in.
Production systems mix native stake, LSTs, fee bidding, and governance. Failures come from mixing them without a clear ownership model.
| Path | What you pay or lock | What you get | Failure mode to design for |
|---|---|---|---|
| Native stake | SOL in stake accounts + opportunity cost | Protocol rewards, validator choice | Cooldown, bad validator, authority mistakes |
| LST | SOL (or LST liquidity) + protocol fees | Liquid receipt + yield exposure | Contract bug, depeg, pause / queues |
| Priority fee | Extra lamports via CU price | Higher chance to land under load | Overpay when calm; still drop if accounts hot |
| MEV tip / bundle | Tip to engine or accounts | Ordering / inclusion guarantees | Different APIs, relay trust, tip griefing |
| Governance hold | Vote weight / lockups (varies) | Parameter and treasury influence | Low turnout, bad proposals, upgrade lag |
Treasuries should separate operating SOL (fees, rent, CU bids) from strategic stake or LST and not assume fixed real yield. Wallets should explain dilution vs staking without promising APR. DeFi that accepts LSTs inherits oracle and liquidity risk. Infra feels fee markets as load spikes long before inflation math.
Validator economics couple commission, vote performance, MEV share policy, and stake concentration. Auto-delegators should document validator choice and delinquency handling.
Parameter sensitivity means reading inflation and epoch info from the cluster, treating SIMDs as product risk, and versioning assumptions the way you pin Agave and Anchor.
For design reviews: where SOL sits, who earns issuance, who pays fees and tips, what exit path exists, and which governance process can change those answers without your next deploy.
SOL ties security, inclusion, and governance together: issuance pays stake, fees and tips clear blockspace, and governance updates the parameters of both.
Rewards flow to active stake tied to performing validators, with commission for the operator and the rest accruing to delegators by stake weight and epoch accounting.
New SOL increases supply. Stakers receive offsetting rewards; wallets that hold idle SOL do not, so they experience dilution relative to staked capital.
It is a program-owned account that locks SOL, tracks stake state, and can be delegated to a validator vote account under explicit stake and withdraw authorities.
Activation, deactivation, and reward boundaries are epoch-based, so clients must show pending state and avoid promising same-slot liquidity for native unstake.
Use an LST when users need a fungible, DeFi-composable claim on staked SOL and accept protocol and liquidity risk; use native stake when validator choice, direct stake accounts, or minimal smart-contract surface matter more.
Only if the LST provider's validators and pipelines capture and share that value by design. MEV-enhanced yield is product policy, not a property of being liquid staked.
Base fee is the baseline signature and inclusion cost; priority fee is the compute-unit price bid that competes for scarce execution under contention.
Leaders, account locks, CU limits, expired blockhashes, and competing demand can still drop or delay work; fee helps under contention, it is not a guarantee.
Priority fees are a general CU-price auction in the public fee path; MEV often uses tips and bundles aimed at ordering and specialized inclusion, sometimes through side pipelines with leaders.
Start with getEpochInfo, inflation rate/schedule APIs, getVoteAccounts, getStakeActivation, getInflationReward, and supply endpoints, then add pool or LST state.
A Solana Improvement Document is a structured proposal for protocol or cluster-impacting change, turning economic and technical debates into implementable client work.
Realms typically governs app DAOs, treasuries, and program authorities. Protocol inflation moves through SIMD and validator processes, not every Realms instance.
Yes. Issuance schedules and fee treatment are parameter- and feature-gated. Pin assumptions, monitor SIMDs, and avoid hardcoding fragile constants into user promises.
Map every SOL balance (fee payer, vault, stake, LST), define exit and cooldown UX, choose fee and tip strategy under load, document validator or LST risk, and name which authorities can change those flows.
Stack versions: This page was written for Agave 4.1.1, Solana CLI 3.0.10, Anchor 0.32.1, Rust 1.91.1, and @solana/kit 7.0.0.
Reviewed by Chris St. John·Last updated Jul 15, 2026