How Solana works: accounts, programs, execution and consensus

Accounts hold the state a program works with

An account is a record addressed by a public key. Its base information includes lamports, data and an owning program. An executable account has a different purpose from a user's ordinary SOL account or a record holding a lending position.

Take a token transfer. A mint identifies the asset and its precision. A source token account holds a quantity under one authority. A destination token account holds a quantity under another. The token program defines how a transfer updates those holdings.

The account's base owner names the program responsible for its data rules. A user authority can be recorded inside that data. A USDC holding account can therefore be owned at the base level by the Token Program while a wallet key has the holder's transfer authority.

Programs contain executable code, and mutable application state lives in separate supplied accounts. This separation lets a program operate on many users' positions without placing every position inside its code account.

Instructions tell programs what to do

An instruction names a program, the accounts it will use and program-defined data. A transfer instruction can specify a quantity; an application instruction can request the creation or update of a position.

A transaction packages instructions into a signed message. The message identifies required signers and relevant read/write access, along with its validity information. Signing authorises the constructed message. The runtime and programs still enforce their checks during processing.

One transaction can prepare an account, perform a trade and clean up a temporary account. A program can also invoke another program during execution, known as a cross-program invocation. The user may see one wallet approval covering a composed action.

This is why reading only the website's button label is incomplete. The actual operation is the collection of program calls and supplied accounts. Builders construct those relationships; explorers decode them after submission.

The runtime checks access and meters the work

The runtime is the execution environment that runs instructions under network rules. It checks message validity, account permissions and resource constraints. Programs add application-specific conditions, such as the required authority or an acceptable trade outcome.

A program cannot modify arbitrary data merely because an account address was supplied. Writable declarations and program ownership are part of the rules, and the program must enforce the intended relationship between the signer and the action.

Execution uses compute units and other bounded resources. If a transaction exceeds its allowed work or an instruction returns an error, execution fails. Application changes execute atomically: they succeed together or are rolled back together. Fees and special durable-nonce handling must be interpreted separately.

For example, an application may request two payments from the same payer. If the second cannot be funded, the first payment's application change does not remain as a successful prefix of that failed transaction. The fee can still be retained for processing.

Execution, consensus and observation

Independent accounts allow independent work

Consider two transfers: Alice pays Bob, while Carol pays Dan. If their writable accounts are separate and the remaining access is compatible, the runtime can schedule their work in parallel when resources permit. Both can read the same read-only program without creating a write conflict.

Now consider two traders swapping against the same pool. Both may need to write its reserves or other shared state. The trades need an ordering because the first changes the conditions seen by the next. Calling the system parallel does not remove that shared-state dependency.

A program's state layout therefore affects its workload. Independent user records can avoid unnecessary contention, while one shared writable counter can couple otherwise unrelated actions. Builders should declare required access accurately and minimise avoidable shared writes.

Parallel scheduling describes execution opportunities. It does not mean every instruction within one transaction is unordered or that every transaction runs at once. Instructions have defined execution relationships and the runtime has finite resources.

Block production, distribution and consensus have separate jobs

A block-production process assembles network work under the protocol's rules. Distribution delivers relevant data to other participants. Consensus determines which candidate history becomes accepted. These jobs interact but are not interchangeable explanations of performance.

The Foundation's current migration documentation says Alpenglow's Votor voting protocol activated on mainnet in epoch 1064 on 21 October 2026. It describes direct votes and certificates replacing the previous voting layer. Rotor is a later propagation phase, separate from the active Votor change.

Older explanations built around Proof of History pacing or a Tower-era 32-slot finality stack describe a previous architecture. Current data consumers must also handle candidate banks: a slot is not a universal one-to-one label for every observed candidate block.

Consensus weight follows the applicable stake-based model. A decorative picture with evenly sized computers should not be interpreted as one equally weighted vote per machine. For measured concentration, use explicit stake definitions and operator attribution.

Applications observe the result through services

A wallet can submit a signed request to an RPC service. A successful send response means the service accepted the request under its API contract; it does not establish successful program execution. The application follows the signature and relevant state afterward.

For current migrated clusters, the Foundation says confirmed and finalized describe the same state and directs new code toward finalized. Generic older commitment tutorials can lag that migration guidance.

The application can still learn the result later because of network transport, provider processing, polling intervals or its own business logic. An exchange can have an additional customer-credit step after the network transfer.

Measure these intervals with named start and end events. A consensus finality target cannot be substituted for a claim that a browser action, bank payout or every trade completes in that same interval.

Use one swap to connect the model

Suppose a user asks to exchange a chosen amount of USDC for SOL. The quote describes a possible route and accepted execution bounds. The transaction supplies the trading program, token accounts, relevant pool state and any necessary setup instructions.

The signer approves the message. The runtime enforces its access and resource rules. The trading program applies the pool's calculation and checks the signed conditions, using token-program calls for the relevant movements. If an included instruction fails, the transaction's application changes roll back.

Compatible unrelated work can be scheduled separately, while another trade writing the same state needs ordered access. The accepted network history then establishes the transaction result.

The wallet obtains that result and displays the changed holdings. An explorer can connect the program calls to input/output account changes and costs. Continue with transaction structure, CPI or RPC for the layer you want to use.

Common questions