Accounts that pay their own rent.

This note annotates the account-model deep dive. It exists because the single question that trips up new program writers is not "what is rent?" but "whose lamports are these?" The answer is the account's, not the program's, and that distinction changes how you size storage.

The mental model

Think of an account as a small safe-deposit box. The box holds two things: some data and some lamports. The box pays a recurring fee to keep its slot in the vault. If the lamports inside fall below the fee, the vault removes the box and the data is gone. The program that created the box does not cover the fee from its own pocket; the box covers it from its own contents.

What this means for sizing

A program writer who treats rent as a one-time fee will underfund accounts and watch them vanish. The right question is: how much data will this account hold, and therefore how many lamports must it carry for its whole intended life? The answer is a function of byte count, not of how often the program runs.

The two exemption cases

Accounts above a size threshold can be marked rent-exempt by carrying a fixed balance, and the runtime will not remove them even after a long idle period. Accounts below the threshold are still subject to the old behaviour. A builder should know which case their account is in before they ship.

Three questions before you turn the page

• Whose lamports pay the rent on a program account — the program's, or the account's?
• If an account falls below the rent threshold, what happens to its data?
• You size an account for 200 bytes of state. Does the rent depend on how often the program runs?

This note links back to the account-model deep dive and the glossary. Filed under the Accounts Track.

← Back to the tracks