100 Days of Solana — Days 1–4: Keys, Lamports, and My First Browser Wallet

Chus — Mon, 27 Apr 2026 03:04:27 +0000

I've been doing the #100DaysOfSolana challenge and I want to share what the first four days looked like — because the mental shift from Web2 to Web3 hit me harder and faster than I expected.

Day 1 — Generate a Keypair and Get Devnet SOL

I generated my first Solana keypair using the CLI and airdropped free SOL to it on devnet. There was no sign-up form. No email. No password. My entire identity on the network is just 64 bytes — a private key and the public key derived from it. That's it. The blockchain doesn't know who I am.

Day 2 — Create a Wallet and Check Its Balance Programmatically

On this day, I wrote a TypeScript script that loads a saved keypair from disk and fetches its devnet SOL balance using @solana/kit. The balance comes back in lamports, not SOL — and the RPC is just a plain JSON HTTP call. No special SDK magic required if you don't want it. It felt surprisingly close to calling a REST API.

Day 3 — Understand SOL and Lamports

I dug into the unit system — 1 SOL = 1,000,000,000 lamports (like satoshis in Bitcoin or wei in Ethereum). Everything on Solana is paid and measured in lamports internally. Even rent for storing data on-chain is denominated in lamports. The precision exists so micro-transactions are practical without floating-point weirdness.

Day 4 — Connect a Browser Wallet

I built a browser dapp (Vite + React + TypeScript) that detects installed Solana wallets, connects to Phantom with user approval, reads the connected address, and shows the live devnet balance — updated in real time via a WebSocket. The dapp detect any compatible wallet using browser-level interface.

The Concept That Clicked for Me

The whole cryptography model finally made sense across these four days.

In Web2, your identity lives on someone else's server — a username-password pair that a company stores and controls. Lose access to their system, lose your account.

In Solana (and Web3 broadly), your identity is a keypair you generate yourself. The private key never leaves your device. The public key is your address — it's what you share. When you "sign" something, you're using math (Ed25519) to prove you hold the private key without ever revealing it. The network verifies the signature against your public key. No server in between. No account recovery email.

The dapp I built on Day 4 makes this tangible: it calls window.phantom.solana.connect(), Phantom pops up its own approval UI (fully sandboxed), and if you approve, it hands back only your public key. The dapp never sees your private key — not even for a millisecond. That's the guarantee cryptographic signing gives you.

That shift — from trust the server to verify the math — is the real unlock of this whole ecosystem.

Things I'm curious about

how accounts actually store state on-chain beyond just a balance.
rent-exemption and why accounts need a minimum balance to exist.
how transactions are structured and signed.

Identity on Solana: SSH Keys Concept

Chus — Mon, 27 Apr 2026 00:50:52 +0000

If you’ve ever run ssh-keygen to push code to GitHub or access a remote server, you already understand 90% of how identity works on Solana.

In the Web2 world, "identity" is usually something a company lends to you. You have a row in a PostgreSQL database owned by Google or Meta. If they delete that row, your identity vanishes. In the Web3 world—specifically on Solana—identity is something you math into existence.

Here is how we move from "Login with Google" to "Login with Cryptography."

1. The Keypair: Your Global Passport

In Web2, your identity is a Username + Password stored on a centralized server. On Solana, your identity is a Keypair.

A keypair consists of two parts:

The Public Key (Your Address): Think of this like your IBAN (International Bank Account Number) or your email address. You share this with the world so people know where to send SOL or tokens.
The Private Key (Your Signature): This is your "password," but it’s never stored on a server. It stays on your machine (or in your wallet).

When you "log in" to a Solana app, you aren't sending a password to be checked against a database. Instead, you are using your private key to digitally sign a piece of data. The network uses your public key to verify that signature. If the math checks out, you are who you say you are.

N/B: We use a private key to sign transactions (such as sending crypto or messages), while the public key is used to verify those transactions and receive funds.

2. Accounts: The Folders of the Network

On Solana, everything is an Account. If the Solana blockchain is a giant global operating system, accounts are the files.
In Web2, a database might have a users table with columns for balance, username, and profile_pic. On Solana, your public key points to an account on the network that stores:

Lamports: The smallest unit of SOL (named after Leslie Lamport). 1 SOL = 1,000,000,000 lamports.
Owner: The program (smart contract) that is allowed to change the account's data.
Data: A buffer of bytes where information (like your token balances) is stored.

3. Ownership vs. Permission

The biggest "click" moment for a Web2 developer is realizing there is no "Forgot Password" button.

In Web2: You own your account because a company grants you access. They can lock you out or reset your password.
In Web3: You own your account because you hold the private key. Because the network is decentralized, no one—not even the creators of Solana—can "admin" your account.

During my first week diving into Solana, I realized that managing these keys manually is risky. That’s where the "Wallet" comes in. Tools like Phantom (a browser wallet) act as a "Identity Proxy." They hold your private keys securely and provide a UI for you to "Sign" transactions when a web app requests it.

Summary

Identity on Solana isn't a record in a company's database; it’s a cryptographic proof. It’s self-custodied, meaning you are the sole gatekeeper of your digital presence.

If you're coming from a Web2 background, stop thinking about "Accounts" as entries in a table and start thinking about them as cryptographically secured files that only you have the key to edit.

DEV Community: Chus