DEV Community: Russell Oje

#100DaysOfSolana Week4 Recap

Russell Oje — Sun, 17 May 2026 21:57:29 +0000

I opened my devnet account in Solana Explorer today and it clicked how much the explorer reveals: balance, owner, executable flag, and full transaction history in one view. I like Solana Explorer for this clarity.

#100DaysOfSolana

Week4 of #100DaysOfSolana: Solana's Account Model

Russell Oje — Sun, 17 May 2026 21:47:11 +0000

If you come from Web2, Solana's account model can feel strange at first. The first time I inspected an account with the CLI, I saw fields like lamports, owner, and data all sitting together and thought, "Wait, where is the smart contract state stored?"

That question is the whole lesson. On Solana, everything is an account. Wallets are accounts. Program code lives in accounts. Application state lives in accounts. There is no separate world of contract accounts versus externally owned accounts like you may have seen elsewhere. Solana uses one flat key-value store where the key is a 32-byte address and the value is the account itself.

That design clicked for me when I started thinking about accounts like files in a filesystem. Each file has metadata, contents, and permissions. Solana accounts work the same way:

the address is the filename
the owner is the program allowed to manage it
the data is the file contents
the balance is the lamports stored alongside it
the executable flag tells you whether the file is runnable code or just data

That analogy is not perfect, but it gets you close fast. The System Program is like the operating system kernel. It creates accounts, assigns ownership, and handles basic bookkeeping. Other programs then read and write the accounts they own.

Every Solana account has the same five fields:

lamports - the balance stored in the account. One SOL equals 1 billion lamports.
data - a byte array that can hold arbitrary state.
owner - the program that controls the account.
executable - whether the account contains runnable program code.
rent_epoch - a legacy field that is now effectively retired and set to the maximum value.

The most important rule is ownership. Only the owner program can modify an account's data or debit its lamports. That means a token program can update token accounts it owns, but nobody else can casually rewrite those bytes. At the same time, anyone can credit lamports to a writable account. That combination is simple, but it creates a very clear security model.

What surprised me most was the statelessness of programs. In Web2 terms, a program is not a server that keeps its own memory forever. It is more like a web server binary that reads from and writes to a database. The executable account stores the code, and separate data accounts store the application state. That separation is why the account model matters so much: if you understand who owns the account and what data it contains, you understand how the program behaves.

Here is the kind of output I kept seeing while exploring accounts:

Each field tells a story. A zero-length data field means the account is just holding value. The owner 11111111111111111111111111111111 is the System Program. executable: false means this is not a program account. And the huge rentEpoch value is a clue that rent exemption has taken over the old rent schedule.

Rent exemption is another detail that makes Solana feel different from a traditional backend. Every account must hold a minimum lamport balance proportional to its data size if it wants to stay on-chain. If the account drops below that threshold, it risks being purged over time. For a tiny basic account, the minimum is around 0.00089 SOL, though the exact value depends on the account size. You can check it with solana rent or the getMinimumBalanceForRentExemption RPC method.

That idea matters because it forces you to think about storage costs up front. If you create a larger state account, you need to fund it accordingly. In Web2, disk space is usually someone else's problem. On Solana, the cost of storage is part of the design.

The account model also explains why Solana feels so composable. Programs do not hide their state inside private memory. They operate on explicit accounts that can be inspected, passed around, and reasoned about independently. Once I stopped thinking in terms of "a contract with internal state" and started thinking in terms of "a program that manages files," the architecture made much more sense.

If you are a Web2 developer, that is the mental model I would keep: Solana is a filesystem for programmable state. Accounts are the files. Programs are the executables. The System Program is the kernel. And ownership is the permission system that keeps everything safe.

That framing turned Solana from something mysterious into something structured. The account model is not just an implementation detail. It is the core abstraction that makes the rest of Solana understandable.

Recap of Week3

Russell Oje — Thu, 14 May 2026 10:55:19 +0000

This week I built my some Solana tools: a CLI transfer app and a confirmation UI, and I deep-dived into transaction anatomy: signatures, blockhashes, and atomicity.

I broke transactions to understand failure. Now I can send SOL, verify it on-chain, and explain exactly what's happening at every step.

#100DaysOfSolana

Week3 of #100DaysOfSolana: Understanding Solana Transactions

Russell Oje — Thu, 14 May 2026 10:49:35 +0000

By the end of Week 2, I understood how data lives on accounts, public keys, and the absence of a backend. This week was about understanding change: how transactions work, how to build them, and what happens when they fail.

The turning point: transactions aren't requests to a server. They're cryptographically signed messages that prove you own the keypair and authorize a specific state change. And if they fail, the whole thing rolls back (even though you still pay the fee :)).

The Week 3 Journey

Day 15: Understand transaction anatomy

I started by taking apart an actual transaction on devnet. I sent a small transfer and then inspected it:

Pulled the transaction signature from the terminal
Ran solana confirm -v SIGNATURE to see the raw structure
Opened the same transaction in Solana Explorer and compared the two views.

What I discovered: a transaction has exactly five parts:

Part	What it means	Web2 analogy
Signatures	64-byte Ed25519 signatures proving you own the keypair	Auth token
Header	Three bytes describing how many signers and read-only accounts	HTTP headers
Account Keys	Every account the transaction may touch, in order	Paths / query params
Recent Blockhash	A recent block hash that expires in ~60-90 seconds	CSRF token with expiry
Instructions	The actual program calls with program ID, accounts, and data	Request body

The constraint clicked immediately: a serialized transaction must fit within 1,232 bytes. That's the maximum. And if any instruction fails, the whole transaction rolls back atomically (and like I stated before, you will still pay the fee).

In Web2, I'm used to stateless request/response. This is different. A transaction is atomic, expiring, and size-limited. Those aren't bugs; they're features that make on-chain state changes safe and deterministic.

Day 16: Send your first SOL transfer

Next, I built the practical skill: actually sending SOL on devnet.

The steps felt straightforward:

Set the CLI to devnet: solana config set -ud
Airdrop 2 SOL (devnet only)
Create a recipient keypair
Send 0.5 SOL: solana transfer RECIPIENT_PUBKEY 0.5 --allow-unfunded-recipient
Verify both balances changed on-chain

Day 17: Build a transfer tool

Then I wrote a reusable CLI tool that accepts a recipient and amount. This wasn't just wrapping the CLI command. The tool worked. I could send SOL with three lines of code. But the real insight was seeing the transaction signature in the output. That signature is both the receipt and the transaction's unique ID. I can search it on Solana Explorer forever.

Day 18: Add transaction confirmation UI

On this day, I added a confirmation layer to transaction implementation:

This added complexity, but it taught me something crucial: transactions are asynchronous. You send it, you get a signature immediately, but the transaction isn't confirmed until validators include it in a block. That can take seconds or fail entirely if the blockhash is too old.

Day 19: Explore failed transactions

Finally, I broke transactions on purpose to understand failure modes.

I forced invalid scenarios:

Sending more SOL than I had
Sending to invalid addresses

Each failure gave me a different error message on-chain:

InsufficientFunds — clear and expected
Invalid address formats — caught during construction before sending

What Clicked for Me

Transactions as cryptographic proof: In Web2, a request is just data sent to a trusted server. On Solana, a transaction is a cryptographically signed message that proves I authorized it and that it hasn't been tampered with. That's a fundamentally more trustless model.
Also, confirmation is different from sending: The signature appears immediately, but confirmation requires validators to include the transaction in a block. Polling for confirmation taught me that devnet sometimes takes a few seconds, and mainnet is even less predictable. I can't assume a transaction is final just because I have the signature.

What about you? Have you built with Solana transactions yet? What surprised you most about how they work? Drop a comment below.

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.