Rent-Exemption and Storage Costs

Solana does not have a gas fee for contract storage as Ethereum does, but it requires accounts to be rent-exempt to persist. As mentioned, any account (program or data account) must carry a balance sufficient for 2 years of rent for its size. If not, the account would normally pay rent each epoch and eventually get reclaimed if it runs out of funds. However, since new accounts must be rent-exempt upon creation now, Nyvo handles depositing the required lamports when initializing accounts.

Key points for Nyvo developers regarding storage:

• Account Size and Cost: When Nyvo creates, say, a staking pool account that holds some state, it calculates how many bytes are needed (based on the struct of that state). Using Solana’s rent constants, it then computes the minimum lamports. The formula is: (account_size in bytes) * 3,480 lamports/byte/year * 2 yearsrareskills.io plus a base of 128 bytes overhead. Simplified, approximately rent_exempt_lamports = (account_size + 128) * 6,960For example, if account_size = 200 bytes, then rent exempt lamports = (328 bytes * 6960) ≈ 2,284, which is 0.000002284 SOL. In practice, Nyvo will likely over-fund slightly by a few lamports to ensure no edge case.

• Program Storage: Programs (the deployed smart contract code) are also just data in an account. These can be large (tens or hundreds of KB). Nyvo will cover the rent-exemption for these as well, which is why deploying a program costs more lamports upfront – e.g., a 200 KB program would need ~200,000 * 6,960 lamports = 1.392e9 lamports = 1.392 SOL just to be rent-exempt. This is why complex programs have a noticeable deployment cost. Nyvo’s launchpad or marketplace programs are designed to be as compact as possible, but their size is part of deployment cost considerations.

• State Accounts for Users: Some modules create per-user accounts (like a stake account for each staker). When a user interacts for the first time, Nyvo’s program may create a new account for them. Usually, the wallet signing the transaction must also fund the rent for their account (unless the program uses the Sysvar Rent exemption to exempt it, but that just checks the funding). Nyvo’s front-end will automatically add the required lamports to the instruction that creates the account, debiting the user. The amount is small (e.g., a 50-byte account needs ~50*6960 = 348000 lamports = 0.000348 SOL). It’s good to inform your end-users that a tiny amount of SOL will be used to create their account, but it’s not a fee – if they ever close the account, they get this rent back. Solana’s design refunds rent: when an account is no longer needed, Nyvo’s program can system_program::close_account to return the lamports to a specified receiver (often the user or admin)

• Data Compression and Off-chain Storage: For very data-heavy applications, storing everything on Solana can become expensive (and also limited by the maximum account size, ~10MB). Nyvo modules encourage only critical state to live on-chain. For example, an NFT marketplace doesn’t store images or metadata on-chain (it uses off-chain references for those); it only stores what it absolutely must (prices, ownership, etc.). If your use-case involves large data (like files or logs), consider using off-chain storage (IPFS/Arweave) and storing a reference on-chain. While Nyvo doesn’t directly cover off-chain storage in this guide, it’s a general Solana best practice to be mindful of what data you put in accounts.

In practice, Nyvo takes care of rent math for you. However, if you add custom accounts or modify a module’s structure, you should use Solana’s CLI or RPC (getMinimumBalanceForRentExemption) to calculate the needed lamports. Nyvo’s CLI (if available) might even have a command like nyvo rent-calc <bytes> which simply wraps the Solana CLI call to output the rent-exempt minimum. Always ensure any account you create via custom instructions is rent-exempt; otherwise, the runtime will reject its creation.