Arc 4 of 100 Days of Solana was about the Solana account model: what state actually looks like on-chain, who can change it, and how developers read and decode it.
Arc 3 gave us the transaction model. We learned that transactions are how Solana changes state.
Arc 4 asked the next question:
Where does that state live?
On Solana, the answer is accounts.
That sounds simple, but it is one of the biggest mental model shifts in the whole foundation epoch. A Solana account is not just a wallet. It is not just a user profile. It is not just a row in a database.
On Solana, almost everything is an account: wallets, programs, token mints, token accounts, sysvars, and application state.
The whole arc hangs off one idea:
On Solana, accounts are the containers that hold state, code, ownership, and balance.
Once that clicks, the rest of Solana starts to fit together.
Accounts are where state lives
In a Web2 app, state usually lives in places you control.
User data might be in Postgres. Files might be in object storage. sessions might be in Redis. App code runs on your servers or serverless functions. Access control often lives in middleware, business logic, row-level security, or API permissions.
Solana rearranges that picture.
State lives in accounts. Programs are accounts too. Wallets are accounts. Token data is stored in accounts. Even bits of cluster state are exposed through special accounts.
That is what people mean when they say “everything is an account.”
It does not mean every account behaves the same way. A wallet account, a token mint, and an executable program account do different jobs. But they share the same basic structure, and that shared structure is what Arc 4 unpacked.
A Solana account has five core fields:
- lamports: how much SOL the account holds
- data: the bytes stored in the account
- owner: the program allowed to modify the account’s data
- executable: whether the account contains runnable program code
- rentEpoch: a legacy rent-related field
That is the foundation. Different accounts become meaningful because those fields are set differently.
The owner field is the security model
For Web2 developers, the owner field is one of the most important ideas to get right.
It does not mean “the human who owns this account.”
It means:
Which program is allowed to change this account’s data?
That makes owner much closer to a low-level access-control rule than a user-facing ownership label.
In a Web2 app, you might enforce permissions in your API layer:
Can this user update this row?
Can this service write to this bucket?
Can this job mutate this record?
On Solana, the runtime enforces a stricter version of that idea. Only the owning program can modify an account’s data. If a token account is owned by the Token Program, your random application code cannot just rewrite it. If your program owns a data account, then your program defines how that data can change.
That is why the account model matters so much.
Transactions may carry the instructions, but accounts define the state those instructions act on. The owner field helps decide which program has authority over that state.
That is not middleware. It is part of the runtime.
Programs are accounts too
One of the more useful realizations in Arc 4 was that programs are not magical things floating somewhere outside the account model.
Programs are accounts.
The difference is that program accounts have executable: true. Their data contains compiled program code, and their owner is a loader program rather than the System Program.
That is a strange idea at first, but there is a useful Web2 analogy:
The code and the data are separate.
A web server might run application code, then read and write rows in a database. On Solana, a program account contains executable code, while separate data accounts hold the state that program works with.
That separation becomes crucial later.
When you write Solana programs, you are not usually storing mutable state inside the program itself. You are writing code that receives accounts, checks them, reads their data, and changes the accounts it is allowed to change.
So Arc 4 quietly set up one of the most important Solana development habits:
Think in accounts, not objects.
Your program logic is only half the story. The accounts passed into that program are the other half.
Reading an account is like opening a file
Arc 4 started with inspection.
Using the Solana CLI, we looked at a normal wallet account, the SPL Token Program, and the System Program side by side. That made the shared structure visible.
The Web2 analogy here is not perfect, but it helps:
Reading a Solana account is a bit like opening a file or inspecting a database row.
You can see its balance. You can see whether it has data. You can see who owns it. You can see whether it is executable.
But unlike a normal database row, account data often starts as raw bytes. The network can give you the bytes, but it does not automatically know how you want to interpret them.
That is where account decoding comes in.
Raw bytes are where this gets real
Arc 4 was the most “under the hood” week of Epoch 1, and the account decoding work was the reason.
At first, an account’s data field can look like base64 gibberish. That is not because it is meaningless. It is because you are looking at serialized bytes.
The challenge was to decode those bytes and prove that the same account data could be understood in three ways:
- with a typed decoder from
@solana-program/token - manually, byte by byte, using
DataView - through the RPC’s
jsonParsedencoding
That is not just busywork. It is the moment where “on-chain data” stops being abstract.
If you have ever parsed a binary file format, decoded a network packet, or mapped bytes into a struct, this is the same kind of work. The data is there. Your job is to know its layout.
Arc 4 introduced several ideas that will keep coming back:
- Borsh serialization: how structured data becomes bytes
- little-endian numbers: a common source of decoding bugs
- base64: how RPC often returns account data
- hex: useful for debugging raw bytes
- base58: how Solana addresses are displayed
This was the hardest part of the arc, but it was also the most transferable.
If you can decode account data, you are no longer limited to what a block explorer chooses to show you. You can inspect state yourself.
The System Program is the account clerk
Arc 4 also took us one layer deeper into the system itself.
The System Program is one of the native programs that makes Solana work. A useful way to think about it is as the clerk that creates and labels accounts.
It can create accounts. It can assign ownership. It can allocate space. It handles basic SOL transfers.
That makes it feel a little like part of an operating system. Not your application logic, but the lower-level machinery that makes files, processes, permissions, and memory possible.
Sysvar accounts are another useful piece of that system layer. They expose read-only cluster state, such as clock or rent information, through accounts.
A rough Web2 analogy would be /proc on Linux: system information exposed as readable data.
Again, the analogy is not exact. But it helps place the idea. Solana’s account model is not only for application state. It is also how the system exposes information about itself.
Block explorers are blockchain DevTools
After decoding account data by hand, Arc 4 stepped back and looked at Explorer again.
That was useful because block explorers are not just places to paste transaction signatures. They are the debugging surface for a public blockchain.
Solana Explorer, Solscan, and similar tools are basically UI wrappers around public chain data. They show accounts, transactions, owners, program logs, balances, token data, and instruction details.
If you are used to browser DevTools, database consoles, or log dashboards, this is the role explorers play.
They help you answer questions like:
What account am I looking at?
Who owns it?
Is it executable?
What data does it hold?
Which transaction changed it?
What logs were emitted?
Reading explorers fluently is a real Solana development skill. It lets you move between your code, RPC calls, transaction signatures, and on-chain state without guessing.
Arc 4 made that explicit.
Writing helps the model settle
Arc 4 ended the same way the earlier arcs did: by writing and sharing.
That matters especially for this arc because the account model is not something you fully absorb by reading one definition. It takes a few passes.
You inspect an account. You compare it with another one. You decode bytes. You look at a program. You notice that the same five fields keep showing up. Then you try to explain it to someone else.
That is when the model starts to stick.
Writing about the account model forces useful questions:
What does owner really mean?
How is a program also an account?
Where does state live?
Why is account data raw bytes?
What does rent-exempt storage mean?
Those questions are exactly the point.
The goal is not polished certainty. The goal is a clearer map.
What Arc 4 sets up
Arc 4 closed Epoch 1 by giving us the data model underneath everything else.
Strip it back to the core ideas:
Accounts are where Solana state lives. Every account has the same basic fields. The owner field controls who can change account data. Programs are executable accounts. Application state lives in separate data accounts. Raw account data is bytes, and decoding those bytes is a core developer skill.
That brings the foundation epoch together.
Arc 1 gave us identity: keys, wallets, addresses, and devnet SOL.
Arc 2 gave us reads: RPC calls, balances, transaction history, and public blockchain data.
Arc 3 gave us writes: signed transactions, confirmation, and failure modes.
Arc 4 gave us state: accounts, ownership, executable programs, raw data, and decoding.
From here, the next step is natural.
Once you understand identity, reads, writes, and state, you are ready to build with the programs that own and modify those accounts.
Use this post as the map, revisit the Arc 4 challenges when you want the hands-on version, and carry the account model into what comes next.
