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.
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.
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.
What Is an Account on Solana?
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 or a Program Derived Address (PDA) generated by a program rather than a private key.
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.
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.
The Five Fields Every Account Has
Every account exposes the same five fields, no matter what it stores. These are defined in Solana’s account structure docs.
| Field | Type | What it holds |
|---|---|---|
lamports | u64 | The account’s balance. The owner can debit it; any program can credit it. |
data | byte array | The account’s contents: state for a data account, or bytecode for a program. |
owner | Pubkey | The address of the program allowed to modify the data. |
executable | bool | true if the account is a program, false if it is a data account. |
rent_epoch | Epoch | A deprecated field, now set to the maximum value for stored accounts. |
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.
The rent_epoch field is a leftover from an earlier design, which the next section explains. For now, treat it as inactive.
Why Does Solana Separate Programs From Data?
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.
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.
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.
Who Owns a Solana Account?
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.
Ownership follows a few predictable patterns:
- Wallets are owned by the System Program, whose address is the recognizable
11111111111111111111111111111111. The System Program is also what creates new accounts and transfers SOL. - Token accounts are owned by the SPL Token Program, which is why your token balances are not held directly by your wallet account.
- Programs are owned by a loader program that manages deployed bytecode.
An account’s owner can only change while its data is zeroed out, which prevents a program from quietly seizing state it did not create. This ownership boundary is the core security rule of the whole model: your wallet can receive tokens from anyone, but only the program that owns each account can alter what is inside it.
Types of Accounts You’ll Encounter
In practice, the five-field structure shows up as a handful of recognizable account types:
- System accounts — ordinary wallets that hold SOL and are controlled by a keypair.
- Program accounts — executable accounts that store compiled code.
- Data accounts — non-executable accounts that store a program’s state, such as a configuration or a user record.
- Token accounts — a specific kind of data account owned by the SPL Token Program, tracking one token balance for one owner.
- Program Derived Addresses (PDAs) — accounts with no private key, controlled entirely by their owning program.
You do not need to memorize these. The point is that they are all the same kind of object underneath, distinguished mainly by their owner and executable fields.
What Is Rent on Solana, and Do You Still Pay It?
Rent is a minimum SOL balance an account must hold to stay on-chain, and it is proportional to how many bytes the account stores. On the current network it behaves as a refundable deposit, not a running charge. Ongoing rent collection is disabled, so an account that meets the minimum is marked rent-exempt and keeps its full balance until someone closes it.
That was not always the case. The original design periodically deducted lamports from accounts that fell below the threshold, and the deprecated rent_epoch field tracked when the next deduction was due. The account structure docs now state plainly that rent collection is turned off and set rent_epoch to its maximum value for exempt accounts.
Rent exists for a concrete reason. Validators keep the entire set of accounts in fast storage to process transactions, so every account consumes real hardware. Requiring a deposit sized to the data discourages the chain from filling up with abandoned accounts that cost validators memory forever.
How the Rent-Exempt Minimum Is Calculated
The rent-exempt minimum is the account’s size plus a fixed 128 bytes of overhead, multiplied by a per-byte rate, held as a two-year storage deposit. The account model docs express it as:
(account_size + 128) × lamports_per_byte_year × 2 years
Under the original rate of 3,480 lamports per byte-year, that works out to 6,960 lamports for each byte over a two-year window. Plug in a few common account sizes and you get the deposits below.
| Account | Data size | Rent-exempt deposit (original rate) |
|---|---|---|
| Empty account | 0 bytes | 890,880 lamports ≈ 0.00089 SOL |
| SPL token mint | 82 bytes | 1,461,600 lamports ≈ 0.00146 SOL |
| Standard token account | 165 bytes | 2,039,280 lamports ≈ 0.00204 SOL |
Those numbers are falling. A phased upgrade known as SIMD-0437 is cutting the per-byte rate by about 90%, from 6,960 lamports toward a target of 696 lamports per byte, across five steps. According to Solana’s reduced-rent upgrade page, the first steps went live on mainnet starting September 2026, with the remaining steps expected around November 2026 alongside the Agave 4.4 release. Once the full reduction lands, the deposit for an empty account drops to roughly 0.00009 SOL.
The practical takeaway: budget for the deposit when you create accounts, but know that it is money parked, not money spent, and that it is getting cheaper.
Getting Your Deposit Back
Because the balance is a deposit, you recover it when an account is no longer needed. Closing an account transfers its lamports to a destination you choose and removes the account from the chain.
The SIMD-0437 reduction adds a second angle. Accounts funded under the old, higher rate now hold more than the new minimum requires, and that excess can be reclaimed. Early phases of the rollout freed hundreds of thousands of SOL that had been locked as surplus deposits across existing accounts.
How to Read Account Data
To inspect any account, you send a request to a Solana endpoint using standard JSON-RPC methods. The common ones are getAccountInfo for a single account, getMultipleAccounts for a batch, and getProgramAccounts to fetch every account owned by a given program. For balances alone, getBalance returns the lamport count.
There is also a method built specifically for rent. getMinimumBalanceForRentExemption takes a data size in bytes and returns the exact deposit required, which is the reliable way to fund a new account rather than hardcoding a figure that a rent reduction will soon change.
Serving these calls reliably means reaching a synced Solana validator. Running one yourself is possible, but it means maintaining hardware, keeping the client updated, and absorbing the storage growth that comes with Solana’s account set. Many teams instead point their application at a managed Solana endpoint from NOWNodes and spend their time on application logic instead of infrastructure upkeep. For prototyping, NOWNodes also exposes free public endpoints rate-limited to 5 requests per second, which is enough to test a few getAccountInfo calls before committing to a plan.
Conclusion
A Solana account is a simple object with an outsized role: a balance in lamports, an owner program, a chunk of data, and a flag for whether it runs as code. That uniform structure, combined with the split between stateless programs and the accounts they operate on, is what lets the network execute transactions in parallel.
Rent is the piece worth remembering clearly. It is a refundable, size-based deposit rather than an ongoing fee, ongoing collection is switched off, and the SIMD-0437 upgrade is steadily lowering the cost of keeping data on-chain. If you are building, size your deposits with getMinimumBalanceForRentExemption, reclaim balances by closing accounts you no longer use, and connect through infrastructure that keeps the account data flowing without you running a validator.
FAQ
Is a Solana wallet address the same as an account?
Not quite. The address is the 32-byte identifier, while the account is the on-chain record it points to. A wallet is a system account controlled by your keypair, and its address is how you and programs locate it.
Does Solana use UTXOs like Bitcoin?
No. Bitcoin tracks spendable transaction outputs, while Solana uses an account-based model where balances and state live in persistent accounts. This is closer to Ethereum’s approach, though Solana separates program code from the data it touches.
What happens to a Solana account that isn’t rent-exempt?
On the current network, new accounts are expected to hold the rent-exempt minimum, and accounts that meet it are stored indefinitely because rent collection is disabled. Under the old design, accounts below the threshold had lamports deducted over time and could eventually be purged, which is the behavior the deprecated rent_epoch field tracked.
What is a Program Derived Address (PDA)?
A PDA is an account address derived from a program’s ID and a set of seeds, with no corresponding private key. Because only the owning program can
