DEV Community: Akeem Palmer

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