Launch budgets
Mint, metadata, the first token accounts and a few dozen transactions — know the SOL you need before you start.
01 — Cost of being on-chain
Rent for any account size, fees for any transaction, priority fees from the live network — itemised like a receipt, in SOL and dollars.
1 signature · no priority fee · live from mainnet
The SOL an account must hold to be rent-exempt, for any data size. It's a deposit, not a fee — you get it back when the account is closed.
Presets
(128 + bytes) × rate
Exact value from getMinimumBalanceForRentExemption
Base fee per signature, plus an optional priority fee priced per compute unit. Priority levels are read from the last ~150 slots of real fees.
Fee market sample
Bars: minimum priority fee that landed in each of the last ~150 slots for the selected sample.
base = signatures × 5,000 lamports
priority = CU limit × price ÷ 1,000,000
What it costs to hold the accounts you meet every day, using the live rent rate and SOL price.
| Account | Bytes | Lamports | SOL | USD | Who usually pays |
|---|
Sizes are the standard on-chain layouts. Token-2022 accounts with extensions are larger than 165 bytes; a program's ProgramData account is 45 bytes of header plus the program binary (and is often allocated at twice the binary size to leave room for upgrades).
An estimate for distributing a token to N recipients — the classic airdrop or payroll question. Uses your priority settings from the fee calculator.
Creating an associated token account plus a transfer takes roughly 25k–35k CU; six per transaction is a comfortable fit within the 1,232-byte size limit without lookup tables.
Rent goes to the recipients' new accounts (they can reclaim it by closing them); fees are spent. Estimate only.
Type in any box. Uses the live SOL price.
Rent minimums come straight from getMinimumBalanceForRentExemption on a public mainnet RPC — the same call wallets and programs use.
getRecentPrioritizationFees returns the lowest priority fee that landed in each of the last ~150 slots, globally or for transactions touching a given account.
Jupiter's Price API supplies SOL in USD. Every dollar figure is that price times the lamports shown.
Formulas are printed on every receipt, so you can check the arithmetic yourself — nothing is a black box.
Mint, metadata, the first token accounts and a few dozen transactions — know the SOL you need before you start.
Designing account layouts? See instantly what an extra 1 KB of state costs per user, multiplied by your user count.
Rent for new token accounts usually dwarfs fees. The scenario tool shows the split.
See what median and 90th-percentile prices cost at your real compute limit instead of guessing.
Every empty token account you close returns its deposit. Multiply the token-account row by how many you have.
A clean way to show newcomers why a transfer costs fractions of a cent and why "rent" isn't really rent.
A compact guide to every lamport you'll spend or lock up.
Each account stores its data on every validator, so Solana requires a minimum balance proportional to its size. Accounts at or above that minimum are "rent-exempt" and are never charged; new accounts must be created rent-exempt. The minimum is computed from the account's data length plus 128 bytes of fixed overhead, multiplied by a per-byte rate and an exemption threshold of two years. When you close an account, the whole deposit returns to whoever you choose. Older guides quote fixed figures such as 0.00203928 SOL for a token account, derived from 3,480 lamports per byte-year; Lamportly always shows what the cluster returns today.
Every transaction pays 5,000 lamports for each signature it carries, charged to the fee payer even if the transaction fails. Half of the base fee is burned and half goes to the leader that processed it. A typical wallet transfer has one signature, so it costs 0.000005 SOL before any priority fee.
Transactions can bid for faster inclusion with a priority fee: a compute-unit price in micro-lamports, multiplied by the compute-unit limit the transaction requests. If you don't set a limit, the default is 200,000 CU per instruction, capped at 1.4 million per transaction. You pay for the limit you request, not the units you use, so setting a tight limit is the cheapest way to bid high. Priority fees go entirely to the validator.
Solana schedules by account locks, so congestion is mostly local: a hot pool or mint can be expensive while the rest of the network is quiet. That's why the global sample often shows zero and the busy-pool sample does not. Wallets usually estimate fees for the specific accounts your transaction writes.
| Action | Spent | Locked (refundable) |
|---|---|---|
| SOL transfer | 5,000 lamports + priority | — |
| First token transfer to a new wallet | fee | token-account rent |
| Create a token mint | fee | mint (82 B) rent |
| Close an empty token account | fee | rent returned |
No. Rent is a deposit held in the account and returned in full when the account is closed. Fees are spent.
That sample reports the minimum fee that landed in each slot across all transactions, and many transactions pay no priority fee. Busy accounts show what competing transactions actually pay.
Yes. The base fee and priority fee are charged once a transaction is processed, even if an instruction fails. Transactions that are dropped before processing (for example, an expired blockhash) cost nothing.
Tips are ordinary SOL transfers to a tip account, paid by users who submit bundles through Jito. They're separate from Solana's priority fee and not included here.
It's arithmetic on your inputs: real compute use, failed transactions and changing fees will move the result. Use it for budgeting, then test on devnet.
10 MiB (10,485,760 bytes) is the maximum size of a single Solana account.
No. There's no account, no wallet connection and no tracking — the page only reads public data.