DEV Community: Samuel Emmanuel

Program Derived Addresses (PDAs): The Solana Feature Every Web2 Developer Should Understand

Samuel Emmanuel — Mon, 29 Jun 2026 15:16:05 +0000

If you're coming from a Web2 background, one of the first things that feels strange about Solana is that applications don't always create accounts using private keys.
Instead, they often use something called a "Program Derived Address (PDA)".

At first, that sounded complicated to me.
After building several Anchor programs during my #100DaysOfSolana challenge, I realized PDAs aren't magic at all they solve a problem that every backend developer already understands.

Let's look at them through a Web2 lens.

How We Usually Think in Web2

Imagine you're building a SaaS application.

You have a table like this:

User ID	Counter
101	5
205	12
318	0

Whenever a request arrives, you already know the user's ID.

You don't generate a random database key every time. Instead, you derive which row belongs to the user.
Your application always knows exactly where that user's data lives.

The Problem on Solana

My first Anchor counter program didn't work like that.

To create a counter, I generated a brand new keypair for the account. That worked... but it meant the client had to remember that keypair forever.
Lose it, and you lose the ability to easily locate your counter account.
That approach is fine for tutorials but not for real applications.

Enter Program Derived Addresses

A PDA is an account whose address is deterministically derived from:

one or more seeds
your program ID
a bump value For example:

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

Every time the same user calls the program, Anchor derives the exact same address.

No database lookup.
No random account generation.
No extra storage needed to remember where the account lives.

The Web2 Analogy

Imagine this function:

getCounter(userId)

Internally your backend might do:

SELECT *
FROM counters
WHERE user_id = ?

The user ID uniquely identifies the row.

PDAs work almost the same way.
Instead of looking up a database row, Solana derives an account address from predictable inputs.

It's closer to computing a deterministic primary key than generating a UUID.

Why This Is Powerful

Suppose Alice opens your app.

Anchor derives:

("counter", Alice)

Bob opens the app.

Anchor derives:

("counter", Bob)

Both users automatically get different accounts.

No collisions.
No bookkeeping.

Your program always knows where each user's state belongs.

Where Anchor Helps

One thing I really appreciate about Anchor is how much boilerplate disappears.
Instead of manually checking addresses, ownership, and account creation, you simply declare constraints:

#[account(
    init,
    payer = user,
    seeds = [b"counter", user.key().as_ref()],
    bump
)]

Anchor then:

derives the PDA
computes the canonical bump
creates the account
allocates storage
makes the program sign for it

All before your instruction handler even runs.

Security Comes from Constraints

Another thing that clicked for me was that authorization often lives in account constraints rather than business logic.
For example:

#[account(
    has_one = user
)]

#[account(
    constraint = !config.paused
)]

Instead of writing lots of validation code inside the handler, Anchor verifies everything first.
If validation fails, the transaction never reaches your business logic.
As a backend developer, it reminded me of middleware that rejects unauthorized requests before your controller executes.

The Bigger Picture

One thing the Solana journey has taught me is that blockchain development isn't about throwing away Web2 knowledge.

It's about applying familiar backend concepts in a different environment.
Database rows become accounts.
Primary keys become deterministic addresses.
Middleware becomes account constraints.

Tables become on-chain state.
Once I started viewing Solana through concepts I already understood, everything became much easier to reason about.

What I'm Building

This article is based on one of the programs I built during my #100DaysOfSolana challenge.

The project evolved from:

a simple counter
to stateful accounts
to authorization with has_one
to negative testing with LiteSVM
to per-user PDAs
to configuration PDAs
to reclaiming rent by closing PDA accounts

Each step felt surprisingly familiar once I translated it into Web2 concepts.

Final Thoughts

If you're a Web2 developer curious about Solana, don't start by trying to memorize blockchain terminology.
Instead, ask:

"What problem is this solving that I already solve every day?"
More often than not, there's a familiar backend concept hiding underneath.

That's what finally made PDAs click for me.

Thanks for reading!

I'm documenting my learning journey through #100DaysOfSolana, sharing what I build and translating blockchain concepts into language that backend developers already understand.

If you're learning Solana too, I'd love to connect and learn together.

My Solana Learning Journey So Far 🚀

Samuel Emmanuel — Tue, 02 Jun 2026 09:55:08 +0000

Over the past few days, I've been diving into Solana development, and it's been a fascinating shift from traditional web development. I've built wallets, worked with keypairs, explored SOL and lamports, connected browser wallets using the Wallet Standard API, and interacted with both Devnet and Mainnet through RPC calls.

One thing that surprised me was how identity works in Web3. In Web2, we're used to usernames, emails, and passwords. In Solana, your identity is essentially a cryptographic keypair, and wallet extensions handle authentication without exposing private keys to applications. That was a major mindset shift for me.

What really clicked was understanding that most blockchain interactions are just requests to a network. Once I started using RPC endpoints to fetch balances, transaction history, and account data, the blockchain felt much less mysterious and more like a distributed system that exposes APIs.

What's still a bit confusing is the deeper relationship between accounts, programs, and how on-chain data is structured. I understand the basics, but I'm looking forward to learning more about Solana programs and seeing how everything fits together when building full decentralized applications.

Overall, the journey has been both challenging and rewarding. Every day I gain a better understanding of how blockchain applications work under the hood, and I'm excited to keep building and exploring the Solana ecosystem.

Day 7 of my Solana learning journey

Samuel Emmanuel — Mon, 01 Jun 2026 14:12:00 +0000

Today, I built a Solana web application that connects to browser wallet extensions using the Wallet Standard API. The application can discover compatible wallets, connect securely with user permission, and retrieve wallet account information without ever handling private keys.

One of the biggest shifts from traditional web development has been realizing that wallet extensions manage identity and authentication. Instead of creating accounts with usernames, emails, and passwords, users authenticate through cryptographic wallets that they control.

This project gave me a deeper understanding of how Web3 applications interact with users while maintaining security and ownership of private keys.

Next, I'm excited to move beyond wallet connections and balance checks and start building full-featured Web3 applications on Solana, including creating and signing transactions.

SSH Keys, But for the Internet: Understanding Identity on Solana

Samuel Emmanuel — Wed, 27 May 2026 12:49:24 +0000

If you’ve spent years building in Web2, the idea of “identity on a blockchain” can sound strange at first. Where are the usernames? The login forms? The OAuth providers?

On Solana, identity works very differently but there’s a good chance you already understand the core idea without realizing it.

Think about SSH keys.

When you SSH into a server, you don’t type “who you are” every time. Instead, you prove ownership of a private key. The server trusts the corresponding public key, and that cryptographic relationship becomes your identity.

Solana works almost exactly the same way.

Your keypair is your identity
In Solana, identity starts with a keypair:

A private key that only you control
Public key that everyone can see When you create a wallet, you are really generating a cryptographic identity. Your public key becomes your address on the network. It looks something like this: 14grJpemFaf88c8tiVb77W7TYg2W3ir6pfkKz3YjhhZ5, That’s not a username stored in a database. It’s a 32-byte Ed25519 public key encoded in Base58.

Base58 exists for practical reasons:
It removes visually confusing characters like 0, O, I, and l
It avoids punctuation that breaks copying and URLs
It makes addresses safer for humans to handle
Under the hood, though, it’s still just a public key.

The network replaces the company
In Web2, identity is usually managed by a company.
Your Twitter account exists because Twitter’s database says it exists.
Your access depends on:
Email/password records
Session tokens
OAuth providers
Admin systems
Ultimately, the platform decides whether your account is valid.
Solana removes that middle layer.
There is no central database saying “Alice owns this account.” Instead, ownership is proven cryptographically.

If you can produce a valid signature using the private key, the network accepts that you are the owner.
That’s it.
No support ticket.
No password reset.
No admin override.
This is one of the biggest mindset shifts for Web2 developers: identity is not granted by an application. Identity is derived from cryptographic control.

Accounts on Solana are more like containers
Another important difference is that Solana’s accounts are not “user profiles.”
On Solana, everything lives inside accounts:
Wallet balances
Program state
Smart contracts
NFTs
Governance records
Accounts are the fundamental storage units of the network.
Your keypair controls some of those accounts by signing transactions.

If you’re coming from backend development, think of it this way:
In Web2:
Your app owns the database
Users authenticate against your system
Your backend decides permissions

In Solana:
The blockchain is the shared database
Users authenticate with signatures
Programs verify permissions cryptographically
Instead of checking:
if (session.user.id === post.ownerId)
A Solana program checks whether the transaction was signed by the expected public key.
The trust model moves from application logic to cryptographic proof

Identity becomes portable
This is where things get interesting.
In Web2, your identity is fragmented:
GitHub knows one version of you
Discord knows another
Stripe knows another
None of them automatically trust each other

On Solana, the same identity works everywhere on the network.
One wallet can:
Hold tokens
Vote in governance systems
Trade NFTs
Interact with DeFi protocols
Build on-chain reputation
Sign into apps

And no application has to ask another application for permission.
That portability is possible because the identity layer is shared infrastructure.

Signing replaces logging in
A useful mental model is this:
Web2 apps ask:
“Do you know the password?”
Solana asks:
“Can you prove ownership of this key?”
That proof happens through digital signatures.
When your wallet signs a transaction:

The transaction data is hashed
Your private key signs the hash
The network verifies it using your public key The private key never leaves your wallet, but the network can still verify ownership mathematically.

This is why wallets matter so much in crypto. They are not just payment apps — they are identity providers.

The tradeoff: freedom and responsibility
This model gives users something rare on the internet: true ownership.
But it also removes safety nets.
If a company controls identity, they can restore access.
If you control identity, losing the private key usually means losing access permanently.

That tradeoff is intentional.
Solana’s identity model prioritizes self-custody over recoverability.
For Web2 developers, this can feel uncomfortable at first because we are used to centralized account recovery systems. But it also unlocks something powerful: users no longer need permission from a platform to exist online.

Their identity belongs to them.

And on Solana, that identity is simply a keypair.

Is Learning to Code Still Worth It in the AI Era?

Samuel Emmanuel — Sun, 24 May 2026 01:37:04 +0000

With AI tools becoming more powerful every day, many beginners are wondering if learning programming is still worth it.
Do you think AI will replace some developer jobs, or will it simply make developers more productive?

I’d love to hear your thoughts and experiences 👇

Hello DEV! 👋🏽 My Developer Journey Begins

Samuel Emmanuel — Sat, 16 May 2026 17:58:58 +0000

Hello DEV 👋

Hi everyone! I'm new here and excited to join the DEV Community.

I'm currently learning software development and exploring areas like web development, AI, and open-source technologies. I enjoy building small projects, learning new tools, and improving my coding skills every day.

I joined DEV to connect with other developers, share my learning journey, and learn from the community.

Looking forward to growing with you all 🚀