Solana Quick Start Guide

This code does three simple things:

• Gets your Playground wallet's address

  const address = pg.wallet.publicKey;
  

• Fetches the AccountInfo for the account at that address

  const accountInfo = await pg.connection.getAccountInfo(address);
  

• Prints out the AccountInfo to the Playground terminal

  console.log(JSON.stringify(accountInfo, null, 2));
  

Your wallet is actually just an account owned by the System Program, where the main purpose of the wallet account is to store your SOL balance (amount in the lamports field).

At its core, all Solana accounts are represented in a standard format called the AccountInfo. The AccountInfo data type is the base data structure for all Solana Accounts.

Let's break down the fields in the output:

• data - This field contains what we generally refer to as the account "data". For a wallet, it's empty (0 bytes), but other accounts use this field to store any arbitrary data as a serialized buffer of bytes.
• executable - A flag that indicates whether the account is an executable program. For wallets and any accounts that store state, this is false.
• owner - This field shows which program controls the account. For wallets, it's always the System Program, with the address 11111111111111111111111111111111.
• lamports - The account's balance in lamports (1 SOL = 1,000,000,000 lamports).
• rentEpoch - A legacy field related to Solana's deprecated rent collection mechanism (currently not in use).
• space - Indicates byte capacity (length) of the data field, but is not a field in the AccountInfo type

The Token Extensions program is an executable program account, but note that it has the same AccountInfo structure.

Key differences in the AccountInfo:

• executable - Set to true, indicating this account represents an executable program.
• data - Contains serialized data (unlike the empty data in a wallet account). The data for a program account stores the address of another account (Program Executable Data Account) that contains the program's bytecode.
• owner - The account is owned by the Upgradable BPF Loader (BPFLoaderUpgradeab1e11111111111111111111111), a special program that manages executable accounts.

You can inspect the Solana Explorer for the Token Extensions Program Account and its corresponding Program Executable Data Account.

The Program Executable Data Account contains the compiled bytecode for the Token Extensions Program source code.

Key differences in the AccountInfo:

• owner - The mint account is owned by the Token Extensions program (TokenzQdBNbLqP5VEhdkAS6EPFLC1PHnBqCXEpPxuEb).
• executable - Set to false, as this account stores state rather than executable code.
• data: Contains serialized data about the token (mint authority, supply, decimals, etc.).

The getMint function deserializes the account data into the Mint data type defined in the Token Extensions program source code.

• address - The Mint account's address
• mintAuthority - The authority allowed to mint new tokens
• supply - The total supply of tokens
• decimals - The number of decimal places for the token
• isInitialized - Whether the Mint data has been initialized
• freezeAuthority - The authority allowed to freeze token accounts
• tlvData - Additional data for Token Extensions (requires further deserialization)

You can view the fully deserialized Mint Account data, including enabled Token Extensions, on the Solana Explorer.

This script does the following:

• Set your Playground wallet as the sender

  const sender = pg.wallet.keypair;
  

• Creates a new keypair as the receiver

  const receiver = new Keypair();
  

• Constructs a transfer instruction to transfer 0.01 SOL

  const transferInstruction = SystemProgram.transfer({
    fromPubkey: sender.publicKey,
    toPubkey: receiver.publicKey,
    lamports: 0.01 * LAMPORTS_PER_SOL,
  });
  

• Builds a transaction including the transfer instruction

  const transaction = new Transaction().add(transferInstruction);
  

• Sends and confirms the transaction

  const transactionSignature = await sendAndConfirmTransaction(
    pg.connection,
    transaction,
    [sender],
  );
  

• Prints out a link to the SolanaFM explorer in the Playground terminal to view the transaction details

  console.log(
    "Transaction Signature:",
    `https://solana.fm/tx/${transactionSignature}?cluster=devnet-solana`,
  );
  

This script performs the following steps:

• Sets up your Playground wallet and a connection to the Solana devnet

  const wallet = pg.wallet;
  const connection = new Connection(clusterApiUrl("devnet"), "confirmed");
  

• Generates a new keypair for the mint account

  const mint = new Keypair();
  

• Calculates the minimum lamports needed for a Mint account

  const rentLamports = await getMinimumBalanceForRentExemptMint(connection);
  

• Creates an instruction to create a new account for the mint, specifying the Token Extensions program (TOKEN_2022_PROGRAM_ID) as the owner of the new account

  const createAccountInstruction = SystemProgram.createAccount({
    fromPubkey: wallet.publicKey,
    newAccountPubkey: mint.publicKey,
    space: MINT_SIZE,
    lamports: rentLamports,
    programId: TOKEN_2022_PROGRAM_ID,
  });
  

• Creates an instruction to initialize the mint account data

  const initializeMintInstruction = createInitializeMint2Instruction(
    mint.publicKey,
    2,
    wallet.publicKey,
    wallet.publicKey,
    TOKEN_2022_PROGRAM_ID,
  );
  

• Adds both instructions to a single transaction

  const transaction = new Transaction().add(
    createAccountInstruction,
    initializeMintInstruction,
  );
  

• Sends and confirms the transaction. Both the wallet and mint keypair are passed in as signers on the transaction. The wallet is required to pay for the creation of the new account. The mint keypair is required because we are using its publickey as the address of the new account.

  const transactionSignature = await sendAndConfirmTransaction(
    connection,
    transaction,
    [wallet.keypair, mint],
  );
  

• Prints out links to view the transaction and mint account details on SolanaFM

  console.log(
    "\nTransaction Signature:",
    `https://solana.fm/tx/${transactionSignature}?cluster=devnet-solana`,
  );
   
  console.log(
    "\nMint Account:",
    `https://solana.fm/address/${mint.publicKey}?cluster=devnet-solana`,
  );
  

For now, we'll only cover the high-level overview of the program code:

• The declare_id! macro specifies the on-chain address of your program. It will be automatically updated when we build the program in the next step.

  declare_id!("11111111111111111111111111111111");
  

• The #[program] macro annotates a module containing functions that represent the program's instructions.

  #[program]
  mod hello_anchor {
      use super::*;
      pub fn initialize(ctx: Context<Initialize>, data: u64) -> Result<()> {
          ctx.accounts.new_account.data = data;
          msg!("Changed data to: {}!", data); // Message will show up in the tx logs
          Ok(())
      }
  }
  

  In this example, the initialize instruction takes two parameters:

  1. ctx: Context<Initialize> - Provides access to the accounts required for this instruction, as specified in the Initialize struct.
  2. data: u64 - An instruction parameter that will be passed in when the instruction is invoked.

  The function body sets the data field of new_account to the provided data argument and then prints a message to the program logs.

• The #[derive(Accounts)] macro is used to define a struct that specifies the accounts required for a particular instruction, where each field represents a separate account.

  The field types (ex. Signer<'info>) and constraints (ex. #[account(mut)]) are used by Anchor to automatically handle common security checks related to account validation.

  #[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>,
  }
  

• The #[account] macro is used to define a struct that represents the data structure of an account created and owned by the program.

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

Only the upgrade authority of the program can close it. The upgrade authority is set when the program is deployed, and it's the only account with permission to modify or close the program. If the upgrade authority is revoked, then the program becomes immutable and can never be closed or upgraded.

When deploying programs on Solana Playground, your Playground wallet is the upgrade authority for all your programs.

The #[account] macro in an Anchor program is used to annotate structs that represent account data (data type to store in the AccountInfo's data field).

In this example, we're defining a MessageAccount struct to store a message created by users that contains three fields:

• user: A Pubkey representing the user who created the message account.
• message: A String containing the user's message.
• bump: A u8 storing the "bump" seed used in deriving the program derived address (PDA). Storing this value saves compute by eliminating the need to rederive it for each use in subsequent instructions.
• user - A Pubkey representing the user who created the message account.
• message - A String containing the user's message.
• bump - A u8 storing the "bump" seed used in deriving the program derived address (PDA). Storing this value saves compute by eliminating the need to rederive it for each use in subsequent instructions. When an account is created, the MessageAccount data will be serialized and stored in the new account's data field.

Later, when reading from the account, this data can be deserialized back into the MessageAccount data type. The process of creating and reading the account data will be demonstrated in the testing section.

The #[derive(Accounts)] macro in an Anchor program is used to annotate structs that represent a list of accounts required by an instruction where each field in the struct is an account.

Each account (field) in the struct is annotated with an account type (ex. Signer<'info>) and can be further annotated with constraints (ex. #[account(mut)]). The account type along with account constraints are used to perform security checks on the accounts passed to the instruction.

The naming of each field is only for our understanding and has no effect on account validation, however, it is recommended to use descriptive account names.

The Create struct defines the accounts required for the create instruction.

1. user: Signer<'info>

   • Represents the user creating the message account
   • Marked as mutable (#[account(mut)]) as it pays for the new account
   • Must be a signer to approve the transaction, as lamports are deducted from the account

2. message_account: Account<'info, MessageAccount>

   • The new account created to store the user's message
   • init constraint indicates the account will be created in the instruction
   • seeds and bump constraints indicate the address of the account is a Program Derived Address (PDA)
   • payer = user specifies the account paying for the creation of the new account
   • space specifies the number of bytes allocated to the new account's data field

3. system_program: Program<'info, System>

   • Required for creating new accounts
   • Under the hood, the init constraint invokes the System Program to create a new account allocated with the specified space and reassigns the program owner to the current program.

The #[instruction(message: String)] annotation enables the Create struct to access the message parameter from the create instruction.

The seeds and bump constraints are used together to specify that an account's address is a Program Derived Address (PDA).

seeds = [b"message", user.key().as_ref()],
bump,

The seeds constraint defines the optional inputs used to derive the PDA.

• b"message" - A hardcoded string as the first seed.
• user.key().as_ref() - The public key of the user account as the second seed.

The bump constraint tells Anchor to automatically find and use the correct bump seed. Anchor will use the seeds and bump to derive the PDA.

The space calculation (8 + 32 + 4 + message.len() + 1) allocates space for MessageAccount data type:

• Anchor Account discriminator (identifier): 8 bytes
• User Address (Pubkey): 32 bytes
• User Message (String): 4 bytes for length + variable message length
• PDA Bump seed (u8): 1 byte

#[account]
pub struct MessageAccount {
    pub user: Pubkey,
    pub message: String,
    pub bump: u8,
}

All accounts created through an Anchor program require 8 bytes for an account discriminator, which is an identifier for the account type that is automatically generated when the account is created.

A String type requires 4 bytes to store the length of the string, and the remaining length is the actual data.

The create function implements the logic for initializing a new message account's data. It takes two parameters:

1. ctx: Context<Create> - Provides access to the accounts specified in the Create struct.
2. message: String - The user's message to be stored.

The body of the function then performs the following logic:

1. Print a message to program logs using the msg!() macro.

   msg!("Create Message: {}", message);
   

2. Initializing Account Data:

   • Accesses the message_account from the context.
   let account_data = &mut ctx.accounts.message_account;
   

   • Sets the user field to the public key of the user account.
   account_data.user = ctx.accounts.user.key();
   

   • Sets the message field to the message from the function argument.
   account_data.message = message;
   

   • Sets the bump value used to derive the PDA, retrieved from ctx.bumps.message_account.
   account_data.bump = ctx.bumps.message_account;
   

The Update struct defines the accounts required for the update instruction.

1. user: Signer<'info>

   • Represents the user updating the message account
   • Marked as mutable (#[account(mut)]) as it may pay for additional space for the message_account if needed
   • Must be a signer to approve the transaction

2. message_account: Account<'info, MessageAccount>

   • The existing account storing the user's message that will be updated
   • mut constraint indicates this account's data will be modified
   • realloc constraint allows for resizing the account's data
   • seeds and bump constraints ensure the account is the correct PDA

3. system_program: Program<'info, System>

   • Required for potential reallocation of account space
   • The realloc constraint invokes the System Program to adjust the account's data size

Note that the bump = message_account.bump constraint uses the bump seed stored on the mesesage_account, rather than having Anchor recalculate it.

#[instruction(message: String)] annotation enables the Update struct to access the message parameter from the update instruction.

The update function implements the logic for modifying an existing message account. It takes two parameters:

1. ctx: Context<Update> - Provides access to the accounts specified in the Update struct.
2. message: String - The new message to replace the existing one.

The body of the function then:

1. Print a message to program logs using the msg!() macro.

2. Updates Account Data:

   • Accesses the message_account from the context.
   • Sets the message field to the new message from the function argument.

The Delete struct defines the accounts required for the delete instruction:

1. user: Signer<'info>

   • Represents the user closing the message account
   • Marked as mutable (#[account(mut)]) as it will receive the lamports from the closed account
   • Must be a signer to ensure only the correct user can close their message account

2. message_account: Account<'info, MessageAccount>

   • The account being closed
   • mut constraint indicates this account will be modified
   • seeds and bump constraints ensure the account is the correct PDA
   • close = user constraint specifies that this account will be closed and its lamports transferred to the user account

The delete function takes one parameter:

1. _ctx: Context<Delete> - Provides access to the accounts specified in the Delete struct. The _ctx syntax indicates we won't be using the Context in the body of the function.

The body of the function only prints a message to program logs using the msg!() macro. The function does not require any additional logic because the actual closing of the account is handled by the close constraint in the Delete struct.

In this section, we are simply setting up the test file.

Solana Playground removes some boilerplate setup where pg.program allows us to access the client library for interacting with the program, while pg.wallet is your playground wallet.

const program = pg.program;
const wallet = pg.wallet;

As part of the setup, we derive the message account PDA. This demonstrates how to derive the PDA in Javascript using the seeds specified in the program.

const [messagePda, messageBump] = PublicKey.findProgramAddressSync(
  [Buffer.from("message"), wallet.publicKey.toBuffer()],
  program.programId,
);

First, we send a transaction that invokes the create instruction, passing in "Hello, World!" as the message.

const message = "Hello, World!";
const transactionSignature = await program.methods
  .create(message)
  .accounts({
    messageAccount: messagePda,
  })
  .rpc({ commitment: "confirmed" });

Once the transaction is sent and the account is created, we then fetch the account using its address (messagePda).

const messageAccount = await program.account.messageAccount.fetch(
  messagePda,
  "confirmed",
);

Lastly, we log the account data and a link to view the transaction details.

console.log(JSON.stringify(messageAccount, null, 2));
console.log(
  "Transaction Signature:",
  `https://solana.fm/tx/${transactionSignature}?cluster=devnet-solana`,
);

First, we send a transaction that invokes the update instruction, passing in "Hello, Solana!" as the new message.

const message = "Hello, Solana!";
const transactionSignature = await program.methods
  .update(message)
  .accounts({
    messageAccount: messagePda,
  })
  .rpc({ commitment: "confirmed" });

Once the transaction is sent and the account is updated, we then fetch the account using its address (messagePda).

const messageAccount = await program.account.messageAccount.fetch(
  messagePda,
  "confirmed",
);

Lastly, we log the account data and a link to view the transaction details.

console.log(JSON.stringify(messageAccount, null, 2));
console.log(
  "Transaction Signature:",
  `https://solana.fm/tx/${transactionSignature}?cluster=devnet-solana`,
);

First, we send a transaction that invokes the delete instruction to close the message account.

const transactionSignature = await program.methods
  .delete()
  .accounts({
    messageAccount: messagePda,
  })
  .rpc({ commitment: "confirmed" });

Once the transaction is sent and the account is closed, we attempt to fetch the account using its address (messagePda) using fetchNullable since we expect the return value to be null because the account is closed.

const messageAccount = await program.account.messageAccount.fetchNullable(
  messagePda,
  "confirmed",
);

Lastly, we log the account data and a link to view the transaction details where the account data should be logged as null.

console.log(JSON.stringify(messageAccount, null, 2));
console.log(
  "Transaction Signature:",
  `https://solana.fm/tx/${transactionSignature}?cluster=devnet-solana`,
);

We're adding a new account called vault_account to our Update struct. This account serves as a program-controlled "vault" that will receive SOL from users when they update their messages.

By using a PDA for the vault, we create a program-controlled account unique to each user, enabling us to manage user funds within our program's logic.

Key aspects of the vault_account:

• The address of the account is a PDA derived using seeds [b"vault", user.key().as_ref()]
• As a PDA, it has no private key, so only our program can "sign" for the address when performing CPIs
• As a SystemAccount type, it's owned by the System Program like regular wallet accounts

This setup allows our program to:

• Generate unique, deterministic addresses for each user's "vault"
• Control funds without needing a private key to sign for transactions.

In the delete instruction, we'll demonstrate how our program can "sign" for this PDA in a CPI.

In the update instruction, we implement a Cross Program Invocation (CPI) to invoke the System Program's transfer instruction. This demonstrates how to perform a CPI from within our program, enabling the composability of Solana programs.

The Transfer struct specifies the required accounts for the System Program's transfer instruction:

• from - The user's account (source of funds)

• to - The vault account (destination of funds)

  lib.rs

  let transfer_accounts = Transfer {
      from: ctx.accounts.user.to_account_info(),
      to: ctx.accounts.vault_account.to_account_info(),
  };
  

The CpiContext specifies:

• The program to be invoked (System Program)

• The accounts required in the CPI (defined in the Transfer struct)

  lib.rs

  let cpi_context = CpiContext::new(
      ctx.accounts.system_program.to_account_info(),
      transfer_accounts,
  );
  

The transfer function then invokes the transfer instruction on the System Program, passing in the:

• The cpi_context (program and accounts)

• The amount to transfer (1,000,000 lamports, equivalent to 0.001 SOL)

  lib.rs

  transfer(cpi_context, 1_000_000)?;
  

The setup for a CPI matches how client-side instructions are built, where we specify the program, accounts, and instruction data for a particular instruction to invoke. When our program's update instruction is invoked, it internally invokes the System Program's transfer instruction.

The vault_account uses the same PDA derivation as in the Update struct.

Add the vault_account to the Delete struct enables our program to access the user's vault account during the delete instruction to transfer any accumulated SOL back to the user.

In the delete instruction, we implement another Cross Program Invocation (CPI) to invoke the System Program's transfer instruction. This CPI demonstrates how to make a transfer that requires a Program Derived Address (PDA) signer.

First, we define the signer seeds for the vault PDA:

let user_key = ctx.accounts.user.key();
let signer_seeds: &[&[&[u8]]] =
    &[&[b"vault", user_key.as_ref(), &[ctx.bumps.vault_account]]];

The Transfer struct specifies the required accounts for the System Program's transfer instruction:

• from: The vault account (source of funds)

• to: The user's account (destination of funds)

  lib.rs

  let transfer_accounts = Transfer {
      from: ctx.accounts.vault_account.to_account_info(),
      to: ctx.accounts.user.to_account_info(),
  };
  

The CpiContext specifies:

• The program to be invoked (System Program)

• The accounts involved in the transfer (defined in the Transfer struct)

• The signer seeds for the PDA

  lib.rs

  let cpi_context = CpiContext::new(
      ctx.accounts.system_program.to_account_info(),
      transfer_accounts,
  ).with_signer(signer_seeds);
  

The transfer function then invokes the transfer instruction on the System Program, passing:

• The cpi_context (program, accounts, and PDA signer)

• The amount to transfer (the entire balance of the vault account)

  lib.rs

  transfer(cpi_context, ctx.accounts.vault_account.lamports())?;
  

This CPI implementation demonstrates how programs can utilize PDAs to manage funds. When our program's delete instruction is invoked, it internally calls the System Program's transfer instruction, signing for the PDA to authorize the transfer of all funds from the vault back to the user.

Only the upgrade authority of the program can update it. The upgrade authority is set when the program is deployed, and it's the only account with permission to modify or close the program. If the upgrade authority is revoked, then the program becomes immutable and can never be closed or upgraded.

When deploying programs on Solana Playground, your Playground wallet is the upgrade authority for all your programs.