Anchor PDAs and Accounts

Lesson Objectives

By the end of this lesson, you will be able to:

Use the seeds and bump constraints to work with PDA accounts in Anchor
Enable and use the init_if_needed constraint
Use the realloc constraint to reallocate space on an existing account
Use the close constraint to close an existing account

TL;DR

The seeds and bump constraints are used to initialize and validate PDA accounts in Anchor
The init_if_needed constraint is used to conditionally initialize a new account
The realloc constraint is used to reallocate space on an existing account
The close constraint is used to close an account and refund its rent

Overview

In this lesson you'll learn how to work with PDAs, reallocate accounts, and close accounts in Anchor.

Recall that Anchor programs separate instruction logic from account validation. Account validation primarily happens within structs that represent the list of accounts needed for a given instruction. Each field of the struct represents a different account, and you can customize the validation performed on the account using the #[account(...)] attribute macro.

In addition to using constraints for account validation, some constraints can handle repeatable tasks that would otherwise require a lot of boilerplate inside our instruction logic. This lesson will introduce the seeds, bump, realloc, and close constraints to help you initialize and validate PDAs, reallocate accounts, and close accounts.

PDAs with Anchor

Recall that PDAs are derived using a list of optional seeds, a bump seed, and a program ID. Anchor provides a convenient way to validate a PDA with the seeds and bump constraints.


1#[derive(Accounts)]
2struct ExampleAccounts {
3  #[account(
4    seeds = [b"example_seed"],
5    bump
6  )]
7  pub pda_account: Account<'info, AccountType>,
8}

During account validation, Anchor will derive a PDA using the seeds specified in the seeds constraint and verify that the account passed into the instruction matches the PDA found using the specified seeds.

When the bump constraint is included without specifying a specific bump, Anchor will default to using the canonical bump (the first bump that results in a valid PDA). In most cases you should use the canonical bump.

You can access other fields from within the struct from constraints, so you can specify seeds that are dependent on other accounts like the signer's public key.

You can also reference the deserialized instruction data if you add the #[instruction(...)] attribute macro to the struct.

For example, the following example shows a list of accounts that include pda_account and user. The pda_account is constrained such that the seeds must be the string "example_seed," the public key of user, and the string passed into the instruction as instruction_data.


1#[derive(Accounts)]
2#[instruction(instruction_data: String)]
3pub struct Example<'info> {
4    #[account(
5        seeds = [b"example_seed", user.key().as_ref(), instruction_data.as_ref()],
6        bump
7    )]
8    pub pda_account: Account<'info, AccountType>,
9    #[account(mut)]
10    pub user: Signer<'info>
11}

If the pda_account address provided by the client doesn't match the PDA derived using the specified seeds and the canonical bump, then the account validation will fail.

Use PDAs with the init constraint

You can combine the seeds and bump constraints with the init constraint to initialize an account using a PDA.

Recall that the init constraint must be used in combination with the payer and space constraints to specify the account that will pay for account initialization and the space to allocate on the new account. Additionally, you must include system_program as one of the fields of the account validation struct.


1#[derive(Accounts)]
2pub struct InitializePda<'info> {
3    #[account(
4        init,
5        seeds = [b"example_seed", user.key().as_ref()],
6        bump,
7        payer = user,
8        space = 8 + 8
9    )]
10    pub pda_account: Account<'info, AccountType>,
11    #[account(mut)]
12    pub user: Signer<'info>,
13    pub system_program: Program<'info, System>,
14}
15
16#[account]
17pub struct AccountType {
18    pub data: u64,
19}

When using init for non-PDA accounts, Anchor defaults to setting the owner of the initialized account to be the program currently executing the instruction.

However, when using init in combination with seeds and bump, the owner must be the executing program. This is because initializing an account for the PDA requires a signature that only the executing program can provide. In other words, the signature verification for the initialization of the PDA account would fail if the program ID used to derive the PDA did not match the program ID of the executing program.

When determining the value of space for an account initialized and owned by the executing Anchor program, remember that the first 8 bytes are reserved for the account discriminator. This is an 8-byte value that Anchor calculates and uses to identify the program account types. You can use this reference to calculate how much space you should allocate for an account.

Seed inference

The account list for an instruction can get really long for some programs. To simplify the client-side experience when invoking an Anchor program instruction, we can turn on seed inference.

Seed inference adds information about PDA seeds to the IDL so that Anchor can infer PDA seeds from existing call-site information. In the previous example, the seeds are b"example_seed" and user.key(). The first is static and therefore known, and the second is known because user is the transaction signer.

If you use seed inference when building your program, then as long as you're calling the program using Anchor, you don't need to explicitly derive and pass in the PDA. Instead, the Anchor library will do it for you.

You can turn on seed inference in the Anchor.toml file with seeds = true under [features].


1[features]
2seeds = true

Use the #[instruction(...)] attribute macro

Let's briefly look at the #[instruction(...)] attribute macro before moving on. When using #[instruction(...)], the instruction data you provide in the list of arguments must match and be in the same order as the instruction arguments. You can omit unused arguments at the end of the list, but you must include all arguments up until the last one you will be using.

For example, imagine an instruction has arguments input_one, input_two, and input_three. If your account constraints need to reference input_one and input_three, you need to list all three arguments in the #[instruction(...)] attribute macro.

However, if your constraints only reference input_one and input_two, you can omit input_three.


1pub fn example_instruction(
2    ctx: Context<Example>,
3    input_one: String,
4    input_two: String,
5    input_three: String,
6) -> Result<()> {
7    ...
8    Ok(())
9}
10
11#[derive(Accounts)]
12#[instruction(input_one:String, input_two:String)]
13pub struct Example<'info> {
14    ...
15}

Additionally, you will get an error if you list the inputs in the incorrect order:


1#[derive(Accounts)]
2#[instruction(input_two:String, input_one:String)]
3pub struct Example<'info> {
4    ...
5}

Init-if-needed

Anchor provides an init_if_needed constraint that can be used to initialize an account if the account has not already been initialized.

This feature is gated behind a feature flag to make sure you are intentional about using it. For security reasons, it's smart to avoid having one instruction branch into multiple logic paths. And as the name suggests, init_if_needed executes one of two possible code paths depending on the state of the account in question.

When using init_if_needed, you need to make sure to properly protect your program against re-initialization attacks. You need to include checks in your code that check that the initialized account cannot be reset to its initial settings after the first time it was initialized.

To use init_if_needed, you must first enable the feature in Cargo.toml.


1[dependencies]
2anchor-lang = { version = "0.25.0", features = ["init-if-needed"] }

Once you’ve enabled the feature, you can include the constraint in the #[account(…)] attribute macro. The example below demonstrates using the init_if_needed constraint to initialize a new associated token account if one does not already exist.


1#[program]
2mod example {
3    use super::*;
4    pub fn initialize(ctx: Context<Initialize>) -> Result<()> {
5        Ok(())
6    }
7}
8
9#[derive(Accounts)]
10pub struct Initialize<'info> {
11    #[account(
12        init_if_needed,
13        payer = payer,
14        associated_token::mint = mint,
15        associated_token::authority = payer
16    )]
17    pub token_account: Account<'info, TokenAccount>,
18    pub mint: Account<'info, Mint>,
19     #[account(mut)]
20    pub payer: Signer<'info>,
21    pub system_program: Program<'info, System>,
22    pub token_program: Program<'info, Token>,
23    pub associated_token_program: Program<'info, AssociatedToken>,
24    pub rent: Sysvar<'info, Rent>,
25}

When the initialize instruction is invoked in the previous example, Anchor will check if the token_account exists and initialize it if it does not. If it already exists, then the instruction will continue without initializing the account. Just as with the init constraint, you can use init_if_needed in conjunction with seeds and bump if the account is a PDA.

Realloc

The realloc constraint provides a simple way to reallocate space for existing accounts.

The realloc constraint must be used in combination with the following constraints:

mut - the account must be set as mutable
realloc::payer - the account to subtract or add lamports to depending on whether the reallocation is decreasing or increasing account space
realloc::zero - boolean to specify if new memory should be zero initialized

As with init, you must include system_program as one of the accounts in the account validation struct when using realloc.

Below is an example of reallocating space for an account that stores a data field of type String.


1#[derive(Accounts)]
2#[instruction(instruction_data: String)]
3pub struct ReallocExample<'info> {
4    #[account(
5        mut,
6        seeds = [b"example_seed", user.key().as_ref()],
7        bump,
8        realloc = 8 + 4 + instruction_data.len(),
9        realloc::payer = user,
10        realloc::zero = false,
11    )]
12    pub pda_account: Account<'info, AccountType>,
13    #[account(mut)]
14    pub user: Signer<'info>,
15    pub system_program: Program<'info, System>,
16}
17
18#[account]
19pub struct AccountType {
20    pub data: String,
21}

Notice that realloc is set to 8 + 4 + instruction_data.len(). This breaks down as follows:

8 is for the account discriminator
4 is for the 4 bytes of space that BORSH uses to store the length of the string
instruction_data.len() is the length of the string itself

If the change in account data length is additive, lamports will be transferred from the realloc::payer to the account in order to maintain rent exemption. Likewise, if the change is subtractive, lamports will be transferred from the account back to the realloc::payer.

The realloc::zero constraint is required in order to determine whether the new memory should be zero initialized after reallocation. This constraint should be set to true in cases where you expect the memory of an account to shrink and expand multiple times. That way you zero out space that would otherwise show as stale data.

Close

The close constraint provides a simple and secure way to close an existing account.

The close constraint marks the account as closed at the end of the instruction’s execution by setting its discriminator to the CLOSED_ACCOUNT_DISCRIMINATOR and sends its lamports to a specified account. Setting the discriminator to a special variant makes account revival attacks (where a subsequent instruction adds the rent exemption lamports again) impossible. If someone tries to reinitialize the account, the reinitialization will fail the discriminator check and be considered invalid by the program.

The example below uses the close constraint to close the data_account and sends the lamports allocated for rent to the receiver account.


1pub fn close(ctx: Context<Close>) -> Result<()> {
2    Ok(())
3}
4
5#[derive(Accounts)]
6pub struct Close<'info> {
7    #[account(mut, close = receiver)]
8    pub data_account: Account<'info, AccountType>,
9    #[account(mut)]
10    pub receiver: Signer<'info>
11}

Demo

Let’s practice the concepts we’ve gone over in this lesson by creating a Movie Review program using the Anchor framework.

This program will allow users to:

Use a PDA to initialize a new movie review account to store the review
Update the content of an existing movie review account
Close an existing movie review account

1. Create a new Anchor project

To begin, let’s create a new project using anchor init.


1anchor init anchor-movie-review-program

Next, navigate to the lib.rs file within the programs folder and you should see the following starter code.


1use anchor_lang::prelude::*;
2
3declare_id!("Fg6PaFpoGXkYsidMpWTK6W2BeZ7FEfcYkg476zPFsLnS");
4
5#[program]
6pub mod anchor_movie_review_program {
7    use super::*;
8
9    pub fn initialize(ctx: Context<Initialize>) -> Result<()> {
10        Ok(())
11    }
12}
13
14#[derive(Accounts)]
15pub struct Initialize {}

Go ahead and remove the initialize instruction and Initialize type.


1use anchor_lang::prelude::*;
2
3declare_id!("Fg6PaFpoGXkYsidMpWTK6W2BeZ7FEfcYkg476zPFsLnS");
4
5#[program]
6pub mod anchor_movie_review_program {
7    use super::*;
8
9}

2. MovieAccountState

First, let’s use the #[account] attribute macro to define the MovieAccountState that will represent the data structure of the movie review accounts. As a reminder, the #[account] attribute macro implements various traits that help with serialization and deserialization of the account, set the discriminator for the account, and set the owner of a new account as the program ID defined in the declare_id! macro.

Within each movie review account, we’ll store the:

reviewer - user creating the review
rating - rating for the movie
title - title of the movie
description - content of the review


1use anchor_lang::prelude::*;
2
3declare_id!("Fg6PaFpoGXkYsidMpWTK6W2BeZ7FEfcYkg476zPFsLnS");
4
5#[program]
6pub mod anchor_movie_review_program {
7    use super::*;
8
9}
10
11#[account]
12pub struct MovieAccountState {
13    pub reviewer: Pubkey,    // 32
14    pub rating: u8,          // 1
15    pub title: String,       // 4 + len()
16    pub description: String, // 4 + len()
17}

3. Add Movie Review

Next, let’s implement the add_movie_review instruction. The add_movie_review instruction will require a Context of type AddMovieReview that we’ll implement shortly.

The instruction will require three additional arguments as instruction data provided by a reviewer:

title - title of the movie as a String
description - details of the review as a String
rating - rating for the movie as a u8

Within the instruction logic, we’ll populate the data of the new movie_review account with the instruction data. We’ll also set the reviewer field as the initializer account from the instruction context.


1#[program]
2pub mod movie_review{
3    use super::*;
4
5    pub fn add_movie_review(
6        ctx: Context<AddMovieReview>,
7        title: String,
8        description: String,
9        rating: u8,
10    ) -> Result<()> {
11        msg!("Movie Review Account Created");
12        msg!("Title: {}", title);
13        msg!("Description: {}", description);
14        msg!("Rating: {}", rating);
15
16        let movie_review = &mut ctx.accounts.movie_review;
17        movie_review.reviewer = ctx.accounts.initializer.key();
18        movie_review.title = title;
19        movie_review.rating = rating;
20        movie_review.description = description;
21        Ok(())
22    }
23}

Next, let’s create the AddMovieReview struct that we used as the generic in the instruction's context. This struct will list the accounts the add_movie_review instruction requires.

Remember, you'll need the following macros:

The #[derive(Accounts)] macro is used to deserialize and validate the list of accounts specified within the struct
The #[instruction(...)] attribute macro is used to access the instruction data passed into the instruction
The #[account(...)] attribute macro then specifies additional constraints on the accounts

The movie_review account is a PDA that needs to be initialized, so we'll add the seeds and bump constraints as well as the init constraint with its required payer and space constraints.

For the PDA seeds, we'll use the movie title and the reviewer's public key. The payer for the initialization should be the reviewer, and the space allocated on the account should be enough for the account discriminator, the reviewer's public key, and the movie review's rating, title, and description.


1#[derive(Accounts)]
2#[instruction(title:String, description:String)]
3pub struct AddMovieReview<'info> {
4    #[account(
5        init,
6        seeds = [title.as_bytes(), initializer.key().as_ref()],
7        bump,
8        payer = initializer,
9        space = 8 + 32 + 1 + 4 + title.len() + 4 + description.len()
10    )]
11    pub movie_review: Account<'info, MovieAccountState>,
12    #[account(mut)]
13    pub initializer: Signer<'info>,
14    pub system_program: Program<'info, System>,
15}

4. Update Movie Review

Next, let’s implement the update_movie_review instruction with a context whose generic type is UpdateMovieReview.

Just as before, the instruction will require three additional arguments as instruction data provided by a reviewer:

title - title of the movie
description - details of the review
rating - rating for the movie

Within the instruction logic we’ll update the rating and description stored on the movie_review account.

While the title doesn't get used in the instruction function itself, we'll need it for account validation of movie_review in the next step.


1#[program]
2pub mod anchor_movie_review_program {
3    use super::*;
4
5		...
6
7    pub fn update_movie_review(
8        ctx: Context<UpdateMovieReview>,
9        title: String,
10        description: String,
11        rating: u8,
12    ) -> Result<()> {
13        msg!("Movie review account space reallocated");
14        msg!("Title: {}", title);
15        msg!("Description: {}", description);
16        msg!("Rating: {}", rating);
17
18        let movie_review = &mut ctx.accounts.movie_review;
19        movie_review.rating = rating;
20        movie_review.description = description;
21
22        Ok(())
23    }
24
25}

Next, let’s create the UpdateMovieReview struct to define the accounts that the update_movie_review instruction needs.

Since the movie_review account will have already been initialized by this point, we no longer need the init constraint. However, since the value of description may now be different, we need to use the realloc constraint to reallocate the space on the account. Accompanying this, we need the mut, realloc::payer, and realloc::zero constraints.

We'll also still need the seeds and bump constraints as we had them in AddMovieReview.


1#[derive(Accounts)]
2#[instruction(title:String, description:String)]
3pub struct UpdateMovieReview<'info> {
4    #[account(
5        mut,
6        seeds = [title.as_bytes(), initializer.key().as_ref()],
7        bump,
8        realloc = 8 + 32 + 1 + 4 + title.len() + 4 + description.len(),
9        realloc::payer = initializer,
10        realloc::zero = true,
11    )]
12    pub movie_review: Account<'info, MovieAccountState>,
13    #[account(mut)]
14    pub initializer: Signer<'info>,
15    pub system_program: Program<'info, System>,
16}

Note that the realloc constraint is set to the new space required by the movie_review account based on the updated value of description.

Additionally, the realloc::payer constraint specifies that any additional lamports required or refunded will come from or be send to the initializer account.

Finally, we set the realloc::zero constraint to true because the movie_review account may be updated multiple times either shrinking or expanding the space allocated to the account.

5. Delete Movie Review

Lastly, let’s implement the delete_movie_review instruction to close an existing movie_review account.

We'll use a context whose generic type is DeleteMovieReview and won't include any additional instruction data. Since we are only closing an account, we actually don't need any instruction logic inside the body of the function. The closing itself will be handled by the Anchor constraint in the DeleteMovieReview type.


1#[program]
2pub mod anchor_movie_review_program {
3    use super::*;
4
5		...
6
7    pub fn delete_movie_review(_ctx: Context<DeleteMovieReview>, title: String) -> Result<()> {
8        msg!("Movie review for {} deleted", title);
9        Ok(())
10    }
11
12}

Next, let’s implement the DeleteMovieReview struct.


1#[derive(Accounts)]
2#[instruction(title: String)]
3pub struct DeleteMovieReview<'info> {
4    #[account(
5        mut,
6        seeds=[title.as_bytes(), initializer.key().as_ref()],
7        bump,
8        close=initializer
9    )]
10    pub movie_review: Account<'info, MovieAccountState>,
11    #[account(mut)]
12    pub initializer: Signer<'info>,
13    pub system_program: Program<'info, System>
14}

Here we use the close constraint to specify we are closing the movie_review account and that the rent should be refunded to the initializer account. We also include the seeds and bump constraints for the the movie_review account for validation. Anchor then handles the additional logic required to securely close the account.

6. Testing

The program should be good to go! Now let's test it out. Navigate to anchor-movie-review-program.ts and replace the default test code with the following.

Here we:

Create default values for the movie review instruction data
Derive the movie review account PDA
Create placeholders for tests


1import * as anchor from "@project-serum/anchor"
2import { Program } from "@project-serum/anchor"
3import { assert, expect } from "chai"
4import { AnchorMovieReviewProgram } from "../target/types/anchor_movie_review_program"
5
6describe("anchor-movie-review-program", () => {
7  // Configure the client to use the local cluster.
8  const provider = anchor.AnchorProvider.env()
9  anchor.setProvider(provider)
10
11  const program = anchor.workspace
12    .AnchorMovieReviewProgram as Program<AnchorMovieReviewProgram>
13
14  const movie = {
15    title: "Just a test movie",
16    description: "Wow what a good movie it was real great",
17    rating: 5,
18  }
19
20  const [moviePda] = anchor.web3.PublicKey.findProgramAddressSync(
21    [Buffer.from(movie.title), provider.wallet.publicKey.toBuffer()],
22    program.programId
23  )
24
25  it("Movie review is added`", async () => {})
26
27  it("Movie review is updated`", async () => {})
28
29  it("Deletes a movie review", async () => {})
30})

Next, let's create the first test for the addMovieReview instruction. Note that we don't explicitly add .accounts. This is because the Wallet from AnchorProvider is automatically included as a signer, Anchor can infer certain accounts like SystemProgram, and Anchor can also infer the movieReview PDA from the title instruction argument and the signer's public key.

Once the instruction runs, we then fetch the movieReview account and check that the data stored on the account match the expected values.


1it("Movie review is added`", async () => {
2  // Add your test here.
3  const tx = await program.methods
4    .addMovieReview(movie.title, movie.description, movie.rating)
5    .rpc()
6
7  const account = await program.account.movieAccountState.fetch(moviePda)
8  expect(movie.title === account.title)
9  expect(movie.rating === account.rating)
10  expect(movie.description === account.description)
11  expect(account.reviewer === provider.wallet.publicKey)
12})

Next, let's create the test for the updateMovieReview instruction following the same process as before.


1it("Movie review is updated`", async () => {
2  const newDescription = "Wow this is new"
3  const newRating = 4
4
5  const tx = await program.methods
6    .updateMovieReview(movie.title, newDescription, newRating)
7    .rpc()
8
9  const account = await program.account.movieAccountState.fetch(moviePda)
10  expect(movie.title === account.title)
11  expect(newRating === account.rating)
12  expect(newDescription === account.description)
13  expect(account.reviewer === provider.wallet.publicKey)
14})

Next, create the test for the deleteMovieReview instruction


1it("Deletes a movie review", async () => {
2  const tx = await program.methods
3    .deleteMovieReview(movie.title)
4    .rpc()
5})

Lastly, run anchor test and you should see the following output in the console.


1anchor-movie-review-program
2    ✔ Movie review is added` (139ms)
3    ✔ Movie review is updated` (404ms)
4    ✔ Deletes a movie review (403ms)
5
6
7  3 passing (950ms)

If you need more time with this project to feel comfortable with these concepts, feel free to have a look at the solution code before continuing.

Challenge

Now it’s your turn to build something independently. Equipped with the concepts introduced in this lesson, try to recreate the Student Intro program that we've used before using the Anchor framework.

The Student Intro program is a Solana Program that lets students introduce themselves. The program takes a user's name and a short message as the instruction data and creates an account to store the data on-chain.

Using what you've learned in this lesson, build out this program. The program should include instructions to:

Initialize a PDA account for each student that stores the student's name and their short message
Update the message on an existing account
Close an existing account

Try to do this independently if you can! But if you get stuck, feel free to reference the solution code.