Day 27: Writing About the Solana Account Model

atharv shukla — Tue, 30 Jun 2026 10:45:29 +0000

Today, I took a step back from writing code to write about the core architectural foundation of Solana: The Account Model. To solidify my understanding, I wrote a comprehensive article aimed at Web2 developers who are new to blockchain, explaining how Solana manages state.

Below is the draft of the article, formatted for publishing on DEV.to.

DEV.to Article Draft

Title: Demystifying the Solana Account Model: A Guide for Web2 Developers
Tags: solana, blockchain, web3, beginners

If you are a Web2 developer dipping your toes into the Web3 waters, blockchain architecture can feel incredibly alien. You hear terms like "smart contracts," "state," and "ledgers," and you try to map them to things you know.

If you look at Ethereum, it might make sense at first: it uses an Account-based model where you have Externally Owned Accounts (EOAs, like your MetaMask wallet) and Contract Accounts (which contain both the code and the state/variables of a smart contract). This feels a bit like Object-Oriented Programming, where an object contains both its methods (code) and its properties (state).

But then you look at Solana, and everything you thought you understood gets flipped on its head.

On Solana, programs are completely stateless, and everything is an account.

Let's break down Solana’s Account Model using Web2 concepts you already use daily.

The Ultimate Analogy: Solana as a Filesystem

The easiest way to understand Solana's account model is to think of the entire blockchain as a global, decentralized filesystem.

The Ledger is the Hard Drive: A massive, shared storage space.
Accounts are Files: Every piece of information on Solana lives inside an "account," which acts just like a file.
Public Keys are File Paths: Every account has a unique 32-byte address (like BPFLoaderUpgradeab1e11111111111111111111111 or a wallet address). Think of this public key as the absolute path to the file (e.g., /users/alice/data.json).
The System Program is the OS Kernel: The underlying operating system kernel that manages file creation, allocating size, and assigning permissions.

Just like a file on your computer has metadata (file size, owner, read/write permissions) and file contents, a Solana account contains metadata and a raw byte array for data.

The Anatomy of an Account: The 5 Fields

Every single account on Solana shares the exact same basic structure. When you query an account using the Solana command-line interface (solana account <ADDRESS>), the JSON response reveals five main fields:

json
{
"pubkey": "3zcpeKkCFg1z3sR1u1qQcm6h4n5t282a5cQ5bX2gYp3Z",
"account": {
"lamports": 124806720,
"data": ["...", "base64"],
"owner": "BPFLoaderUpgradeab1e11111111111111111111111",
"executable": true,
"rentEpoch": 18446744073709551615
}
}

Let's unpack what these fields represent:

lamports (The SOL Balance): A lamport is the smallest fractional unit of SOL, named after Leslie Lamport (think of it like a Satoshi for Bitcoin or a Wei for Ethereum). 1 SOL = 1,000,000,000 lamports. This balance is used to pay for storage and transaction fees.
data (The File Contents): A raw byte array (Vec<u8>) containing the actual state stored by this account. For a wallet account, this might be empty. For a database account, it contains serialized variables.
owner (The File Owner/Permissions): This is the public key of the program that controls this account. Crucially, only the owner program is allowed to modify the account's data or deduct its lamport balance.
executable (Is it an App or a Document?): A boolean flag. If true, this account contains compiled WebAssembly/SBF bytecode that the Solana runtime can run. It is a program (smart contract). If false, it's just a data storage account.
rent_epoch (Storage Rent): Historically used to track rent collections. Today, rent is deprecated because all accounts are required to be "rent-exempt" (more on this below). It is now set to a placeholder max value (18446744073709551615).

Programs Don't Store State (Stateless Architecture)

In Web2, if you write a Node.js express server, the code is loaded into memory, and it might read/write from a local Postgres database. The server code itself doesn't dynamically change its own binary files on disk to save user data; it talks to an external database.

Solana works the exact same way. Solana programs are stateless.

On Ethereum, a smart contract's code and its variables are packed together in the same contract account. On Solana, they are strictly separated:

mermaid
graph TD
subgraph Program Account
A[Program ID / Proxy Address] -->|Executable: true| B[Program Data Account: Bytecode]
end

subgraph Data Accounts
    C[User Wallet Account A]
    D[User Wallet Account B]
    E[Protocol Configuration Account]
end

B -->|Reads/Writes Data| C
B -->|Reads/Writes Data| D
B -->|Reads/Writes Data| E

For example, the Token-2022 Program (TokenzQdBNbXt8TuTRCEjrpb5764uWo1tz5SQH376BB) contains the executable logic for minting and transferring tokens. But it doesn't store your token balance. Instead, your balance is stored in a separate Token Account owned by the Token-2022 program, which holds data indicating: "This wallet address owns X amount of this token."

The Rules of Ownership: Solana's Security Model

How does Solana ensure someone doesn't just write a malicious script to change another user's balance? Through strict runtime ownership rules:

Only the Owner Program can write to the account data.
Only the Owner Program can deduct lamports (debit) from the account.
Anyone can credit lamports to any writable account (just like anyone can transfer money to your bank account).
Anyone can read any account's data. All accounts are public by default.

If Program A tries to modify an account owned by Program B, the Solana runtime rejects the transaction immediately. This simple rule eliminates a massive class of security vulnerabilities.

Rent Exemption: Keeping the Ledger Lean

In Web2, if you rent an AWS EC2 instance or store files in an S3 bucket, you pay a recurring subscription. If you stop paying, AWS deletes your files.

Solana handles blockchain storage in a similar way. Because validators must keep all active accounts in memory (RAM) for fast transaction processing, storage isn't free.

To prevent the blockchain from being filled with abandoned accounts, Solana requires accounts to maintain a minimum lamports balance. This is called being Rent-Exempt.

The rent-exempt balance is directly proportional to the size of the account's data array.
For a basic wallet account with zero data bytes, the rent-exempt minimum is roughly 0.00089 SOL.
When you close a Solana account, you can reclaim all the rent lamports back into your main wallet! It's like getting a deposit refund on a rental apartment.

Summary

As a Web2 developer, you can master the Solana Account Model by keeping these four rules in mind:

Everything is a file (account) in a flat key-value store.
Metadata is standardized across all files (Lamports, Data, Owner, Executable).
Programs are stateless executables; they read and write to separate database files (data accounts).
Ownership is absolute; only the program marked as the owner can modify a file's contents or spend its funds.

Understanding this separation of code and state is the "aha!" moment for every Solana developer. Once you grasp this, building decentralized applications, understanding PDA (Program Derived Addresses) generation, and writing efficient Anchor programs starts to make perfect sense!

Have questions about how accounts work on Solana? Drop a comment below, and let's discuss!

Solana Transactions Explained for Backend Developers

atharv shukla — Tue, 30 Jun 2026 08:41:51 +0000

If you're coming from a Web2 backend background, your mental model of APIs is probably built on the standard HTTP client-server pattern: client makes a request, the database runs a transaction, and you return a status code.

When diving into Solana, you quickly run into a lot of the same terms—like "transactions"—but the actual execution under the hood is very different. Here's a quick guide on how Solana transactions actually work, what's inside them, and a few things that caught me off guard.

Anatomy of a Solana Transaction : An HTTP request is usually headers and a JSON body. A Solana transaction is a packed binary payload that cannot exceed 1,232 bytes (this limit exists so transactions can fit cleanly into a single IPv6 packet).

Inside that byte limit, a transaction contains:

Signatures: Cryptographic proof from the accounts authorizing the action.
Message: The instructions and context, which includes:
- Account Keys: Every single account the transaction will read from or write to. Solana needs this declared upfront so it can parallelize execution.
- Recent Blockhash: A hash from a recent block. This acts as a timestamp and prevents replay attacks. If the blockhash is too old (usually over 150 blocks, or about a minute), the transaction expires.
- Instructions: The actual operations to execute. Each instruction specifies an on-chain program (like calling a controller method) and passes along the necessary accounts and raw data.

The Transaction Lifecycle In Web2, a database transaction is either committed or it isn't. On a blockchain, consensus is reached in stages:
Processed: A single validator has included the transaction in a block.
Confirmed: A supermajority (66%+) of validators have voted on the block. At this point, the transaction is functionally irreversible.
Finalized: 31 or more blocks have been built on top of your block. The write is permanently locked into ledger history.

You can think of this as moving from a local write, to multi-region replication, to an immutable backup.

Failed Transactions Still Cost Fees This is the biggest shift. In Web2, if a request fails validation (say, a 400 Bad Request), you don't get billed for the server CPU cycles it took to reject the request.

On Solana, failed transactions still charge fees.

If your signatures are valid and the blockhash is recent, validators will execute your transaction. Even if the program logic fails halfway through (e.g. you tried to transfer more SOL than you actually have), you still pay for the compute.

Here is what it looks like when a transaction fails on-chain:

text
Transaction executed:
Signature: 5LseX35v...K4KgG7
Status: Error processing Instruction 0: custom program error: 0x1
Fee: 0.000005 SOL
Account 0 balance: 0.428975 SOL -> 0.42897 SOL
Compute Units Consumed: 150
Log Messages:
Program 11111111111111111111111111111111 invoke [1]
Transfer: insufficient lamports 428970000, need 500000000000
Program 11111111111111111111111111111111 failed: custom program error: 0x1

Notice that the fee-payer's balance still decreased by 0.000005 SOL even though the transfer failed.

To avoid wasting real money on failed execution, Web3 developers use Transaction Simulation (preflight checks) on the client side to test the transaction's success on a local state before broadcasting it to the network.

Key Takeaways
No ad-hoc lookups: You cannot query arbitrary accounts mid-transaction; every address you interact with must be declared in your instructions.
Keep it fast: Because of the recent blockhash requirement, signed transactions expire in about a minute.
Preflight is your friend: Run simulations on the RPC node first to save your users from paying fees on failed transactions.

DEV Community: atharv shukla

Day 27: Writing About the Solana Account Model

Solana Transactions Explained for Backend Developers