There is a particular cognitive dissonance that hits you when you first study blockchain concepts and Solana’s execution model in particular. It isn’t confusion exactly — it’s something closer to the feeling of a familiar room with the furniture rearranged. Everything is still there. But it’s been deliberately separated.

Just checking our cognitive compass: in Software Engineering, what we do with libraries and clients and nodes is create enforceable abstractions that allow programs (automated computations) to scale and to have predictable output for a spectrum of valid inputs.

With that we have a definition that feels abstract until we apply it to a very concrete problem:

I want a gazillion valid transactions per second available all the time!

So what very concrete problem does Solana solve for us? Well — here’s the precise technical challenge that gives us that throughput:

Solana solves the fundamental “synchronization bottleneck” of transactions in a decentralized network. Many nodes can process many transactions very fast without the overhead of nodes talking to each other to agree which transaction happened before the other.

Solana works as if it had a centralized global clock providing Proof of History but, with an elegant architectural approach and cryptographic Math, that’s achieved in a way that doesn’t require centralization. This makes it performant, doesn’t introduce single points of failure, and is unfalsifiable (transparently backed by Math).

If you take a photo of yourself holding today’s New York Times, you have proven that the photo was taken after that newspaper was printed.

If the New York Times then publishes that photo in tomorrow’s paper, you have proven the photo existed before tomorrow’s edition.

Solana does that but with Math functions to produce the Proof of History and keep the ledger consistent. This happens millions of times per second. Your transaction is the “photo,” and the PoH stream is the “newspaper.” By being sandwiched between two hashes, your transaction is chronologically locked. If a Leader tries to broadcast a “fake” clock (e.g., skips hashes to make it look like they worked faster), the parallel verification by the other nodes will immediately see the math doesn’t add up, and the Leader’s staked SOL is slashed — potentially millions of dollars — for providing a faulty proof.

So that’s an interesting proposition, but what are the building blocks? Without them conveniently defined, it’s hard to think about how it gets used and what all this is useful for.

Main Solana concepts

Account. A persistent data structure stored under a 32-byte address, with five fields:

{
    lamports: u64       // Balance in Lamports. Owner debits; any program credits.
    data: Vec<u8>       // State (when an Account) or BPF bytecode (when a Program). Owner-writable only.
    owner: Pubkey       // The Program with write authority over this Account.
    executable: bool    // false = data Account; true = Program.
    rent_epoch: u64     // Deprecated. Set to u64::MAX for rent-exempt Accounts.
}

Program. An Account with executable = true. Its data field is not state but compiled BPF bytecode — the immutable instructions the runtime processes when the Program is invoked.

SOL. The network’s native token. Used to pay transaction fees, the rent-exempt deposit on Accounts, and to stake with validators.

Lamports. The smallest unit of SOL: 1 SOL = 1,000,000,000 Lamports (1 Lamport = 10⁻⁹ SOL). Named after Leslie Lamport, a pioneer in distributed systems.

Rent. The minimum SOL balance every Account must hold to remain stored on-chain, proportional to its data size. It is a refundable deposit, not a fee — the full balance is recovered when the Account is closed.

Owner. Every Account has an owner Program. Only the owner can mutate the Account’s data and debit Lamports from it. Any program can credit Lamports to a writable Account.

Instruction. The smallest unit of execution. A request to invoke a specific function on a Program, carrying the Program ID, the list of Accounts it will read or write, and a byte array whose format the target Program defines (typically a discriminator followed by serialized arguments).

Transaction. A bundle of one or more Instructions executed atomically — all succeed or all revert. It carries the signatures that authorize the changes and a recent blockhash that anchors the Transaction in time and prevents replay.

Proof of History (PoH). The decentralized clock. A sequential hash chain that produces a verifiable passage of time, letting validators order transactions without round-tripping to agree on order.

Sealevel. The parallel transaction processing engine (sometimes referred to today as the Solana runtime / SVM). Because every Transaction must declare upfront which Accounts it will read and which it will write, the runtime can build a dependency graph of pending Transactions before scheduling. Non-conflicting Transactions — those touching disjoint sets of Accounts — execute on separate CPU cores at the same time, locking only the specific Accounts they touch. Parallelism is not bolted on top of the system; it falls out of the model itself once state is external and dependencies are explicit.

PDAs (Program Derived Addresses). Account addresses derived deterministically from a Program ID and a set of seeds, and guaranteed to lie off the Ed25519 curve — which means no private key can exist for them. The runtime lets the Program whose ID was used in the derivation sign on a PDA’s behalf via invoke_signed, enabling Programs to act as autonomous custodians of state and assets.

CPI (Cross-Program Invocation). The mechanism by which one Program invokes a specific instruction on another Program during execution. CPIs are how composition happens on Solana: any Program’s instructions can be called by any other Program.

What the building blocks unlock

The primitives above are inert until you start composing them. And once you do, the interesting question is no longer “what is an Account?” but “what falls out when you compose Accounts and Programs in everyday situations?”

Most of what we already do today with registries, ticket booths, loyalty desks, and intermediaries can be expressed as small compositions of these moves. Four examples, deliberately chosen from outside the crypto bubble, to make the design space visible.

Concert and event tickets

A ticket today is a row in a company’s database. Whether you really own it depends on whether that company is still in business and willing to honor it. Resale is governed by whichever marketplace the company integrated with; usually the one that pays them the most, not the one that is best for you.

In Solana you can model it as the ticket being an Account and the “box office” being a Program. The Program owns the ticket Accounts and defines the rules: how many can be issued, who can resell, what the maximum resale price is, whether the ticket is bound to your identity at the door. The venue scans the ticket by reading the Account directly. There is no central database to trust, because the Account is the record of truth. If the company that sold you the ticket disappears tomorrow, you still hold it — the Program is still on chain, the Account is still yours.

The shift is from “the company keeps a record of your ticket” to “you hold the ticket, and the Program defines what can be done with it.”

Land titles and registries

Today, owning a piece of property means a county office somewhere has a record with your name on it. Title insurance exists because everyone knows that record can be wrong, forged, or contested. An entire industry is a tax on the unreliability of the registry.

Model the deed as an Account. The local registry runs the Program. The Program enforces the rules: only the current title-holder can authorize a transfer, the buyer must sign, the state change is recorded atomically. Every transfer is in the public history forever, and nothing outside the registry’s Program can quietly alter a deed: the Account’s owner field — pointing to the registry Program — is enforced by the runtime, not by a clerk.

The “security guard” the runtime provides (only the designated custodian can transform the state) is exactly what we pay notaries and title companies to do today, except now it is enforced by infrastructure instead of by trust.

Loyalty and gift cards that work across stores

Every coffee shop, airline, and bookstore runs its own loyalty program. Their points don’t talk to each other because integrating two databases across two companies is a contract negotiation, not a technical exercise.

Model loyalty as a Program. Every customer’s balance is an Account. A coffee shop’s point-of-sale calls the Program; so does a bookstore’s; so does an airline’s. None of them need a side deal with the others. The points compose because the Program is shared and the Accounts are public. A customer can spend points earned at one merchant on another in a single atomic Transaction, because the rules are the same Program.

This is the move that quietly removes “integrations” as a concept. There is no API to wire up. There is one Program, addressed by a public key, and any merchant can call it.

Supply chain and product recalls

This is the example that puts more of the model to work because the right programs model the desired state machine that renders its activity in the blockchain.

A bag of coffee beans gets a Program-owned Account when it is harvested. Each step in the chain — the roaster, the distributor, the retailer — calls the Program to transfer custody. The Program enforces the legal sequence of states: a bag cannot move from “harvested” directly to “on the shelf”; it has to pass through “roasted” and “in transit.” Only the current custodian recorded inside the Account can authorize the next step. The full history lives in the ledger, which is the changes file from earlier in this article. A consumer scanning the QR code on the bag at the supermarket reads not a marketing claim but a verifiable history.

Now the interesting part. A contamination is detected at a roaster’s batch on March 14th. In a traditional system the company emails distributors, hopes retailers respond, prints recall notices, and waits weeks while affected product continues to be sold. With this model, a single Transaction queries every Account whose history includes that batch, calls the retail Program via CPI to flag every affected unit as recalled, and atomically updates all of them. Sealevel runs those updates in parallel because each affected Account is independent — no two of them touch the same memory.

The recall is not a workflow that has to be coordinated across companies. It is a Transaction. The same primitives that let you transfer a single ticket let you recall a million products in seconds, because the dependency graph is declared up front and the runtime knows what is independent of what.

Notice that none of these are novel ideas. They are traditional problems implemented with new primitives.

Primitives that do not require a coordinating intermediary at the center.

The pattern is the same across every example.

A Program defines the rules for a kind of thing — a ticket, a deed, a loyalty card, a bag of coffee. Accounts hold the individual instances. The runtime enforces who is allowed to change what. Transactions are the atomic, parallelizable units of change.

When that lands, the ergonomic shift lands with it: we stop asking “what does this object do?” and start asking “what are the valid transformations of this state, and who is authorized to invoke them?”

Solana’s answer is direct: divorce the state from the behavior, publish both, enforce custody at the infrastructure layer, and let parallelism emerge from the explicit dependency graph.

All deterministic, all independently verifiable by Math.

The room is not rearranged badly. It is rearranged so a million people can walk through it at once without bumping into each other — and the registrar, the box office, the loyalty desk, and the customs inspector are all the same kind of thing, expressed in code that anyone can read.