Every account on Solana has a balance. Every account costs something to keep on the chain. Both numbers are measured in the same tiny unit, and both work the way a security deposit at an apartment works: you pay it up front, the chain holds it while the account exists, and you get it back when the account closes. Once that picture is in place, "rent" stops being a worry and becomes a one-time number you look up.

A SOL is a big number split into a billion small pieces called lamports. One lamport is the smallest amount of value the chain knows how to talk about. Everything is measured in lamports underneath: balances, fees, storage deposits, validator rewards. SOL is the friendlier label humans put on top of large lamport numbers.

The conversion is exact. One SOL is one billion lamports. Half a SOL is five hundred million lamports. The base fee for one transaction signature is five thousand lamports, or 0.000005 SOL. Storage deposit for a typical token account is around two million lamports, or 0.00204 SOL. The numbers stay in the thousands and millions for almost everything you'll do day to day.

Every byte of data on the chain has to be held in memory by every validator on the network. Holding data has a cost, and the chain charges for it. The name for that charge is rent.

In the original design, rent was meant to be ongoing. An account paid a small amount each epoch out of its lamports balance, and if the balance ran out, the account was deleted. In practice, almost nobody uses this mode. The system has a second option called rent-exemption: deposit enough lamports up front to cover roughly two years of rent in advance, and the chain stops charging the account. Every account created on Solana today uses this second option, and the language around rent has shifted accordingly. When a developer says "rent" they almost always mean the one-time deposit rather than an ongoing fee.

The size of the deposit scales with the bytes the account holds. A bigger account needs a bigger deposit. The math is fixed: roughly 6,960 lamports per byte, plus 128 bytes of overhead per account. An empty wallet costs about 890,000 lamports. A 165-byte token account costs about 2,040,000 lamports. A 200-kilobyte program account costs about 1.4 SOL.

Two consequences fall out of this. The first is that every account on Solana has to be sized at creation time. You can't have an account that grows without bound, because growing it later means paying additional deposit to cover the new bytes. The second is that storage cost is paid by whoever creates the account, which is almost always either the user or the program acting on the user's behalf. The program never pays out of its own pocket. The lamports come from the user's wallet at the moment of creation.

Every account on the chain follows the same three-stage life. It gets created, it sits there being read and written, and eventually it gets closed.

Creating an account takes one instruction from the System Program. That instruction does three things in one step: it allocates the right number of bytes for the account's data, transfers the rent-exempt deposit from a payer into the account's lamports field, and assigns ownership to a target program. After this completes, the new account exists, has the right size, holds the right balance, and the listed owner program can start using it.

Holding an account does not cost anything. As long as the rent-exempt deposit is in place, the account stays on the chain indefinitely. Validators keep it in memory, programs read and write its data field as their logic requires, and nothing on the network ever decides to garbage-collect it. There is no per-block fee, no expiration, no need to top up. The deposit just sits there.

Closing an account is two operations packed into one. The owner program zeros out the data field and transfers the entire lamports balance out to a recipient address you specify. Once the balance hits zero, the runtime considers the account uninitialized and free to be created again at the same address by anybody. The data is gone, the bytes are released, and the deposit you paid at creation is now sitting in whatever wallet received it.

The refund part is more useful than it looks at first. It means applications that ask users to deposit funds, like a staking program or a raffle, can give the deposit back when the user exits. The user's net storage cost is zero. They paid to hold space while they were using the application, and when they were done, the space went back to the pool and their money went back to their wallet.

When your program creates an account, somebody has to pay the deposit. That somebody is one of the accounts listed in the transaction, marked as the payer. Almost always it is the user whose action triggered the creation, since the user is the one who benefits from the new account existing. Your program does not pay out of its own balance.

When you decide how big an account should be, you decide its cost. A 200-byte account is cheap. A 10,000-byte account is fifty times more expensive. There is no penalty for using small accounts, so most production programs keep their accounts as small as the data they need to store.

When you want to clean up after a user, you close the account and send its lamports back to them. The Anchor framework you'll be using has a close constraint that does this in one line. The user gets their deposit back, the account disappears, and the chain has less garbage in it. Programs that don't bother to clean up leave dust everywhere and force their users to pay for storage they no longer need.