1

As the question suggests, I am fairly new to Solana, but I do have experience in creating/deploying smart contracts in Ethereum. Just from the get go, there are a ton of things I like about program development in Solana, but RUST and some stuff in general has been fairly tricky to wrap my head around.

In Ethereum, the question above is as easy as sending a msg.value to a smart contract for storing, and then just providing an address for sending.

I'm curious as to how this would be achieved in Solana and Anchor, so any enlightenment would be greatly appreciated!

2
  • In Solana, you should ignore the SOL balance on the program itself. It's just there to be rent-exempt (or pay rent) for program binary storage by validators. You should preferably have other another account, owned by your program, where you store/transfer SOLs to/from.
    – sohrab
    Commented Jul 20, 2022 at 3:31
  • @sohrab this would be a good answer
    – trent.sol
    Commented Jul 23, 2022 at 4:43

2 Answers 2

4

How Accounts work in Solana

First go through how Accounts work in Solana from the Cookbook to understand who and what can credit / debit an account. Use this link.

Transfer via System Program

You may achieve this by using Cross Program Invocations (CPI) with the System Program.

Learn Anchor CPIs here

Learn anchor_lang::system_program::transfer() here

Credit / Debit of Lamports via Addition

Another way is following this tutorial from the cookbook. Snippet below from Solana Cookbook.

/// Transfers lamports from one account (must be program owned)
/// to another account. The recipient can by any account
fn transfer_service_fee_lamports(
  from_account: &AccountInfo,
  to_account: &AccountInfo,
  amount_of_lamports: u64,
) -> ProgramResult {
  // Does the from account have enough lamports to transfer?

  if **from_account.try_borrow_lamports()? < amount_of_lamports {
    return Err(CustomError::InsufficientFundsForTransaction.into());
  }

  // Debit from_account and credit to_account
  **from_account.try_borrow_mut_lamports()? -= amount_of_lamports;
  **to_account.try_borrow_mut_lamports()? += amount_of_lamports;
  Ok(())
}
3
  • I agree with Kristian, but think the question was more about storing SOL in a program, than about transferring SOL with a program. Commented Jul 22, 2022 at 6:01
  • As it’s currently written, your answer is unclear. Please edit to add additional details that will help others understand how this addresses the question asked. You can find more information on how to write good answers in the help center.
    – Community Bot
    Commented Jul 22, 2022 at 6:02
  • You're right it needs some clarifications let me edit it a bit. Commented Jul 22, 2022 at 6:47
0

I don't know that much about Ethereum, but I believe when you write storing SOL "in a program", the closest equivalent in Solana will be to create a separate account that is controlled by your program, and store SOL (or tokens, or data) there.

The address of that new account will be a PDA, Program Derived Address. This address is off the curve, meaning no private key exists whose public key would that PDA. Using a special function called invoke_signed, your program, and only your program, can sign for that account. That's why I mentioned above the account is controlled by your program.

So, in Solana, rather than storing things inside your Program, you Program can create as many PDA accounts as it wants and store stuff in there.

Find docs about PDAs e.g. here (with Anchor).

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.