Arc 3 of 100 Days of Solana was the arc where Solana stopped being something we read from and started being something we wrote to.
Across the arc, we inspected transactions, sent SOL on devnet, built a transfer tool, tracked confirmation, and deliberately triggered failures. That shift changes how everything else fits together: accounts, programs, fees, confirmation, errors, and application state.
They all hang off one idea:
A Solana transaction is a signed request to change on-chain state.
Reading is pretty much like Web2. Writing is not.
Reading from Solana maps neatly onto things most Web2 developers already do. You ask for a balance. You fetch account data. You look up a transaction. The network answers.
Writing is different. It is closer to making a POST request that changes production data, except there is no single server receiving it.
In a Web2 app, a write usually follows a familiar path: take some input, check authorization, run logic, change state, return a result. Solana has the same broad shape, but the mechanics are different. To change state, you create a transaction: a signed, time-limited message that says which accounts are involved, which program should run, and what instruction that program should execute.
That is why a SOL transfer is such a useful first write. It is small enough to understand, but it contains the ingredients that keep showing up across Solana development: accounts, signatures, instructions, fees, confirmation, and failure modes.
Calling a program, minting a token, swapping an asset, or updating application state all build on the same foundation. The details change, but the shape remains familiar: prepare the instruction, sign the transaction, submit it to the network, and handle the result.
That was the real purpose of Arc 3: not just sending SOL, but learning Solana’s write path.
The HTTP analogy helps, until it doesn't
If you're coming from a Web2 background, the easiest on-ramp is to think of a Solana transaction as something like an HTTP request. At first, the comparison is useful. A transaction has structure, travels over the network, carries authorization, asks another system to do something, and produces a result you can inspect afterwards.
But it breaks down once you look closer.
An HTTP request is handled by an application server or backend service. A Solana transaction is validated by a network.
An HTTP request usually authenticates with a cookie, API key, or bearer token. A Solana transaction is signed with a cryptographic keypair before it leaves your machine.
And unlike a chain of separate API calls, a Solana transaction is atomic. If one instruction fails, the whole transaction fails. You do not get partial success where step two worked but step three did not.
There is also a freshness constraint. Every transaction includes a recent blockhash, which means it is only valid for a short window before the network refuses it.
So maybe it's better to think of it like this:
A Solana transaction is a signed message that says: “Run these instructions, against these accounts, before this short validity window closes.”
That makes it different from a normal API request. It is authorized before it is sent, it only works for a short window, and it succeeds or fails as one unit. On Solana, that short window is enforced with a recent blockhash, which stops old transactions from being replayed forever.
What's actually inside a transaction
Transactions can feel abstract because most of the time we only see the receipt: a signature, a success message, or an Explorer link.
But a transaction is not just a receipt. It is the actual message sent to the network.
If you have ever opened your browser’s network tab and inspected a request, the idea is similar. You stop seeing “the button worked” and start seeing the parts underneath: who sent the request, what data went with it, what endpoint it hit, and what the server returned.
Solana gives us the same kind of visibility. Using solana confirm -v and Solana Explorer, you can open up a transaction and see the main pieces:
- Signatures: proof of who authorized the transaction.
- Account keys: the accounts the transaction reads from or writes to.
- Recent blockhash: the freshness check that helps stop old transactions being replayed.
- Instructions: the operations the transaction asks a program to run.
The account list is not just a bag of addresses. Its ordering matters. The transaction header uses position to work out which accounts are signers, which are writable, and which are read-only.
You do not need to memorize the whole transaction format before building anything. The important thing is to see that a transaction is structured data, not magic.
It has authorization. It has inputs. It has instructions. It has constraints.
Once you have seen that structure once, a transaction stops feeling like a mysterious blockchain blob and starts looking more like something a developer can inspect, reason about, and debug.
Why a simple SOL transfer teaches so much
A SOL transfer is a good first write because it is small enough to follow, but complete enough to show the full pattern.
In Web2 terms, it is like starting with the simplest useful endpoint: POST /transfer. You are not building the whole application yet, but you are exercising the important pieces of a write path.
A single SOL transfer includes:
- a fee payer, who pays for the transaction
- a source account, where the SOL comes from
- a recipient public key, where the SOL is going
- an amount, measured in lamports
- a System Program instruction, which performs the transfer
- a signature, which authorizes it
- an Explorer record, which proves what happened
That is a lot of Solana in one action. It shows accounts, signatures, instructions, fees, confirmation, and verification without needing to write a custom program first.
It also introduces an important idea for Arc 4: a public key can exist before there is an on-chain account for it. When SOL lands at a brand-new recipient, the System Program can create the account state the network will track from that point on.
That is the first hint that an “account” on Solana is not just another word for “wallet.” It is where state lives.
Wrapping a transfer in a tool
Running a transfer from the CLI proves the basic idea. Turning it into a tool makes the pattern reusable.
In Arc 3, that tool was a small Node.js command-line app built with @solana/kit, the newer Solana JavaScript SDK. You will still see plenty of tutorials using @solana/web3.js, so it is useful to know both names.
The tool did the same things a good wrapper around any important operation should do:
- accept a recipient and amount
- validate the input
- check the sender’s balance
- build and sign the transaction
- submit it to devnet
- print an Explorer link as a receipt
That shape should feel familiar. If you have ever wrapped a payment API, built an internal CLI, or added guardrails around a production write, you already know the pattern: validate, prepare, execute, return something the user can trust.
The difference is what sits underneath.
This tool was not sending a normal API request to one company’s backend. It was creating a signed transaction and submitting it to a decentralized network.
That was the practical bridge in Arc 3: moving from “I understand what a transaction is” to “I can build something that uses one.”
Confirmation is a product decision
One of the most useful realizations in Arc 3 was that “success” on Solana is not a single moment.
A transaction moves through commitment levels: processed, confirmed, and finalized. Each stage tells you something different about how far the transaction has moved through the network.
For developers, that is not just blockchain terminology. It affects the product experience.
If you are building a wallet, payment flow, marketplace, game, or developer tool, you have to decide what the user sees after they click the button.
Do you show “pending” as soon as the transaction is submitted? Do you show success once it is confirmed? Do you wait for finalization before enabling the next action? Do you include an Explorer link so the user can verify the result themselves?
A signature is a receipt, but not an explanation. Good tools show progress.
That is why the Arc 3 tool added confirmation feedback. It helped turn the gap between “sent” and “settled” into something visible, understandable, and useful.
Failed transactions are still real transactions
The most useful thing we did in Arc 3 was break things on purpose.
We tried sending from an empty wallet. We tried sending more SOL than the wallet held. We skipped preflight checks to push a doomed transaction onto the network anyway. Then we inspected what came back: CLI output, Explorer pages, logs, and transaction metadata.
The lesson is important for Web2 developers: on Solana, a failed transaction is still a real transaction attempt.
If signature verification succeeds, the transaction can still pay the base signature fee — 5,000 lamports per signature, before any optional priority fee — even if execution later fails. Validators still did work. The chain still attempted the change. The intended state change failed, but the fee was still real.
That reframes error handling.
You validate before signing. You simulate before submitting. You read structured errors like meta.err and InstructionError. You watch for blockhash expiry. You design flows that avoid wasting user fees on failures you could have caught earlier.
In Web2, error handling is mostly about user experience and reliability. On Solana, it is also part of the cost model.
What Arc 3 sets up
Strip Arc 3 back to its core and the main ideas are clear:
Transactions are how Solana changes state. They are signed before submission. They contain instructions. Those instructions act on accounts. Confirmation happens in stages. Failed transactions can still cost money.
That leads directly to the next question:
If transactions change state, where does that state live?
On Solana, the answer is accounts.
That is where Arc 4 goes next: how state is stored, who owns it, and how programs interact with it.
Use this post as the map, revisit the Arc 3 challenges whenever you want the hands-on version, and jump into Arc 4 from here.
Top comments (0)