The single thing that makes Solana feel different from other chains, once you get past the speed, is that almost everything is an account. Your balance is an account. Your program is an account. The state your program writes is an account. Once that idea lands, the rest of the runtime starts to make sense. This guide walks through it slowly, with the small confusions we hit along the way.
What an account holds
An account is a record with a handful of fields. It has an address, which is a public key. It has a balance of lamports, the smallest unit of SOL. It has a blob of data, up to ten megabytes by default, which can hold anything a program wants to put there. It has an executable flag, which is true if the account is a program and false otherwise. And it has an owner, which is the address of the program allowed to change the account's data and deduct its balance.
The first surprise, for readers coming from elsewhere, is that a program is itself an account. The program's bytecode lives in the data field of an account whose executable flag is true. That is why deploying a program costs SOL: you are paying rent on the account that holds the code.
Why rent exists
Rent is the fee an account pays for the space its data takes up on the chain. The reason it exists is honest: validators have to store every account, forever, and storage is not free. Rent turns that cost back onto the account holder.
These days, rent is usually a deposit rather than a recurring fee. If an account holds at least two years' worth of rent, it is rent-exempt and nothing is deducted. If it falls below that, it cannot exist. This is why small accounts you create tend to need a little more SOL than you expect: the runtime will not let you make an account that cannot pay for its own storage.
When a reader writes to us asking why their account was emptied, the answer is almost always rent on a token account they forgot they had. The fix is to close the account deliberately, which returns the rent deposit to them.
The owner field
The owner field is the rule that keeps programs from rewriting each other's state. Only the account's owner may change its data, and only the owner may deduct its balance. Anyone may credit balance to any account, but only the owner may spend it.
This is why a token account is owned by the token program, not by you. You can sign for the account \u2014 the token program checks your signature \u2014 but the token program is the one that actually moves the balance, because it is the owner. Once this clicks, the shape of a Solana program becomes clear: a program reads the accounts it is handed, checks that they are owned by who it expects, and then writes to the ones it owns.
Putting it together
With those three ideas \u2014 everything is an account, rent pays for storage, and the owner field governs writes \u2014 most of the runtime falls into place. A transaction is a list of accounts and a program to call. The runtime loads the accounts, charges rent and fees, hands the accounts to the program, and lets the program write to the ones it owns. The cleverness of Solana is in how it orders and schedules those calls; the shape of the data is this, and it is simpler than it first looks.
If you want to test your understanding, try to explain, out loud, why a token account cannot be emptied by a program you wrote. If you can answer it using only the three ideas above, the guide has done its job.