Ultimate Solana glossary: 2026 edition

Last updated on 30 Mar 2026

TL;DR

Solana uses Proof of History (PoH) as a shared, cryptographically verifiable clock to *pre-order* events before consensus. PoH itself is not the full consensus mechanism. Solana uses PoH alongside a Proof-of-Stake BFT consensus (called Tower BFT) to agree on blocks and finalise state.
The state is separated from logic. Unlike the EVM, where contracts store their own state, Solana separates the executable (Program) from the storage (Account).
Parallelism is the default. The Sealevel runtime executes non‑overlapping transactions in parallel, like a multi‑core CPU running independent threads.
We’ve put together a glossary of the terms you’ll hear when talking about Solana. From this article, for each core term you’ll get:
- a definition (what it is)
- a function on Solana (what it does)
- a simple mental model / you can use to understand its function and definition better

Terms marked with 🟢 may change or evolve with upcoming protocol upgrades such as Alpenglow.

1. Time & consensus

TL;DR

Most blockchains spend more effort arguing about when something happened than actually processing it. Solana flips this by establishing a cryptographically verifiable clock before consensus even starts. Note: Solana still relies on a Proof-of-Stake consensus algorithm (Tower BFT) to finalise the agreed history. PoH provides ordering that makes consensus more efficient, but does not replace it.

Imagine an endless ship’s logbook (ledger).

The leader is the captain on shift.
A slot is a single page in that logbook.
The leader's schedule is the roster that tells us who the captain is for each page.
If a captain is “sick” (down), that page number still exists but stays blank (skipped slot), and the book continues.

TERM	DEFINITION	WHAT IT DOES ON SOLANA	MENTAL MODEL
🟢Proof of history (PoH)	A cryptographic time-ordering mechanism based on a chain of SHA-256 hashes that proves the passage of time and the order of events.	Acts as a global, verifiable clock for the network, so validators don’t have to negotiate ordering, only transaction validity.	A security camera timestamp on a videotape: the timecode proves exactly when an event happened without needing a witness.
VDF (Verifiable Delay Function)	A function that requires a fixed amount of sequential time to compute but is fast for others to verify.	Forces the PoH producer to spend real time generating the hash chain so that no one can fake or speed up Solana’s “clock.”	A Rubik’s Cube: it takes 30 seconds to solve, but a judge can check in 1 second that it’s solved correctly.
Slot	The fundamental unit of time (~400 ms) during which a single Leader is scheduled to produce a block.	Limits how long a Leader has to bundle and produce a block; if they’re slow or offline, the network immediately moves on to the next slot.	A single page in the captain’s logbook. It can be written on (block) or left blank if the captain is asleep (skipped).
Epoch	A collection of consecutive slots (≈432,000 slots, ~2–3 days) with a fixed Leader schedule.	Defines the “work period” for the cluster: when leader assignments are fixed, when stake changes take effect, and when rewards are calculated and paid.	A 24‑hour day: whatever happens in the hours (slots), the day’s length is fixed.
Entry / Entry ID	A record in the ledger (tick or transaction) with a unique hash.	Serves as the smallest individual unit of history in the ledger.	A numbered line item on a long grocery store receipt.
Leader	The validator assigned to append entries to the ledger for the current slot (typically for 4 consecutive slots).	Collects and orders transactions, executes them, builds a block from the results, then splits the block into shreds and propagates them to the rest of the network.	The captain on deck: only they can write in the logbook during their shift; everyone else just reads.
Leader schedule	A deterministic sequence of validator public keys mapped to future slots in an epoch.	Tells each node which validator is responsible for each slot so that they can route transactions and votes to the correct Leader.	A shift roster on a factory wall so every worker knows exactly which hours they’re working for the next few days.
Block	A connected set of ledger entries (ticks and transactions) that share a PoH history and are covered by votes.	Groups executed transactions into an ordered batch that validators can vote on and build future blocks on top of.	Everything written on the captain’s log page. If the page is ripped out, the text (block) is gone, but the page number (slot) is still in the book’s history.
Genesis block	The very first block in the chain (block 0) containing the initial state and cluster configuration.	Defines the starting balances, system accounts, and parameters from which the later Solana state evolves.	The constitution of a country: the foundational document from which all other laws are derived.
🟢Tick / Tick height	A special ledger entry in the PoH stream that represents elapsed wall‑clock time, even if no transactions occur.	Keeps the network synchronised during quiet periods; lets validators track how much time has passed between blocks.	A heartbeat while you sleep: no visible action, but the pulse proves you’re still alive.
🟢Tower BFT	Solana’s Byzantine Fault Tolerant consensus algorithm, built on PoH, where validator votes are time‑locked and accumulate lockout.	Makes it progressively harder to revert older blocks; the more votes and time a fork has, the “heavier” and more stable it becomes.	A cloud save that is replicated across many data centres, so losing all copies becomes extremely unlikely.
🟢Lockout	A time‑based commitment period that grows as validators keep voting on the same fork.	Penalises flip‑flopping between forks; switching to a conflicting chain becomes increasingly costly, stabilising consensus.	A poker pot: you keep putting chips in to stay in the hand, which makes it expensive to fold and switch tables mid‑game.
Vote/ledger vote	A signed message by a validator attesting to the validity of a specific bank state (fork).	Records stake‑weighted support for a chain, moving blocks toward finality and earning the validator vote credits.	A parliament member says “Aye”, so their support is permanently recorded in the meeting minutes.
🟢Fork	A divergence in the ledger where two or more blocks compete to extend the same parent slot.	Represents competing versions of history that consensus must resolve into a single canonical chain.	A train track switch: the train can only go down one line, and the passengers (validators) must agree on which track is the correct route.
Root	A block that has accumulated maximum lockout (31+ confirmed blocks on top of it) and is treated as final by the network.	Acts as a permanent checkpoint; reverting it would require breaking the system's assumptions (e.g., destroying the network’s trust model).	Wet concrete that has fully dried and hardened into solid cement.
🟢Finality	The point at which a block has enough time‑locked, stake‑weighted votes that reversing it becomes economically or practically impossible.	Gives users strong confidence that their transactions in that block are effectively permanent, even if, in theory, extreme reorgs could exist.	A jury verdict that is so overwhelmingly supported that, in practice, the case is closed and never retried.
Supermajority	At least 66% of the active stake.	Sets the stake threshold for binding decisions in consensus, such as confirming blocks, finalising roots, and choosing the winning fork.	A decisive jury verdict where almost everyone agrees, overruling the few dissenters.
🟢Commitment	A user‑facing measure of how far a transaction has progressed in the confirmation pipeline (e.g., processed, confirmed, finalised).	Lets wallets and apps show where a transaction currently stands, so they can decide when to treat it as reliable.	A pizza tracker: “Order received” (processed) → “In the oven” (confirmed) → “In your hands” (finalised).
🟢Confirmation time	The wall‑clock duration between submitting a transaction and it reaching a chosen commitment level.	Captures the latency from “send” click to “network agrees this happened,” used to benchmark performance.	The time between handing cash to the cashier and receiving the printed receipt.

2. Memory & state

TL;DR

Crucially, Solana separates logic from data. The logic (program) does not store user balances or NFTs within itself; it processes data stored in a separate state (accounts). This decoupling is a key design choice that enables Solana’s performance and parallelism. To understand it, imagine Solana as a global computer, where

Accounts are files.
Programs are applications that read/write in those files.
Rent is the cost of occupying storage space.

TERM	DEFINITION	WHAT IT DOES ON SOLANA	MENTAL MODEL
On‑chain program	Executable code deployed to a special program account, written in Rust/C and compiled to BPF.	Defines the rules for reading and modifying specific accounts. Any transaction can invoke it to apply those rules.	Google Sheets: the app that edits spreadsheets but doesn’t store the files itself; that’s Google Drive’s job.
Account	A generic state object in the ledger that holds data or executable code and has an owner program.	Stores balances, NFTs, configuration, or program binaries. Programs read/write accounts to implement behaviour.	A folder in a filing cabinet: it has a label (address) and can hold documents (data) or instructions (code).
Account owner	The program ID stored in the account’s metadata that has write authority over an account.	Enforces access control so only the designated program can change that account’s data.	Google Sheets is the only app allowed to edit “.gsheet” docs; a calculator app can’t open or change them.
Data plane	The network path and mechanisms used to move and store ledger entries and account data across validators.	Distributes shreds and state efficiently so every validator can maintain an up‑to‑date copy of the ledger.	The highway system that moves freight (block data) between cities, separate from the radio network (gossip) that coordinates the drivers.
Bank state	The complete set of all accounts and balances at a specific slot or tick.	Represents the canonical “truth” that programs execute against and that validators vote on.	A stadium scoreboard showing the exact score after every single play is applied.
PDA (program-derived address)	An address derived from a program ID and seeds that has no private key and can only be signed programmatically.	Lets programs own assets and data without any human‑held key, enabling secure, program‑controlled accounts.	A deposit safe at a bank with no keyhole; only the manager (program) can open it using a specific internal code (seeds).
Rent	A fee charged (in lamports) for storing data on‑chain over time (policy is evolving, but the concept remains).	Discourages junk data by giving storage a real economic cost, especially for short‑lived or low‑value accounts.	A monthly fee for a self‑storage unit to keep your things in a warehouse.
Rent‑exempt	A status for accounts that maintain at least a protocol‑defined minimum lamport balance.	Allows important accounts to persist indefinitely without ongoing rent collection once they deposit enough upfront.	A bank endowment: you deposit enough money so the interest covers maintenance fees forever.
Sysvar	Special read‑only system accounts that expose cluster‑wide state (clock, rent config, rewards, etc.).	Gives programs a trusted source of global parameters, such as “what slot is it?” or “what are current rent costs?”	A public info board in a town square that always shows the latest official information everyone relies on.
Keypair	A cryptographic public/private key pair generated together.	Creates and controls identities on the network; the public key becomes an address, the private key signs transactions.	A padlock (public) and its matching key (private) that are always sold (generated) together as a set.
Public key (pubkey)	The public half of a keypair, encoded in base58 and used as an address.	Serves as the destination for SOL or tokens and as the ID for programs and system accounts.	An email address you share freely so people can send you messages.
Private key	The secret half of a keypair used to generate signatures.	Grants authority to move funds and authorise actions from the corresponding public key.	The password to your email account that you never share with anyone.
Wallet	Software or hardware that manages one or more key pairs (across accounts and chains)	Provides a UX for signing transactions, viewing balances, and safely storing keys.	A physical keychain holding keys to your house and car: the keychain doesn’t hold the house, just access to it.
Snapshot	A complete, serialised copy of the bank state at a specific slot.	Lets nodes start or restart quickly by loading that state instead of replaying the entire ledger from genesis.	A detailed 3D photograph of a room so you can rebuild it the same way if it’s destroyed.
Hash	A digital fingerprint of a sequence of bytes.	Uniquely identifies data and underpins PoH, signatures, and Merkle proofs.	A unique DNA sequence that identifies a person; no two are exactly alike.

3. Execution & runtime

TL;DR

Imagine that inside every Solana validator, there’s a commercial kitchen optimised for throughput.

Sealevel is a kitchen layout that lets multiple chefs (CPU cores) cook simultaneously.
Accounts are the ingredients each chef needs.
Transactions are order tickets.
Instructions are individual recipe steps.

If Chef A is cooking steak and Chef B is making salad, they can cook in parallel. They only wait if they both need the same ingredient (write‑lock contention on the same account).

TERM	DEFINITION	WHAT IT DOES ON SOLANA	MENTAL MODEL
Sealevel	A parallel transaction execution engine that schedules non‑overlapping transactions across CPU cores.	Uses account read/write sets to run independent transactions concurrently, maximising validator CPU utilisation.	A high‑end kitchen where multiple chefs work at different stations simultaneously without bumping into each other.
Runtime	The component inside validators that executes program instructions and enforces protocol rules. (Sealevel + safety + rules + metering)	Runs on‑chain code safely, meters compute, checks limits, and ensures every validator gets the same deterministic result.	A referee in a sports game ensuring every player follows the rules during play.
Transaction	A signed message containing a header, a list of accounts, and one or more instructions. It is atomic: all instructions either succeed or all fail.	Carries user intent to the chain. If any step fails, no state changes are applied.	A bank check: you either cash the full amount or the check bounces; you can’t cash half of it.
Instruction	The smallest unit of execution logic: a call into a specific program with input data and a set of accounts.	Tells a program exactly which action to perform on which accounts.	A single line in a recipe (“crack two eggs”) telling the chef what to do next. If the step can’t be done (there’s only 1 egg), the whole dish is cancelled.
Inner instruction (CPI)	A cross‑program invocation where one on‑chain program calls another program.	Enables composability, allowing programs to reuse each other’s logic (e.g., a DEX program invoking the Token program).	A general contractor (Program A) hiring a licensed electrician (Program B) during a renovation.
Instruction handler	The specific function in a Solana program’s code that processes a given instruction.	Implements the business logic for that instruction: validation, state updates, and error handling.	The chef at the pass assigned to check orders as they come in and decide how the kitchen should handle them.
Compute units (CU)	The metric used to measure computational work (CPU, memory, complexity) used by a transaction.	Caps how much work a single transaction can force the network to do; if it exceeds its CU limit, it fails.	Arcade tokens (CU) used to play a game, where more complex and longer games cost more tokens to play.
Compute budget	The maximum CU limit and related settings a transaction declares (optionally via a special “compute budget” instruction).	Lets users raise or lower their CU limit and fee per CU, so they can balance cost vs. priority and avoid overspending on failed transactions.	A spending limit you set for a night out so you don’t accidentally blow your entire credit line.
Cost units	An internal estimate of resources (bandwidth, memory, etc.) required to process a transaction.	Helps leaders decide which subset of transactions can fit into the current block, given hardware and network constraints.	Planning gas, tolls, and drive time before a road trip so you know whether it fits into your schedule & budget.
BPF loader	The on‑chain system program responsible for loading, verifying, and dispatching Berkeley Packet Filter (BPF) bytecode.	Lets validators deploy, upgrade, and execute compiled Solana programs written in Rust or C.	A translator device that listens to an alien language (Rust/C) and converts it into local instructions the machine (a Solana node) understands.
Message	The structured, unsigned content of a transaction: header, accounts, and instructions.	Defines exactly what will execute; once signatures are attached, it becomes a full transaction.	A filled‑out form at the doctor’s office before you sign at the bottom.
Signature	An Ed25519 digital signature over the transaction message, generated with a private key.	Proves that the signer (key holder)authorised the actions in the transaction and that the message wasn’t tampered with.	A wax seal on a letter that only the king can create, proving it came from him and hasn’t been opened.
Blockhash (recent blockhash)	The hash of a recent block that every transaction must reference.	Acts as an anti‑replay protection and expiry: old blockhashes make transactions invalid, so they can’t be reused later.	A dated event ticket that only works on the printed date; you can’t reuse it tomorrow.
Program / on‑chain program	Executable code stored in a program account that interprets instructions and updates accounts.	Provides reusable logic for protocols, wallets and apps call these programs to perform on‑chain actions.	Google Sheets as the tool used to edit spreadsheet files that live in Google Drive (accounts).
Smart contract (EVM vs. Solana)	On EVM, “smart contract” refers to code plus its own state. On Solana, people sometimes (mis)use it to mean “program.”	On Solana, the precise term is “program” (logic) plus separate accounts (state); lumping them together as “smart contract” can cause confusion.	On EVM – a whole machine with its coins and sodas inside; on Solana, the program is just the button‑press logic, the machine itself is the state (stored in accounts).
Loader	A system program with the ability to deploy, upgrade, and dispatch other programs.	Enables developers to publish new programs and have validators execute them using the correct runtime.	A media player that knows how to open and play different video file types.
Erasure coding	A method of data protection where data is broken into fragments and expanded with redundant pieces.	Ensures the network can reconstruct a full block even if many shreds are lost in transit.	Overlapping sets of notes given to students; even if some pages are lost, the full lesson can still be reconstructed.
Merkle proof	A cryptographic proof that a piece of data belongs to a larger Merkle tree, without revealing the whole set.	Lets light clients verify that a transaction or account is included in the ledger without downloading everything.	A DNA test proving you’re part of a family without needing to test every single ancestor.

4. Network & infrastructure

TL;DR

We’ve talked about time and execution. Now we need to move data and blocks between machines.

A cluster is a specific network (e.g. Solana mainnet‑beta) and all the elements inside of it.
Nodes are servers within the cluster that run the Solana software (Agave).
Protocols like turbine, gulf stream, and gossip are used to move data efficiently across that cluster.

TERM	DEFINITION	WHAT IT DOES ON SOLANA	MENTAL MODEL
Cluster	A set of validators maintaining a single coherent ledger (e.g., mainnet‑beta, devnet, testnet).	Defines a specific Solana environment where programs run and accounts exist, isolated from other clusters.	Parallel universes that look identical but never interact with each other.
Node	A machine (or server) running Solana software (Agave) and connected to a cluster.	Stores ledger data, relays messages, and may validate or produce blocks depending on its role.	A single ant in a colony contributing to the overall work of the nest.
Validator	A staked node that participates in consensus by producing blocks and voting on them.	Secures the network, executes transactions, and earns rewards proportional to its stake and performance.	A notary with official authority (stake) who verifies documents, stamps them as valid; also reads & validates other stamped documents.
Bootstrap validator	The node that produced the genesis block when the network launched (in this case, Triton’s validator for Solana’s testnet and mainnet‑beta).	Bootstrapped the chain at genesis; afterwards, it behaves like any other validator.	The first factory machine that kicks off a brand‑new assembly line.
🟢Turbine	The block/entry propagation protocol that breaks data into shreds and forwards them in a tree‑like hierarchy.	Splits and propagates block data so it can reach all validators quickly and efficiently, even over unreliable links.	A phone tree: one person calls 2 people, they each call 2 more, and the message spreads to everyone.
Shred	A fixed‑size fragment of block data (data or coding shred) sent between validators.	Acts as the smallest unit of data transmission and storage, enabling erasure coding and parallel forwarding.	Puzzle pieces mailed to different people so each person can reassemble the full picture from the pieces they receive.
Gulf stream	A transaction forwarding protocol that pushes transactions directly to upcoming Leaders.	Eliminates a traditional mempool by pre‑routing transactions to the validators that will soon produce blocks.	A self‑order tablet at a restaurant: customers send orders directly to the kitchen; waiters (RPCs) can also input orders through their tablets.
Gossip network (control plane)	The peer‑to‑peer protocol validators use to exchange cluster metadata (contact info, stakes, votes, etc.).	Keeps all validators aware of who is in the cluster, how to reach them, and the current consensus/vote state.	Air traffic control coordination: keeping all pilots informed about where planes are and the current instructions.
TPU (Transaction Processing Unit)	The pipeline on a Leader validator node that ingests packets and constructs blocks.	Receives transactions, filters and orders them, executes them, and assembles them into blocks ready for broadcast.	The kitchen station where orders are received and cooks (CPU cores) start preparing meals.
TVU (Transaction Validation Unit)	The pipeline on non‑Leader nodes that verifies and replays blocks from Leaders.	Checks signatures, PoH, and execution results, then decides whether to vote on each block.	Quality control in another kitchen, where finished dishes are received and confirmed to match the recipe before serving.
Bank	The in‑validator component that tracks the current state (all accounts and balances) at a particular slot.	Applies transactions, updates balances, and produces the next consistent state for consensus and voting.	A master accounting book that always shows the latest balances after every transaction is written in.
Nakamoto coefficient	The minimum number of distinct entities that could collude to control or halt the network, based on stake distribution.	Quantifies decentralisation: the higher the number, the harder it is for any small group to censor or attack the chain.	A % of jurors would need to work for the same employer before you’d doubt the fairness of the trial.
Skip rate	The percentage of slots where the scheduled Leader failed to produce a block.	Measures validator and cluster health: a high skip rate means poor performance and fewer vote credits.	An employee’s absentee record showing how often they miss work.
Skipped slot	A slot where the scheduled Leader did not produce any block.	Appears as a missing block for that slot; consensus simply continues on the next slot and Leader.	A blank page in the captain’s log where nothing was written for that watch.
Leader’s pipeline 🟢	The flow of data through a leader validator: TPU (ingest) → BankingStage (process) → PoH recorder (timestamp).	Turns incoming transactions into ordered, executed entries in the ledger.	A factory conveyor belt: raw dough in → shaping → baking → finished loaves out.
Sealed slot	A slot that has ended and can no longer accept new transactions.	Marks the close of that specific time window so validators can vote on its contents.	The referee blowing the whistle to end the round; no more points can be scored.

5. Economics & tokens

TL;DR

Any decentralised network needs an automatic way to pay the people securing it. Naturally, users pay fees when they send transactions, and those fees go to validators who provide hardware, bandwidth, and security.

SOL is the main currency the network uses for fees, staking, and rewards.
Lamports are tiny units of SOL that let the system price things precisely.
Staking is how SOL holders back validators with value, earn rewards, and align incentives toward honest behaviour.

TERM	DEFINITION	WHAT IT DOES ON SOLANA	MENTAL MODEL
SOL	The native token of the Solana network.	Pays transaction and storage fees, is staked to validators for security, and underpins governance and economic activity.	The main national currency used to pay for everything in a country (e.g., the dollar).
Lamport	The smallest fractional unit of SOL (10⁻⁹ SOL).	Sets the minimum unit you can send or charge in fees, enabling precise accounting.	One cent in a dollar system, used for exact change when a full dollar is too large.
Micro‑lamport	An even smaller unit used internally for fee and prioritisation calculations.	Enables very granular pricing and prioritisation without changing the user‑visible lamport unit.	Accounting in 0.0001 cents so the system can keep track of tiny differences even when users only see whole cents.
Inflation	A deliberate increase in total SOL supply over time to fund rewards.	Pays validators and stakers for securing the network; parameters can be tuned over time.	A central bank printing new money to pay interest and stimulate economic participation.
Stake	SOL delegated to a validator via a stake account, increasing its voting weight.	Increases network security by putting value at risk behind honest validators; determines who earns inflation rewards and how much.	Owning shares in a company, which gives you both voting rights and dividends.
Vote credit	A counter of successful, timely votes cast by a validator on finalised forks.	Determines how much of the staking reward pool the validator and its delegators receive at the end of each epoch.	Points in a reward system that track how often someone does the right job on time, which later affects how much they earn.
Prioritisation fee	A dynamic fee component paid per compute unit to increase a transaction’s processing priority.	Lets transactions pay more to be included and executed sooner during congestion.	Paying for express shipping so your package arrives overnight instead of next week.
🟢SWQoS (Stake‑Weighted quality of service)	A network quality‑of‑service mechanism that allocates bandwidth in proportion to stake.	Ensures staked validators and their clients have guaranteed capacity, reducing spam and improving liveness.	A VIP fast‑pass at a theme park where season‑pass holders get a dedicated, faster line on every attraction (slot).
Token program (SPL token standard)	The standard on‑chain program for creating and managing fungible (and some non‑fungible) tokens.	Mints, burns, and transfers SPL tokens such as USDC, wSOL, and BONK, according to standardised rules.	A minting press machine that can print any design of currency you give it, as long as it follows strict design rules.
Token mint	A special token account that defines a specific SPL token’s configuration and supply.	Controls how many units of that token can exist and tracks parameters like decimals and authorities.	The master printing plate used to create a specific type of banknote.
Token extensions	An enhanced SPL token standard that adds optional features (hooks, fees, transfer restrictions, privacy, etc.).	Enables richer token behaviour, such as fee‑bearing, programmable, or confidential tokens, without requiring custom token logic.	An add‑on module for the minting press that lets you print notes with extra elements, without inventing a whole new system.
Warmup/cooldown period	The time it takes for a stake to fully activate or deactivate after delegation or withdrawal.	Prevents huge amounts of stake from instantly jumping between validators, stabilising consensus and rewards.	A 2-week notice period is required before leaving a job, so your employer can adjust gradually.

6. Clients

TL;DR

Solana is the shared backend that stores state and runs programs. Most people don’t talk to the cluster directly. Instead, they use clients, RPC endpoints, and dApp frontends that turn clicks and API calls into the low‑level requests the chain understands.

Clients are the software that connect to Solana clusters (wallets, SDKs, backends).
RPC endpoints are the URLs that clients hit to read data or send signed transactions.
Apps (dApp frontends) are the UIs that let users sign, send, and see what’s happening on‑chain.

TERM	DEFINITION	WHAT IT DOES ON SOLANA	MENTAL MODEL
Client	Any software that connects to a Solana cluster (wallets, SDKs, indexers, backends).	Bridges users or services with the blockchain’s RPC and transaction APIs.	A web browser like Chrome used to access the internet.
RPC endpoint	An HTTP/WebSocket URL exposed by a (typically non-staked) Solana node for Remote Procedure Calls.	Accepts read requests (get data), write requests (send transactions), and can stream data back to clients that subscribe.	A librarian who not only fetches books from the archive for you, but can also call you with live updates whenever new books arrive on the shelf.
App (dApp frontend)	A user‑facing frontend that interacts with Solana via RPC or a backend.	Gives users a UI to sign transactions and interact with on‑chain programs without touching raw RPC calls or CLIs.	The website interface you click on hiding the complex database logic behind itself
Bot (backend)	A backend that connects to Solana via RPC node, streams on‑chain data, and sends transactions (MEV bots, HFT systems, MMs or arb).	Executes automated strategies to gain profit for whoever runs it, reacting to on‑chain events faster than any human could.	An algorithmic trader sitting in the back office, watching the market feeds all day and placing orders on your behalf without you ever stepping onto the trading floor.
Compact array format	A serialisation format that stores arrays in a space‑efficient way.	Compresses arrays in messages to fit more data into each packet or block.	Vacuum‑packing clothes so they fit into a smaller suitcase.

7. Advanced concepts & future tech

TL;DR

Once the basics are in place, networks need new engines, better tooling, and safer consensus paths. This section covers the under‑the‑hood machinery that makes Solana faster, safer, or easier to build on, plus ideas that are still in the lab.

Validator clients (Agave, Firedancer, Frankendancer, Jito) are alternative engines that run the same chain but with different performance and features.
Consensus and networking upgrades (MCP, BAM, Alpenglow, Rotor, 2Z, Slashing) are new approaches to reaching agreement and moving data faster.
Developer tooling and execution layers (SVM, Anchor, Rust) are how builders actually write and run code on top of all that infrastructure.

TERM	DEFINITION	WHAT IT DOES ON SOLANA	MENTAL MODEL
Slashing	A penalty where part of a validator’s staked funds are destroyed if cryptographic evidence shows malicious behaviour (e.g. double‑signing).	Will create a real financial downside for cheating, helping keep validators honest.	A part of the security deposit your landlord takes if you break something in the apartment.
MCP (Multiple Concurrent Leaders) 🟢	A proposed mechanism allowing multiple leaders to propose blocks simultaneously.	Aims to drastically increase throughput by removing the single‑leader bottleneck.	Opening several checkout lanes at a supermarket instead of forcing everyone through just one.
Agave	The current main Solana validator client (successor to the original Solana Labs client).	Runs consensus, networking, and block production for most validators today.	The “Windows 10” of Solana, the standard OS that almost everyone is used to.
Firedancer	A new validator client built from scratch in C/C++ by Jump Crypto.	Targets much higher throughput (~1M TPS) and lower latency than Agave.	A Formula 1 race engine that fits into the original Solana car, letting the same car drive much faster on the same track.
Frankendancer	A hybrid validator client that combines Agave’s runtime with Firedancer’s networking/block production.	Lets operators test Firedancer’s speed on Mainnet while keeping Agave’s reliable runtime during the transition.	The original engine upgraded with Formula 1 parts, designed to fit into the same Solana car.
Validator client	Any full validator software implementation responsible for consensus (voting) and block production.	The program that runs on validator nodes to maintain the chain, vote on forks, and produce blocks.	A computer operating system, like Windows or macOS, that runs on the machine and controls how it works.
Alpenglow	A proposed new consensus and networking mechanism with fast‑path/slow‑path modes.	Will replace Proof of History (PoH) with Votor/Rotor for faster finality ~150ms and better reliability,	An upgrade to every card terminal in a store so payments take milliseconds (instead of minutes), letting the store serve far more customers.
SVM (Solana Virtual Machine)	The execution environment of Solana, decoupled from the consensus layer.	Allows other chains (L2s, appchains, rollups) to reuse Solana’s parallel execution model.	The Android OS: it runs on a Samsung (Solana mainnet) but can also run on a Pixel (Fogo/L2).
Anchor	A framework for Solana’s Sealevel runtime that provides developer tooling, macros, and an IDL.	Simplifies writing Solana programs by handling boilerplate (accounts, serialisation, error codes) for you.	Cake mix box: you just add eggs and water (logic) instead of buying 15 ingredients and starting from scratch.
Rust	The primary systems programming language used for Solana programs.	Lets developers write fast, memory‑safe on‑chain programs and off‑chain services.	English; the shared language people use to write rulebooks everyone can follow.
Jito	A modified Solana validator client maintained by Jito with built‑in support for MEV flows.	Lets validators accept bundles and tips from searchers and traders, and build fee‑maximising blocks while still following Solana’s consensus rules.	A delivery truck with a smart routing system that highlights express packages, pays tips, and helps the driver earn more on each route.
Jito BAM	Jito's new open‑source block‑building marketplace that uses Trusted Execution Environments (TEEs) and cryptographic proofs to assemble blocks.	Lets validators outsource block construction to a transparent, programmable marketplace that aims for fairer ordering and more custom block strategies.	A parcel sorter who works out which parcels should go on the next van and in what order, then suggests that loading plan to the driver.
DoubleZero	A high‑performance infrastructure layer built to connect Solana validators and RPC nodes over a private, low‑latency fibre network.	Removes public Internet bottlenecks so blocks, shreds, and data can move between nodes faster and more reliably.	A staff‑only corridor that lets employees move boxes between storerooms without squeezing through crowded customer aisles.

Conclusion

Solana can feel like an entirely new universe of jargon, moving parts, and acronyms. That’s normal: every Solana maxie, builder, and infra nerd you know started by wrestling with these same words, trying to make sense of them.

The goal of this glossary is not for you to memorise everything, but to give you a map: what each piece does, how it fits into the machine, and a simple way to talk about it without diving into the docs.