Solana rent calculator

Everything on Solana is stored in accounts, and every validator keeps all account data ready for fast access. To price that storage, the protocol requires each account to hold a SOL balance proportional to its size. The name rent is historical: accounts below the threshold were once charged periodically until they were emptied and deleted. That mechanism has been retired. Today every new account must be rent-exempt from the moment it is created, and a transaction that would leave an account under its minimum simply fails.

So rent now works as a refundable storage deposit. You put it down once when the account is created, it sits in the account's lamport balance for as long as the account exists, and whoever closes the account receives it back in full. Nothing is deducted over time. The cost of holding an account is only that the deposit is locked up while the account is open.

The minimum balance is (account data size + 128) × 5,080 lamports. The 128 bytes cover the metadata every account carries: its lamport balance, owner, executable flag and so on, which is why even an account with no data needs 650,240 lamports. The rate used to be 6,960 lamports per byte; Solana has since lowered it, which is why older guides still quote larger figures.

Worked through for a 165-byte SPL token account: 165 + 128 = 293 bytes, and 293 × 5,080 = 1,488,440 lamports, or 0.00148844 SOL. An account keeps the lamports it was created with, so a token account opened at the old rate still holds 2,039,280 lamports and returns all of it when closed. The rate is part of the cluster's configuration and can change, as it has, so this calculator asks the RPC for the current minimum at two sizes and derives the rate from the answer rather than assuming it. Programs should do the same by calling getMinimumBalanceForRentExemption instead of hard-coding a figure.

A plain wallet, which is a system account with no data, needs 650,240 lamports, about 0.00065 SOL; that is why sending a smaller amount to a brand-new address fails. A token mint is 82 bytes and needs 1,066,800 lamports. A token account is 165 bytes and needs 1,488,440 lamports, about 0.0015 SOL every time you receive a new token. An SPL multisig is 355 bytes, or 2,453,640 lamports.

Metaplex metadata accounts were created at 679 bytes for most of the NFT era, and those still hold the 5,616,720 lamports they were opened with; the same size needs 4,099,560 lamports today, and newer accounts are somewhat smaller. Token-2022 accounts start at the same 165 bytes and grow with each extension enabled on the mint, so a token with transfer fees or a transfer hook costs more to hold. Deployed programs are the expensive case: a program's data account is sized to the binary, so a 300 KB program locks up a little over 1.5 SOL, recoverable if the program is ever closed.

Closing an account returns its entire lamport balance, deposit included, to an address chosen by the account's authority. For token accounts that means the Token program's CloseAccount instruction, which requires a zero token balance first, so leftover tokens have to be transferred out or burned. Wallets that have traded many tokens or received airdrops typically hold dozens or hundreds of empty token accounts, each with 0.0015 to 0.002 SOL locked inside, depending on when it was opened.

Multiply the figure from this calculator by the number of accounts to see what is at stake: 100 empty token accounts hold about 0.15 SOL if all were opened at today's rate and about 0.2 SOL if all are older. SOLTidy's token account closer finds and closes them in batches for a fee of 5% of the rent recovered, and for older accounts you keep it withdraws the excess over today's minimum, 0.00055084 SOL per SPL token account, without closing them; the NFT burner, stake account manager and program buffer closer recover the larger deposits held by other account types. Accounts you still need should stay open — reopening one later simply means paying the deposit again.