The analogy that rewired my brain - The Filing Cabinet

Imagine a room filled with filing cabinets. Each drawer has a random label. Inside each drawer is a folder.

On the front of the folder is written:

• Owner — who can open and change the contents
• Executable — is this a set of instructions or just data?
• Data — the actual contents (a number, JSON, raw bytes)

Anyone can walk up to any drawer and read the label. Only the Owner can modify what's inside.

This room is Solana. The drawers are accounts. The folders are account data. The owners are programs.

💡 What This Explains

There is no "users table." Your wallet is a file owned by the System Program. The data inside is one number — your SOL balance. "Sending SOL" means authorizing the System Program to decrease the number in your file and increase it in someone else's.

You can't modify every account. Only the owning program can. This isn't a restriction — it's the entire security model. If anyone could modify any account, the network would be chaos. The runtime enforces ownership at the validator level, not in application code.

Programs are stateless. A program is like a person who knows how to read specific file formats. The System Program reads simple balance files. The Token Program reads mint metadata and token balances. Your custom program reads whatever format you define. The program itself stores nothing — state lives in separate accounts it owns. Think of it like a web server (the program) that reads and writes to a database (data accounts) rather than keeping everything in memory.

📋 The Four Fields

Every account on Solana has the same structure:

Here's what they look like in practice:

$ solana account TokenkegQfeZyiNwAJbNbGKPFXCWuBvf9Ss623VQ5DA

Public Key: TokenkegQfeZyiNwAJbNbGKPFXCWuBvf9Ss623VQ5DA
Balance: 0.00028296 SOL
Owner: BPFLoaderUpgradeab1e11111111111111111111111
Executable: true
Data: (compiled program bytecode)

A wallet, a token program, a sysvar — all use the same four fields. Different values. That's the entire state model.

💰 Rent Exemption

Keeping a file on-chain costs storage space. Solana charges rent — a small deposit proportional to your account's data size. Deposit enough (~2 years worth) and your account is "rent-exempt" — it stays forever.

solana rent 0     # 0.00089088 SOL (basic account)
solana rent 100   # cost for 100 bytes of data

For a basic wallet with no extra data, it's roughly 0.00089 SOL. This deposit is refundable when you close the account. Not a bug — it's the price of storing data in a globally replicated system.

🔑 Three Things That Suddenly Make Sense

1. Ownership rules. Only the owner program can modify an account's data or deduct lamports. Anyone can credit lamports to any writable account. Simple, powerful, enforced by every validator.

2. PDAs. Sometimes a program needs a file it controls but no private key can sign for it. Program-Derived Addresses are deterministic drawer labels — computed from program ID + seeds — that only the program can authorize. Like a combination lock where only the program knows the combination.

3. Composability. Every file declares its owner. Anyone can read. Only the owner can write. Programs chain together: Program A reads a Token account to check your balance, then asks the System Program to move SOL. All in one atomic transaction. That's composability.

🎯 Why This Matters

Before this analogy clicked, every Solana concept felt like learning a new language from scratch. After it clicked, the documentation became readable. Error messages became decipherable. I stopped asking "what is an account?" and started asking "what kind of file is this, and who owns it?"

If you're coming from Web2 and struggling with Solana's account model, try the filing cabinet. You'll know it clicked when you stop thinking about tables and start thinking about drawers.

This is the final post in a 4-part series on unlearning Web2 mental models for Solana:

1. 📊 Solana Is a Public Spreadsheet — Not Your Private Database
2. 🔌 The "Connect Wallet" Button Replaced My Entire Auth System
3. ✍️ A Solana Transaction Is a Signed Check — Not an API Request
4. You're reading it.

This is a submission for the 100 Days of Solana Writing Challenge, running from 15 May to 22 May.