Forem: Russell Oje

Day 16 of #100DaysOfSolana

Russell Oje — Tue, 05 May 2026 23:14:06 +0000

I just made a transfer to a new Solana account in less than a second.

Week2 Recap of #100DaysOfSolana

Russell Oje — Mon, 04 May 2026 14:14:04 +0000

This week I queried on-chain data, built a dashboard, and mapped traditional databases to Solana's account model. The biggest shift: I don't need a backend. The RPC is the API. The ledger is the database. Wallets are auth. Same address, different networks, same architecture. It finally made sense.

#100DaysOfSolana

Week2 of #100DaysOfSolana: The Account Model

Russell Oje — Mon, 04 May 2026 14:11:03 +0000

By the end of Week 1, I understood identity on Solana. This week was about understanding state.

In traditional Web2 development, I was trained to think in two separate layers: code lives on a server, data lives in a database. They talk to each other through the database queries and middleware. It felt natural because I built that way for years. But Solana doesn't work that way, and this week it finally made sense why.

The Week 2 Journey: From RPC Queries to Account Architecture

Day 8: "Read your first on-chain data"

I wrote a simple script that connected to devnet's RPC and queried a balance. It felt like calling a REST API, just pointing at a different kind of backend.

The key moment: I realized I wasn't querying a database. I was asking the Solana network for the state of an account. That account is not a row in a table somewhere. It's a first-class entity on the ledger itself.

Day 9: "Fetch transactions"

Next, I pulled transaction history for an address. Seeing block times, signatures, and slot numbers make me realize: every state change is a transaction, and every transaction is immutable history on-chain.

For the first time, I understood audit logs at the protocol level. There's no way to delete a transaction. No way to "update" the past. If a balance changed, that change is forever stored on-chain, visible to everyone.

Day 10: "Build a dashboard"

Similar to Day 4 of Week1, I also built a browser app, but this one displays account data. Nothing fancy, just RPC calls in the frontend, rendered on the page.

What clicked: the dashboard talks directly to the network. No backend API needed. No session management. The wallet in the browser is the auth. The RPC endpoint is the database. This is genuinely different.

Day 11: "Compare accounts vs databases"

On this day, I mapped Web2 database concepts to Solana accounts:

Rows → Accounts
Tables → A flat space of accounts identified by public key
Auto-increment IDs → Base58 public keys
Middleware auth → Program ownership rules
Storage costs → Rent-exempt deposits

Seeing the comparison table made it real. The account model isn't just a different API. It's a fundamentally different way to think about data architecture. And like I leaned here, in web3, there's no "join" operation because you organize data differently from the start. You fetch accounts by address, not by filtering queries. And you pay explicitly for storage, which makes you think carefully about what you store.

Day 12: "Compare networks"

Finally, I queried the same address on both devnet and mainnet. Different balances, different transaction histories, same address model.

The insight: the architecture is identical, but the state is independent. Devnet is a sandbox. Mainnet is production. Both follow the same rules. I could deploy the same program to both and it would work. Same address derivation, same account queries, different network validators securing different state.

What Surprised Me

The biggest surprise was realizing I could build a complete on-chain app without writing a backend. In Web2, "no backend" means leaning on a third-party service (Firebase, Supabase, etc.). On Solana, "no backend" means the network is the backend. The RPC is the API. The ledger is the database. Wallets handle identity.

What's Still Confusing

PDAs (Program Derived Addresses) and how they relate to accounts. I saw them mentioned but haven't built with them yet. The concept of accounts owned by programs, and how programs use PDAs to derive deterministic addresses.

Also, the economics of rent. I understand the concept, but I haven't felt the weight of deploying a large program or managing multiple accounts yet. When do rent costs become a serious consideration? When do I need to optimize?

Solana Accounts vs Web2 Databases

Russell Oje — Fri, 01 May 2026 09:43:27 +0000

"Unlike when you are used to building full-stack applications; a Next.js frontend, connected to a Laravel backend, and modeling state in MySQL or PostgreSQL; moving to Solana requires rewiring how you think about data."

I've been exploring blockchain development with Solana, and the biggest hurdle initially is the phrase: "Everything is an account."

solana account $(solana address)

The output of the CLI command above maps out exactly how traditional Web2 database concepts translate to the Solana runtime.

Here is the side-by-side comparison I put together:

The Web2 vs. Solana comparison table

Concept	Web2	Solana
Data Storage	MySQL/PostgreSQL rows or MongoDB docs	A "flat" byte array in an Account
Logic vs. State	Your Laravel/Node code is the logic; the DB is the state	Both are Accounts; logic is just an account with `executable: true`
Primary Keys	Auto-increment IDs or UUIDs (e.g., `user_id: 101`)	Base58 Public Keys (32 bytes) or PDAs
Security/Auth	Middleware checks (e.g., `$request->user()`)	The Runtime checks: only the "Owner" program can write
Filtering/Joins	`SELECT * FROM table WHERE...` (Server-side)	No Joins. You fetch the account by address or filter off-chain via RPC
Infrastructure	AWS/DigitalOcean monthly bills	"Rent": A lamport deposit you get back when you `close()` the account
Deployment	CI/CD pushes code to a server	Deploying a Program creates an account owned by the BPF Loader

The Biggest Takeaway

In a traditional setup, you deploy your code to a server, and that code orchestrates database transactions. On Solana, both your application logic (programs) and your user data live as accounts in the exact same global space.

There are no native queries, no joins, and no backend middleware guarding your tables. You pay upfront for the bytes you store via rent, and the runtime itself physically blocks unauthorized writes. Your database instincts around data modeling still matter, but the architectural execution is completely flipped.

#100DaysOfSolana

Week1 Recap of #100DaysOfSolana

Russell Oje — Mon, 27 Apr 2026 09:49:04 +0000

This week I generated my first Solana keypair, persisted it, and connected a browser wallet to read my devnet balance in a small app. What surprised me most was realizing my identity is not a username in someone’s database; it is a keypair I control.

Next I hope to turn this into real on-chain interactions and ship something people can use.

#100DaysOfSolana

Week1 of #100DaysOfSolana

Russell Oje — Mon, 27 Apr 2026 09:37:29 +0000

On Day 1 of this challenge, I thought I was doing something small: generate a wallet, print an address, move on.

I ran a script, got a fresh keypair, and saw a long string appear in my terminal. It looked random and slightly intimidating, but also familiar in the same way SSH keys feel familiar. In Web2, I have dozens of identities: GitHub username, work email, banking login, social accounts. Every system has its own account model, its own password reset flow, and its own lockout rules.

Solana felt different immediately. That one keypair was not just an account for one app. It was the beginning of identity across an entire network.

## The Week 1 Journey

### Day 1: "Here is your wallet"

The first script generated a keypair and printed the public key. The idea seemed simple:

Public key = safe to share
Private key = proof of ownership

At this stage, it still felt like setup boilerplate.

### Day 2: "Make it persistent"

Then I built a script that loads an existing wallet from wallet.json or creates one if missing. That changed the feeling.

In Web2, identity is often a row in a database controlled by a platform. In this script, identity became something I could hold, persist, and re-use without asking anyone for permission. I also started to understand responsibility: if I lose this private key, there is no "Forgot Password" link.

### Day 3: SOL vs lamports

I set up the CLI wallet and looked at balances both in SOL and in lamports. One SOL equals one billion lamports. Seeing balances in the smallest unit made Solana feel less abstract. It reminded me of cents in payments systems, except enforced by protocol rules instead of application code conventions.

### Day 4: Browser wallet connection

This was the turning point. I built a Vite page, discovered installed wallets with Wallet Standard, connected Phantom, and fetched balance from RPC.

In Web2 terms, this is what stood out: the app did not "create" my identity. The wallet presented an account, and the app read state from the network. The identity lived outside the app. If I switch apps, I keep the same on-chain identity because it is tied to my keypair, not that product's user table.

### Day 5: Compare wallet types

After trying CLI, browser, and mobile wallets, I saw a practical tradeoff:

CLI: Fastest for scripts; least secure (plaintext file).

Browser: Best for dApps; medium security (password/encryption).
Mobile: Best for personal use; highest hot-wallet security (biometrics).

Different interfaces, same underlying identity model.