What is an Instruction
An instruction is a single call to a single program – "swap on this Orca pool," "create this token account," "transfer these tokens." A transaction is the envelope around one or more instructions – signed, size-limited, and executed atomically: if any of the instructions inside fail to execute, then the entire transaction fails, no state changes, and nothing in the transaction happens at all. Understanding the two-level structure of Solana – the difference between an instruction and a transaction – goes a long way toward understanding most of what you see on a Solana block explorer.
To put it another way, transactions and instructions work much like online shopping. Each line item in your shopping cart is an instruction. When you go to the checkout and hit the "pay" button, you've created a transaction. Your single "pay" instruction is used to authorize every line item in your transaction. And if your bank or card decline your payment instruction at checkout, then no items ship from the store. It's "all or nothing;" you never get to take half of your shopping cart home. Solana makes this "all or nothing" guarantee built-in at the protocol level, free of charge on every transaction.
How Transactions Work Technically
A transaction consists of four main components: at least one signature, a list of every account the transaction may modify, a recent blockhash, and one or more instructions. Each instruction declares which program it should call, which accounts the program may access, and a binary blob of input data for that instruction. The whole transaction must fit within 1,232 bytes – this was chosen so that the entire payload of a transaction could fit within a single network packet.
Two of these details serve some important purposes. The recent blockhash is used as a timestamp so that transactions eventually expire – a transaction roughly 150 slots from its blockhash is too old to be accepted by the network; roughly 1 minute of latency (given a 400 ms target slot time) is enough to ensure that most stale transactions die without clogging the network. The base fee is 5,000 lamports per signature – roughly $0.0004 in fees per signature at $80 SOL – regardless of how many instructions it contains, so there are very cheap single instructions.
A Jupiter swap can be a good example of how instructions are bundled within a single transaction. Many Jupiter swaps execute one transaction that includes one instruction to create your new destination token account, one or more swap instructions going through Raydium and Orca liquidity pools, and one final instruction to close any temporary wrapped-SOL accounts. If the price of the second liquidity pool is outside of your slippage tolerance when the swap actually executes, then the entire transaction rolls back. You'll never see a half-exchange with some tokens stuck in one place and some stuck in another, because atomicity guarantees that the entire transaction either goes all the way through or doesn't happen at all.
How This Compares to Ethereum
An Ethereum transaction is one top-level contract call into exactly one contract. If you want multiple top-level actions in one transaction, you need a multicall contract, or a smart account as specified in EIP-4337, or you do a multi-step process like you would for a token swap (send an approve transaction, send a swap transaction, and so forth), where each step requires a separate transaction, pays a separate base fee, and waits in its own queue. Solana builds atomic batching into the very base of the protocol itself. A batch of five instructions can be executed atomically with no special tooling, no extra contracts, or special rules. Solana's account list is also used by Sealevel, Solana's runtime, which can read and write any of the accounts listed within a transaction to allow transactions to be executed in parallel. The EVM has traditionally had to process Ethereum transactions one-by-one.
The 1,232 byte transaction size limit is not an exaggeration. A complicated multi-hop router can call dozens of programs and touch dozens of tokens and will be too big to fit into a transaction. This is one of the reasons versioned transactions and on-chain address lookup tables (ALTs) are in the works, which allows you to write compact, one-byte pointers on-chain to a directory of addresses instead of using the full 32 bytes to encode an account address. There may also be other situations that are just too big for a single transaction size, so your instruction sequence must span multiple transactions; in these cases atomicity must be compromised between the multiple separate instructions.
Why the Distinction Matters
Distinguishing instructions from transactions explains a lot of what you might experience using Solana day-to-day. Solscan listing 7 instructions under one transaction? You're making a single transaction with 7 steps, all atomic. An NFT mint sold out, then you saw a "transaction failed" message? You paid a 5,000 lamport fee, but nothing in the transaction happened. A message from Phantom "transaction expired" after your dApp hung for several seconds during a congested period? Your transaction's blockhash had already become too old (past 150 slots) for your transaction to be accepted by Solana before the leader that accepted the transaction had time to include it in the ledger; the money was never spent in the blockchain; you're perfectly safe to resubmit the transaction. Ethereum users have been trained to be concerned with two things, and Solana has solved them both: partial, halfway execution states and stuck transactions never included in the ledger. What it costs you for that is a size limit on your transaction payload and a one-minute shot-clock for how quickly your transaction must include to be executed.
So if one instruction fails, do I lose my money?
You pay a 5,000-lamport transaction fee; all state changes from any of your instructions are reverted and the transaction never happened in its entirety. The transaction is considered atomic; if one fails, all fail and none happened.
