Skip to main content


The following terms are used throughout the documentation.


A persistent file addressed by public key and with lamports tracking its lifetime.


A front-end application that interacts with a Solana cluster.

bank state#

The result of interpreting all programs on the ledger at a given tick height. It includes at least the set of all accounts holding nonzero native tokens.


A contiguous set of entries on the ledger covered by a vote. A leader produces at most one block per slot.


A preimage resistant hash of the ledger at a given block height. Taken from the last entry id in the slot

block height#

The number of blocks beneath the current block. The first block after the genesis block has height one.

bootstrap validator#

The first validator to produce a block.

CBC block#

Smallest encrypted chunk of ledger, an encrypted ledger segment would be made of many CBC blocks. ledger_segment_size / cbc_block_size to be exact.


A node that utilizes the cluster.


A set of validators maintaining a single ledger.

confirmation time#

The wallclock duration between a leader creating a tick entry and creating a confirmed block.

confirmed block#

A block that has received a supermajority of ledger votes with a ledger interpretation that matches the leader's.

control plane#

A gossip network connecting all nodes of a cluster.

cooldown period#

Some number of epochs after stake has been deactivated while it progressively becomes available for withdrawal. During this period, the stake is considered to be "deactivating". More info about: warmup and cooldown


See vote credit.

cross-program invocation#

An instruction called from within an instruction. Put differently, it is how a program calls into another program. For more information, see calling between programs.

data plane#

A multicast network used to efficiently validate entries and gain consensus.


An off-chain service that acts as a custodian for a user's private key. It typically serves to validate and sign transactions.


An entry on the ledger either a tick or a transactions entry.

entry id#

A preimage resistant hash over the final contents of an entry, which acts as the entry's globally unique identifier. The hash serves as evidence of:

  • The entry being generated after a duration of time
  • The specified transactions are those included in the entry
  • The entry's position with respect to other entries in ledger

See Proof of History.


The time, i.e. number of slots, for which a leader schedule is valid.

fee account#

The fee account in the transaction is the account pays for the cost of including the transaction in the ledger. This is the first account in the transaction. This account must be declared as Read-Write (writable) in the transaction since paying for the transaction reduces the account balance.


When nodes representing 2/3rd of the stake have a common root.


A ledger derived from common entries but then diverged.

genesis block#

The first block in the chain.

genesis config#

The configuration file that prepares the ledger for the genesis block.


A digital fingerprint of a sequence of bytes.


An increase in token supply over time used to fund rewards for validation and to fund continued development of Solana.

inner instruction#

See cross-program invocation.


The smallest unit of a program that a client can include in a transaction. Within its processing code, an instruction may contain one or more cross-program invocations.


A public key and corresponding private key.


A fractional native token with the value of 0.000000001 sol.


The role of a validator when it is appending entries to the ledger.

leader schedule#

A sequence of validator public keys mapped to slots. The cluster uses the leader schedule to determine which validator is the leader at any moment in time.


A list of entries containing transactions signed by clients. Conceptually, this can be traced back to the genesis block, but actual validators's ledger may have only newer blocks to save storage usage as older ones not needed for validation of future blocks by design.

ledger vote#

A hash of the validator's state at a given tick height. It comprises a validator's affirmation that a block it has received has been verified, as well as a promise not to vote for a conflicting block (i.e. fork) for a specific amount of time, the lockout period.

light client#

A type of client that can verify it's pointing to a valid cluster. It performs more ledger verification than a thin client and less than a validator.


A program with the ability to interpret the binary encoding of other on-chain programs.


The duration of time for which a validator is unable to vote on another fork.

native token#

The token used to track work done by nodes in a cluster.


A computer participating in a cluster.

node count#

The number of validators participating in a cluster.


See Proof of History.


A weighted credit in a rewards regime. In the validator rewards regime, the number of points owed to a stake during redemption is the product of the vote credits earned and the number of lamports staked.

private key#

The private key of a keypair.


The code that interprets instructions.

program id#

The public key of the account containing a program.

Proof of History#

A stack of proofs, each which proves that some data existed before the proof was created and that a precise duration of time passed before the previous proof. Like a VDF, a Proof of History can be verified in less time than it took to produce.

public key#

The public key of a keypair.


A block or slot that has reached maximum lockout on a validator. The root is the highest block that is an ancestor of all active forks on a validator. All ancestor blocks of a root are also transitively a root. Blocks that are not an ancestor and not a descendant of the root are excluded from consideration for consensus and can be discarded.


The component of a validator responsible for program execution.


A fraction of a block; the smallest unit sent between validators.


A 64-byte ed25519 signature of R (32-bytes) and S (32-bytes). With the requirement that R is a packed Edwards point not of small order and S is a scalar in the range of 0 <= S < L. This requirement ensures no signature malleability. Each transaction must have at least one signature for fee account. Thus, the first signature in transaction can be treated as transacton id

skipped slot#

A past slot that did not produce a block, because the leader was offline or the fork containing the slot was abandoned for a better alternative by cluster consensus. A skipped slot will not appear as an ancestor for blocks at subsequent slots, nor increment the block height, nor expire the oldest recent_blockhash.

Whether a slot has been skipped can only be determined when it becomes older than the latest rooted (thus not-skipped) slot.


The period of time for which each leader ingests transactions and produces a block.

Collectively, slots create a logical clock. Slots are ordered sequentially and non-overlapping, comprising roughly equal real-world time as per PoH.

smart contract#

A set of constraints that once satisfied, signal to a program that some predefined account updates are permitted.


The native token tracked by a cluster recognized by the company Solana.


Tokens forfeit to the cluster if malicious validator behavior can be proven.


2/3 of a cluster.


An account maintained by the runtime and provided to programs which provide cluster state such as current tick height, rewards points values, etc. Sysvars can either be passed to the program as an account or queried by the program via a syscall.

thin client#

A type of client that trusts it is communicating with a valid cluster.


A ledger entry that estimates wallclock duration.

tick height#

The Nth tick in the ledger.


A scarce, fungible member of a set of tokens.


Transactions per second.


One or more instructions signed by the client using one or more keypairs and executed atomically with only two possible outcomes: success or failure.

transaction id#

The first signature in a transaction, which can be used to uniquely identify the transaction across the complete ledger.

transaction confirmations#

The number of confirmed blocks since the transaction was accepted onto the ledger. A transaction is finalized when its block becomes a root.

transactions entry#

A set of transactions that may be executed in parallel.


A full participant in the cluster responsible for validating the ledger and producing new blocks.


See verifiable delay function.

verifiable delay function#

A function that takes a fixed amount of time to execute that produces a proof that it ran, which can then be verified in less time than it took to produce.


See ledger vote.

vote credit#

A reward tally for validators. A vote credit is awarded to a validator in its vote account when the validator reaches a root.


A collection of keypairs.

warmup period#

Some number of epochs after stake has been delegated while it progressively becomes effective. During this period, the stake is considered to be "activating". More info about: warmup and cooldown