Solana rent is a deposit, not an expense

Solana fees are spent, but the rent-exempt balance locked in accounts you control comes back when they close. Book them differently.

2026-10-16 · 5 min read

On Solana, two different things leave your wallet when you transact: fees, which are gone for good, and rent-exempt balances, which sit inside accounts and can be recovered later. If you control those accounts, treating rent as an expense understates your SOL and overstates costs.

Fees: base plus priority, paid in lamports

Solana amounts are measured in lamports, and one SOL equals one billion lamports [2]. Every transaction pays a base fee of 5,000 lamports per signature [1]. A sender can add an optional prioritisation fee, calculated from the compute-unit price multiplied by the compute-unit limit requested, divided by one million and rounded up [1]. The priority fee is based on the limit requested, not the compute actually used [1].

Half of the base fee is burned and half goes to the block-producing validator; the whole priority fee goes to the validator [1]. The fee is taken from the fee payer before execution and is still charged if the transaction fails [1]. For accounting, fees are a consumption of SOL: spent, not parked.

Rent: a minimum balance, not a running charge

Every account on Solana, including each token account, must hold a minimum lamport balance to stay on-chain. The required amount grows with the account's data size [2]. Solana's documentation describes this as a storage balance that is fully refunded when the account is closed [2].

Token accounts are the case finance teams meet most. A standard SPL token account is 165 bytes and needs 2,039,280 lamports, about 0.00204 SOL; a Token-2022 account with the immutable-owner extension is 170 bytes and needs 2,074,080 lamports [3]. Extensions can raise this, so Solana recommends querying the current minimum rather than hard-coding it [3]. One wallet holding many tokens, or a programme that opens accounts for users, can lock up a meaningful amount of SOL this way.

Getting it back: closing accounts

A token account can usually be closed only once its token balance is zero. Closing removes the account and sends all its lamports, including the storage deposit, to a destination chosen by the owner or the designated close authority [4]. Two details matter for the books:

• Whoever paid to create the account does not automatically get the refund; it goes to the chosen destination [4]. The payer, fee payer and owner can all be different parties [3].
• So a deposit is only recoverable by you if you, or an account you control, can direct the close. Rent paid to open accounts for customers or counterparties is a different matter.

Wrapped SOL

Wrapped SOL is native SOL held in a token account for the special native mint, so it can be used like any other SPL token [5]. You fund the account with SOL and call SyncNative, which sets the token amount to the lamports held above the rent-exempt reserve [5]. Unwrapping means closing the account, which returns all lamports, principal and rent reserve together [5]. Unlike other token accounts, a wrapped SOL account can be closed while it still has a balance [4].

That single refund mixes two things: the wrapped principal and the rent deposit. Splitting them, using the token amount for principal and the remainder for rent, keeps your SOL quantities reconciling.

Why reclassify rather than expense

Standard setters have not issued guidance specific to Solana rent, so this is a policy choice to document. The economics, though, are clear from the protocol design: when the entity controls the account, the SOL has not been consumed. It is still the entity's, held in a different place and recoverable on close [2][4]. A common approach is therefore:

• Treat rent funding of controlled accounts as a reclassification from liquid SOL to a restricted or deposited SOL balance, carried at the same cost basis, with no gain or loss.
• On close, reverse the reclassification back to liquid SOL.
• Treat fees, base and priority, as disposals of SOL used to pay an expense, with any difference between fair value and basis as a gain or loss under your normal policy.
• Treat rent paid for accounts you do not control as a cost, expensed or capitalised according to its purpose, because you cannot recover it.

Whether the restricted balance is shown separately or disclosed within crypto assets depends on materiality and your presentation policy. Tax treatment of deposits and refunds is not addressed by Solana's documentation and should be confirmed for your jurisdiction.

What to do

• Separate fees from rent deposits when importing Solana transactions; do not book every outflow as gas.
• Track which accounts you control and who holds close authority over each.
• Keep a sub-ledger of open accounts and their deposits so refunds can be matched on close.
• Split wrapped SOL unwraps into principal and rent refund.
• Document the policy, including how rent paid for third-party accounts is treated, and agree it with your auditors.

Sources

1. Fee Structure (Solana documentation)
2. Accounts (Solana documentation)
3. Create a Token Account (Solana documentation)
4. Close Token Account (Solana documentation)
5. Sync Native (Wrapped SOL) (Solana documentation)

General information for finance teams, current as of publication. Not legal, tax or accounting advice.

All Newsroom explainers