Skip to content

Latest commit

 

History

History
52 lines (43 loc) · 3.44 KB

rent_Exemptions_check.md

File metadata and controls

52 lines (43 loc) · 3.44 KB

Rent is a mechanism on the Solana blockchain that ensures efficient usage of the blockchain's resources. It requires accounts to maintain a minimum balance proportional to the amount of data they store on the network. Accounts that fail to maintain this minimum balance will be removed from the ledger to free up storage. You can think of it as similar to a bank account. For many accounts, the bank will charge you a fee if you do not maintain a minimum balance. If your balance falls below the required minimum, the bank may charge you a fee or close your account. Solana rent is like the minimum balance requirement, ensuring that accounts on the network have enough lamports (a lamport is one one-billionth of a SOL) to cover network storage costs. If an account's balance falls below the rent-exempt threshold, the account may be removed from the network. Rent is refundable. If an account is closed (removed from the network), the data is deleted from the chain and the rent is refunded to the account owner (or other defined account).

In Solana, any account that has deposited more than 2 years worth of rent is considered rent-exempt. When an account is rent-exempt, it means that no rent is ever taken, which means that it can run indefinitely. Program executable accounts are required by the runtime to be rent-exempt to avoid being purged.

a program executable with the size of 15,000 bytes requires a balance of 105,290,880 lamports (=~ 0.105 SOL) to be rent-exempt

However, there is a potential vulnerability in Solana smart contracts related to missing rent exemptions checks. Developers need to ensure that account owners and account states are validated before deploying the programs to the Solana main chain

If a developer misses this validation, a malicious user could potentially pass in accounts which are owned by a malicious program. This could lead to loss of funds if not properly checked

To avoid this vulnerability, it is crucial to validate the owners of the input accounts and ensure they are the expected owners. Here is an example

/// Check system program address
fn check_system_program(program_id: &Pubkey) -> Result<(), ProgramError> {
    if *program_id != system_program::id() {
        msg!(
            "Expected system program {}, received {}",
            system_program::id(),
            program_id
        );
        Err(ProgramError::IncorrectProgramId)
    } else {
        Ok(())
    }
}

Here the function checks if a program is a system program. If not, it returns an error, preventing any further action.

Calculating rent for given account in solana

  1. Using solana cli: You can use solana rent command to check the rent for your given account.

  2. Using account space constraint in anchor: In the following example struct Initialize is used for creating new account. The space constraint in the struct contains values. Here 8 + 8 suggests that the data variable which is u64 is 8 bytes and 8 bytes space for the account discriminator totalling to 16 bytes. When the initialize function is called, anchor will make sure that enough lamports are allocated for this account from the account creator when the transaction is submitted.

#[derive(Accounts)]
pub struct Initialize<'info> {
    #[account(init, payer = signer, space = 8 + 8)]
    pub new_account: Account<'info, NewAccount>,
    #[account(mut)]
    pub signer: Signer<'info>,
    pub system_program: Program<'info, System>,
}

#[account]
pub struct NewAccount {
    data: u64
}