DEV Community: Akeem Palmer

What I learned about PDAs in a week of building on Solana

Akeem Palmer — Tue, 11 Aug 2026 03:14:01 +0000

If you come from a Web2 background, one of the hardest things to understand about Solana is that programs are stateless. In a typical backend application, you might keep user information in a database row, a session store, Redis, or some other persistent layer. A Solana program cannot simply hold that data in memory between transactions.

That is the problem Program Derived Addresses (PDAs) solve.

A PDA is a deterministic account address derived from:

one or more seeds,
your program ID, and
a small extra byte called the bump.

The PDA itself is not the state. The state lives in an account stored on-chain at that PDA.

The mental model

The closest Web2 analogy I found is this:

A PDA is like a database primary key that can be computed from the logical identity of the record.

For example, if you were building a SaaS app, a user profile row might be identified by:

("profile", user_id)

On Solana, the equivalent idea is:

[b"profile", user.key().as_ref()]

The important difference is that there is no central database table managing these keys. The address is derived on demand from the seeds and the program ID, and an account may or may not exist there yet.

Anatomy of a PDA derivation

Here is the pattern from my counter program:

#[account(
    init,
    payer = user,
    space = 8 + Counter::INIT_SPACE,
    seeds = [b"counter", user.key().as_ref()],
    bump
)]
pub counter: Account<'info, Counter>,

Let’s break this down.

`b"counter"`

A static seed prefix. This namespaces the PDA so it does not collide with other PDAs in the same program.

`user.key().as_ref()`

A dynamic seed based on the wallet interacting with the program.

`seeds = [...]`

Anchor hashes the seeds together with the program ID to derive the PDA.

`bump`

The runtime searches for a one-byte value that produces an address outside the Ed25519 curve. Because the resulting address has no corresponding private key, only the program can sign for it using the same seeds.

That last point was the biggest mental shift for me: PDAs are intentionally un-signable by wallets.

Why the seeds matter

These two derivations look similar but behave very differently.

Per-user PDA

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

Every wallet gets a different counter account.

Global PDA

seeds = [b"counter"]

Every wallet resolves to the same PDA.

That second pattern is useful for things like:

protocol configuration,
treasury metadata,
global admin settings.

It would be a terrible choice for a per-user counter because all users would be mutating the same account.

Authorization through constraints

This is the close instruction from my program:

#[derive(Accounts)]
pub struct CloseCounter<'info> {
    #[account(
        mut,
        close = user,
        seeds = [b"counter", user.key().as_ref()],
        bump = counter.bump,
        has_one = user,
    )]
    pub counter: Account<'info, Counter>,

    #[account(mut)]
    pub user: Signer<'info>,
}

What surprised me is that most of the authorization happens before my handler runs.

Anchor automatically checks that:

the PDA was derived from the expected seeds,
the bump matches the stored bump,
the counter.user field equals the provided signer.

If any of those checks fail, the transaction is rejected before the business logic executes.

That feels much closer to declarative authorization than the manual guard clauses I usually write in backend APIs.

What the bump buys you

A common misconception is that the bump is some kind of random nonce.

It is not.

find_program_address tries bump values from 255 down to 0 until it finds a derivation that is not on the Ed25519 curve. The first valid value is called the canonical bump.

In practice:

pub bump: u8,

is often stored inside the account so later instructions can reuse it:

bump = counter.bump

This avoids re-deriving the PDA every time and guarantees you are using the same canonical derivation that was used during initialization.

The full lifecycle

The pattern I ended up using throughout the week was:

1. Derive

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

2. Initialize

#[account(init, payer = user)]

This creates the on-chain account and allocates rent-exempt storage.

3. Mutate

Subsequent instructions load the PDA account and update its fields.

4. Close

close = user

Closing does not mean “delete a row from a database.”

It means:

transfer the account’s lamports (Solana’s smallest unit) to another account,
zero out the data,
mark the account for cleanup at the end of the transaction.

That distinction matters because account storage on Solana is fundamentally tied to lamports funding the account’s existence.

What I would tell past me

A few things I wish I understood on Day 64:

The program ID is part of the derivation. The same seeds in a different program produce a completely different PDA.
PDAs cannot sign transactions by themselves. Programs sign on their behalf using the same seeds and bump.
Store the bump in the account. It makes later instructions simpler and more reliable.

The takeaway

The biggest insight from this week is that PDAs are not a storage mechanism. They are a deterministic addressing scheme for Solana accounts.

Once I stopped thinking of them as “special accounts” and started thinking of them as program-owned, reproducible addresses derived from business logic, the entire Anchor model became much easier to reason about:

logical identity
        ↓
seeds + program ID
        ↓
PDA
        ↓
on-chain account stored at that address

That is the mental model I took away from working with PDAs this week.

How I Built a Counter Program in Rust and Learned to Trust My Tests

Akeem Palmer — Sun, 09 Aug 2026 03:13:15 +0000

Building smart contracts on Solana using Rust and the Anchor framework requires a mindset shift from traditional Web2 backends. This week, I built a counter program, broke it on purpose, and used my test suite to verify that my security constraints were truly load-bearing.

Here is how the program works under the hood and why every test in the suite exists.

The Initialize Accounts Struct

In Anchor, security boundaries are enforced before your instruction logic ever runs. The Initialize context defines three main accounts:

counter: Initialized as a new on-chain account allocated with exact bytes (8 bytes for Anchor's discriminator, 32 for the authority's public key, and 8 for the count value).
authority: Marked as a mutable signer who pays the account creation rent.
system_program: The native Solana System Program required to execute account creation.

Handler Logic & Constraints

Because Anchor handles account creation and validation in the background, handler logic remains minimal.

Initialize Handler
The initialize handler receives the context, sets the counter account's authority field to match the transaction signer's public key, and sets the initial count state to zero.

Increment Instruction with Constraints
For the increment logic, Anchor uses an account constraint: has_one = authority, directly on the account context. This guarantees that the key in counter.authority matches the signer's wallet before any custom code executes. If an unauthorized wallet attempts to trigger an increment, Anchor rejects the transaction immediately at the constraint level.

Testing the Happy and Failure Paths

To prove these security checks work, I wrote unit tests for both valid execution and unauthorized attempts using LiteSVM.

1. Happy Path: Successful Initialization

The Test: Executes the initialize instruction and asserts that the fetched account's count value equals zero.
Why it exists: If space allocation fails or account deserialization breaks, this test fails because the on-chain state won't reflect the expected starting value.

2. Failure Path: Unauthorized Increment Attempt

The Test: Attempts to trigger the increment instruction using an unauthorized attacker keypair, expecting the call to throw a ConstraintHasOne error.
Why it exists: If someone accidentally removes the has_one = authority check from the struct, this test fails, warning us that arbitrary wallets can mutate state they don't own.

Planting Bugs to Test the Tests

A test suite that passes isn't helpful unless it fails when the program breaks. To test my harness, I deliberately introduced a bug by changing the counter increment logic from adding 1 to adding 2 in the handler.

When running the test suite, it immediately caught the regression, throwing an assertion error showing an expected result of 1 against an actual result of 2.

Seeing the assertion catch the precise mutation gave me complete confidence that my test suite was active and load-bearing rather than just passing silently.

What’s Next

Writing this post highlighted a gap in my understanding around program derived addresses (PDAs). We will continue working with PDAs and Rust.

Understanding Solana Token-2022: Transfer Fees, Interest-Bearing Tokens, & Non-Transferable

Akeem Palmer — Fri, 24 Jul 2026 03:58:40 +0000

This week, I took a deep dive into Solana Token-2022 (also known as Token Extensions or spl-token-2022).

If you're building on Solana, you've likely heard about Token-2022, but what actually is it?

In short, Token Extensions are protocol-level configurations enabled directly on a token's Mint Account. Because these configurations exist at the mint level, every token account created under that mint automatically inherits those rules.

The best part? You get advanced features natively out of the box, without having to write custom Rust smart contracts (programs) to handle complex token logic.

In this post, we'll explore three popular token extensions: Transfer Fee, Interest-Bearing, and Non-Transferable.

1. Transfer Fee Extension

The Transfer Fee Extension allows token issuers to automatically collect a fee whenever tokens are transferred between accounts.

Because the fee check happens at the base protocol level, it's impossible for secondary transfers or dApps to bypass it. Fees are configured using basis points (where 100 basis points = 1%).

Primary Use Case: Payments & Treasuries

If your protocol or merchant accepts your native token as payment, you can set a transfer fee where a small percentage of every transaction is automatically routed to a designated authority or treasury account.

2. Interest-Bearing Extension

This extension brings native yield mechanics on-chain, allowing tokens to dynamically accumulate interest over time simply by residing in a wallet.

What makes this extension fascinating is how the balance calculation works under the hood:

How Interest Calculation Works:
Suppose you transfer 500 coins to John's wallet. John's on-chain raw balance remains exactly 500. Over six months, John's balance visually increases in the UI based on the set interest rate, but the raw balance on-chain never changes until a state transition occurs.

Solana calculates the visual display balance dynamically using three key variables:

Original Timestamp: When the raw balance was last updated.
Current Timestamp: When the balance UI/RPC is queried.
Interest Basis Rate: The configured interest rate.

The actual interest is only settled on-chain when the tokens are moved or touched.

3. Non-Transferable Extension

For developers working in industries where KYC/KYB compliance is critical, this extension provides an elegant protocol-level solution.

By enabling this tag, a token becomes permanently tied to the recipient wallet upon minting (similar to a "Soulbound Token"). It cannot be transferred to any other address under any condition.

Primary Use Case: Compliance & Credentials

On-chain KYC/KYB identity badges
Non-transferable event tickets or educational certificates
Corporate credentials and soulbound access tokens

Combining Extensions: Enforcing Protocol Policies

The real superpower of Token-2022 is stacking extensions. You can combine multiple configurations on a single mint to build complex behavior without writing custom Rust code.

However, the combination must make logical sense:

Valid Stack: Transfer Fee + Interest Bearing = Yield-generating payment token that collects a fee on transfer.
Invalid/Redundant Stack: Transfer Fee + Non-Transferable = Unnecessary, because a token that cannot be transferred will never trigger a transfer fee.

Conclusion

Solana's Token Extensions significantly reduce development overhead while increasing protocol level security. Enforcing complex token policies directly at the mint level, without custom smart contracts opens up huge possibilities for Web3 devs.

Are you using Token-2022 in your project? Let me know in the comments which extensions you're building with!

My First Look at NFTs on Solana

Akeem Palmer — Sun, 28 Jun 2026 23:56:45 +0000

When I first heard about NFTs, I assumed they were just randomly generated JPEG collections—mostly apes and profile pictures that became valuable because of hype. After building one on Solana, I realized an NFT is much more than an image. It's simply a token with a unique set of rules.

Coming from a Web2 background, my biggest question was: What actually makes an NFT an NFT? I expected there to be a special NFT object. Instead, I learned that on Solana, an NFT is just a token configured with the right properties and metadata.

An NFT (Non-Fungible Token) is unique because it cannot be exchanged one-for-one like a cryptocurrency. To create one on Solana, the token typically has a supply of 1, uses 0 decimals so it cannot be divided into fractions, and has its mint authority removed after minting so no additional copies can be created. Metadata gives the NFT its identity by storing information such as its name, description, image, and collection.

Before the introduction of Token Extensions, most NFT projects relied on Metaplex, an open-source protocol that simplified creating and managing NFTs on Solana. It provided standards for metadata, collections, and creators, making it the foundation for many NFT projects.

One of the biggest things I learned this week is that Solana's Token Extensions now allow many of these features to be built directly into the token itself. Instead of depending entirely on external frameworks, developers can attach extensions that add new functionality while remaining compatible with the Solana ecosystem.

Some of the extensions I explored include the Metadata Extension, which stores information about the NFT, the Group and Group Member extensions for collections, and other extensions that introduce additional business logic.

The biggest surprise for me was realizing that NFTs are not a completely different asset type. They are simply tokens with specific rules and metadata. Once I understood that mental model, the entire NFT ecosystem became much easier to understand.

This project changed the way I look at Solana development. Instead of seeing NFTs as digital collectibles, I now see them as programmable digital ownership that can be used for tickets, memberships, certificates, gaming assets, and many other real-world applications.

A Deep Dive Into Building Compliance-Gated Tokens with Solana Token Extensions

Akeem Palmer — Wed, 17 Jun 2026 00:27:55 +0000

Building on Solana can massively simplify your application logic once set up correctly. Solana’s Token Extensions Program streamlines development by providing native, customizable features directly at the protocol level. As the Solana documentation states, it "provides more features through extra instructions referred to as extensions."

Let’s break down exactly what this means and how you can leverage it for compliance-gated assets.

The Fundamentals: Mints, Authorities, and Minting

Before diving into extensions, we need to align on three foundational terms:

Mint Account: An account owned by the Solana SPL Token Program. It doesn’t hold tokens itself; instead, it acts as the global "source of truth" for a token's configuration (e.g., total supply, decimals).
Mint Authority: The entity (wallet or program) with the power to increase the token supply by generating new units against the Mint Account. Think of it like a central bank or an issuing body.
Minting: The actual process of generating new units of a token, which directly increases the total supply.

When you initialize a token on Solana; for instance, using the Command Line Interface (CLI), you can pass specific "tags" or arguments. These tags tell the network, "Hey, I want to enable this specific feature for this token." That is exactly what Token Extensions are.

Crucial Note: A token’s extensions must be defined at the moment of creation. Once the Mint Account is initialized, you cannot add or remove extensions.

Key Extensions for Compliance and Control

While the Token Extensions Program supports a wide array of features; including native metadata configuration (like setting your token's name, symbol, and image asset), it shines brightest when used to enforce compliance.

Here are four powerful extensions to know:

1. Non-Transferable Tokens

This extension locks tokens to the account they are originally minted to, making them completely non-transferable between users.

How it works: While they can't be traded, they can still be minted by the authority, burned (destroyed) by an authorized entity, or closed entirely once the balance hits zero.
Use Cases: Non-transferable loyalty points, achievement badges, or identity-bound credentials.

2. Interest-Bearing Tokens

This feature allows a mint to store an annualized interest rate directly on-chain.

How it works: It’s important to note that this does not continuously inject new tokens into user accounts. The raw token balance stays the same. Instead, the UI amount adjusts over time to reflect the accumulated interest.
Use Cases: Real-world assets (RWAs), bonds, or compounding financial instruments.

3. Immutable Owner

By default, Solana allows a token account's ownership to be transferred to another wallet. The Immutable Owner extension permanently locks the account to its original owner.

Why it matters: It prevents users from accidentally or maliciously bypassing transfer restrictions by simply trading the underlying wallet account structure.

4. Transfer Hooks & Permanent Delegates (Delegation)

This acts as the ultimate gatekeeper for your token ecosystem. By establishing a permanent delegate or a transfer hook, the mint-level authority can enforce custom validation rules for every single transfer or burn.

How it works: The authority retains the right to freeze, transfer, or burn tokens if a user violates platform policies.
Use Cases: Regulated securities, compliance-gated enterprise tokens, or professional certifications that can be revoked if a holder breaks industry rules.

Conclusion

The Solana Token Extensions Program is an incredibly potent tool for developers. By baking common guardrails, compliance rules, and financial logic directly into the token mint itself, you eliminate the need to write complex, risky custom smart contracts.

As I dive deeper into the Solana ecosystem, I’ll be sharing more architectural deep dives. Thanks for reading!

What do you think?

Are you building with Token Extensions? Which extension do you find most useful for your project? Let's discuss in the comments!

Demystifying Solana Mints and Token Extensions: A Web2 Developer’s Perspective

Akeem Palmer — Sun, 07 Jun 2026 03:07:13 +0000

Transitioning from a traditional Web2 background into the blockchain space can feel daunting, but completing days 29 through 33 of the Solana 100 Days Challenge completely shifted my perspective. On Solana, digital assets are deployed using the Solana Program Library (SPL). These can be fungible assets (like standard utility tokens or stablecoins) or non-fungible tokens (NFTs). As a software engineer getting my hands dirty with Web3 architecture for the first time, seeing these building blocks click together has been incredibly exciting.

Here is my breakdown of how tokens actually function under the hood on Solana.

1. The Mint Account: The Blueprint

We kicked off the challenge by creating a Mint Account using the newer Token-2022 Program (also known as the Token Extension Program). If you are coming from Web2, the easiest mental model is to think of the Mint Account as a locked filing cabinet or a master blueprint. This account does not actually hold your token balance; instead, it defines the global rules for the asset, such as the total supply, the number of decimals, and the authorized public keys allowed to mint or freeze the tokens.

By leveraging Token Extensions, we can natively bake metadata (like the token name, symbol, description, and image URI) directly into the mint initialization transaction.

One of the coolest extensions we experimented with is the --enable-non-transferable flag. When you pass this flag during creation, the mint permanently restricts the token from ever moving between wallets. It creates a "soulbound" asset perfect for digital certificates, achievement badges, or KYC verification records.

The catch? This rule is immutable; you can only configure it at the exact moment the mint is deployed, and it can never be reversed. On the flip side, leaving this flag off creates standard transferable tokens, which form the backbone of everyday Web3 currencies and stablecoins.

2. Token Accounts: The Folders Inside the Cabinet

If the Mint Account is the master blueprint, how do we actually track who owns what? This is where Token Accounts (and specifically, Associated Token Accounts, or ATAs) come into play.

Think of a Token Account as an individual folder placed inside our main filing cabinet. The folder is explicitly mapped to a specific user's wallet address. While the Mint Account coordinates the asset's rules, your actual token balance sits safely inside your unique Token Account.

Before you can mint new supply or receive a transfer from someone else, that specific Token Account folder must be initialized on-chain. This structural segregation of data is what allows Solana to process transactions in parallel at lightning speeds, keeping assets secure and organized.

3. Execution: Minting, Burning, and Moving Assets

Once your data accounts are active, you can interact with the Token-2022 program to manage the asset's lifecycle based on its initialized extensions:

Non-Transferable Tokens: The mint authority can issue tokens to a user's wallet folder, and the owner can safely burn (destroy) them if they expire or need to be revoked. However, attempting to send them to a friend will result in an immediate program-level rejection.
Transferable Tokens: When you transfer tokens to a public wallet, the network routes the assets from your folder into theirs. If the recipient doesn't have a folder yet, a new Associated Token Account must be opened for them before the transfer can clear.

Conclusion

Stepping through these operations made it clear how powerful Solana's architecture is. Instead of writing complex, risky custom smart contracts to handle basic asset behaviors, the Token-2022 Program allows us to implement enterprise-grade logic right out of the box using clear, concise program extensions.

Understanding Solana Accounts: The Blockchain Filesystem

Akeem Palmer — Tue, 02 Jun 2026 05:12:54 +0000

If you want to understand how Solana works under the hood, you have to understand accounts.

I like to think of the Solana blockchain as a distributed operating system, where every account is simply a file on a filesystem. Unlike traditional Web2 architectures where applications live on a server and data lives in a database, Solana stores everything using a unified file-type system.

Here is a breakdown of how these "files" work, what they contain, and how they shape the network.

The 5 Anatomy Fields of a Solana Account

Every single account on Solana shares the exact same five-field structure. This structure is mapped to a 32-byte address, ensuring it aligns perfectly with IPv6 minimum MTU requirements.

Lamports: The account's SOL balance, where 1 SOL = 1,000,000,000 lamports.
Data: A byte array that stores arbitrary state. For a wallet, this might be token balances; for a program, it stores the executable byte code.
Owner: The specific program that controls the account (for most standard wallets, this is the System Program). Only the owner program can modify an account’s data or debit its lamports.
Executable: A binary flag (true/false) that tells the network whether the account can execute code and instructions.
Rent Epoch: A legacy field (now deprecated) previously used to track the balance an account needed to maintain to avoid paying storage rent. Today, almost all accounts are loaded with enough SOL to be permanently rent-exempt.

The Two Main Categories: Logic vs. Data

Solana strictly separates code from data. Because of this, accounts broadly fall into two categories:

1. Executable Accounts (The Apps)

These accounts have their executable flag set to true. They contain smart contract code (program logic) stored directly on the blockchain that automatically runs when specific conditions are met. Think of these as the applications or software running on the OS.

2. Non-Executable Accounts (The Databases)

These accounts cannot execute code. Instead, they store data-such as balances, user info, or state-that executable programs read from and write to. Think of these as the databases or storage files used by the apps.

The Four Functional Account Types

To make development practical, these categories are split into four functional types that you interact with daily:

Account Type	Description	Web2 Analogy
System Accounts	Regular user wallets (e.g., Phantom or Solflare). They hold your SOL balance and do not execute code.	Your personal bank account
Program Accounts	Accounts that store compiled smart contract logic. They dictate how things work but don't hold user state.	The application software
Data Accounts	Accounts managed by programs to store specific information like user profiles, token balances, or settings.	A database row or file
Sysvars (System Variables)	Special global accounts that provide real-time network info (e.g., current time, fees, slot data).	The system clock / OS settings

The Big Picture: Everything is a File

By looking at Solana through the lens of an operating system, the architecture becomes incredibly intuitive. Every account is just a file, and each file consists of two things:

Metadata: Who owns it, whether it can execute code, and how much money (lamports) it holds.

Contents: The actual data or program code stored inside.

In Solana, programs act on accounts rather than possessing their own internal memory. By treating everything as a unified file system, Solana achieves incredible speed, transparency, and composability.

Solana Transactions Explained for Backend Developers

Akeem Palmer — Mon, 18 May 2026 01:34:24 +0000

Before starting this challenge, I went from knowing next to nothing about Web3 transactions to being able to break down and extract granular details from the Solana ledger. That is progress.

As backend developers, we are deeply familiar with how data moves in traditional systems. In this post, I will break down Solana transactions using the mental models we already use every day, and look at how they differ from the standard Web2 API calls we are used to.

Reframing the Architecture: From Private Servers to Shared State

Before diving into Solana, let’s ground ourselves in Web2. An API (Application Programming Interface) is how we communicate between systems-whether via HTTP, gRPC, WebSockets, or SOAP. These communication techniques fundamentally rely on private servers, centralized databases, and authentication tied to a single entity's environment.

Web3 completely flips this paradigm. In Web3, the blockchain operates as a decentralized, public, globally shared state machine. Because there is no single authoritative server, any action that mutates this state must be atomic. If you have ever written a complex database transaction where multiple queries must either all succeed or all roll back together, you already understand the core execution model of Web3.

What is a Solana Transaction?

According to the official Solana documentation:

"A transaction includes one or more instructions, the signatures of accounts that authorize the changes, and a recent blockhash. The network processes all instructions in a transaction together. If any instruction fails, the entire transaction fails and all state changes are reverted."

If we map this directly to Web2, a Solana transaction is the functional equivalent of an API request designed to trigger an atomic state change on a database.

Mapping the Data: Solana vs. HTTP

To make this granular, let’s look at how a Solana transaction structure maps to a standard HTTP request:

Solana Transaction Component	Web2 HTTP Equivalent	Purpose / Function
Transaction Signatures	Auth Headers / JWT / API Keys	Proves identity and cryptographic authorization to mutate data.
Transaction Message	HTTP Request (Headers + Body)	The container holding the state change instructions and metadata.
Instructions	HTTP Request Body / Payload	The specific business logic execution (e.g., calling a specific function with arguments).
Account Keys	Database Keys / URL Route Params	Explicitly declares which records/accounts will be read from or written to.
Recent Blockhash	Idempotency Keys / Nonce / TTL	Prevents replay attacks and acts as a time-to-live mechanism for the request.

The Network Layer: Why Solana is High-Performance

As backend engineers, we are used to treating network bandwidth as relatively cheap. A typical HTTP header alone can easily exceed 1,000 bytes due to bloated cookies, user-agent strings, and verbose metadata.

Solana operates under strict architectural constraints. A Solana transaction is strictly limited to 1,232 bytes. This size isn't arbitrary; it is designed to fit perfectly within the IPv6 MTU (Maximum Transmission Unit) size limit of 1,280 bytes, leaving exactly 48 bytes for network packet overhead.

Because Solana transactions are entirely data-dense and predictable, validators can ingest, verify, and parallelize them instantly over UDP-based protocols like QUIC. Unlike heavy HTTP payloads that require TCP handshakes, packet reassembly, and massive memory overhead, Solana transactions are built for raw, low-latency execution.

Final Thoughts

Transitioning from Web2 to Web3 doesn't mean throwing away your backend knowledge. It means taking concepts you already know-like database atomicity, payload optimization, and cryptography-and applying them to a distributed runtime environment. Understanding the transaction lifecycle is the first step toward building highly optimized, scalable on-chain applications.

Private Database (Web2) vs Public Account (Web3 - Solana)

Akeem Palmer — Sun, 03 May 2026 00:12:17 +0000

I've officially wrapped up the second week of my Solana deep dive. This week was all about moving from the "private" silos of Web2 databases to the "public" transparency of Blockchain and Solana accounts.

Here are my key takeaways on how Solana handles data:

1. The Anatomy of an Account

Unlike a row in a SQL database, every Solana account contains five specific fields:

Lamports: The SOL balance (1 SOL = 10^9 lamports)
Data: The actual state stored in the account.
Owner: The Program ID that has the authority to modify the data.
Executable: A boolean flag indicating if the account is a smart program.
Rent Epoch: (Now deprecated) Historically used for storage management.

2. Rent: "Living" on the Blockchain

In Web3, storage isn't free. While Transaction Fees cover the cost of processing, Rent covers the cost of storage. It scales linearly with data size.

To be Rent Exempt, an account must maintain a balance equivalent to 2 years of rent. Most modern wallets handle this automatically!

3. Transactions: Signatures & Messages

Transparency is the superpower of the blockchain. Every transaction is public and cryptographically signed. A transaction consists of a Signature and a Message. The message itself contains:

The Header (metadata)
Account Keys (who is involved)
Recent Block hash (to prevent replays)
Instructions (the actual logic being executed)

I'm excited to keep building and sharing this journey with you guys!

Day 7: Building My First Solana Wallet from Scratch

Akeem Palmer — Sun, 26 Apr 2026 17:36:53 +0000

I generated my first Solana key-pair using the CLI (Command Line Interface) and funded it through the Solana faucet, as well as a transfer from my Solflare wallet.

After just six days in the 100 Days of Solana challenge, I’ve gained a solid foundation on how Solana works; covering identity, SOL, and Lamports.

If you’re interested, check out my previous post on Solana identity: Exploring Web3 and How Solana Handles Identity.

Looking forward to continuing this journey and sharing more as I progress.

Exploring Web3 and How Solana Handles Identity

Akeem Palmer — Sun, 26 Apr 2026 15:07:07 +0000

From Web2 to Web3, identity remains an important aspect for authentication and authorization for both users and the server owners. However, the underlying architecture is shifting. In Web2, we rely on usernames and passwords stored on server owner’s hardware or handled by SSO vendors like Auth0, Google or Microsoft. On the other hand, in Web3 we swap databases for cryptographic keys. In this post, we’ll dive into how the Solana network uses these keys for On-Chain Identification.

The Key-pair: Your New Credentials

Solana is a high-performance network powering decentralized finance (DeFi), NFTs and decentralized applications (dApps). Unlike traditional systems where a server “owns” your identity, Solana uses a Public Key as your unique address.

Think of it this way:

Public Key (Your Username): A unique 32-byte address. This is what people use to send you tokens.
Private Key (Your Password): A digital signature that stays on your personal device. You use this to “sign” and authorize transactions.

Ed25519 vs. PDAs

Wallets usually use the Ed25519 digital signature, with the exception of Multisig Wallets or Smart wallets (Escrows, etc..), When you create an account, it must be accompanied by a private key that you or a secure third-party vendor maintains.

Solana uses PDAs (Program Derived Addresses), which are unique addresses that is not associated with a private key. Instead, they rely on a Program ID and specific seeds like user ID or user public key for authentication. This allows programs to programmatically sign for accounts. We can think of it like a service account in a cloud environment.

Beyond Usernames: What Identity Enables

On-chain identity isn’t just a replacement for a login, it’s a self-custodied foundation for:

Token Ownership: Providing what assets you hold.
Governance: Your right to vote on protocol changes.
Reputation: Your history on the public ledger is permanent and verifiable.

Because this is cryptographic, it works across every application on the network without needing server permission or an API integration. Your identity allows you to be discovered on the network, receive tokens, and maintain a wallet assignment globally.

The Math: SOL and Lamports

Once you have your identity, you’ll interact with SOL, Solana’s native cryptocurrency. Programmatically, we don’t usually work in whole SOL, we work in Lamports. Lamports are SOL’s smallest fractional unit.

1 SOL = 1,000,000,000 (10⁹) Lamports.

Think of Lamports as cents or pennies and SOL as dollars. This allows for high-precision transactions without the floating-point errors we try to avoid in financial code.

Conclusion: Who Owns The Server?

The biggest shift from Web2 to Web3 is ownership. In Web2, there is one true owner: the entity hosting the servers. In Web3, the network is decentralized and hosted across the globe.

I’m currently participating in the 100 Days of Solana challenge hosted by Major League Hacking (MLH). If you’re a developer looking to move from centralized databases to the blockchain, I highly encourage you to join!

I’d love to hear your feedback on this research in the comments below.

Image Generated By A.I