What are Solana PDAs? Explanation & Examples (2025)

Thanks to 0xIchigo for reviewing, Unboxed Software for the movie review program, and Paul Verhoeven for Robocop.

Solana programs (smart contracts) store their data in separate accounts called Program Derived Addresses (PDAs).

PDAs can be accessed and updated independently, reducing contention and allowing for parallel processing.

While PDAs aren't a difficult concept, they can be difficult for new developers to understand.

justin 🌵

@JustinChitla

·Follow

Replying to @JustinChitla

- took me a bit to grasp Solana’s separation of logic and state and “PDAs” - would be cool is an example bank of different structures/use cases for PDAs. PDAs are a foreign concept to all newbie solanoors and while the docs are great, I only got extremely comfortable with the…

6:20 PM · Nov 24, 2024

6

Reply

Copy link

Read 2 replies

This article will help you think about PDAs as Key/Value stores and share four practical examples of PDAs.

Let's begin.

PDAs as a Key/Value Data Store

Key/value stores existed in programming for many years before blockchain. They are a way to quickly find data. Looking up the value at a given key inside the store always finds the same data.

In Solana’s programming model, your program’s key/value store is the PDA system.

The key for each piece of data is a special kind of address made from input seeds determined by the programmer.

The same seeds always generate the same address, so anyone can deterministically find the data for a given set of seeds.

PDA addresses will never conflict with actual public keys as their values are ‘off curve’, i.e., the addresses made for PDAs are mathematically distinct from public key values that exist on Solana’s Ed25519 curve.

The value is a struct (or object) with the fields and values you, the program author, want to store there.

PDAs are best explained by example, so let's do that.

1. PDA for Storing Tokens Associated with a Wallet

Let's start with someone else's program—one you've already used. You already know that you have different tokens in your wallet and that each has its own balance. Welcome to your first example of PDAs!

Each of your token balances is stored in a PDA account, with the seeds determined by the Associated Token Account program.

Let's look at exactly how that works:

Video Recap

Program: the Associated Token Account program

Account Purpose: store the balance of a unique token in your wallet

Seeds: the wallet address and the token's mint address

Data: the balance of this token for this wallet

Benefit:

There's a canonical place to look up a user's holdings of a particular token, and since user balances are in separate accounts, more transactions can be run in parallel, making Solana fast!

2. PDA for Storing Your Program's Data

OK, great, but how can we use PDAs as a general-purpose data store in our Solana programs? What do we need to consider when designing the seeds and data for our PDAs?

Video Recap

Program: a movie review program that uses asset ownership to ensure reviews are more likely to be genuine

Account Purpose: storing each asset owner's review of a movie

Seeds: the wallet address, the film name, and the year of release

Data:

1. a written review (string)
2. a rating from 0-10 stored as a u8

Benefit:

There's a canonical place to look up a user's review of a particular movie. Users can update their reviews in parallel without blocking each other. Our smart PDA design ensures there is only one review of a film per user, and handles edge cases like bad people remaking Robocop.

3. PDA for Setting Configurable Values for Your Program

When making your own apps, you’ll likely have some configurable values you want to set throughout the program’s lifecycle: 

• Constant values (e.g. fees for your platform)
• Lists of mint addresses for the tokens your program will use
• Feature flags that you can enable and disable at will
• Whether your program is active or paused (e.g. allowing an admin account to pause a program is a typical emergency break-glass feature of many blockchain programs)

We don't want to upgrade our program just to change these values, so let's put our config into a PDA account! We can then make some instruction handlers to update these values, and check the incoming instructions are signed by a designated ‘admin’ account. 

In this case, we'll have a config with a list of allowed public keys so we can limit who can interact with our program, but we could add whatever other config settings we want.

This is an interesting example, since it may not be obvious that PDAs can be used to store global config like this!

Video Recap

Program: any program you've made

Account Purpose: storing some dynamically updatable config

Seeds: "config"

Data: our config, in this case, an allow list and an admin account

• allow_list: a vector of public keys for users that are allowed to use this app
• authority: the public key of an account that can change these settings (Solana apps typically use the word authority to convey some kind of permission). We'll ensure that this account signs privileged actions!

Benefit:

Rather than hard-coding a certain config into your source code, we can update it on the fly using an instruction function in our program.

Our config updates are also not blocked by changes to unrelated data. The first time you deploy your program, you'd also want to run intialize_config() and set your authority!

4. PDA for Owning and Transferring Tokens

PDAs aren’t just for storing data. PDAs can also own their own token accounts. Our program then signs transactions as the PDA to move tokens from those token accounts elsewhere. This allows our programs to store and transfer value:

Video Recap

Program: swap program

Account Purpose: 

1. Storing details of a swap offer, specifically what tokens and what amount of tokens the offer maker wants in return for the tokens they have supplied. 
2. This PDA owns a token account, which stores the supplied tokens. The PDA can sign transactions and transfer tokens from this account to recipients. 

Seeds: "offer", an offer ID (just any identifier as long as it's not already taken), and the maker's address

Data:

• maker_wanted_token: the token wanted in return, as a public key of the token's mint address
• maker_wanted_amount: the amount wanted of the token (u64)

Benefit:

This PDA enables users to store data and also act as the owner of a token account to hold tokens and transfer them to other accounts.

Summary

That was four practical examples of Solana PDAs.

First, the Associated Token Account program uses PDAs to store the balance of each token your wallet owns.

Second, a program you write can store data associated with particular users using their public key or with particular data items using the IDs you’ve set for them.

Third, programs can store their own config in a PDA, with admin-only instruction handlers restricting who can modify these settings.

Fourth, your PDAs can own their own token accounts, allowing your program to hold funds. Your program can ‘sign for’ transactions that use these tokens just by specifying the seeds of the PDA that owns them.

PDAs not only make Solana fast, but also provide a full key/value store that allows your programs to quickly find data based on the seeds that you specify. 

Have fun using PDAs and watch more Paul Verhoeven films!