Network
Launch Date
Consensus
Note
Sepolia
Oct 2021
PoW
Like-for-like representation of Ethereum
Görli
Jan 2019
PoA
Proof-of-Authority
Kiln
Mar 2022
PoS
Post-Merge (for ETH2), shadow fork of the mainnet
Kintsugi
Dec 2021
PoS
DEPRECATED, use Kiln; post-Merge (for ETH2)
Ropsten
Nov 2016
PoW
DEPRECATED, use Sepolia; the Merge to happen on Jun 8, 2022
Rinkeby
Apr 2017
PoA
DEPRECATED, use Görli and Görli Faucet
Kovan
Mar 2017
PoA
DEPRECATED, use Sepolia or Görli
List of active and deprecated Ethereum testnets, including Kintsugi.
Features
Optimistic rollup 
ZK-rollup 
Proof
Uses fraud proofs to prove transaction validity. 
Uses validity (zero-knowledge) proofs to prove transaction validity. 
Capital efficiency
Requires waiting through a 1-week delay (dispute period) before withdrawing funds. 
Users can withdraw funds immediately because validity proofs provide incontrovertible evidence of the authenticity of off-chain transactions. 
Data compression
Publishes full transaction data as calldata to Ethereum Mainnet, which increases rollup costs. 
Doesn't need to publish transaction data on Ethereum because ZK-SNARKs and ZK-STARKs already guarantee the accuracy of the rollup state. 
EVM compatibility
Uses a simulation of the Ethereum Virtual Machine (EVM), which allows it to run arbitrary logic and support smart contracts. 
Doesn't widely support EVM computation, although a few EVM-compatible ZK-rollups have appeared. 
Rollup costs
Reduces costs since it publishes minimal data on Ethereum and doesn't have to post proofs for transactions, except in special circumstances. 
Faces higher overhead from costs involved in generating and verifying proofs for every transaction block. ZK proofs require specialized, expensive hardware to create and have high on-chain verification costs. 
Trust assumptions
Doesn't require a trusted setup. 
Requires a trusted setup to work. 
Liveness requirements
Verifiers are needed to keep tabs on the actual rollup state and the one referenced in the state root to detect fraud. 
Users don't need someone to watch the L2 chain to detect fraud. 
Security properties 
Relies on cryptoeconomic incentives to assure users of rollup security. 
Relies on cryptographic guarantees for security. 
Start building
on Alchemy.
Sign up for free
Start building on Optimism.
Sign up for free
Start building on Arbitrum.
Sign up for free
Start building on Ethereum.
Sign up for free
Start building on Polygon.
Sign up for free
Start building on Starknet.
Sign up for free
Start building on Flow.
Sign up for free
kiln faucet
Get free Kiln ETH.
Start building today
Goerli faucet
Get free Goerli ETH.
Start building today
SEPOLIA FAUCET
Get free Sepolia ETH.
Start Building Today
mumbai faucet
Get free Mumbai Matic.
Start building today
rinkeby faucet
Get free Rinkeby
ETH.
Start building today
Start building on Ethereum.
Get started for free
Start building on Ethereum.
Get started for free
Start building on Flow.
Get started for free
Start building on Polygon.
Get started for free
Start building on Starknet.
Get started for free
Start building on Optimism.
Get started for free
Start building on Solana.
Get started for free
Start building on Solana.
Sign up for beta access
Start building on Solana.
Join the waitlist
Arbitrum logo
Start building on Arbitrum.
Get started for free
Build with Alchemy's
Gas Manager & Bundler APIs
Learn
Solidity at
Alchemy
University
Get started today
Build with Alchemy's
Gas Manager & Bundler APIs
curl 
https://release.solana.com/v1.10.32/solana-install-init-x86_64-pc-windows-msvc.exe 
--output 
C:\solana-install-tmp\solana-install-init.exe 
--create-dirs
Solana
SOLANA PDA OVERVIEW

What are Solana’s Program Derived Addresses (PDAs)?

Learn What Program Derived Addresses Are, How PDAs Are Different From Regular Addresses, And PDA Use Cases
Last Updated:
January 25, 2023
Table of Contents
Table of Contents
Table of Contents

{{get-started-solana}}

Program Derived Addresses (PDAs) are accounts on the Solana blockchain that have special properties. Using PDAs properly can make Solana dApp development fast and efficient since they aid in cross-program communication. 

This article will explain PDAs, what they are, which problems they solve, how they work, and how they are different from other accounts in Solana's account model.

What is a Program Derived Address (PDA)?

A Program Derived Address is an account on the Solana blockchain that does not have a private key. Since a PDA is not a public key, the address of the account is found using the program ID, a SHA-512 hashing function, seed array, and a special bump seed.

What is a standard account on Solana?

A standard Solana account has both private and public keys (32 bytes each), and together they form a keypair, which is 64 bytes long and sits on an elliptic curve (ED25519). In order for the keypair to be valid it must lie on this curve. 

Here is a representation of an ED25519 Elliptic Curve:

ED25519 Elliptic Curve on Solana

How are program addresses derived?

PDAs require three main components:

  1. Parent Program ID - the ID of the parent program that creates the PDA
  2. Seeds - an array of strings*
  3. Bump Seed - makes sure that the PDA does not have a private key

Creating a valid Program Derived Address requires taking the ID of its parent program, the seeds array, and running them through a SHA-512 hashing function

In about 50% of the cases, however, the result of this hash is a keypair that lies on the ED25519 Elliptic Curve. Because PDAs do not have a private key, Program Derived Addresses must not lie on the elliptic curve. To prevent PDAs from having private keys, a special bump seed is used to “bump” the hash result off the curve. 

The bump seed is nothing more than a number, starting at 255. In the case where even with the bump seed, the hash result still resides on the curve, the hashing function is run again, with a bump equating to 254, then 253, etc. until the generated result is not on curve.

*Note: Seeds can be any arbitrary string, but developers use them in a context specific to the state variables of the parent program to create hashmap-like structures.

What problems do PDAs solve?

Program derived addresses streamline transaction confirmation by programmatically generating transaction signatures, thus helping trustless services like DeFi accounts to function seamlessly.

Here is a hypothetical example use case for PDAs.

Consider a Solana program that lets the user set an NFT as their default profile picture (PFP). The program will consist of two programs:

  1. The PFP program - creates accounts to store a user’s selected profile picture
  2. The Core program - acts as a proxy between the user’s inputs and the PFP program

For the PFP program to update a user’s selected profile picture, it would need to use its private key to sign a transaction that will change the user’s profile picture. However, this would also mean that the program would need to store its private key on-chain.

A Solana program cannot use its private key to sign a transaction on its own behalf, because the key itself would be stored on-chain, making it visible to everyone. If this happened, the private key could be used to sign transactions on behalf of the program and change the profile picture of any user.

Imagine that the PFP program was responsible for handling millions of SOL tokens. Such an exploit would become a major hack. Program Derived Addresses solve this.

Why are PDAs important?

Program Derived Addresses play an instrumental part in Solana programming because they aid the communication between different programs (Cross Program Invocations) and can act as a hashmap for storing specific data that its parent program can easily update and change.

1. Storing a Program’s State Variables

PDAs allow Solana developers to store and track a variable or a set of variables, related to a specific user. A PDA’s best use case is storing state variables or data for its parent program because by default it has authorized the parent program to make changes on its behalf.

2. Use PDAs as Hashmaps

Mapping represents a set of key-value pairs, and is used to easily find information that is associated with a key. In Solana development, a PDA’s seeds and the correct strings can be used to achieve the same result. 

Let's go back to our previous wallet profile picture example.

Once a user selects their wallet’s PFP, the PFP program takes the selected image, the user’s address, and uses those as ‘seeds’ for creating a PDA that would store the user’s choice.

Once the Program Derived Address is successfully found by the hashing algorithm, its public key is ‘mapped’ to the user’s address and chosen NFT avatar.

The hashmap feature could be utilized even better by providing another PDA as a third seed. We can take all the available profile pictures and store them in a separate PDA, and we will pass each profile picture as its seed, and we end up with a PDA that stores all the profile pictures.

Now, when a user comes and picks their profile picture, the PDA will look like a hashmap because the seeds are passed so that if you look at them, you will know that out of a selection of profile pictures (the PFP group PDA), a user’s address that we passed as a first seed, has chosen the profile picture that we passed as the second seed. 

This example could be built upon to create even deeper hashmap structures.

A PDA as a hashmap program flow - NFT example

3. Cross Program Invocations

Cross Program Invocations (CPI) is the process of one program calling a function in another program. CPIs are useful because they allow for better code composability.

Going back to our example, let's say that a user wants to change their profile picture from a Degen Ape to a Solana Monkey Business avatar.

Here’s what happens under the hood:

Upon logging into their wallet, the core contract will take the user’s address (public key) and will look for an already created PDA, whose seeds include the user’s public key. 

After finding it, the core program will invoke a function in the PFP program called ‘changePFP()’ (this is a Cross-Program Invocation), which would accept the PDA that has already been ‘selected’ by the Core program as an argument. 

Once the function is called, the selected PDA will check if the account that is ‘asking’ for the change to happen is its parent. If the PDA is a mismatch the transaction will be rejected, because only a parent program can modify the data of a PDA. 

Since the PFP program is the parent of the selected PDA, it will be allowed to change the selected profile picture of the user from a Degen Ape to an SMB avatar.

Cross program invocation with PDA - Changing NFT images

Program Derived Addresses allow their parent programs to sign on their behalf and can be used to store a program’s state, hashmaps and in cross-program invocations. PDAs are a foundational topic in the realm of Solana programming that enable fast and efficient dApp development.

Program Derived Address FAQs

When working with Program Derived Addresses, it may be helpful to understand how Solana handles transactions and data. The two primary types of accounts are executable and non-executable.

What is an executable account?

Executable accounts, also known as programs, are similar to an Ethereum smart contract — a piece of code that changes its state when an account interacts with it.

What is a non-executable account?

Non-executable data accounts are simply used for storing data (e.g. the amount of SOL that the account owns, NFTs, token balances, etc.), essentially, the state variables of a program.

How is Solana program data storage different than Ethereum smart contracts?

One foundational difference between Ethereum and Solana is how the storage of executable code is organized. Smart contracts on Ethereum come ‘prebuilt’ with storage where the smart contract stores all its state variables. In comparison, programs on Solana do not have pre-built storage, but they have separate data accounts which hold the various state variables they want to store and reference.

ALCHEMY SUPERNODE - ETHEREUM NODE API

Scale to any size, without any errors

Alchemy Supernode finally makes it possible to scale blockchain applications without all the headaches. Plus, our legendary support will guide you every step of the way.

Get started for free
Supernode footer
Solana
SOLANA PDA OVERVIEW

What is a Program Derived Address (PDA)?

Learn What Program Derived Addresses Are, How PDAs Are Different From Regular Addresses, And PDA Use Cases
Last Updated:
January 25, 2023
Last Updated:
March 14, 2023
Don't miss an update
Sign up for our newsletter to get alpha, key insights, and killer resources.
Thank you! Your submission has been received!
Oops! Something went wrong while submitting the form.
Table of Contents

Talk to an Expert

Learn how Alchemy's blockchain developer tools can help your business succeed in web3!
Valid number
Thank you! An Alchemy expert will be in touch with you shortly!
Oops! Something went wrong while submitting the form.

{{get-started-solana}}

Table of Contents

Program Derived Addresses (PDAs) are accounts on the Solana blockchain that have special properties. Using PDAs properly can make Solana dApp development fast and efficient since they aid in cross-program communication. 

This article will explain PDAs, what they are, which problems they solve, how they work, and how they are different from other accounts in Solana's account model.

What is a Program Derived Address (PDA)?

A Program Derived Address is an account on the Solana blockchain that does not have a private key. Since a PDA is not a public key, the address of the account is found using the program ID, a SHA-512 hashing function, seed array, and a special bump seed.

What is a standard account on Solana?

A standard Solana account has both private and public keys (32 bytes each), and together they form a keypair, which is 64 bytes long and sits on an elliptic curve (ED25519). In order for the keypair to be valid it must lie on this curve. 

Here is a representation of an ED25519 Elliptic Curve:

ED25519 Elliptic Curve on Solana

How are program addresses derived?

PDAs require three main components:

  1. Parent Program ID - the ID of the parent program that creates the PDA
  2. Seeds - an array of strings*
  3. Bump Seed - makes sure that the PDA does not have a private key

Creating a valid Program Derived Address requires taking the ID of its parent program, the seeds array, and running them through a SHA-512 hashing function

In about 50% of the cases, however, the result of this hash is a keypair that lies on the ED25519 Elliptic Curve. Because PDAs do not have a private key, Program Derived Addresses must not lie on the elliptic curve. To prevent PDAs from having private keys, a special bump seed is used to “bump” the hash result off the curve. 

The bump seed is nothing more than a number, starting at 255. In the case where even with the bump seed, the hash result still resides on the curve, the hashing function is run again, with a bump equating to 254, then 253, etc. until the generated result is not on curve.

*Note: Seeds can be any arbitrary string, but developers use them in a context specific to the state variables of the parent program to create hashmap-like structures.

What problems do PDAs solve?

Program derived addresses streamline transaction confirmation by programmatically generating transaction signatures, thus helping trustless services like DeFi accounts to function seamlessly.

Here is a hypothetical example use case for PDAs.

Consider a Solana program that lets the user set an NFT as their default profile picture (PFP). The program will consist of two programs:

  1. The PFP program - creates accounts to store a user’s selected profile picture
  2. The Core program - acts as a proxy between the user’s inputs and the PFP program

For the PFP program to update a user’s selected profile picture, it would need to use its private key to sign a transaction that will change the user’s profile picture. However, this would also mean that the program would need to store its private key on-chain.

A Solana program cannot use its private key to sign a transaction on its own behalf, because the key itself would be stored on-chain, making it visible to everyone. If this happened, the private key could be used to sign transactions on behalf of the program and change the profile picture of any user.

Imagine that the PFP program was responsible for handling millions of SOL tokens. Such an exploit would become a major hack. Program Derived Addresses solve this.

Why are PDAs important?

Program Derived Addresses play an instrumental part in Solana programming because they aid the communication between different programs (Cross Program Invocations) and can act as a hashmap for storing specific data that its parent program can easily update and change.

1. Storing a Program’s State Variables

PDAs allow Solana developers to store and track a variable or a set of variables, related to a specific user. A PDA’s best use case is storing state variables or data for its parent program because by default it has authorized the parent program to make changes on its behalf.

2. Use PDAs as Hashmaps

Mapping represents a set of key-value pairs, and is used to easily find information that is associated with a key. In Solana development, a PDA’s seeds and the correct strings can be used to achieve the same result. 

Let's go back to our previous wallet profile picture example.

Once a user selects their wallet’s PFP, the PFP program takes the selected image, the user’s address, and uses those as ‘seeds’ for creating a PDA that would store the user’s choice.

Once the Program Derived Address is successfully found by the hashing algorithm, its public key is ‘mapped’ to the user’s address and chosen NFT avatar.

The hashmap feature could be utilized even better by providing another PDA as a third seed. We can take all the available profile pictures and store them in a separate PDA, and we will pass each profile picture as its seed, and we end up with a PDA that stores all the profile pictures.

Now, when a user comes and picks their profile picture, the PDA will look like a hashmap because the seeds are passed so that if you look at them, you will know that out of a selection of profile pictures (the PFP group PDA), a user’s address that we passed as a first seed, has chosen the profile picture that we passed as the second seed. 

This example could be built upon to create even deeper hashmap structures.

A PDA as a hashmap program flow - NFT example

3. Cross Program Invocations

Cross Program Invocations (CPI) is the process of one program calling a function in another program. CPIs are useful because they allow for better code composability.

Going back to our example, let's say that a user wants to change their profile picture from a Degen Ape to a Solana Monkey Business avatar.

Here’s what happens under the hood:

Upon logging into their wallet, the core contract will take the user’s address (public key) and will look for an already created PDA, whose seeds include the user’s public key. 

After finding it, the core program will invoke a function in the PFP program called ‘changePFP()’ (this is a Cross-Program Invocation), which would accept the PDA that has already been ‘selected’ by the Core program as an argument. 

Once the function is called, the selected PDA will check if the account that is ‘asking’ for the change to happen is its parent. If the PDA is a mismatch the transaction will be rejected, because only a parent program can modify the data of a PDA. 

Since the PFP program is the parent of the selected PDA, it will be allowed to change the selected profile picture of the user from a Degen Ape to an SMB avatar.

Cross program invocation with PDA - Changing NFT images

Program Derived Addresses allow their parent programs to sign on their behalf and can be used to store a program’s state, hashmaps and in cross-program invocations. PDAs are a foundational topic in the realm of Solana programming that enable fast and efficient dApp development.

Program Derived Address FAQs

When working with Program Derived Addresses, it may be helpful to understand how Solana handles transactions and data. The two primary types of accounts are executable and non-executable.

What is an executable account?

Executable accounts, also known as programs, are similar to an Ethereum smart contract — a piece of code that changes its state when an account interacts with it.

What is a non-executable account?

Non-executable data accounts are simply used for storing data (e.g. the amount of SOL that the account owns, NFTs, token balances, etc.), essentially, the state variables of a program.

How is Solana program data storage different than Ethereum smart contracts?

One foundational difference between Ethereum and Solana is how the storage of executable code is organized. Smart contracts on Ethereum come ‘prebuilt’ with storage where the smart contract stores all its state variables. In comparison, programs on Solana do not have pre-built storage, but they have separate data accounts which hold the various state variables they want to store and reference.

Program Derived Addresses (PDAs) are accounts on the Solana blockchain that have special properties. Using PDAs properly can make Solana dApp development fast and efficient since they aid in cross-program communication. 

This article will explain PDAs, what they are, which problems they solve, how they work, and how they are different from other accounts in Solana's account model.

What is a Program Derived Address (PDA)?

A Program Derived Address is an account on the Solana blockchain that does not have a private key. Since a PDA is not a public key, the address of the account is found using the program ID, a SHA-512 hashing function, seed array, and a special bump seed.

What is a standard account on Solana?

A standard Solana account has both private and public keys (32 bytes each), and together they form a keypair, which is 64 bytes long and sits on an elliptic curve (ED25519). In order for the keypair to be valid it must lie on this curve. 

Here is a representation of an ED25519 Elliptic Curve:

ED25519 Elliptic Curve on Solana

How are program addresses derived?

PDAs require three main components:

  1. Parent Program ID - the ID of the parent program that creates the PDA
  2. Seeds - an array of strings*
  3. Bump Seed - makes sure that the PDA does not have a private key

Creating a valid Program Derived Address requires taking the ID of its parent program, the seeds array, and running them through a SHA-512 hashing function

In about 50% of the cases, however, the result of this hash is a keypair that lies on the ED25519 Elliptic Curve. Because PDAs do not have a private key, Program Derived Addresses must not lie on the elliptic curve. To prevent PDAs from having private keys, a special bump seed is used to “bump” the hash result off the curve. 

The bump seed is nothing more than a number, starting at 255. In the case where even with the bump seed, the hash result still resides on the curve, the hashing function is run again, with a bump equating to 254, then 253, etc. until the generated result is not on curve.

*Note: Seeds can be any arbitrary string, but developers use them in a context specific to the state variables of the parent program to create hashmap-like structures.

What problems do PDAs solve?

Program derived addresses streamline transaction confirmation by programmatically generating transaction signatures, thus helping trustless services like DeFi accounts to function seamlessly.

Here is a hypothetical example use case for PDAs.

Consider a Solana program that lets the user set an NFT as their default profile picture (PFP). The program will consist of two programs:

  1. The PFP program - creates accounts to store a user’s selected profile picture
  2. The Core program - acts as a proxy between the user’s inputs and the PFP program

For the PFP program to update a user’s selected profile picture, it would need to use its private key to sign a transaction that will change the user’s profile picture. However, this would also mean that the program would need to store its private key on-chain.

A Solana program cannot use its private key to sign a transaction on its own behalf, because the key itself would be stored on-chain, making it visible to everyone. If this happened, the private key could be used to sign transactions on behalf of the program and change the profile picture of any user.

Imagine that the PFP program was responsible for handling millions of SOL tokens. Such an exploit would become a major hack. Program Derived Addresses solve this.

Why are PDAs important?

Program Derived Addresses play an instrumental part in Solana programming because they aid the communication between different programs (Cross Program Invocations) and can act as a hashmap for storing specific data that its parent program can easily update and change.

1. Storing a Program’s State Variables

PDAs allow Solana developers to store and track a variable or a set of variables, related to a specific user. A PDA’s best use case is storing state variables or data for its parent program because by default it has authorized the parent program to make changes on its behalf.

2. Use PDAs as Hashmaps

Mapping represents a set of key-value pairs, and is used to easily find information that is associated with a key. In Solana development, a PDA’s seeds and the correct strings can be used to achieve the same result. 

Let's go back to our previous wallet profile picture example.

Once a user selects their wallet’s PFP, the PFP program takes the selected image, the user’s address, and uses those as ‘seeds’ for creating a PDA that would store the user’s choice.

Once the Program Derived Address is successfully found by the hashing algorithm, its public key is ‘mapped’ to the user’s address and chosen NFT avatar.

The hashmap feature could be utilized even better by providing another PDA as a third seed. We can take all the available profile pictures and store them in a separate PDA, and we will pass each profile picture as its seed, and we end up with a PDA that stores all the profile pictures.

Now, when a user comes and picks their profile picture, the PDA will look like a hashmap because the seeds are passed so that if you look at them, you will know that out of a selection of profile pictures (the PFP group PDA), a user’s address that we passed as a first seed, has chosen the profile picture that we passed as the second seed. 

This example could be built upon to create even deeper hashmap structures.

A PDA as a hashmap program flow - NFT example

3. Cross Program Invocations

Cross Program Invocations (CPI) is the process of one program calling a function in another program. CPIs are useful because they allow for better code composability.

Going back to our example, let's say that a user wants to change their profile picture from a Degen Ape to a Solana Monkey Business avatar.

Here’s what happens under the hood:

Upon logging into their wallet, the core contract will take the user’s address (public key) and will look for an already created PDA, whose seeds include the user’s public key. 

After finding it, the core program will invoke a function in the PFP program called ‘changePFP()’ (this is a Cross-Program Invocation), which would accept the PDA that has already been ‘selected’ by the Core program as an argument. 

Once the function is called, the selected PDA will check if the account that is ‘asking’ for the change to happen is its parent. If the PDA is a mismatch the transaction will be rejected, because only a parent program can modify the data of a PDA. 

Since the PFP program is the parent of the selected PDA, it will be allowed to change the selected profile picture of the user from a Degen Ape to an SMB avatar.

Cross program invocation with PDA - Changing NFT images

Program Derived Addresses allow their parent programs to sign on their behalf and can be used to store a program’s state, hashmaps and in cross-program invocations. PDAs are a foundational topic in the realm of Solana programming that enable fast and efficient dApp development.

Program Derived Address FAQs

When working with Program Derived Addresses, it may be helpful to understand how Solana handles transactions and data. The two primary types of accounts are executable and non-executable.

What is an executable account?

Executable accounts, also known as programs, are similar to an Ethereum smart contract — a piece of code that changes its state when an account interacts with it.

What is a non-executable account?

Non-executable data accounts are simply used for storing data (e.g. the amount of SOL that the account owns, NFTs, token balances, etc.), essentially, the state variables of a program.

How is Solana program data storage different than Ethereum smart contracts?

One foundational difference between Ethereum and Solana is how the storage of executable code is organized. Smart contracts on Ethereum come ‘prebuilt’ with storage where the smart contract stores all its state variables. In comparison, programs on Solana do not have pre-built storage, but they have separate data accounts which hold the various state variables they want to store and reference.

{{get-started-solana}}

Contact Us

Talk to an expert at Alchemy to answer all of your product questions.
Valid number
Thank you! Your submission has been received!
Oops! Something went wrong while submitting the form.

Build blockchain magic with Alchemy

Alchemy combines the most powerful web3 developer products and tools with resources, community and legendary support.

Get started for free