DEV Community: Erick Carvajal

What I Learned Building NFTs on Solana with Token Extensions

Erick Carvajal — Tue, 09 Jun 2026 00:20:47 +0000

Before this week, NFTs on Solana weren't new to me. I've previously worked with Programmable NFTs (pNFTs) and even built projects that integrate them. However, most of my experience was centered around the Metaplex ecosystem, so I tended to think about NFTs through that lens.

What surprised me during this learning arc was discovering how much can be built directly with Token Extensions. By creating NFTs from the token level upward, I gained a much deeper understanding of the underlying primitives that make digital assets work on Solana.

The Mental Model: What Is an NFT on Solana?

As developers, we often interact with NFTs through SDKs, frameworks, and marketplace tooling. Those abstractions are useful, but they can hide what's actually happening on-chain.

This week helped me simplify the model:

An *NFT * is fundamentally a token mint configured with:

A supply of one
Zero decimals
Metadata describing the asset
Optional relationships to collections or groups

Using Token Extensions, many of these capabilities can be attached directly to the token itself rather than relying on additional programs or infrastructure.

That shift in perspective was one of the biggest takeaways from this challenge.

What I Built

Over the course of this arc, I created an NFT on Solana Devnet using Token Extensions and explored several capabilities that I had never implemented directly before.

The process included:

Creating a mint configured as an NFT
Adding metadata using the Metadata Extension
Minting a single token
Creating a collection using the Group Extension
Associating the NFT with the collection through the Member Extension
Auditing the account structure and extension data on-chain
Updating metadata after the NFT had already been created

One of the most valuable parts of the exercise was inspecting the accounts directly instead of relying solely on SDK abstractions.

For example:

spl-token initialize-metadata \
<NFT_MINT> \
"My First NFT" \
"MNFT" \
https://example.com/metadata.json

Seeing how the metadata is stored and referenced at the token level gave me a much clearer understanding of how Token Extensions work behind the scenes.

The Surprising Part

The most surprising discovery was how self-contained the Token Extensions approach feels.

Coming from pNFT development, I was already familiar with advanced NFT functionality. What I didn't fully appreciate was how many NFT features can now be represented directly through token extensions.

The Group and Member Extensions were especially interesting because they model collection relationships as native on-chain structures rather than purely application-level concepts.

Another surprise was how easy it became to inspect and verify everything. By auditing the mint accounts and extension data directly, I could see exactly how the NFT was composed and how each extension contributed to its behavior.

That level of transparency made the architecture much easier to understand.

What I Would Build Next

Now that I've explored NFT construction with Token Extensions, I'd like to experiment with more dynamic asset models.

Some ideas include:

Achievement NFTs that evolve based on user actions
On-chain certificates with updateable attributes
Membership assets with configurable permissions
Hybrid systems that combine Token Extensions with pNFT functionality

Understanding both approaches gives developers more flexibility when deciding which NFT architecture best fits a particular use case.

Even with previous experience building NFT applications on Solana, this challenge helped me understand the ecosystem at a deeper level.

Instead of viewing NFTs only through higher-level frameworks, I now have a much clearer picture of the token primitives that power them.

Token Extensions, Metadata, Group, and Member Extensions demonstrate that NFTs on **Solana **are more than collectibles. They're programmable digital assets built from composable on-chain components.

Token Extensions on Solana: Building Tokens That Do More Than Store Value

Erick Carvajal — Fri, 05 Jun 2026 16:34:18 +0000

From Simple Tokens to Programmable Assets

When most developers think about tokens, they think about balances and transfers.

A user owns tokens, sends them to another account, and that's it.

But many real-world assets need additional rules:

A gift card that charges a fee when transferred
A membership badge that cannot be sold
A regulated asset that can be frozen
A credential that an issuer can revoke
A loyalty program with rich metadata attached

In traditional systems, these rules are usually implemented in backend services and databases.

With Solana's Token-2022 program, many of these behaviors can be embedded directly into the token itself through Token Extensions.

Over the past week as part of the #100DaysOfSolana challenge, I explored several Token Extensions and experimented with combining them to create different token behaviors.

This article summarizes what I learned and how these extensions can be used in practice.

What Are Token Extensions?

Token Extensions are optional features that can be attached to a mint or token account when using the Token-2022 program.

Instead of deploying a custom smart contract for every use case, developers can activate predefined extensions that add functionality directly to the token.

Some examples include:

Extension Purpose

Transfer Fee Charges a fee on token transfers
Metadata Pointer Links metadata directly to the mint
Default Account State New accounts start frozen
Non-Transferable Prevents tokens from being transferred
Permanent Delegate Grants permanent authority over token accounts

The interesting part is that these extensions can be combined to create entirely different asset models.

Combination Nº1: Transfer Fees + Metadata

This was the first combination I experimented with.

The idea is simple:

Every transfer pays a fee
The token includes rich metadata

This could be useful for:

Loyalty points
Community currencies
Revenue-sharing systems
In-app economies

The metadata makes the asset easier to identify in wallets and explorers, while transfer fees introduce economic rules directly at the protocol level.

Combination Nº2: Default Frozen Accounts + Permanent Delegate

This combination felt much closer to traditional compliance systems.

Every newly created token account starts in a frozen state.

A designated authority can then decide:

Who receives access
When accounts become active
When access should be revoked

This pattern could be useful for:

Enterprise assets
Compliance-gated tokens
Educational certificates
Membership programs

What surprised me most was how little custom logic is needed.

Many behaviors that would normally require an additional smart contract already exist as built-in extensions.

Combination Nº3: Non-Transferable + Permanent Delegate

This was probably the most interesting experiment.

A non-transferable token behaves similarly to a soulbound credential.

Once issued, the holder cannot transfer it to another account.

Adding a Permanent Delegate introduces administrative control that can be useful for:

Certifications
Event attendance badges
Academic credentials
Identity systems

The token becomes a credential rather than a tradable asset.

This shift in thinking was one of the biggest lessons from exploring Token Extensions.

Not every token needs to represent money.

Sometimes a token represents reputation, access, or proof.

Reading a Mint and Inspecting Extensions

One of the most valuable exercises was inspecting existing Token-2022 mints and reading their configuration accounts.

Instead of only creating tokens, I started asking:

Which extensions are enabled?
What authorities exist?
How are fees configured?
Is metadata stored on-chain?
Are transfers restricted?

This helped me understand how other developers design token systems and how different extension combinations affect behavior.

Example: Creating a Transfer Fee Token

One of the commands I used during my experiments was creating a mint with transfer fees enabled.

spl-token create-token \
  --transfer-fee-basis-points 250 \
  --transfer-fee-maximum-fee 1000

What this configuration does:

Creates a Token-2022 mint
Applies a 2.5% transfer fee
Caps the maximum fee at 1000 tokens

From that point forward, transfers automatically follow the rules defined by the extension.

No additional smart contract logic is required.

What Confused Me

Initially, I assumed Token Extensions were simply extra metadata fields. They're much more powerful than that.

The biggest mental shift was understanding that extensions modify token behavior itself. The token is no longer just a balance. It becomes a programmable asset with built-in rules.

Another challenge was understanding which extensions make sense together.

Some combinations complement each other naturally, while others introduce restrictions that may not fit the intended use case.

Designing token behavior becomes an architecture exercise.

What Clicked

The idea that clicked for me was this:

Token Extensions move business rules closer to the asset itself.

Instead of relying entirely on backend infrastructure, many common requirements can be enforced directly by the token program.

That opens interesting possibilities for:

Digital credentials
Loyalty systems
Compliance-focused assets
Membership tokens
On-chain identity

Final Thoughts

Before exploring Token-2022, I mostly thought about tokens as transferable balances.

After working with Token Extensions, I started thinking about tokens as configurable digital objects.

A token can represent money.

A credential.
A membership.
A permission.

Or something entirely different.

The extension model gives developers a toolkit for defining those behaviors without building everything from scratch.

If you're learning Solana and haven't explored Token Extensions yet, I highly recommend experimenting with them.

They completely change what a token can be.

For deeper technical details, check out the official Token-2022 Extensions documentation and implementation guides from the Solana ecosystem.

https://www.solana-program.com/docs/token-2022/extensions

How Token-2022 Changes Token Logic: A Hands-On Experiment with Minting, Transfers, and Burning on Solana

Erick Carvajal — Thu, 04 Jun 2026 01:10:45 +0000

In Web2, asset distribution is controlled by backend services, databases, and business logic.

In Solana, those rules can live directly inside the token itself.

In this experiment, I explored how far Token-2022 Program can go by combining:

Non-transferable tokens
Token accounts across multiple wallets
Transfers with protocol-level enforcement
Token burning
On-chain state inspection

The goal was not just to create tokens, but to understand how Token-2022 changes the mental model of token design.

🧭 Context: Why Token-2022 matters

Traditional SPL tokens rely on application-level logic. That means rules like restrictions, permissions, or behavior are often enforced off-chain.

With Token-2022, those rules move into the protocol layer.

Official references:

This changes the mental model completely:

Tokens are no longer just balances. They become programmable state machines with built-in economic rules.

🪙 1. Creating a non-transferable token mint

The first step was creating a mint using the Non-Transferable extension.

I used this because I wanted to test how Token-2022 can enforce identity-like behavior directly at the protocol level.

spl-token create-token \
--program-id TokenzQdBNbLqP5VEhdkAS6EPFLC1PHnBqCXEpPxuEb \
--enable-non-transferable

Result:

Address:  BdjdjoR9bS1bei3Gn5crn4jqYAtsxgm7q9B7NAubj42k
Decimals:  9

Signature: 52FfGLA8UHYskSZuwzdWTMnMZnjh8sjAGmM8WT7rjjSgL5jFt6HhkvA5saowDx2cAkwvEhT4PVC9Pw1BorSxU45i

💡 Why this matters

Non-transferable tokens cannot be moved between wallets.

This makes them useful for:

credentials
identity systems
achievements
access control mechanisms

Instead of enforcing rules in an application layer, the restriction is enforced by the protocol itself.

👛 2. Creating a token account and minting

Next, I created a token account and initialized the mint flow.

spl-token create-account BdjdjoR9bS1bei3Gn5crn4jqYAtsxgm7q9B7NAubj42k \
--program-id TokenzQdBNbLqP5VEhdkAS6EPFLC1PHnBqCXEpPxuEb

Result:

Creating account P2H8JGKs7TGNmrv1TP9HRCQK7wwLFRSzC8MsgE5DiUQ
Signature: 5t6y36E2UQxeV3Sr6eBVUbJAEoVGtZTVheETash9f3G6eSkeMhC2Shk88XnCRAjNZT5fKYTEQskJzhqKE3Wze6J5

💡 Why this matters

Each token account represents:

ownership
balance
and state tied to mint rules

Even with extensions, the account model remains the foundation of Solana’s token system.

🔁 3. Creating an ATA for a second wallet

To simulate multi-user behavior, I created a second wallet account:

spl-token create-account BdjdjoR9bS1bei3Gn5crn4jqYAtsxgm7q9B7NAubj42k \
--owner ~/.config/solana/id_back.json \
--fee-payer ~/.config/solana/id.json \
--program-id TokenzQdBNbLqP5VEhdkAS6EPFLC1PHnBqCXEpPxuEb

Result:

Creating account 9z325AvvFhnb6AqsVCGLWtccTSdxuNZafurZqnmE7UMD
Signature: 28b5K5o9xhPmNwgUHDwHmHRXq1GwLYQpawdYH2N27PEuadDD4BLxGmJFSdVM94md1hqB1MB13uFHyD8Ycj4xuEyE

💡 Why this matters

This step represents real-world multi-user distribution systems.

However, Token-2022 extensions allow rules to be enforced at protocol level instead of relying on backend logic.

💸 4. Attempting a transfer

I attempted a token transfer between accounts:

spl-token transfer BdjdjoR9bS1bei3Gn5crn4jqYAtsxgm7q9B7NAubj42k 5 \
$(solana-keygen pubkey ~/.config/solana/id_back.json) \
--program-id TokenzQdBNbLqP5VEhdkAS6EPFLC1PHnBqCXEpPxuEb \
--allow-unfunded-recipient

💡 Why this matters

This is where Token-2022 shows its flexibility.

Depending on enabled extensions, transfers can be:

fully allowed
restricted
or modified at protocol level

This reduces the need for custom validation logic in traditional applications.

🔥 5. Burning tokens

To test supply control, I burned tokens:

spl-token burn P2H8JGKs7TGNmrv1TP9HRCQK7wwLFRSzC8MsgE5DiUQ 3 \
--program-id TokenzQdBNbLqP5VEhdkAS6EPFLC1PHnBqCXEpPxuEb

Result:

Burn 3 tokens
Source: P2H8JGKs7TGNmrv1TP9HRCQK7wwLFRSzC8MsgE5DiUQ

Signature: 33uX4vtabxexV5teve7VCUbTZRcs3D3Kha3kzNz2zbJpsswRXGmdVptViDsYFFfpkLwwZCbKjb3s4dFxM3yiYT7a

💡 Why this matters

Burning tokens is not just destruction.

It represents a deterministic state change on-chain, reducing total supply at the protocol level.

📉 6. End-to-end lifecycle observation

After running the full flow:

Mint was created successfully
Token accounts were initialized
Transfers were executed under protocol rules
Tokens were burned
State changes were visible across explorers

This highlights a key difference from Web2 systems:

In Web2, state lives in databases.
In Solana, state is deterministic, replicated, and enforced by the protocol.

🧠 What surprised me

The biggest shift was conceptual:

Tokens are not just balances
They are programmable state machines
Ownership rules live at mint level
Behavior is enforced at the protocol layer

This becomes even more powerful when combined with extensions like:

transfer fees
metadata binding
identity-based tokens

🚀 What’s next

Next steps in this exploration:

Transfer fee extensions and fee withdrawal mechanisms
Metadata-driven token systems
Token-gated applications
More advanced Token-2022 behaviors

Because Token-2022 is not just a token standard.

It is a framework for building economic logic directly into blockchain primitives.

Auditing a Real Solana Transaction: Creating a USDC Account on Devnet

Erick Carvajal — Tue, 02 Jun 2026 19:14:49 +0000

Today I decided to go one step deeper into Solana by not just reading transactions, but actually auditing one I created myself using Solana Explorer.

To generate the transaction, I created an Associated Token Account (ATA) for USDC on devnet using the SPL Token CLI:

spl-token create-account 4zMMC9srt5Ri5X14GAgXhaHii3GnPAEERYPJgZJDncDU

Transaction Details: https://explorer.solana.com/tx/2Xa2DAWDooLy99p1ch4dFpVdEKZWCegxahQj1xLRiFvy4oo8FsW1CumPmH558UgmnwWNSKk7Gw3QQzFQDiMzdnN1?cluster=devnet

This triggered a transaction that looked simple at first glance, but once inspected in Solana Explorer, it revealed how many moving parts are involved just to initialize a token account.

🧠 What I was looking at

The transaction created an Associated Token Account for the USDC mint on devnet:

4zMMC9srt5Ri5X14GAgXhaHii3GnPAEERYPJgZJDncDU

This account is where USDC would be stored for my wallet.

But what stood out is that this is not a single operation. It is a coordinated execution across multiple programs:

Associated Token Program (creates the ATA)
System Program (allocates space + funds rent)
Token Program (initializes account state)
Compute Budget Program (controls execution limits)

⚙️ What happens under the hood

To create a simple token account, Solana must:

Derive the Associated Token Address (ATA)
Allocate 165 bytes of account storage
Fund the account with ~0.002 SOL for rent exemption
Assign ownership to the Token Program
Initialize the account for the USDC mint

All of this happens atomically — either everything succeeds or nothing does.

🔗 What I learned

The most interesting realization is how explicit everything is in Solana.

Even something as simple as “having a USDC account” requires:

A program to create it
A system-level allocation of space
A rent-exempt balance
A deterministic address derived from wallet + mint

Nothing is hidden. Everything is visible in the Explorer.

🧩 Final thought

This exercise helped me understand something fundamental:

On Solana, state is not assumed — it is constructed step by step through programs and accounts.

And tools like Solana Explorer make that entire process transparent and auditable in real time.

Solana's Account Model Explained for Web2 Developers

Erick Carvajal — Tue, 02 Jun 2026 18:28:27 +0000

When I first started learning Solana, the account model was probably the most confusing concept.

Coming from Web2 development, I was used to thinking in terms of applications, databases, users, and servers. Then I opened Solana Explorer and suddenly everything seemed to be an account.

Wallets are accounts.
Programs are accounts.
Token balances are accounts.

Even data storage is handled through accounts.

At first, it felt strange. After spending time building on Solana, I realized the account model is actually one of the network's most elegant design choices.

Think of Solana Like a Filesystem

The easiest way to understand Solana is to imagine an operating system filesystem.

Every file has:

An address or location
Metadata
Content
Permissions

Solana accounts work in a very similar way.

Every account lives in a giant key-value store.

The key is a 32-byte public address.

The value is the account itself.

Instead of thinking about wallets and smart contracts as separate objects, think of everything as files stored in the same global filesystem.

The Five Fields Every Account Has

Every account on Solana contains the same structure:

Lamports

Lamports are the smallest unit of SOL.

Just like 1 dollar contains 100 cents:

1 SOL = 1,000,000,000 lamports.

This field stores the account's SOL balance.

Data

This is where an account stores information.

A wallet account might store little or no data.

A token account stores token balances.

A DeFi protocol might store liquidity pool information, positions, or user state.

The data field is simply a byte array that programs can interpret however they want.

Owner

This is one of the most important fields.

The owner is the program that has permission to modify the account's data.

Think of it like file ownership in Linux.

If a program doesn't own an account, it cannot arbitrarily change its contents.

Executable

This field indicates whether the account contains executable code.

If executable is true, the account is a program.

If executable is false, the account is simply storing data.

Rent Epoch

Historically this field was used for rent collection.

Today it is deprecated and typically set to a maximum value.

You will still see it when inspecting account data, but modern applications rarely need to interact with it directly.

Ownership Is Solana's Security Model

One rule explains most of Solana's security model:

Only the owner program can modify an account's data or remove lamports from it.

Interestingly, anyone can send lamports to a writable account.

This means ownership is not about who can deposit funds.

Ownership determines who can modify state.

For Web2 developers, this feels similar to database permissions.

You may have read access to a table, but only specific services can modify certain records.

The Concept That Surprised Me Most

The biggest surprise for me was learning that programs do not store their own state.

In many systems we think of an application and its data as being tightly connected.

On Solana they are separated.

A program account contains executable code.

Data accounts contain state.

The program reads and writes data from those accounts when processing instructions.

A useful analogy is a web application.

Imagine:

The program is your backend server.
Data accounts are your database tables.
Transactions are API requests.

The backend doesn't keep all data inside its source code.

It reads and writes information to a database.

Solana works in a very similar way.

Why Rent Exemption Exists

Since storing data on-chain consumes network resources, accounts must maintain a minimum balance.

This is known as rent exemption.

The larger the account's data size, the more lamports it must hold.

For a basic account, the amount is relatively small, but larger accounts require more SOL.

This mechanism prevents the blockchain from being flooded with free, permanent storage.

A Real Example

When I explored my own DeFi swap transaction in Solana Explorer, I expected to see a simple token exchange.

Instead, I found dozens of accounts interacting together.

Transaction: https://explorer.solana.com/tx/3DW1LgsjDg2cbgZnsPE4UkR4WqnZoZpwn5tufuRgKaAtV3FuujkCoHxQ4Lx3PfN6zRjL9tDoShJR8HsBR6DQ42rV

Some accounts held token balances.

Some belonged to liquidity pools.

Some were temporary accounts created during execution.

Others belonged to programs like Jupiter and the Token Program.

Understanding the account model suddenly made the transaction much easier to follow.

Everything was just accounts interacting under a set of ownership rules.

Final Thoughts

If you're coming from Web2, the Solana account model can initially feel unfamiliar.

But once you stop thinking in terms of wallets versus smart contracts and start thinking in terms of accounts, programs, and ownership, many parts of Solana begin to make sense.

Accounts are the foundation of everything on the network.

Tokens, NFTs, DeFi protocols, governance systems, and wallets all build on the same simple idea:

Everything is an account.

Anatomy of a Solana Transaction: Following Every Step from Creation to Finalization

Erick Carvajal — Mon, 01 Jun 2026 19:26:39 +0000

Over the past few days, I've been learning Solana transactions by doing what every developer eventually does: building things, breaking them, and trying to understand what happens under the hood.

At first, I thought a transaction was just a blockchain version of an API request.

Create it.
Send it.
Wait for a response.
Done.

But Solana transactions are much more than that.

A transaction is a cryptographically signed package containing instructions, accounts, metadata, and execution rules that validators process atomically.

To better understand the process, I built a small script that transfers SOL on Devnet while exposing every major component of the transaction before it reaches the network.

Let's follow that transaction from creation to finalization.

The Transaction Lifecycle

Before writing any code, it helps to visualize what actually happens.

Create Transaction
│
▼
Add Instructions
│
▼
Attach Recent Blockhash
│
▼
Sign Transaction
│
▼
Send To Network
│
▼
Processed
│
▼
Confirmed
│
▼
Finalized

Every transaction on Solana follows a similar path.

The transfer itself is just one instruction inside a larger structure.

Visit the complete script

✅ anatomy of a transaction script

Step 1: Loading the Signer

The first thing my script does is load the wallet generated by Solana CLI.

This signer is more than just an address.

It contains the cryptographic key pair required to authorize changes on-chain.

Without a valid signature, validators will reject the transaction immediately.

When the script starts, it prints information about the wallet and current balance:

Wallet: 8xY...
Balance: 4.82 SOL

This account will also become the fee payer for the transaction.

Step 2: Fetching a Recent Blockhash

Before a transaction can be submitted, it needs a recent blockhash.

A common misconception among new developers is that transactions remain valid forever.

They don't.

The recent blockhash acts as an expiration mechanism.

If too much time passes before the transaction reaches the network, validators will reject it.

This design helps prevent replay attacks and ensures transactions are processed within a limited time window.

My script prints:

Blockhash: 7P7...
Last Valid Block Height: 412345678

This information defines the lifetime of the transaction.

Step 3: Creating an Instruction

Transactions don't perform actions by themselves.

Instructions define what should happen.

For this example, the instruction is a simple SOL transfer.

This tells Solana's System Program:

> Transfer a specific amount of SOL from one account to another.

The script outputs:

Type: System Program Transfer
From: 8xY...
To: FdQ...
Amount: 0.01 SOL

Although this example contains a single instruction, a transaction may include multiple instructions that execute together.

Step 4: Building the Transaction

Now we assemble all the pieces.

This is where the transaction anatomy becomes visible.

The transaction now contains:

A fee payer
A recent blockhash
One instruction
Required account metadata

At this point the transaction is fully constructed but still cannot be executed.

Why?

Because it hasn't been signed.

Step 5: Signing the Transaction

Signing proves authorization.

The resulting signature becomes the unique identifier for the transaction.

Output:

Signature:
5q8mD7...

One important detail is that changing any part of the transaction after signing invalidates the signature.

Validators verify this before execution.

Step 6: Broadcasting to the Network

Once signed, the transaction is serialized and sent.

At this stage the transaction leaves my machine and enters the validator network.

This is where many developers expect the process to be finished.

In reality, it's only beginning.

Step 7: Understanding Commitment Levels

One of the most interesting concepts I encountered while learning Solana was transaction commitment.

A transaction doesn't instantly become final.

Instead, it moves through several states.

Processed
✓ Processed

The transaction has been included in a block and executed.

However, the network has not yet fully agreed on its permanence.

Confirmed
✓ Confirmed

A supermajority of validators has voted on the block.

Confidence is significantly higher.

Finalized
✓ Finalized

The block is considered irreversible.

For applications that require maximum certainty, this is usually the status that matters most.

My script waits for all three stages and prints each one as it occurs.

Watching the transaction progress through these levels helped me understand that blockchain state isn't updated in a single instant.

Consensus is a process.

Viewing the Transaction On-Chain

After finalization, the script prints a Solana Explorer URL.

https://explorer.solana.com/tx/?cluster=devnet

Opening that link reveals the same transaction from the network's perspective:

Signature
Accounts
Instructions
Fee information
Confirmation status
Block information

This is one of the best ways to connect your local code with what validators actually process.

The Mental Model Shift

The biggest lesson I learned wasn't how to transfer SOL.

It was understanding what a transaction really is.

As developers, we're often trained to think in terms of requests and responses.

Client
↓
Server
↓
Database

> Solana requires a different mindset.

Build Transaction
↓
Sign Transaction
↓
Broadcast
↓
Validators Execute
↓
Consensus

The transaction itself becomes the unit of state change.

Once that mental model clicked, concepts like signatures, blockhashes, instructions, and confirmation levels became much easier to understand.

A simple transfer may look trivial on the surface, but it contains nearly every foundational concept needed to build applications on Solana.

And that's what makes it such a powerful learning exercise.

What I'm Exploring Next

Now that I understand the anatomy of a successful transaction, I'm interested in exploring the opposite side of the equation:

Expired blockhashes
Failed instructions
Compute budget limits
Multi-instruction transactions
Program interactions

Because sometimes the fastest way to understand how something works is to see how it breaks.

Solana and How It Changed the Way I Think About Software

Erick Carvajal — Fri, 29 May 2026 16:47:35 +0000

For the past two weeks I’ve been diving deeper into Solana development as part of the #100DaysOfSolana challenge.

Even though I already had experience in software engineering and blockchain development, I realized very quickly that understanding Solana is not only about learning new tools or SDKs — it’s about changing the way you think about applications, state, and ownership.

What surprised me the most

Coming from a traditional Web2 background, I expected blockchain data to feel similar to working with a distributed database.

But Solana’s account model feels very different once you start interacting with it directly.

At first, hearing “everything is an account” sounded simple.

Then I started inspecting accounts through the CLI:

> solana account $(solana address)

That was one of the first moments where things started to click.

A wallet is not just an address. It is actual on-chain state:

balance
ownership
permissions
executable flags
raw data storage

And unlike traditional databases, every validator in the network maintains that state collectively.

That changes your perspective completely.

The “public database” idea finally became real

One of the biggest mindset shifts for me was understanding that Solana is not trying to replace databases.

Instead, it solves a different problem:
how to coordinate state in a trustless environment where no single company owns the infrastructure.

In Web2:

your backend owns the database
your server controls access
users trust your application

In Solana:

users own accounts
programs define rules
validators enforce execution

That distinction became much clearer after comparing traditional databases with Solana accounts side by side.

RPC calls felt very different from APIs

Another interesting realization was how different reading blockchain data feels compared to traditional APIs.

Normally in Web2:

you call an API endpoint
the backend queries a database
the server returns processed data

In Solana:

you read raw account state through RPC
there are no SQL joins
no relational queries
no backend magically assembling your data

You start understanding very quickly why indexing layers and infrastructure providers are so important in Web3.

The first time I used methods like:

> connection.getAccountInfo(publicKey)

I realized:
this is much closer to reading low-level state than consuming a normal REST API.

What still feels confusing

One thing I’m still trying to better understand is how large-scale Solana applications organize and index massive amounts of account data efficiently.

The account model makes sense conceptually, but designing scalable architectures around:

PDAs
indexing
account relationships
pagination
caching
transaction limits

feels very different from designing traditional backend systems.

I’m also interested in learning more about:

Sealevel parallel execution
account compression
advanced Anchor patterns
Solana runtime internals
validator architecture

These two weeks reinforced something important for me:

Web2 knowledge still matters a lot in Web3.

Concepts like:

data modeling
architecture
security
scalability
developer experience

all still apply.

But Solana forces you to rethink where state lives, who owns it, and how applications interact with it.

And honestly, that’s what makes learning it so interesting.

Comparing Databases vs Solana Accounts ⚡

Erick Carvajal — Fri, 29 May 2026 16:23:56 +0000

As a developer coming from Web2 and traditional backend systems, one of the biggest mindset shifts while learning Solana is understanding the account model.

At first, accounts sound simple:
“everything is an account.”

But after exploring it deeper, I realized Solana is not trying to replace databases; it’s solving a completely different problem: how to manage state in a decentralized environment where no single entity owns the system.

Today I compared traditional databases with Solana accounts using the Solana CLI and Devnet.

🧠 Traditional Database vs Solana Accounts

Concept	Traditional Database	Solana Accounts
Data location	Rows in tables on a centralized server	Accounts on a distributed ledger across validators
Schema	Defined by the database (SQL DDL, document schema)	Defined by the owning program; stored as raw bytes in the account’s data field
Access control	Application-level auth (SQL roles, app middleware)	Enforced by the runtime: only the owning program can modify an account, and only with the required signer(s)
Cost of storage	Server/cloud hosting fees, pay for disk space	Rent-exempt deposit proportional to data size; refundable when the account is closed
Identity/keys	Auto-increment IDs, UUIDs	32-byte public keys or Program Derived Addresses (PDAs)
Reads	SQL queries, document lookups	RPC calls (`getAccountInfo`, `getProgramAccounts`)
Writes	INSERT/UPDATE via application code	Transactions with instructions, signed by authorized keys
Code vs data	Application code and database are separate systems	Both are accounts; programs and data accounts coexist in the same model
Deletion	DELETE query removes the row	Close the account and recover lamports
Visibility	Private by default; controlled by the server owner	Public by default; anyone can read account data

🔥 Biggest Takeaways

In Solana, users own their accounts, not your application.
Programs are stateless and receive accounts as inputs during execution.
There are no SQL joins or server-side queries on-chain.
Storage costs are explicit through rent-exemption.
Transparency is the default.
Wallet signatures replace traditional authentication systems.

One of the most interesting realizations was understanding that:

Programs do not search for accounts.
Accounts are explicitly passed into instructions during transactions.

That changes everything about how you design software in Web3.

Web2 knowledge still matters
But the execution model is fundamentally different

⚡ Backend server → Validator network
⚡ Database row → Account
⚡ API endpoint → Program instruction
⚡ Authentication middleware → Wallet signatures + runtime validation

Revisiting Solana Identity Through Vanity Addresses

Erick Carvajal — Fri, 29 May 2026 02:18:33 +0000

Sometimes revisiting fundamentals teaches you more than learning something new.

I’m not new to Solana.

I’ve already worked with wallets, transactions, dApps, and on-chain interactions before joining this challenge. But one thing I’ve enjoyed about revisiting the fundamentals is realizing how many concepts we eventually normalize as developers.

One of those moments happened while creating a vanity address.

At surface level, vanity addresses seem cosmetic:
a personalized public key with a recognizable prefix.

Something like:

neo...
dev...
sol...

But while generating one, I found myself thinking less about customization and more about identity.

🧠 We Normalize Cryptographic Identity Very Quickly

In Web2, identity usually depends on platforms.

Your GitHub account exists because GitHub says it exists.
Your email exists because a provider manages it.
Your access can be revoked, recovered, or modified through centralized systems.

In Solana, identity starts with a keypair.

That concept sounds simple, but its implications are massive.

Your public key becomes:

👛 your wallet
🧾 your account
🏆 your reputation
🔐 your ownership layer
⚡ your authentication method

All without asking permission from a platform.

As developers, we eventually stop thinking about how radical that actually is.

Generating a vanity address made me revisit that idea from a different angle.

✨ Creating My Vanity Address

I decided to generate a vanity address starting with:

neo

Using the Solana CLI, the process was surprisingly simple:

solana-keygen grind --starts-with neo:1

🔍 What does this command do?

Part	Description
`solana-keygen`	Solana CLI key generation tool
`grind`	Continuously generates keypairs
`--starts-with`	Searches for a matching prefix
`neo:1`	Look for addresses starting with `neo` and stop after finding 1

The CLI continuously generates valid cryptographic keypairs until one naturally matches the pattern.

That means the resulting wallet is still:

✅ Cryptographically secure
✅ Fully decentralized
✅ Controlled only by the private key owner

The tool is not editing an address.

It’s brute-forcing mathematically valid combinations until one matches the requested pattern.

🎯 You Can Customize the Beginning or the End

One thing I found interesting is that Solana vanity addresses are not limited to prefixes.

You can generate addresses:

starting with specific characters
ending with specific characters

Starts with

solana-keygen grind --starts-with neo:1

Ends with

solana-keygen grind --ends-with neo:1

You can even combine patterns depending on how much time and computational power you are willing to spend.

⚠️ The more characters you add, the longer the process takes because the search space grows exponentially.

🖥️ Watching the CLI Search Felt Weirdly Satisfying

Seeing the terminal continuously generate millions of keypairs made something click for me:

Blockchain identity is mathematical.

Not platform-based.

No company approves your identity.
No database stores your username.
No admin grants access.

Your identity is literally tied to cryptographic ownership.

And somehow, adding a simple neo prefix made the address feel more human.

👛 Wallets Are Not Just Wallets

One thing this challenge reinforced for me is how misleading the word wallet can be for newcomers.

People imagine:

storage,
balances,
banking interfaces.

But the wallet is really an identity layer.

Everything on Solana connects back to the keypair:

transactions
governance
token ownership
program interactions
reputation

The assets are not “inside” the wallet.

The blockchain simply recognizes that a specific public key has authority over them.

That distinction becomes clearer the more time you spend building in Web3.

🚀 Why Revisiting Fundamentals Matters

As developers, it’s easy to rush toward:

smart contracts
frameworks
AI integrations
scaling architectures
complex protocols

But revisiting the basics has value.

Because the entire ecosystem ultimately depends on a few foundational ideas:

cryptographic ownership
self-custody
decentralized identity
verifiable interaction

Creating a vanity address reminded me that even small experiments can expose much bigger ideas underneath.

And honestly, that’s one of the reasons I’m enjoying this challenge despite already having experience with Solana.

Sometimes relearning fundamentals gives you a better perspective than learning something entirely new.

🧵 Final Thought

Before this challenge, I mostly saw vanity addresses as a branding detail.

Now I see them as a small but interesting expression of on-chain identity.

And that’s probably one of the most fascinating parts of Web3:

Your identity doesn’t belong to a platform.

It belongs to your keys.

Your Solana Wallet Is More Than a Wallet — It’s Your Identity

Erick Carvajal — Fri, 29 May 2026 01:49:50 +0000

If you come from Web2 development, you’re used to identity being fragmented across platforms.

You have:

a GitHub username,
a Google account,
an email address,
maybe OAuth logins for different apps,
and passwords stored in dozens of databases you don’t control.

Each platform owns your identity inside its own system. Blockchain changes that model completely. On Solana, your identity starts with a cryptographic keypair.

And once that clicks, many Web3 concepts suddenly make sense. From Web2 Accounts to Cryptographic Identity In Web2, accounts are usually stored in centralized databases.

When you log into a service, the platform checks:

your email,
your password,
or an OAuth token

The company decides whether you can access your account.

They can:

suspend you,
reset your password,
lock your account,
or even delete your access entirely.

Your “identity” exists because their servers say it does. On Solana, identity works differently. There’s no central authority managing your account. Instead, identity is based on public-key cryptography.

When you create a Solana wallet, you generate:

a public key
and a private key

The public key becomes your address on the network.

The private key proves ownership.

That’s it.

No username.
No email.
No password reset flow.

Just cryptographic proof. Think About SSH Keys. The easiest way for a Web2 developer to understand this is through SSH.

When you use SSH:

You generate a keypair.
You place the public key on a server.
You prove ownership by signing with the private key.

Solana works in a very similar way. Except instead of authenticating against a single server, you authenticate against the entire network. Your wallet signs transactions using your private key. Validators verify the signature using your public key. If the signature is valid, the network accepts the action. If not, the transaction is rejected.

This means your identity is portable across every Solana application. You don’t create a new account for every dApp. Your wallet is your account.

Why Solana Addresses Look Weird?

A Solana public key usually looks something like this:

14grJpemFaf88c8tiVb77W7TYg2W3ir6pfkKz3YjhhZ5

That’s not random formatting.

Solana uses:

32-byte Ed25519 public keys
encoded in Base58

Base58 intentionally removes visually confusing characters like:

0
O
I
l

This reduces mistakes when copying addresses.

Unlike usernames in Web2 databases, these addresses are not assigned by a company. They are mathematically generated. Nobody needs permission to create one.

Ownership Without Permission. This is probably the biggest mental shift for Web2 developers.

In Web2:

Access is granted by a platform.

In Solana:

Ownership is proven cryptographically.

If you control the private key, you control the account. No support team can override that. No admin can reset it. No centralized database determines ownership.

This is what people mean when they say:

“Not your keys, not your crypto.”

The private key is the source of authority. That also means self-custody comes with responsibility. If you lose your private key or seed phrase, there is no password recovery process. The network cannot “recover” your identity for you.

Identity Is More Than Logging In. On Solana, identity is not just authentication. Your public key becomes the foundation for everything you do on-chain:

token ownership,
NFT collections,
governance voting,
DAO participation,
program interactions,
reputation,
transaction history.

And because the identity is standardized across the network, every application can recognize it automatically.

You don’t need:

account integrations,
OAuth providers,
or permission between apps.

Your wallet works everywhere by default. That interoperability is one of the most powerful ideas in Web3.

Final Thoughts

Before learning Solana, I thought wallets were mainly about storing crypto. But after working with keypairs and signing transactions, I realized something bigger:

A wallet is really a cryptographic identity layer.

In Web2, companies own the relationship between users and applications.

In Solana, users own their identity directly.

That changes how authentication, ownership, and interoperability work across the internet.

And honestly, once you understand that, many parts of Web3 stop feeling “magical” and start feeling like a natural evolution of systems developers already know.