DEV Community: Erick Carvajal

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.