On May 20, 1862, Abraham Lincoln signed into law an unprecedented piece of legislation: the Homestead Act. With a pen stroke, he created a system where any American could lay claim to up to 160 acres of public land - a revolutionary idea that would transform the American West [1, 2].
Contrary to popular belief, settlers couldn't just create new plots or choose any spot they wanted. They had to discover valid claims within existing surveyed territories - plots that met specific government criteria. Using maps and survey markers, they searched for land that met specific requirements:
The plot had to be already surveyed and mapped by the government
It had to be unclaimed by any other settler
It had to fall within designated homesteading zones
It had to be exactly 160 acres - no more, no less
Only after finding such a plot could they begin the process of claiming it - filing an application, improving the land, living on it for five years, and "proving up" their claim.
The government didn't give them the deed directly - instead, they derived their ownership from meeting these predetermined conditions. Over 150 years later, Solana reinvented this concept for the digital age through what’s now known as Program-Derived Addresses (PDAs).
Program-derived Addresses
What are they? What’s their usefulness? How do you use them? When? If I'm new to Solana development, should I even care about PDA? What makes them so special that they're built into Solana's core design? Are they really as complicated as they seem? And why does every Solana tutorial eventually lead to that dreaded moment when PDAs enter the picture?
What exactly happens under the hood when we "derive" these addresses? How are they different from regular Solana accounts? If they are so essential, why aren't they more intuitive to understand? And most importantly—will learning about PDAs actually make me a better Solana developer, or is this just another technical rabbit hole? These, and many more, are the questions that will be answered in this article.
What you will gain from reading this article
By the time you are done, you will gain:
A clear, jargon-free understanding of PDAs that you can confidently explain to others
The mental model that makes PDAs click - no more confusion or guesswork
Real-world examples showing exactly where and why PDAs fit in Solana programs
The ability to identify when a program truly needs a PDA versus simpler alternatives
A step-by-step walkthrough of creating and using PDAs (with code you can actually understand)
Battle-tested patterns and practices that will save you hours of debugging
A foundation that makes advanced Solana concepts feel natural and intuitive.
Prerequisite: What you need to know
Basic blockchain concepts including public/private key pairs, digital signatures, transaction mechanics, and smart contract fundamentals
Solana fundamentals: Account model and how accounts store data, program structure and execution flow, transaction processing
Development requirements: Proficiency with TypeScript (Rust not required since Poseidon transpile TypeScript to Rust), comfort with command line operations
Key concepts: Understanding of deterministic functions, basic cryptographic primitives, experience with asynchronous programming patterns
Optional but helpful: Prior Solana program development experience, familiarity with the Anchor framework, understanding of cross-program invocation (CPI)
That said, let’s dive in…
How do you prove ownership on the Solana Blockchain?
In traditional Solana programs, the answer is simple: Cryptographic Keypairs.
Every account has a public address derived from a private key, and whoever holds that private key controls the account. Want to move tokens? Sign with your private key. Want to change account data? Sign with your private key. It's a beautiful system that's secured billions of dollars in assets.
When Programs Need to Be People
Now, think about every blockchain interaction you've ever made: sending tokens, minting NFTs, updating profile data. They all have one thing in common - a human with a private key signing the transaction. But what happens when you don't want people in the loop? What happens when programs themselves need to control accounts?
This seemingly simple question exposes a critical challenge in blockchain architecture. Programs are just code - they can't hold private keys or sign transactions like humans can. Yet in modern DeFi and Web3 applications, programs frequently need to:
Hold tokens in escrow during complex trades
Store shared program-state that no individual user should control
Manage communal resources like liquidity pools
Sign transactions to interact with other programs
The obvious solution?
It might seem to be: "Just create a keypair for the program!" But that immediately raises some uncomfortable questions:
Who gets custody of the program's private key?
How do you protect it from theft or compromise?
What happens if a key holder goes rogue?
How do you handle emergency key rotations?
You could try sophisticated solutions like splitting the key among trusted parties or implementing elaborate multi-signature schemes. But you're still just swapping blockchain's trustless security for trust in people. All it takes is one compromised laptop, one disgruntled team member, or one successful hack and your entire program could be at risk.
This exposes the core problem with using traditional keypairs for program-controlled accounts: they're designed for human users, not autonomous code. Nevertheless, programs need a way to control accounts and sign transactions that don't depend on private keys.
This is the problem PDAs solve
Thanks to Program Derived Addresses (PDAs), Solana blockchain programs gained a powerful way to control accounts without relying on private keys. These addresses emerge from a deterministic process using seeds. Seeds are typically public information like user IDs or trade parameters.
//
//
//
Since anyone can derive these addresses using the same seeds, there's no need for central databases or registries. The mathematics of PDAs themselves create an elegant, self-organizing system.
This innovative approach revolutionized how we build on Solana
Now, the Escrow program can instantly locate accounts for any trade, while gaming platforms can derive addresses for player stats directly from their IDs. Social networks can generate post addresses from user and content identifiers, and Vaults can find each user's deposit account through their wallet address.
The system works through a careful combination of the program's ID, identifying-seeds, and a special number called a bump. This ensures addresses remain deterministic - the same inputs always find the same accounts - while guaranteeing they are unique and "off the curve,".
"off the curve," is how to ensure it’s impossible for normal keypairs to control. Only the program that discovered a PDA can authorize operations on it by proving it has the original seeds.
The genius lies in removing human keyholders from the equation entirely.
In the same way that Homesteaders had to find plots meeting government criteria, programs must discover addresses that satisfy specific cryptographic requirements. And just as homesteaders couldn't create new land but had to locate existing valid plots, programs don't create PDAs - they find them within Solana's mathematical space.
This simple but powerful innovation has become the foundation for how programs safely manage assets and data on Solana. The parallel to the Homestead Act runs deep - both systems created organized frameworks for claiming and controlling resources, transforming the chaotic challenge of account management into a structured, deterministic space where everything has its proper place - and anyone can find it.
So let's explore how to stake these claims with Poseidon...