100daysofsolana Week 2: From hating Solana to loving it

Shaun — Sat, 02 May 2026 18:48:50 +0000

I just finished my second week of #100DaysOfSolana, and it’s been a massive shift in perspective.
The first week was about understanding the what (wallets and Lamports), this week was all about the how—specifically, pulling that data off the chain and showing it to the world.

Here’s a breakdown of what I’ve been building and the discovery moments I had along the way.

The Mental Shift: The Public Database

I expected Solana to be cryptic rust-based and hard to reach. The reality is that Solana feels like a made-for-utility globally distributed public database. In a traditional app, your data is tucked away in a private SQL or NoSQL database managed by a backend server. On Solana, everything is an account and accounts are public by default; anyone with an RPC connection can read the state of an account at any time.

The CLI vs. The Frontend

My week was a game of two halves: working in the terminal and building in the browser.

1. Reading Balances

I started by checking address balances via the Solana CLI using simple commands like solana balance. But the real magic happened when I moved this into a JavaScript frontend. Using the @solana/web3.js library, I established a Connection through an RPC and used the getBalance method to fetch data programmatically.

The Surprise:

I learned that Solana doesn't store balances as "1 SOL." It uses Lamports—the smallest unit of SOL. To show a user their actual balance, you have to divide the result by the LAMPORTS_PER_SOL constant everytime:

SOL = Lamports / 10^9

2. Tracking Transactions

Next, I moved on to account history.

In the Terminal: I logged raw transaction data to see the flow of SOL.
In the Browser: I built a dashboard to display these transactions as a readable list.

What Clicked: Reading transactions is a two-step process. You first fetch a list of signatures (transaction IDs) using getSignaturesForAddress.
We'll probably learn to fetch the actual transaction details using getParsedTransactionsometime later in the program. I also discovered a built-in limit: you can only fetch 1,000 signatures at a time, so you have to use pagination with the before parameter if you want the full history.

Devnet vs. Mainnet: The Build Tester

Another important milestone was comparing data across Devnet (the playground) and Mainnet-beta (the real deal).

Feature	Devnet	Mainnet-beta
SOL Value	$0 (Free airdrops)	Real market value
Rate Limits	Permissive for testing	Highly restrictive on public nodes
Purpose	Testing and Demos	Production Apps

A Big Lesson:
I realized that while public RPC endpoints are great for learning, a real dashboard on Mainnet-beta needs a private RPC provider to avoid Too Many Requests (429) errors, as public endpoints are heavily throttled.

What’s Next?

I’m still getting my head around Commitment Levels—balancing the speed of a "processed" transaction with the absolute certainty of a finalized one. Next week, we'll probably be diving into Programs and how to write data back to the chain.

If you're also on this journey, don't hold back from connecting!

From OAuth to Ed25519: Why Your Solana Keypair is the Ultimate Dev Identity

Shaun — Mon, 27 Apr 2026 10:49:44 +0000

If you're a Web2 developer, you've spent a significant portion of your career managing identity. You've configured OAuth providers, set up JWT handling, managed users tables in PostgreSQL, and maybe even integrated Auth0 or Firebase.

In every one of those scenarios, identity is a fragmented concept. You are a row in a database owned by someone else. If GitHub decides to flag your account, your identity on that platform ceases to exist. If a service provider's API goes down, your "Log in with..." button is a brick.

On Solana, identity isn't a row in a database---it's a cryptographic primitive. It's not granted; it's generated.

The SSH Analogy: Identity as a Keypair

The easiest way to understand Solana identity is to look at your .ssh folder. When you run ssh-keygen, you generate a public/private key pair.

You put the public key on a server (like GitHub or a remote VPS).

You keep the private key on your machine.

When you want to access that server, you use your private key to sign a challenge, proving you are the holder of that identity.

Solana operates on the exact same logic, but the server is the entire global network. A Solana identity starts with an Ed25519 keypair:

The Private Key: This is your secret. It's your proof of ownership. In Web3, this is the "Root Access" to your digital existence.

The Public Key: This is your address. It's what you share with the world.

When you interact with a program (smart contract) on Solana, you aren't sending a username and password. You are sending a transaction signed by your private key. The network uses your public key to verify that signature mathematically. No database lookup is required.

Public Keys vs. Usernames: The Power of Base58

In Web2, usernames are human-readable strings like dev_guru_99. On Solana, your username is a 32-byte public key, typically encoded in Base58.

You've likely seen addresses like:

14grJpemFaf88c8tiVb77W7TYg2W3ir6pfkKz3YjhhZ5

Why Base58?

It was a deliberate choice to avoid visual ambiguity. By removing characters like 0 (zero), O (capital o), I (capital i), and l (lowercase L), Solana ensures that developers and users are less likely to make manual entry errors.

While a Base58 string isn't as friendly as a handle, it represents something a username never can: Collision-resistant, permissionless uniqueness. You don't have to check if a public key is "taken." The mathematical space is so vast that the odds of two people generating the same keypair are effectively zero.

Sovereignty: Ownership Without Platforms

The biggest shift for a Web2 dev to grasp is the lack of an Admin. In the traditional world, if you lose your password, you hit Forgot Password. An admin or an automated script verifies your email and resets your access. This is only possible because the platform owns the identity and merely grants you access to it.

On Solana, there is no Forgot Password flow. There is no admin panel.

No Intermediaries: If you hold the private key, you own the account.

No Lockouts: A protocol cannot ban your public key from holding tokens or interacting with the state in the same way a platform can ban a user.

This is self-custody. It shifts the responsibility of security from the platform to the individual. For a developer, this is liberating. It means the apps we build don't have to manage user credentials; we simply build interfaces that allow users to sign transactions with the identity they already own.

The Foundation for Everything Else

On-chain identity is the root from which everything else grows. Because this identity is recognized by the entire network, it works across every dApp natively.

Token Ownership: Your tokens aren't in a wallet app; they are associated with your public key on the ledger.

Reputation: Your history of contributions, governance votes, and program interactions is tied to this key, creating a portable, verifiable resume that isn't locked behind a LinkedIn profile.

Transitioning to Solana means moving from granted access to cryptographic ownership. We are moving away from silos and toward a world where your identity is a piece of math that you carry with you across the entire internet.

As we continue through the #100DaysOfSolana, remember: every line of code you ship and every transaction you sign isn't just data---it's an assertion of your sovereign identity on a global state machine.

DEV Community: Shaun