How a blockchain works, explained with a Solana transfer

Start with a payment and a shared record

Alice has 5 SOL and wants to send 1 SOL to Bob. A bank would update two balances in its own database. On Solana, the payment updates accounts maintained by a network of validators. Bob can check the result through a wallet, an explorer or an application reading the network.

The interesting part is agreement. Alice could sign two requests that each try to spend the same funds. Computers may receive those requests in different orders. A payment system needs a consistent way to decide what happened and reject spending that the accepted state cannot support. This is the double-spending problem.

A blockchain combines an ordered history of accepted transactions with rules for applying them. State means the information those transactions leave behind: balances, token holdings and application records. History explains the changes; state tells an application what it can use now.

Solana uses an account model. An account is an addressable record with a SOL balance and other fields. Some accounts contain token data or an application's state. You can think of an address as the label used to find a record, provided you remember that different records have different rules.

Keys and signatures authorise the change

Alice's wallet prepares a message describing the payment. It names the relevant accounts, the instruction to execute and the transaction's validity information. Her signing key creates a digital signature over that message.

Anyone can check the signature using the corresponding public key. That check establishes that the signer authorised these exact message bytes. Changing the recipient or amount after signing changes the message and invalidates the signature.

The private key stays with the signing system. A software wallet may keep it encrypted on a device; a hardware wallet performs signing on its own device. A recovery phrase can recreate keys in wallets that use that recovery scheme. Giving someone the public receiving address does not give them the private signing key.

Signatures are one part of authorisation. Programs also check which role a signer holds. A signature from an unrelated person is cryptographically valid but cannot authorise spending from Alice's ordinary account. Later articles examine token delegates, stake authorities and program-controlled addresses.

Transactions, blocks and hashes organise the history

A transaction packages a requested action and its authorisation. A block packages network history under the chain's block-production rules. Many transactions can belong to a block. A swap can also contain several instructions inside one transaction.

A cryptographic hash is a fixed-size fingerprint calculated from data. Change the input and the fingerprint changes. Blockchain records use cryptographic references to bind parts of history together, so an altered earlier record will fail the expected checks.

Hashes make changes detectable. The consensus mechanism determines which history participants accept. An attacker cannot establish a legitimate new history merely by editing a local file and recalculating its fingerprints.

A diagram of boxes connected by hashes is a useful introduction to linked history, but chains differ in how they produce and finalise blocks. In current Solana, a slot is a scheduling unit; it is not a promise that exactly one candidate block exists or becomes final. Keep the general blockchain model separate from protocol-specific details.

A transfer changes a shared ledger

Follow Alice’s 1 SOL transfer

Suppose Alice and Bob already have ordinary accounts on the intended network. Alice chooses Bob's receiving address and enters 1 SOL. Her wallet builds a System Program transfer instruction and identifies the transaction's fee payer.

For a teaching calculation, let Alice pay a total network fee of 0.000005 SOL. After a successful transfer, her balance falls from 5 SOL to 3.999995 SOL. Bob's balance increases by 1 SOL. The fee is a separate debit; it does not reduce the 1 SOL specified for Bob. These are chosen example amounts, rather than a quote for every transaction.

The network verifies the required signatures and checks whether the request can execute. The System Program applies its transfer rules to the supplied accounts. A request to spend more than the available funds fails. A transaction can carry several instructions, whose application changes execute atomically: a later failing instruction rolls those application changes back. Execution failures can still pay a fee.

The wallet submits the signed request, often through an RPC service. RPC means remote procedure call: a standard way for an application to request data or submit work. Receipt by that service starts the observation process. Alice then checks the transaction's execution and resulting balances.

Validators agree on the accepted history

A validator runs software that processes network activity and participates in consensus. Consensus gives participants rules for choosing an accepted history when messages arrive at different times or some participants misbehave.

Different networks use different mechanisms. Bitcoin uses proof of work: producing a qualifying block requires repeated hashing, while checking the result is cheap. Solana uses proof of stake, where stake matters to consensus participation. A picture showing ten equally sized computers does not describe their voting weight.

In the current Solana architecture, Alpenglow's Votor protocol handles voting and certificates. The Foundation's migration documentation reports mainnet activation on 21 October 2026. Older descriptions centred on TowerBFT and Proof of History pacing need to be read as historical explanations.

Execution asks what the program does with a transaction. Consensus asks which history the network accepts. Finality concerns the accepted result under the protocol's rules. An app must still obtain that result and show it to Alice or Bob. These separate jobs explain why a wallet display can lag a network event.

Public addresses reveal more than a single payment

A public address is a persistent identifier, so a sequence of payments can reveal relationships even when the address has no real name attached. A service that already knows a customer's identity can connect that identity to a deposit. Other observers may see the transfers without knowing who controlled the address.

Consider a teaching case: Alice receives her salary at address A and later posts A as a public donation address. An observer can connect activity involving A across those contexts. Creating another address does not automatically erase the link if a public transfer connects the two.

An explorer groups records for convenience. Its labels and interpretations come from a data service, while the transaction's accounts and amounts come from the underlying records. A provider can mislabel an address or omit history. Check the identifier and accepted result before treating the displayed story as established fact.

The same distinction explains pseudonymity. You can inspect an address without proving who controls it, and one person can control several addresses. Do not equate an address count with a user count. The active-address guide follows that measurement problem in detail.

Coins, tokens and applications use the same record differently

SOL is Solana's native asset. Its balances are accounted for in lamports, with one billion lamports in one SOL. Network fees use SOL. Other assets, such as USDC, use token programs and token holding accounts.

A token's mint identifies its issuance. Two tokens can share a display name while having different mints. The mint and the program's state determine properties such as supply controls; a wallet image is presentation data.

Programs extend the record beyond simple payments. A trading program can exchange two tokens according to a pool's rules. A lending program can record collateral and debt. An asset program can record the owner and metadata reference of a collectible. Each operation uses instructions and accounts, so the transfer model remains useful as you learn more complex actions.

The application around a program supplies a human interface and may use external services. A token representing an offchain claim also depends on the issuer fulfilling that claim. Network execution establishes the onchain result; other parts of a product have their own responsibilities.

Know when the shared record is useful

A shared blockchain is useful when independent participants need to transfer assets or coordinate state under common, publicly inspectable rules. A wallet can use the same token in several compatible applications without each application maintaining its own isolated ownership database.

A conventional database is often simpler for information that one organisation controls and needs to edit privately. Public execution brings fees, explicit permissions and a history that users should treat as visible. Reusing a public address can link payments and other activity.

For your first operation, identify the network and exact asset, review the recipient and amount, then save the signature. Open it in an explorer and compare the instructions and account changes with your intention. That exercise connects every concept in this guide to evidence you can inspect.

Continue with the Solana ecosystem, then set up and understand a wallet. Developers can practise the same concepts on devnet with test assets.

Common questions