{"id":3901,"date":"2026-10-09T11:00:28","date_gmt":"2026-10-09T11:00:28","guid":{"rendered":"https:\/\/nownodes.io\/blog\/?p=3901"},"modified":"2026-10-09T11:00:29","modified_gmt":"2026-10-09T11:00:29","slug":"what-is-the-solana-account-model-accounts-and-rent-explained","status":"publish","type":"post","link":"https:\/\/nownodes.io\/blog\/what-is-the-solana-account-model-accounts-and-rent-explained\/","title":{"rendered":"What Is the Solana Account Model? Accounts and Rent Explained"},"content":{"rendered":"\n

On Solana, almost everything is an account. A wallet is an account, a token balance is an account, and a deployed program is an account too. Each one is a container of bytes that holds a SOL balance, records which program controls it, and flags whether it stores data or executable code.<\/p>\n\n\n\n

Rent is the part that confuses most newcomers. It sounds like a recurring fee, but on today’s network it is a one-time, refundable deposit that keeps an account stored. Understanding how a Solana account is structured, and how rent works, is the fastest way to stop guessing why a transaction needs extra SOL or why closing an account hands some of it back.<\/p>\n\n\n\n

This guide starts with the plain definition and builds toward the mechanics developers actually hit: ownership rules, account types, the rent-exempt minimum, and how to read account data over an API.<\/p>\n\n\n

What Is an Account on Solana?<\/h2>\n\n\n
\"\"<\/figure>\n\n\n\n

An account is a record stored on-chain, identified by a unique address. That address is a 32-byte value, usually an Ed25519 public key<\/a> or a Program Derived Address (PDA) generated by a program rather than a private key.<\/p>\n\n\n\n

A useful mental model is a filesystem. Each account is like a file, the address is its path, and the Solana runtime is the operating system that decides who can write to what. Every file carries a small amount of metadata and a balance alongside its contents.<\/p>\n\n\n\n

If you come from Ethereum, the account model will feel familiar in one way and strange in another. Both chains track state in accounts rather than Bitcoin-style UTXOs. The difference is that Solana keeps a program’s code and the data it works on in separate accounts, instead of bundling code and storage together inside one contract.<\/p>\n\n\n

The Five Fields Every Account Has<\/h3>\n\n\n

Every account exposes the same five fields, no matter what it stores. These are defined in Solana’s account structure docs<\/a>.<\/p>\n\n\n\n

Field<\/th>Type<\/th>What it holds<\/th><\/tr><\/thead>
lamports<\/code><\/td>u64<\/code><\/td>The account’s balance. The owner can debit it; any program can credit it.<\/td><\/tr>
data<\/code><\/td>byte array<\/code><\/td>The account’s contents: state for a data account, or bytecode for a program.<\/td><\/tr>
owner<\/code><\/td>Pubkey<\/code><\/td>The address of the program allowed to modify the data.<\/td><\/tr>
executable<\/code><\/td>bool<\/code><\/td>true<\/code> if the account is a program, false<\/code> if it is a data account.<\/td><\/tr>
rent_epoch<\/code><\/td>Epoch<\/code><\/td>A deprecated field, now set to the maximum value for stored accounts.<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n

A lamport is the smallest unit of SOL. One SOL equals 1,000,000,000 lamports, so balances are tracked in whole lamports with no rounding. Account data has a hard ceiling of 10 MiB (10,485,760 bytes), which is why large datasets are split across many accounts rather than stuffed into one.<\/p>\n\n\n\n

The rent_epoch<\/code> field is a leftover from an earlier design, which the next section explains. For now, treat it as inactive.<\/p>\n\n\n

Why Does Solana Separate Programs From Data?<\/h2>\n\n\n

Because it lets the network run transactions in parallel. A Solana program is stateless: it holds logic but no data of its own, and it reads and writes the accounts handed to it when a transaction calls it.<\/p>\n\n\n\n

Here’s why that matters. A transaction has to list every account it will touch upfront. The runtime can look at two transactions, see that they use completely different accounts, and execute them at the same time without risk of conflict. This parallel engine, called Sealevel, is a direct consequence of keeping state out of the program itself.<\/p>\n\n\n\n

Ethereum takes the opposite approach. A contract’s code and its storage live in the same place, so the contract owns its state and the network processes transactions touching that contract one after another. Solana’s split is more work to reason about, but it is what the chain’s throughput is built on.<\/p>\n\n\n

Who Owns a Solana Account?<\/h2>\n\n\n

Every account has an owner, and the owner is always a program, not a person. Only the owner program can change an account’s data or subtract from its balance. Any program, meanwhile, can add lamports to any account that a transaction marks as writable.<\/p>\n\n\n\n

Ownership follows a few predictable patterns:<\/p>\n\n\n\n