Arc 2 of 100 Days of Solana was about learning to read from the blockchain.
In Arc 1, we created wallets, worked with addresses, got devnet SOL, and started building the basic identity layer we need to interact with Solana. Arc 2 shifted the focus from identity to information.
What can you read from Solana? How do you ask for it? What comes back? And how is that different from fetching data from a normal Web2 API or querying a database?
The whole arc hangs off one useful mental model:
Solana is a massive public database where every table is readable and every query is free.
That is not a perfect technical description, but it is a useful starting point. If you are coming from Web2, Arc 2 is where Solana starts to feel less like an abstract blockchain and more like a data source you can inspect, query, and build interfaces around.
Reading from Solana feels familiar
Reading from Solana is the easy part to map onto Web2.
You ask for a wallet balance. You fetch recent transactions for an address. You inspect account data. The network answers.
That shape feels familiar if you have ever called a REST API, queried a database, or built a dashboard around backend data.
In Arc 2, the first read was deliberately small: use @solana/kit, connect to devnet, and call getBalance for a wallet address.
That one call teaches more than it first appears to.
There is no user session. No API key. No private dashboard. No auth header. The address is public, the balance is public, and the network can return it directly.
That is the first shift:
On Solana, public data is public by default.
For Web2 developers, that can feel backwards. In most application databases, data starts private. You expose it through APIs, auth rules, dashboards, and permissions. On Solana, a lot of the base data is already out in the open. The job of your application is often not to unlock access, but to make public data understandable and useful.
A wallet balance is just the first query
Once you can fetch a balance, the next step is obvious: fetch activity.
Arc 2 moved from getBalance to recent transaction history. Using getSignaturesForAddress, we queried the most recent transactions for an address and displayed the signature, slot, timestamp, and status.
If getBalance is like:
GET /users/:id/balance
then recent transactions feel more like:
GET /users/:id/transactions
The pattern is familiar. The data is not.
A transaction signature is not just a random ID. It is the identifier you can use to look up what happened. A slot is not quite a timestamp; it is Solana’s way of ordering batches of work over time. A block time gives you a familiar Unix timestamp when one is available.
This is where Solana starts to feel like a database with its own vocabulary.
You can query it. You can display the result. You can build UI around it. But the records you get back are blockchain records, not rows from your own application database.
That distinction matters.
You are not asking your backend, “What did this user do in my app?” You are asking the network, “What activity is visible for this address?”
A dashboard turns reads into something useful
The first two reads happened in scripts. That is a good way to learn the API, but it is not how most users experience software.
So Arc 2 moved the same read patterns into a small browser dashboard.
The dashboard took an address, fetched its balance, pulled recent transactions, and displayed the results in a simple web interface. Same Solana calls. Different surface.
That is a useful moment because it shows how normal this can feel.
You are still doing familiar frontend work: input fields, loading states, error handling, formatted output. The Solana-specific part is the data source.
A read-only dashboard is also a good early blockchain app because the risk is low. You are not signing anything. You are not moving funds. You are not changing state. You are just helping someone understand public data.
That makes Arc 2 a good bridge for Web2 developers. You can use existing frontend instincts while slowly replacing “my backend API” with “the Solana RPC endpoint.”
Accounts are not tables, but the database analogy helps
The conceptual center of Arc 2 was the comparison between Solana accounts and Web2 databases.
The database analogy helps because it gives you a place to start. Solana stores state. You can read that state. Programs interact with that state. Accounts have owners. Data has structure.
But the analogy breaks quickly.
In a normal database, you might expect tables, schemas, indexes, joins, private rows, server-side filtering, and application middleware enforcing access control.
Solana does not work like that.
On Solana, everything is an account: wallets, programs, token accounts, program-owned data. Accounts do not query each other. There are no joins. You usually assemble what you need off-chain by making RPC calls, reading account data, and interpreting the results in your app.
That is a major shift.
In Web2, the database often sits behind your application. Your server decides what to query, what to hide, what to join, and what to return.
On Solana, the data is public, the runtime enforces ownership and write rules, and your application often becomes the layer that makes raw public state usable.
That is why “Solana is a public database” is helpful, but incomplete. It is not Postgres with a blockchain logo. It is a shared state layer with different rules about visibility, ownership, storage, and writes.
Storage has a price tag
Arc 2 also introduced a detail Web2 developers do not usually think about directly: storage cost.
In most Web2 apps, storage cost is real, but abstracted. You pay a cloud bill. Your database grows. Maybe you worry about indexes, backups, or object storage. But individual records do not usually arrive with an obvious upfront storage deposit.
Solana makes storage more explicit.
Accounts need enough lamports to be rent-exempt. That deposit depends on the amount of data the account stores, and it can be returned if the account is closed.
That is a very different mental model from “just insert another row.”
It means storage is not just a backend implementation detail. It is part of the application model. If your app needs on-chain state, someone has to pay for the account space that holds it.
Arc 2 did not require us to build with that model yet, but it planted the idea early: on Solana, reading is free, but storing state is not invisible.
Devnet and mainnet are separate worlds
Arc 2 also made the network environment visible.
In Web2, developers are used to staging and production. Same code, different database. Same API shape, different base URL. Different data, different risk.
Solana has a similar idea with devnet and mainnet.
The RPC calls can look identical. The address can be the same. But the network you query changes everything.
A wallet might have devnet SOL and no mainnet SOL. It might have activity on one network and no history on the other. Devnet is not a sandboxed view of mainnet. It is a separate environment with separate data.
That is a useful Web2 bridge:
Changing networks is like pointing the same app at a different database.
The code shape stays familiar. The data source changes. The consequences change too.
Devnet is where you can experiment freely. Mainnet is where the real assets and real history live.
Writing turns learning into understanding
Arc 2 ended by stepping away from the code and asking us to explain what we had learned.
That was not filler. Writing is part of the learning loop.
When you try to explain Solana accounts, RPC calls, devnet, public data, or transaction history to someone else, you quickly find the gaps in your own understanding. The rough edges become visible. The parts that felt “sort of clear” either sharpen or fall apart.
That is valuable.
A good technical learning journey is not just:
read docs → copy code → move on
It is closer to:
try something → build something → explain it → share it → notice what still feels unclear
Arc 2 followed that pattern. We read on-chain data, turned it into a browser dashboard, compared it against Web2 databases, wrote about what clicked, and shared the work publicly.
That turns a week of exercises into something more durable.
What Arc 2 sets up
Strip Arc 2 back to its core and the main ideas are clear:
Solana data is public by default. You read it through RPC calls. Wallet balances, transaction history, programs, and data all live in accounts. Devnet and mainnet are separate environments. Reading is free, but storing state has a cost.
That gives us the bridge into Arc 3.
Once you understand how to read from Solana, the next question is obvious:
How do you change it?
On Solana, the answer is transactions.
Arc 3 picks up there: signed requests to change on-chain state, SOL transfers, transaction anatomy, confirmation, failure modes, and the write path developers use to interact with the network.
Use this post as the map, revisit the Arc 2 challenges when you want the hands-on version, and jump into Arc 3 with the read model already in place.